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 into 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 custom 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 the 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 ways 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.

Next page: Creating distribution and update files


Be the first to know tips & tricks on business application development!

A confirmation e-mail has been sent to the e-mail address you provided .

Click the link in the e-mail to confirm and activate the subscription.