In this article a want to show the service capabilities of 1С:Enterprise 8 platform within the use of vendor configuration that are often in demand, but, as a practice showed, are familiar not for all the beginners and even experienced specialists.
Consider a typical situation in which the novices often find themselves. Suppose there is a typical configuration 1C:Accounting Suite 8. Initially, it was installed from the distributive. Them, due to the need to adapt it to the enterprise specifics, an ability of modification was enabled (the novices very often mistakenly refer this action to a removal from support, although, it is not the case).

And then, after a while, we have a significantly modified, but still typical configuration. And now consider a few hypothetical situations:

1) Some time later, after the next update we receive a message from the accounting department about an error that occurs during the scheduled operation conduction of month closing. Prior to that, this error did not occur, therefor, the reason is in the update. it is a typical situation. We begin to diagnose an error and see that the source of error is in the general module “GeneralFunctions”. We begin to examine and understand that this module was significantly modified in the typical one and after the join we «lost» a part of procedures/functions.

So, we understand that we need a typical configuration of current release to sort out. But where can we get it? If we have a friend among 1С partners and he can send the distributive — that is fine, but suppose he is not available and the problem must be solved urgently. Moreover, the Internet can be not available, so what to do in this situation? I was repeatedly a witness of the process when a person installed a new base to solve a problem from the existing initial distributive and then updated it subsequently to the last one in order to see in the clean base «how it should actually be». And the solution was quite simple as usual 🙂

Now consider various solutions:

а) First option: Menu -> Configuration -> Compare configurations, then select the vendor configuration and compare it with the basic configuration.

It is amazing but there are the people who do not know about that. And under any circumstances use an item “Compare and merge configuration from file” (using the preliminary found/received typical .cf).

б) The second way is suitable if we need not only to see the changes, but also to perform a join at once.

Menu -> Configuration -> Support -> Support option and click below the button “Compare, merge”.

2) Another situation: suppose we changed or deleted some piece of typical code, and after a while it turned out that we made a mistake and it is required to return everything back. And, as it often happens, a backup of the saved configuration before the made changes is not available. But we do know that this piece of code is contained in the typical one, so, the vendor configuration would solve a problem.

Obviously, we can proceed as in the first case. Wait until the comparison process will end and from the configuration comparison window open a typical module and copy the code from there.

Some people do so, but if we are dealing with a monster like 1C:ERP, therewith significantly modified, then we can wait for the end of comparison process very long. If we had .cf file, it could be just opened in the configuration window(by the way, not all the novices know about this option too) and copy from there the required code.

And the reasonable question arises, how still to save the vendor configuration in file? Why is there no menu item similar to Save configuration in file for the basic configuration or Save DB configuration in file for the database configuration? Where is the same for the vendor configuration? In fact, it is available too, but is buried a little deeper. Namely, in the same support configuration form.

Simply, many open this form a single time only to enable the modification ability and never return to it any more.

We can do much easier, even without saving the configuration in file, click the button Open. The effect is the same, but much faster.

And what else do we need for to save the vendor configuration in file?

3) Consider the following situation. Suppose for the initial stage of typical configuration existence there was no a functional required for us and it was decided to modify it. The modification was minimal, but later it still created the nuisances during update. But then, after a while, we find out that this functional (like it was in due time with the object versioning) appeared in the typical one (and, as it often happens, is implemented much better than our own modification).

Here there are a few examples of real situations where you may need to roll back to the typical configuration:

1. A couple of times I faced with configurations in which only the templates of print forms were modified. Due to the lack of experience or knowledge, the programmer who maintained the configuration removed the configuration from support and modified the embedded templates instead of creation of external print form (often simply to add the company logo) after that the users were disabled from the automatic update mode.

2. Again, due to the lack of knowledge of typical functional, the attributes of catalogs/documents were added instead of the usage of properties and categories, when it had no reasons to do that (the data, for example, were used only to output in the print forms).

And it turns out that, due to insignificant modifications that could be implemented without removal from the complete support, we have a useless pain in the rear with the typical updates.

A reasonable desire appears to refuse the made modifications and set again the configuration for the complete support. How to do it?

The only way to set the configuration for the complete support is to load (not in the comparison and join mode, but just an item “Load configuration from file”) typical .cf. TO do this, we will need exactly an ability to save the vendor configuration in .cf file. Perform the saving, then load, and after the database configuration update we obtain the typical configuration in its original form, i.e. closed editing and complete automatic update for the new versions :). Obviously, before performing these actions, you must take care about saving/transferring required data that will be deleted after rollback to the typical configuration and be sure to make a backup of database!

These are the simple capabilities, as it turned out, that are available for the developer, but the lack of knowledge about these techniques in practice can result in many hours of unnecessary fuss described above. So who knew — well done, and who did not know — make use of them and save your time.