Configuration delivery and support

Configuration delivery and support concept
Delivery settings and generation of distribution and update files
Module merging specifics
Specifying support options
Configurations based on several supported vendor configurations
Specifics of comparing and merging configurations during the update
Recommendations for customizing vendor configurations
Creating distribution and update files

Configuration delivery and support concept

Purpose

Let us consider a typical scenario: a vendor releases a standard configuration. A customer buys the confuguration and customizes it for their needs. Then a vendor releases a new version and the customer wants to integrate their customizations with the vendor changes. Manual integration would be very time-consuming because it requires creating a list of changes and then replicating them to the latest configuration version. Replicating the vendor changes to the customer configuration is also inefficient. The configuration delivery and support feature mostly automates this process, leaving some of the decisions to the customer.

Generic update scenario

The following table summarizes the update options available for each metadata object.

	Customer	Vendor	Update rule
1	Changed	Unchanged	Get from customer configuration
2	Changed	Changed	?
3	Unchanged	Unchanged	Get from customer configuration
4	Unchanged	Changed	Get from vendor configuration

Note that scenarios 1, 3, and 4 seldom require modifications of their update rules. Scenario 2 is more complicated because automatic rule selection makes no sense, but the platform can find all of the changed object properties, leaving the final choice of the update rule to the customer.

Update scenario implementation in 1C:Enterprise

Generic concepts

In 1C:Enterprise any configuration can be based on one or several supported vendor configurations. You can use a configuration created using the Configuration - Distribute configuration - Create distribution package and configuration update file command as a vendor configuration. This command creates a .cf configuration file. Note that files created using the Configuration - Save configuration to file command cannot be used as vendor configurations. To convert a vendor configuration to an infobase file (.1cd) or an infobase dump file (.dt), load the .cf file created as described above to your infobase (which can be empty) using the following command: Configuration - Load configuration from file. Then you can use the standard platform tools to create a .dt file.

There are two ways to add vendor support to your configuration:

Start with a configuration created as described above and customize it whenever you need. Your custom configuration will be based on the supported vendor configuration. Alternatively, you can use the following commands: Configuration - Load configuration from file and Administration - Restore infobase.
Start with a customized configuration and run the Configuration - Compare and merge with configuration from file command. Select a vendor configuration for comparison, and if your configuration is not yet based on this vendor configuration, you are prompted to add vendor support.

Two support modes are available:

The original vendor configuration is never changed. This mode is only available for the first method of adding support, and new vendor configurations have this mode by default. Changes of configuration objects are not allowed and new objects cannot be added to the configuration.
The configuration is supported and configuration changes are allowed. To switch to this mode, open the support settings using the Configuration - Support - Support options command and click the Enable modification button.

You can update your configuration using files of the new version of the vendor configuration, or using .cfu configuration update files. You can update any configuration version using .cf files (including downgrade to an earlier version). During the creation of an update file, a vendor specifies configuration versions that can be updated using this file. Configuration versions that are not specified explicitly, both earlier and later ones, cannot be updated with .cfu files because update files only include the differences between specific configuration versions.

Example:

If the latest configuration version is 4 and the update is created for version 2, you cannot use it to update version 1 and version 3. This limitation is necessary for correct processing of changes that negate each other. If a vendor increased the length of a string attribute in version 3 and reverted to the original length in version 4, this change is not included in the update from version 2 to version 4 because the string length is the same in both versions. If this update file is applied to version 3, the string length will not be reverted, which is incorrect.

Configuration update files have small size because they only store the changes and because they use data compression. They are optimized for downloading through low-bandwidth channels but they provide less update flexibilty than .cf files. The rest of the update process is identical for both .cfu and .cf files.

Figure 1. Interaction between customer and vendor configurations

Updating configurations

If a customer configuration includes a supported configuration with no customization allowed, the update is a strict and fully automated process. The user runs the Configuration - Support - Update configuration command and confirms the update, and then the configuration is updated.

If a customer switched the configuration to the mode where changes are allowed, the configuration is updated using the standard configuration comparison and merging feature, which in this case provides additional functionality: three configurations are involved. These include the customer configuration, the previous vendor configuration (which is stored in the customer configuration) and the new vendor configuration. 1C:Enterprise analyzes the changes automatically and assigns the update rules according to Table 1. If a property was changed by both vendor and customer (scenario 2 in Table 1), 1C:Enterprise cannot determine the update rule and leaves the decision to the customer. Such properties are marked in bold. You can select the Show only properties that were changed twice check box to view only the properties that requre manual selection of update rules. After the merging, the vendor confuguration stored in the customer configuration is updated to the new version.

Modification of update algorithm using support rules

The customer can modify the update algorithm by setting support rules for each metadata object. They might need it if they want to make all further object modifications themselves and they are no longer interested in new object versions provided by the vendor. In particular, this scenario can be used if they want to delete the object from their configuration. Three metadata object support rules are available:

Vendor object changes not allowed. The vendor object cannot be customized. The main purpose of this rule is described below but you can also use it to prevent accidental object changes. During the update, objects having this rule are replaced with their new versions from the vendor configuration.
Vendor object changes allowed w/o breaking support. It is the default rule. It utilizes the update algorithm described above.
Support cancelled for vendor object. The object is never updated. If you want to delete an object, you have to set this support rule first.

The following table extends Table 1 with metadata object support rules.

Table 2. Default update rules.

	Customer	Vendor	Support rule	Update rule
1	Changed	Unchanged	Any	Get from customer configuration
2	Changed	Changed	Vendor object changes not allowed	No update
			Vendor object changes allowed w/o breaking support	Get from vendor configuration
			Support cancelled for vendor object	Get from customer configuration
3	Unchanged	Unchanged	Any	Get from customer configuration
4	Unchanged	Changed	Vendor object changes not allowed	Get from vendor configuration
			Vendor object changes allowed w/o breaking support	Get from vendor configuration
			Support cancelled for vendor object	Get from customer configuration

Restricting customization using delivery rules

A vendor can restrict customization of their configurations using delivery rules for individual metadata objects. This feature is designed to prevent modifications that change the configuration logic to the point when further support no longer makes sense. The following delivery rules are available:

Changes allowed
Changes not recommended
Changes not allowed

The following figure describes the support rules (both default and available to customers) that match various delivery rules.

Figure 2. Correspondence betweer delivery and support rules

Delivery settings and generation of distribution and update files

This article describes generation of applied solution distribution kits.

Configurations can be delivered in the following file formats:

Configuration file (.cf), which contains a configuration distribution kit
Infobase file (.1cd), which contains an out-of-box infobase, either empty or filled with predefined initial data
Infobase file with demo data and the corresponding infobase dump file (.dt)

To create a configuration that can be used as a vendor configuration, prepare specific versions of these files based on the configuration distribution kit (.cf) file that is created using the method described later in this article. The creation of other distribution file types is described at the end of this article.

Specifying delivery settings

Configuration delivery settings define the support rules for customers, including delivery rules for metadata objects. Note that delivery rules are specified for metadata objects that belong to the first level of the object tree, such as catalogs, documents, or registers. Subordinate objects, such as attributes, tabular sections, forms, or templates, use the rules defined for their parent objects. The following delivery rules are available:

Changes allowed
Changes not recommended
Changes not allowed

The selected rule defines the support rules that can be selected at customer side. For details, see Configuration delivery and support concept.

You can also specify delivery rules for object modules by selecting or clearing the Include object module texts check boxes. If module texts are not delivered, customers cannot view or edit the module script. This can be used for protecting intellectual property or for ensuring logical integrity of the configuration.

You can select the Distribution file can be used for updates check box in the delivery settings. As described in section Configuration delivery and support concept, configuration update files (.cfu) and full configuration files (.cf) can be used for updating vendor configurations. If you clear the check box, the resulting .cf file cannot be used for updating configurations. You might want to use this option if the new configuration version requires complicated dababase processing.

For example, changing a catalog attribute from a string to a reference to another catalog requires a two-tier update. First, you have to add a new attribute of reference type and fill it based on the old attribute value, then remove the old attribute and rename the new one. This update cannot be performed in a single database restucturing with pre- and postprocessing. For the update, you have to create an intermediate configuration version where the new attribute is added and the old one is not yet deleted, and write appropriate data processors. This scenario is prone to human error, even if the update process is thoroughly described in the documentation. Selecting the Distribution file can be used for updates check box eliminates the human error. The entire update procedure might look like this:

Generate the configuration update file for update from the previous versions to the intermediate version.
Generate the configuration update file for update from the intermediate version to the latest version.
Generate the configuration file with the Distribution file can be used for updates check box cleared.

A customer that owns a previous configuration version cannot change the update order. Even if they obtain the configuration file for the latest version, they cannot use it to update their configuration.

Note that this method lacks flexibility. If the check box is cleared, the customer cannot downgrade future configuration versions to the current one. By default the Distribution file can be used for updates check box is selected.

Standard directory structure for distribution and update files

The configuration delivery procedure adheres to specific rules for distribution file locations and support of different versions. To specify the root directory for distribution and update files, in the Create Distribution and Configuration Update Files dialog box, click Distribution files directory. By default the files are stored in subdirectories named after their version numbers (the Version property of the configuration). This simplifies preparation of update files (as described later in this article). Note that the root directory is not stored inside the configuration and will be changed if the .1cd configuration file is moved to another computer.

Creating distribution and update files

You can create distribution and update files simultaneously or one at a time from the Create Distribution and Configuration Update Files dialog box. But you can only create a single update file at a time. To create multiple update files for updating a configuration from a variety of versions, repeat the update creation procedure multiple times. The distribution file can be only created once but note that disabling the creation of the distribution file does not speed up the update file creation. In a large configuration it can take a significant time, which also depends on the number of versions that can be updated with the update file.

If you select the Create configuration update file check box, specify one or several previous versions that can be updated using this file. The update files are not cumulative: a file designed to update version 4 to version 6 cannot be used for updating version 5, unless this version was explicitly specified at the file generation stage (for more information, see Configuration delivery and support concept). To select configuration files of previous versions, you can click Add and select a file, or you can click Add from Previous Versions to run automatic search for configuration versions stored on the hard disk, provided that the files are stored in the directory structure described earlier in this article. The Add command also allows you to specify distribution files of different configurations (they must be distribution files, not regular configuration files).

Creating distribution files in other formats

The generated .cf distribution file can be used as a basis for distribution files that have other formats. For example, you can create an infobase file (.1cd) that contains demo data. You can prepare a demo infobase using a configuration obtained by dumping the infobase from the environment where you created the distribution kit. The configurations do not have to be identical but they also should not have significant differences that require complicated updates of data and database configuration.

In Designer, open the infobase file that contains demo data. On the Configuration menu, click Load configuration from file, confirm the replacement of the current configuration, and update the database configuration. You can use the resulting infobase as a distribution file. To prepare a configuration dump (.dt) file, in this infobase, on the Administration menu, click Dump infobase.

Module merging specifics

Mapping

1C:Enterprise merges modules by procedures. It generates the procedure mapping automatically, leaving you the option to correct it manually. Let us look into the mapping generation rules.

A 1C:Enterprise module consists of three areas:

Variable declaration area
Procedure and function area
Main program area

The variable declaration areas are mapped to each other automatically, as well as the main program areas, and you cannot change that mapping. Procedures and functions are mapped based on their names, but a procedure is never mapped to a fucntion, even if they have identical names.

To change the procedure and function mapping manually, set the "Merge prioritizing..." rule for the module. This adds the button that opens the detailed settings. In the settings window, in addition to editing the mapping, you can set a merge rule for each procedure and preview the module merge result.

Merging modules during configuration update

The "Merge..." rule is never set automatically during the configuration update. You can set it manually. If you do, note the following:

For customers:
Verify the procedure and function mapping. Make manual corrections, if necessary. It is especially important if you renamed any of the procedures or functions provided in a vendor module. Remember that module merging cannot be fully automated and always requires manual corrections.
For vendors:
Note that the following issue is possible. An exported function is moved to another module in a new release of a standard configuration, a customer edited these modules earlier, and they select the "Merge..." rule for merging these modules. After the update the procedure might be present in both modules, which might lead to configuration errors. Also remember that procedures cannot be automatically mapped to functions. To handle this, we recommend the following:
- Avoid moving exported procedures and functions between modules. When it cannot be avoided, rename the procedures and functions.
- Avoid converting a procedure to a function, or vice versa. When it cannot be avoided, rename the converted procedure or function.

Specifying support options

Configuration support modes

1C:Enteprise features two configuration support modes: full support and support that allows editing. The full support mode implies that customers always work with the exact copy of the latest version of the vendor configuration. The main advantage of this mode is fully automated configuration update, and a disadvantage is that the configuration cannot be customized for user needs. You might ask why one might prefer an automatic update to getting new vendor configurations manually. There are two reasons:

Integrated configuration version check. Customers cannot load another configuration by mistake, and this protects them from possible data losses.
The option to perform updates using .cfu files, which have small size and therefore can be quickly downloaded even through low-bandwidth channels.

Initial support mode

The initial support mode depends on the method used to enable support. There are two methods available. First, a customer buys a vendor configuration distribution package and installs it as a new infobase, or a customer loads the vendor configuration into their configuration using the Load from file command in Designer. In these scenarios the initial support mode is full support.

Second, a customer merges their configuration with the vendor distribution package. In this scenario the initial support mode is support that allows editing.

Viewing support mode and switching between modes

To view the current support mode, on the Configuration menu, click Support options. This opens the Support options dialog box where you can view the support mode and perform other support-related operations. The first line of the dialog box describes the current support mode. There is also a button that enables configuration editing. Once switched to the mode that allows editing, the configuration cannot be returned to the full support mode. Note that in order to edit the vendor configuration you do not have to completely disable support, switching to the support mode that allows editing is enough.

Other support management options

The support options dialog box also provides the following options: disabling support (the Disable support button), making a backup copy of the latest version of the vendor configuration (the Save to file button), specifying configuration support languages, specifying support rules for individual objects, and opening the dialog box for comparison and merging with vendor configuration.

Configuration support languages

In addition to full configuration comparison, 1C:Enterprise provides the option to compare configurations by language. Suppose that two configurations are being compared (for example, a vendor configuration is compared with a customer configuration). The first configuration includes English and German languages, while the second one includes only English. If you select comparison by English language only, lines that are identical in English are considered identical, even if they include German. There is a dialog box where you can specify comparison languages. You can also specify default languages in the support options. The default languages are used for comparison with vendor configuration and for configuration updates.

Specifying object support rules

The object support rules are described in detail in Configuration delivery and support concept. You can specify support rules for individual objects either from the support options dialog box or from the compare and merge with vendor configuration dialog box.

Note the "Vendor object changes not allowed" rule. This rule can be set only for identical objects (vendor object that are not modified by customer). That is why the rule can only be set in the compare and merge with vendor configuration dialog box. If you attempt to set this rule in the support options dialog box, you get an error message.

Deleting vendor objects

To delete a vendor object, you have to set the "Support canceled for vendor object" rule for this object and all its subordinate objects. In the support options dialog box you can set this rule recursively (for an object and all its subordinate objects at once). Setting a rule for a group of objects is supported, as well as setting a rule for a group of objects with their subordinate objects.

Shared development specifics

All configuration support settings are stored in the configuration root. To update support options or update a configuration, it is enough to lock the root object is the repository. But we strongly recommend that you lock the entire configuration in order to update it.

Reverting to vendor objects

To revert to a vendor object, use the compare and merge with vendor configuration dialog box. Note the following: if a vendor object is deleted by customer and then that object is copied from a vendor configuration to the customer configuration, the copied object, being logically identical to the deleted one, has a different internal ID. And if the database configuration still stores the previous object version, it cannot be mapped to the new object during the database configuration update and some data might be lost during the update. So, if you want to restore a deleted object that is still present in the database configuration, do not merge your configuration with a vendor configuration. Instead, revert to the database configuration.

Configurations based on several supported vendor configurations

General description

Consider the following scenario. A customer needs an integrated solution that includes two very different functionalities, such as warehouse management and human resources management. They cannot find a single solution that suits their needs, but solutions that implement one of the functionalities exactly as they want are available on the market. So they buy two solutions and merge them into a single configuration. Of course combining two original configurations into one, especially if they are provided by different vendors, is a complex task that always requires manual corrections to automatic merging. In particular, if both source configurations have objects with similar functionalities, they should be merged to a single object without functionality losses. Since the methods of solving this task are out of scope of this article, we will only discuss the support of the resulting configuration.

Probably a customer wants to stay eligible for vendor support, but which or the two vendors do they choose? Of course they can choose the configuration that is more important, or a larger one, or a more complex one, and integrate the changes that originate from another vendor configuration manually. But 1C:Enterprise provides the option to get support from both vendor configurations.

Support of mapped objects

A configuration update only affects customer configuration objects that originate from the vendor configuration. The rest of the objects are considered customer-added and they do not affect the update process. So the update does not make a difference between customer-added objects and objects originating from another vendor configuration.

The configuration might also include merged objects that originate from both configurations (which maps the source objects to each other). Let us consider their support options.

For each vendor configuration, 1C:Enterprise only analyzes its links to customer objects. So, if a customer configuration object is also linked to some other vendor configuration, this does not introduce any changes to the delivery and support processes. If a customer updates an object from the first vendor configuration, the second vendor configuration identifies this as customer changes. This is why having a single object supported by two or more vendor configurations is possible. Of course one have to keep a close watch on the object during each update and make manual corrections, but the automatic merging feature is still useful here because at least it provides a report listing the changes introduced by a new version of the vendor configuration.

One does not have to keep an object supported by both vendors. Instead, they can have the object supported in a single configuration, preferably the one whose functionality is more complex or harder to integrate. Alternatively, they can disable support for both vendor configurations and make all the latest changes to the object manually.

Availability of mapped objects

If a configuration is based on several supported vendor configurations, there is at least one mapped object available: the root configuration object. Most of its properties only slightly affect the configuration functionality and their values might be changed by customer. Significant properties include the application module and possibly the external connection module. A customer must decide how these modules are supported, and updating these modules always takes time, regardless of the selected support option. This is one of the reasons for the recommendation to keep all functionality implementations in common modules, leaving only procedure calls in application and external connection modules. Following this recommendation significantly simplifies the update process.

Delivery and support rules

To keep a mapped object supported by both vendor configurations, set the "Changes allowed w/o breaking support" rule in the support options for both configurations.

If you want a mapped object to be supported by a single vendor configuration, set the "Changes allowed w/o breaking support" rule for that configuration, and set the "Support canceled for vendor object" rule for the other configuration. Of course you can do it only if the support rules set by vendors allow these options. If both vendors set the "Changes not allowed" rule, you cannot create a mapped object supported by both vendor configurations.

Enabling support

There are two way to enable support of a vendor configuration: first, create a configuration from a vendor distribution kit, and second, merge your configuration with the distributed configuration with the "enable support" option. Obviously, if your configuration includes two vendor configurations, you have to use the second method for at least one of the configurations.

Specifics of comparing and merging configurations during the update

Object mapping

Mapping rules

When merging configurations, 1C:Enterprise creates the mapping of metadata objects based on their Name properties and internal object IDs. The mapping algorithm to be used depends on which comparison option you have selected. Before we proceed to describing these options, let us discuss how internal object IDs can be changed.

Internal IDs are never changed within a single configuration. They are not changed when you export configurations to .cf or .dt files (including .cf distribution files and .cfu update files). They are not changed in the process of shared development (when you move objects between the configuration and the repository). However, they are always changed when you copy objects, and this includes copying objects in the process of merging.

For example, you create a new configuration and then, on the Configuration menu, click Compare and merge with configuration from file. 1C:Enterprise detects that the current configuration is empty and prompts you to load the entire configuration from a file, as if you used the Load configuration from file command. If you agree, all object IDs are preserved. If you decline and perform regular merging, all object IDs are changed, although the resulting configuration is logically identical to the original one.

Now let us proceed to object mapping algorithms. Three algorithms are available:

Comparison of configurations that are not related to each other. The mapping is based on object names. Objects that cannot be mapped by name are mapped by intermal ID.
Comparison of configurations related to each other (different versions of a single configuration). For example, comparison of a base configuration with a database configuration or with a repository configuration falls into this category. The mapping is based on object IDs only, object names are ignored.
Comparison with vendor configuration. The mapping is based on object IDs but the IDs do not have to be identical.

Let us look into the third algorithm in detail, but first let us make some clarifications to the first two algorithms. There are several ways to start configuration comparison. For example, you can use the Configuration - Compare and merge with configuration from file command, or the Configuration - Database configuration - Compare and merge with database configuration command, or open it from the support options dialog box. In each of these scenarios the platform automatically selects the mapping algorithm.

You also have the universal comparison command Configuration - Compare configurations, which prompts you to select any pair of configurations (for example, a database configuration and some configuration version from the repository). If you select a pair of configurations that are obviously related to each other, the mapping algorithm is selected automatically. Otherwise the Determine match by object names check box, which allows you to select between two algorithms, becomes available.

Note that for the platform to select the algorithm automatically, in addition to selecting a specific pair of configurations, you also have to select them in the right order, the base configuration should go first. You can use this feature if you want to change the algorithm for a certain pair of configurations: just change their order.

Now let us look into the comparison with vendor configuration. If can have one of the two support options: object changes allowed or not allowed. In the latter case the update is performed by loading the entire vendor configuration and the object IDs are not changed, as it is described earlier in this article. In the former case manual corrections are allowed during the merging and new objects acquire new IDs. But is this scenario objects cannot be mapped by name because otherwise objects whose names are changed by customer would lose their links to vendor objects. So the platform uses the following algorithm: for each vendor object, it stores a pair of object IDs (the vendor object ID and the supported configuration object ID), and then generated the mapping using those pairs only. Once created, the pairs are never changed, this ensures the logical integrity of the configuration. If a new object is found in a vendor configuration, a customer can copy the object during the update or they can map it to some customer configuration object, and once they do, this mapping cannot be changed.

Dependence of configuration comparison performance on the object mapping

Comparison of large configurations is a lengthy operation, especially in the update vendor configuration mode, which includes three comparisons: the old vendor configuration, the new vendor configuration, and the customer configuration are compared to each other. Generally, the comparison performance is significantly improved if the following two conditions are met:

The mapping does not include objects pairs with different IDs.
Unmapped objects do not include object pairs with identical IDs.

One can easily explain why following these rules optimizes the performance. Vendor configuration versions are always compared quickly because they are created from a single configuration as delivery or update files and the object IDs are preserved. The comparison performance depends on the change history in the vendor configuration versions. After enabling changes in the customer configuration the comparison is still performed quickly because the mapped objects have identical IDs. But once a vendor adds a new object in an update, the object is assigned a new ID after the update and the performance of all subsequent comparisons of the customer configuration with the vendor configuration is significantly reduced.

Note on enabling support

Deployment specialists often ask which is the right way to enable support. They have the following options: either enable support in a vendor configuration installed from a distribution kit, or merge a customer configuration with the distributed vendor configuration and at the same time enable support. There is no big difference between these options. Logically, both ways give the same result. The update performance is initially better in the first scenario, but only until the vendor adds at least one object, which will most likely happen in the next release of the vendor configuration. After that the performance is the same for both scenarios.

Deletion of vendor objects

Let us consider scenarios that involve deleting vendor objects.

Deletion by customer

In order to delete a vendor object, a customer has to disable support for this object and all its subordinate objects. In subsequent updates the object is excluded from merging.

Deletion by vendor

When you merge configurations, you always have the option to delete base configuration objects. By default this option is only available in the "vendor configuration update" mode. In other modes you can enable it by selecting the Allow base configuration object deletion check box in the compare and merge configuration dialog box.

By default setting deletion marks to vendor objects is performed according to the following rules. If a customer changed the vendor object (compared to the previous version of the vendor configuration), the deletion mark is not set by default. If the object is identical to the vendor object, the deletion mark is set. Once you click Execute, the platform checks the reference integrity for objects that have deletion marks set both automatically and manually. If unresolvable references to an object that has a deletion mark are found, the list or references is displayed in a new window. Unlike the unresolved references that are found when you deny copying an object from a vendor configuration (or from any other configuration involved in the merging), these references do not allow you to delete the object and continue the merging.

Recommendations for customizing vendor configurations

When customizing a standard configuration for the needs of a specific user, think about future updates. The configuration support feauture 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 platofrm 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 compex 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 vendor. While the comparison report provuides 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 knowledge base articles related to configuration delivery and updates. Understanding the delivery and update principles streamlines your configuration development.

Creating distribution and update files

You can create the following distribution and update files in Designer:

Configuration file (.cf), which stores the configuration distribution kit
Update file (.cfu), which stores the configuration update (for one or several previous versions)

Standard dustribution and update directory structure

Creating distribution files

Distribution files are created in the specified distribution files directory if you select the Create distribution file check box in the Create distribution and configuration update files dialog box.

Attention! Do not create delivery files in the configuration that is supported by itself.

Note. If, despite this recommendation, you created delivery files to a configuration that is supported by itself, send only the new configuration file (.cf) to users. This is the only way to perform the update of the supported configuration correctly.

Creating configuration update files

You can create distribution and update files simultaneously from the Create Distribution and Configuration Update Files dialog box if you select both the Create distribution file and Create configuration update file check boxes. But you can only create a single update file at a time. To create multiple update files for updating a configuration from a variety of versions, repeat the update creation procedure multiple times,each time with a different distribution file directory.
If you select the Create configuration update file check box, specify one or several previous version files that can be updated using this file. The update files are not cumulative: a file designed to update version 4 to version 6 cannot be used for updating version 5, unless this version was explicitly specified at the file generation stage (for more information, see Configuration delivery and support concept).

To select configuration files of previous versions, you can click Add and select a file, or you can click Add from Previous Versions to run automatic search for configuration versions stored on the hard disk, provided that the files are stored in the directory structure described earlier in this article.

The Add command also allows you to specify distribution files of different configurations (they must be distribution files, not regular configuration files). The platform creates updates for these configurations.

Updating configurations using .cfu update files

To update a configuration, on the Configuration menu, point to Support and click Update configuration. This opens the Configuration update dialog box.

In this dialog box, select the update source.

Once you pass through the configuration update wizard and click Finish, the platform displays the dialog box with the main parameters of the current confiuation and vendor configuration. For details, see the platform documentation.

Note. When you perform update using a .cfu file, the platform performs a version check based on the internal ID that is changed with ANY configuration change, even disabling support counts as a change.