The Sage 500 custom field values are normalized in the base entity or document table you have chosen to configure. In practical terms, given your example, this means that a custom field value configured for a customer is stored in the tarCustomer table with a prefix of UserFldx. The number of custom fields available in native Sage features is specifically limited by the number of these user fields present in the base table. To view these values in a report you need to add the UserFldx field that represents the custom field data to the body or header. If you have already added the base table to your report, the custom field should already be included in the field collection. It may or may not be available with native Sage reports, but it generally is referenced as some variation of UserField, CustUserField or similar when it is available.

The fields are sequential, so the one that appears at the top in Set Up AR Options is UserFld1, while the second is UserFld2, etc. The value stored in the table does not represent the metadata, restrictions or validations you have configured for the custom field, which are indicated and enforced in the application code. This data is stored in the tciUserField, tciUserFieldUsed and tciUserFieldValue tables and while there is some translation that is needed for input, as well as to normalize the output, the metadata can be obtained using the spciGetUserFieldValues stored procedure (relationships and column metadata are also detailed in the Schema Browser). 

The following example returns the metadata from SOA demo data for user field 1 associated with a customer (entities defined in tciEntity):

EXECUTE [dbo].[spciGetUserFieldValues]
@_iCompanyID = 'SOA',
@_iUserFldNo = 1,
@_iEntityType = 501;

A tip on custom reports is to avoid creating these by directly referencing schema because the Crystal report engine prefers to lock the data it references, and it may pull all data into the report before it applies a filter or groups the data for aggregate operations. Although you can avoid some of that with report settings and configuration, creating a view, stored procedure or function to properly handle the data translation, joins and aggregations is typically a better choice. If you create a report by directly referencing schema, you also must perform your own metadata translations, so you might want to review the many customer-centric views like vdvCustomer (the BIE customer view) to begin an optimized build of your own. 

The Sage 500 custom field values are normalized in the base entity or document table you have chosen to configure. In practical terms, given your example, this means that a custom field value configured for a customer is stored in the tarCustomer table with a prefix of UserFldx. The number of custom fields available in native Sage features is specifically limited by the number of these user fields present in the base table. To view these values in a report you need to add the UserFldx field that represents the custom field data to the body or header. If you have already added the base table to your report, the custom field should already be included in the field collection. It may or may not be available with native Sage reports, but it generally is referenced as some variation of UserField, CustUserField or similar when it is available.

The fields are sequential, so the one that appears at the top in Set Up AR Options is UserFld1, while the second is UserFld2, etc. The value stored in the table does not represent the metadata, restrictions or validations you have configured for the custom field, which are indicated and enforced in the application code. This data is stored in the tciUserField, tciUserFieldUsed and tciUserFieldValue tables and while there is some translation that is needed for input, as well as to normalize the output, the metadata can be obtained using the spciGetUserFieldValues stored procedure (relationships and column metadata are also detailed in the Schema Browser). 

The following example returns the metadata from SOA demo data for user field 1 associated with a customer (entities defined in tciEntity):

EXECUTE [dbo].[spciGetUserFieldValues]
@_iCompanyID = 'SOA',
@_iUserFldNo = 1,
@_iEntityType = 501;

A tip on custom reports is to avoid creating these by directly referencing schema because the Crystal report engine prefers to lock the data it references, and it may pull all data into the report before it applies a filter or groups the data for aggregate operations. Although you can avoid some of that with report settings and configuration, creating a view, stored procedure or function to properly handle the data translation, joins and aggregations is typically a better choice. If you create a report by directly referencing schema, you also must perform your own metadata translations, so you might want to review the many customer-centric views like vdvCustomer (the BIE customer view) to begin an optimized build of your own.