Scope: managed applications, ordinary applications.
1. You can use user-defined types for defining data types, which describe frequently used entities or might be changed upon the application implementation. They allow you to use a described type or a type set multiple times without specifying the content in various configuration places (in attributes, object properties, forms, and other).
2. We recommend that you use user-defined types in the following cases:
2.1. To define a simple type and its classifiers, which has a purpose and is used in various attributes, resources, templates within a subsystem or in the whole application. It guarantees the same length, data accuracy in all usage locations, simplifies customization if requirements are changed.
For example:
- ProformaInvoiceNumber - String, length 30. Regulates the format of a proforma invoice number in various documents: GoodsAndServicesReceipt, PurchaseLedgerRecord, GoodsReturnFromCustomer, and other.
- DeliveryAddress - String, 500. Text presentation of a delivery address in the PurchaseOrder, CarrierDeliveryAddress documents, the SalesWizard data processor, in the CarrierDeliveryAddress attribute of the GoodsReturnRequestFromClient document, and other.
2.2. To define a composite type, which is widely used in objects of a subsystem or in the whole application. The user-defined type guarantees the same content (type) of data in all usage locations and simplifies customization and integration of subsystems into configurations.
For example, the Interactions subsystem is integrated into the configuration. The subsystem is used for email correspondence, registration of calls and meetings. When integrating this subsystem, the developer chose metadata objects acting as interaction contacts - items of the Individuals, Partners, PartnersContactPersons catalogs, and set this type set in the InteractionsContact user-defined type provided in the subsystem. The user-defined type is widely used in object attributes and subsystem forms (in the Meeting, ScheduledInteraction documents - the Participants tabular sections, in the SMSMessage document – the Addressees tabular section, in the PhoneCalldocument - the SubcriberContact attribute, in the AddressBook, SelectContactPerson common forms – the ContactsBySubject, attributes in the InteractionsHierarchyContact template parameter of the Interactions document journal, and other). Otherwise, if the InteractionsContact user-defined type is not used, you will need to no longer support the subsystem objects and set the required set of types in all the mentioned locations.
2.3. When developing a subsystem to be integrated, to override an applied type, which will be specified upon integration.
For example, the Suppliers subsystem type can be replaced with the Counterparties applied configuration type upon integration.
3. Do not use the user-defined type for setting synonyms for existing types, replacing entities, local usage within one subsystem (configuration) without necessity of integration into other configurations. As a rule, it indicates a design error or an incorrect original type name.
For example, there is the Counterparties catalog in the configuration. The catalog references are available in several information registers, form attributes, and other configuration objects. The catalog is not a part of the subsystem being integrated or an applied entity, which can be extended by other types. It is incorrect to create an additional user-defined composite type, which consists of a single Counterparties type, just to simplify possible configuration changes in the future. It negatively affects the entity purpose.