This article describes standards that apply to rename metadata objects. All of the listed recommendations are mandatory unless noted otherwise.
1. Renaming a common module and then creating another module with its old name is not allowed. Instead, create a module with a new name and move the script from the old module to the new one.
If you do not follow this recommendation, you might encounter configuration comparison and merging issues. For example, event subscriptions that refer to a common module will be linked by name to the new common module (which does not contain the required procedures) instead of the renamed one.
2. In some scenarios, when you change the metadata structure, you might want to delete a metadata object and create a new one with the same name. An example of such scenario is reducing the number of register dimensions. We recommend that you rename the obsolete metadata object by adding the Delete prefix.
If you do not follow this recommendation, this might cause some issues during the update of a supported configuration. If the obsolete object was changed in the customer configuration without canceling the support (for example, they redefined the object behavior or fixed some bugs), the obsolete object is not deleted during the configuration merging and the update cannot be successfully completed because two objects have identical names.
This recommendation is optional
3. If you need to store references to metadata objects in your configuration, we recommend the following:
3.1. If your configuration does not use 1C:Subsystems Library, use string attributes (String, 255) for storing full metadata object names. For example, the DocumentGenerationParameterTypeFullName attribute of the MessageTemplates catalog, the ObjectType dimension of the ObjectPrintSettings information register, and so on.
If you rename or delete some configuration objects, ensure that the stored names are renamed or deleted during the Infobase update. Otherwise, you will have broken links to metadata objects, which will lead to various issues within subsystems that rely on metadata object names.
3.2. If your configuration uses 1C:Subsystems Library, use references to the MetadataObjectIDs catalog, which:
The only exception is the renaming of roles and subsystems, which is not handled automatically, so you have to handle this manually.
If you do not describe the renaming rules, this will result in broken links in the MetadataObjectIDs catalog (old catalog items will be marked for deletion and new ones created), which will lead to various issues within subsystems that rely on metadata object names stored in the catalog, for example:
3.3. The MetadataObjectIDs catalog is not intended for storing references to metadata objects belonging to other configurations (for example, they might appear if you are implementing integration with other systems). Instead, use string attributes and implement algorithms for keeping their values up-to-date.
3.4. If several configuration branches are in development (for example, you are simultaneously developing versions 2.0 and 3.0, or you are developing patches together with the new releases), consider the following: renaming an object an then creating a new object with the same name, as well as double renaming, is not allowed in the current configuration version and earlier versions. You can only rename objects in this manner in the latest version (3.0 in this example).
Otherwise during the upgrade from an earlier version to the latest one such objects will be renamed twice, which breaks the links to the metadata objects.
If you use references to the MetadataObjectIDs catalog of 1C:Subsystems Library, this restriction only applies to roles and subsystems.
Next page: Shared configuration development workflow