Answer:
User defined fields are custom fields created by the user that may apply to segment codes, vendors, customers, purchase orders, transaction documents or transaction lines.
These user-defined fields (UDFs), created through Organization > Set Up User Defined Fields, can be included as part of the import process when necessary.
When importing UDF data, the field attributes defined by the user during the creation of the UDF, will determine the editing of the definition file used in the import process. These attributes also have a bearing on the data file requirements. This is consistent with other types of data imports.
It is important to review the UDF setup information carefully before attempting the import of records containing UDF data.
The following are some FAQ’s and other points to keep in mind when preparing to import data which includes UDF values:
Question
Is importing UDF information any different than other system fields related to the same record?
Answer
No, however, the customer’s ability to add, delete, or modify UDF’s at any time may complicate new or existing import processes.
Question
How do I identify the FieldID for a newly created UDF?
Answer
To determine the FieldID, print a User Defined Field List report Reports > Lists > User Defined Fields, select the report called <User Defined Fields>. Include “Field ID/Context ID” in the report body.
Print the report to screen.
The format should appear in the Definition file exactly as it shows in the report including punctuation. For example: The context ID for the import of the “Location” for transactions to be imported reads “Transaction Lines:Transaction Lines:Location”.
Question
How do I indicate a UDF in my DEF file?
Answer
To import UDF data, the UDF must be added to the customer’s definition file.
Add the FieldID to the appropriate section of your DEF file and indicate the location of the data in the text file like you would any other field you were importing. Note: The context section of the definition file contains the [Context Type]_[Field Name] (referred to as the FieldID) of each field that will be imported into the application.
The context section of the definition file contains the [Context Type]_[Field Name] (referred to as the Field ID) of each field to be imported into the system. The Master Definition files, installed with the system, contain the Field IDs for all system defined fields. UDF Field IDs are not included in the Master Definition files. To import UDF data, the UDF Field ID must be added to your definition file. Here is a sample DEF file with the UDF in the transaction line information. The label Transaction Line comes from the UDF setup. The UDF is a Transaction Line type. The Location is the name given to the UDF. By running the UDF List Report, the Context ID column, will tell you exactly what the name should be in your DEF file.
Additional Information:
A UDF with a field type of number can have up to, but not more than 5 decimal places. The setup parameters of the field will determine the number of decimals.
Decimal indicators only work with UDFs of the field type “Currency” and not with field type “Number”.
UDFs with a number or currency field type will always default to 0.00 value if no value exists in the data file. No blanks are allowed for these field types.
UDFs cannot be independently imported.
UDFs follow the same rules as other fields you might import that have the same data type. For instance, a Date UDF will have the same DEF file rules as an Effective Date field that would be imported with a transaction. The DEF file entry would be, ‘Transaction Lines:Transaction Lines:EntryDate, columnnumber,,MM/DD/YYYY’ and your data file would need to reference a date.
If USEDISTCODE is used on the DEF file, UDFs will not import.
Header records and detail records have identifiers. For example, when you import vendors there is the header identifier (HVEND) and the detail identifier (DVEND). When you import new Vendor ID header records (with or without detail records), any Vendor ID beginning with “D” will not import because the import process thinks it is a detail record, such as (Default Vendor, A, Default Vendor). In this case, since there is no matching header, the record is not imported. In order to tell the import process there is no detail record, the first field in the record must be the applicable header identifier (HVEND, Default Vendor, A, Default Vendor).