When customizing a standard configuration for the needs of a specific user, think about future updates. The configuration support feature available in 1C:Enterprise greatly simplifies the update process, but if you introduce significant changes to the vendor configuration, integration of the updates that come with the new version of the vendor configuration to the customized configuration requires manual work.
The recommendations listed in this article are based on the analysis of various update scenarios, and they help to simplify the update procedure. Some of the recommendations are explained in detail in other articles, while this list provides a summary.
- We recommend that you do not disable object support. Set the "Changes allowed w/o breaking support" rule instead. Disabling support only makes sense if you are planning to continue the object development yourself, or if you want to delete the object.
- We recommend that you do not delete vendor objects even if you are not planning to use them in your business logic. The vendor configuration algorithms might use these objects for internal purposes and deleting them might impact the logical integrity of your configuration.
- Order of metadata objects. When you merge configurations with significantly different metadata object trees with the "Order from vendor configuration" rule, preserving the order of metadata objects is not guaranteed. If that order is significant, after the update merge your configuration with the vendor configuration using the support options dialog box. This restores the metadata object order.
- Object mapping. During the update you can map customer objects to new objects of the vendor configuration. But pay special attention to this procedure because you cannot change that mapping in the future.
- Adding subordinate objects. If you need to add an attribute, form, or template to an object (for example, to a catalog), this does not imply disabling support for the catalog. The support feature includes preserving the added attributes. But remember that adding subordinate objects is not always that easy. For example, adding a dimension to a register introduces a significant change to its functionality.
- Updating a configuration that is subject to shared development. We recommend that you lock all of the configuration objects before the update. Objects that are not locked are not updated. Locking the root object is necessary for the update.
- Editing a configuration while specifying update settings. We recommend that you do not use this option. First, updating the comparison result after you edit the configuration will take time. Second, if the editing includes adding a new object that requires update, the platform does not set default update rules for this object. If editing the configuration is absolutely necessary, once you finish the editing, close the configuration comparison window and run the configuration update command again. Unlike pressing the Refresh button, this operation ensures that all of the object update rules are set.
- We recommend that you do not rename metadata objects, procedures, or functions without a good reason. Remember that a name used in a module to access a certain object might be generated dynamically and finding all the instances of that name might be a complex task. Moreover, changing a large number of modules makes subsequent updates more complex.
- Localization of module texts. We recommend that you edit the NStr() function parameters using the Edit interface texts tool, instead of making corrections directly in the modules. When you edit strings directly in the NStr() function, you might encounter some complex templates that represent special characters, so it is better to leave the template updates to the platform.
- Merging complex properties. Remember that merging complex properties, such as forms, templates, or interfaces, with an "Update prioritizing..." rule is a complex process and always requires manual checks. We recommend that you use the tools that provide visual reports on the differences in complex properties. Sometimes it makes sense to avoid the update and make manual corrections to a vendor form instead.
- Editing common modules. When you develop custom universal procedures, we recommend that you store them in new modules rather than in vendor modules. If you need to include them in vendor modules, remember that you can specify individual update rules for each procedure.
- Same as with module modification, we recommend that you add new procedures and functions instead of editing existing ones. If you cannot do it (for example, you need to edit an event handler), declare a new procedure to host the new script and then add the procedure call to the handler.
- Analysis of changes made by the vendor. While the comparison report provides detailed information about the changes, its analysis can take a lot of time. We recommend that you read the patch notes, this will help you select the optimal update strategy for specific objects.
- Do not update objects by copying and pasting them. This impacts the configuration support and this also can affect the logical integrity of your configuration and cause data losses.
- Read other knowledgebase articles related to configuration delivery and updates. Understanding the delivery and update principles streamlines your configuration development.