Best Practices for Extended Data Types
The basic rules for using extended data types are as follows:
-
Use an extended data type wherever possible.
-
Create an extended data type for each atomic entity in the situation that your application is modeling.
-
The hierarchies you create among the extended data types should be able to pass the "is-a" test (except for the super-grouping types and the mixed field types described later in this topic). That is, an extended data type should be a "member" of the parent extended data type concept. For example, SuppItemId "is-a" ItemId, but SuppItemId is not a ClassName.
-
Only create subtypes when they are needed. If you want to add a field to a table or to a dialog, do not choose a type that is too general, and just add texts for label and help locally. Instead, create the type from the beginning and reuse it everywhere else.
-
Use extended data types for setting up relations between two tables by using RecId.
-
Do not directly use the system data types recID or tableID.
Use the extended data type RefRecId for types that refer to record IDs, and RefTableID for types that refer to table IDs, or types derived from these.
For more information, see Best Practices for Extended Data Type Properties
Extended data types like SysGroup and Description are used for defining a uniform user interface in the standard application. All group table identifiers and names are initially set up with the same width. Specialized extensions should be created for each usage.
These super-grouping types can be used for setting the length and so on for all the fields that use their subtypes, but the intention is that they must not be counted on as compatible.
The specialized subtypes can be disintegrated from their super-grouping types at the site of the implementation. This allows for customized settings of each actual type.
The super-grouping types should not be used from X++ code and in fields because their subtypes can be disintegrated. They must only be used as super types.
Sometimes it is necessary to use one field to hold foreign keys to different tables that have keys defined with completely different extended data types. In such cases, you must make sure that the field of the foreign key can hold all possible values of all possible keys that are potentially going to be stored in it. When you have a key for a string field, ensure that the foreign key is at least as wide as the widest key that can potentially be held in it.
Such foreign key fields will always be supported by an Enum type field that is used to decide what kind of key is going to be stored in the field and used in the relation setup as "This fixed" to support the validation of the field contents and so on.
Following are examples:
-
\Data Dictionary\Tables\PriceDiscAdmTrans\Fields\ItemRelation (supported by ItemCode)
-
\Data Dictionary\Tables\PriceDiscAdmTrans\Fields\AccountRelation (supported by AccountCode)
-
\Data Dictionary\Tables\LedgerJournalTrans\Fields\AccountNum (supported by AccountType)
The configuration key specified for the extended data type in a relation must be the same key, or in the same tree of keys, as the key used for the related field. If the external field in a relationship can be removed, due to configuration key settings, and the extended data type on which the relation is set is not also removed, a best practices warning occurs.