This article describes the standards that apply to defined types. All of the listed recommendations are mandatory unless noted otherwise.
1. Defined types are intended for defining data types that describe frequently used entities or have high chances to be modified during the applied solution deployment. You can use the type or the set of types described by a defined type in multiple configuration parts (in attributes, object properties, forms, and so on).
See also the "Defined types" section of the "Configuration objects" chapter of 1C:Enterprise Developer Guide.
2. We recommend that you use defined types in the following scenarios:
2.1. Defining a simple type and its qualifiers when the type describes an applied entity and is used in various attributes, resources, form attributes, templates, and so on within a single subsystem or in the entire applied solution. This guarantees uniform data length and precision in all data usage instances, as well as simplifies development in the event of requirement changes.
- EAN13. String, 13. Describes the barcode format in various documents: Shipment, GoodsReceipt, SalesInvoice, Bill, and more.
- ZIP code. String, length: 5. The ZIP code that is used in the GoodsReceipt and WarehouseTransfer documents, in the SalesHelper data processor, in the ReturnAddress attribute of the GoodsReturn document, and more.
2.2. Defining a composite type that is widely used in objects of a single subsystem or in the entire applied solution. This guarantees uniform data content (type) in all data usage instances, as well as simplifies development and deployment.
For example, the configuration includes the Interactions subsystem, which is intended for processing email and recording calls and meetings. During the deployment of the subsystem the developer determines the metadata object types that can serve as contacts: items of the Individuals, Partners, and PartnerContacts catalogs. Then the developer creates the InteractionContact defined type, which includes all these types and belongs to the subsystem. This defined type is widely used in the attributes of objects and forms included in the subsystem: the Attendees tabular section of the Meeting and PlannedInteraction documents, the To tabular section of the TextMessage document, the Caller attribute of the Call document, the ContactsByCategory attribute of the AddressBook and ContactSelection common forms, the InteractionHierarchyContact template parameter of the Interactions document journal, and more. If the InteractionContact defined type had not been created, this would require disabling support for all of the listed objects and correcting the type content manually in each object.
2.3. In the development of a subsystem that is intended for building into a configuration: defining a type that can be redefined at the deployment stage.
For example, the Vendors type might be changed to the Counterparties type during the deployment.
3. Do not use defined types for creating "aliases" of available types, for substitution of entities, for a single usage in a single subsystem or configuration that is not intended for building into other configurations, despite the fact that it might simplify future development. In fact, the need to do any of these usually indicates that the applied solution has design errors or the initial type name is methodologically incorrect.
For example, a configuration includes the Counterparty catalog that is referenced from several information registers, form attributes, and other configuration objects. But the catalog is not a part of a subsystem intended for building into other configurations, nor it is an applied entity that can be expanded with other types. In this scenario you do not need an additional composite defined type that consists of the single Counterparties type "just in case" of possible future optimizations because this obscures the applied meaning of the entity.
Next page: Using functional options