home › SSD drive › 1C supplier configuration differs from the main one. Restoring the vendor configuration. A special case of an unusual configuration state. Saving update results

1C supplier configuration differs from the main one. Restoring the vendor configuration. A special case of an unusual configuration state. Saving update results

Let's consider a typical situation in which beginners often find themselves. Let's say there is a typical configuration of 1C: Integrated Automation 8. Initially, the configuration was installed from the distribution kit (let's say release 1.1.20.1). Then, due to the need to adapt to the specifics of the enterprise, the possibility of change was included (newcomers very often mistakenly call this action removal from support, although in fact this is not the case).

And now, after some time, we have a highly modified, but still standard (for the purposes of regulated accounting, we regularly updated) configuration. Let's look at a few hypothetical situations:

1) Some time after the next update, we receive a message from the accounting department about an error that occurs during the routine month-end closing operation. There was no such error before, so the update is to blame. Quite a typical situation. We begin to diagnose the error and see that the legs are growing out of the general module Accounting for VAT and Formation of Movements. We begin to understand and understand that this module was significantly redesigned into the standard one and after the merger we “lost” some of the procedures/functions (or, as often happens in standard ones, they “jumped” into another common module). Due to the intricacy of common modules among themselves in standard ones, at the update stage it is not always possible to identify a problem that manifests itself only when users work.

So we understand that in order to figure it out we need a typical configuration of the current release (let’s say 1.1.23.1). But where can I get it? If there is a familiar Frenchman and he can quickly send the distribution kit, great, but let’s assume he is not there, and the problem needs to be fixed urgently. (Do not suggest Varese!). Moreover, there may be no Internet, and what to do in such a situation? I have repeatedly witnessed a process where a person, in order to solve a given problem, installed a new database from the existing initial distribution, and then successively updated it to the latest one in order to see “how it should really be” in a clean database. And the chest, as always, just opened :)

Now let's consider various options solutions:

a) First option: Menu -> Configuration -> Comparison of configurations, then select the vendor configuration and compare it with the main configuration.

Surprisingly, there are those who don’t know about this. Or, under any circumstances, use the item Compare, combine with the configuration from the file (having previously obtained/received the standard .cf).

b) The second method is suitable if we need to not only see the changes, but also immediately perform the merge.

Menu -> Configuration -> Support -> Support settings and at the bottom click the Compare, merge button.

2) Another situation: let’s say we changed or deleted some piece of standard code, and after a while it turned out that we made a mistake and we need to put everything back. And as often happens, there is no backup of the saved configuration before the changes were made. But we know for sure that this piece of code is contained in the standard code, so the vendor configuration would solve the problem.

Naturally, you can do the same as in the first case. Wait for the comparison process to complete, and from the configuration comparison window, open the standard module and copy the code from there.

Some people do just that, but if we are dealing with a monster like UPP, which is also heavily modified, then we can wait a very long time for the comparison process to complete. If we had a .cf file, we could simply open it in the configuration window (by the way, not all beginners know about this feature either) and copy the required code from there.

And a reasonable question arises: how can you still save the supplier’s configuration to a file? Why is there no menu item similar to Save configuration to file for the main configuration or Save database configuration to file for database configuration. Where is the same for the supplier configuration? In fact, it is there too, only buried a little deeper. Namely, everything is in the same form of support settings.

It’s just that many people open it only once. this form only to enable the possibility of change and never return to it.

And in our case, it was possible to do it even simpler, without even saving the configuration to a file, click the Open button. The effect is the same, but much faster.

Why else might you need to save the supplier configuration to a file?

3) Consider the following situation. Let’s say that at the initial stage of the configuration’s existence, the standard configuration did not have the functionality we needed and a decision was made to improve it. The modification was minimal, but in the future it still created inconvenience when updating. But then, after some time, we discover that this functionality (as was the case with object versioning at one time) appeared in the standard version (and, as often happens, it was implemented an order of magnitude better than the “makeshift” modification).

Let me give you a few more examples of real situations when you may need to roll back to a standard configuration:

1. A couple of times I came across configurations in which only the layouts of printed forms were subject to modification. Due to lack of experience or ignorance, the programmer who accompanied the configuration, instead of creating an external printed form removed the configuration from support and modified the built-in layouts (often trivially to add a company logo), after which users were deprived of the ability to automatically update.

2. Again, due to ignorance of the standard functionality (ex-Seven students often suffer from this), instead of using properties and categories, details of directories/documents were added when there was no good reason for this (data, for example, was used only for output to printed forms).

Of course, this is not a problem if we are dealing with a management plan or other configuration of the management plan, where in general updates are not critical, but in in this example We were talking about modified SCPs or complex automation. And it turns out that due to minor improvements that could have been implemented without removing full support, we have unnecessary hemorrhoids with standard updates.

There is a reasonable desire to abandon the modifications made and put the configuration back into full support. How to do it?

The only way to put the configuration back into full support is to load (not in the compare and merge mode, but rather the Load configuration from file item) standard.cf. This is why we need the ability to save the supplier configuration to a .cf file. We save, then load, and after updating the database configuration, we get the standard configuration in its original form, i.e. with a lock :) Naturally, before performing these actions, you must take care in advance of saving/transferring the necessary data, which will be “washed away” after returning to the standard configuration and be sure to do backup copy Database!

These are, as it turns out, simple possibilities available to the developer’s arsenal, but ignorance of these techniques in practice can result in many hours of unnecessary fuss described above. So those who knew - well done, and those who didn’t know - take it into service and save your time.

In this article I want to show the service capabilities of the 1C:Enterprise 8 platform, in terms of using the supplier’s configuration, which are very often in demand, but as practice has shown, they are not familiar to all beginners and even experienced specialists.

And now, after some time, we have a highly modified, but still standard (for the purposes of regulated accounting, we regularly updated) configuration. Let's look at a few hypothetical situations:

1) Some time after the next update, we receive a message from the accounting department about an error that occurs during the routine month-end closing operation. There was no such error before, so the update is to blame. Quite a typical situation. We begin to diagnose the error and see that the legs are growing out of the general module Accounting for VAT and Formation of Movements. We begin to understand and understand that this module was significantly redesigned into a standard one and after merging, we “lost” some of the procedures/functions (or, as often happens in standard ones, they “jumped” into another common module). Due to the intricacy of common modules among themselves in standard ones, at the update stage it is not always possible to identify a problem that manifests itself only when users work.

Now let's look at different solutions:

a) First option: Menu -> Configuration -> Comparison of configurations, then select the vendor configuration and compare it with the main configuration.

b) The second method is suitable if we need to not only see the changes, but also immediately perform the merge.

Menu -> Configuration -> Support -> Support settings and at the bottom click the Compare, merge button.

Naturally, you can do the same as in the first case. Wait for the comparison process to complete, and from the configuration comparison window, open the standard module and copy the code from there.

It’s just that many people open this form only once to enable the change option and never return to it.

And in our case, it was possible to do it even simpler, without even saving the configuration to a file, click the Open button. The effect is the same, but much faster.

Why else might you need to save the supplier configuration to a file?

Let me give you a few more examples of real situations when you may need to roll back to a standard configuration:

1. A couple of times I came across configurations in which only the layouts of printed forms were subject to modification. Due to lack of experience or ignorance, the programmer who maintained the configuration, instead of creating an external printed form, removed the configuration from support and modified the built-in layouts (often trivially to add a company logo), after which users were deprived of the ability to automatically update.

2. Again, due to ignorance of the standard functionality (very often former “seven-year students” suffer from this), instead of using properties and categories, details of directories/documents were added when there was no good reason for this (data, for example, was used only for output to printed forms).

Of course, this is not a problem if we are dealing with UT or another management plan configuration, where updates are generally not critical, but in this example we were talking about modified SCPs or complex automation. And it turns out that due to minor improvements that could have been implemented without removing full support, we have unnecessary hemorrhoids with standard updates.

There is a reasonable desire to abandon the modifications made and put the configuration back into full support. How to do it?

The only way to put the configuration back into full support is to load (not in the compare and merge mode, but rather the Load configuration from file item) standard.cf. This is why we need the ability to save the supplier configuration to a .cf file. We save, then load, and after updating the database configuration, we get the standard configuration in its original form, i.e. with a lock (IMG:) Naturally, before performing these actions, you must take care in advance of saving/transferring the necessary data, which will be “washed away” after returning to the standard configuration, and be sure to make a backup copy of the database!

[you must register to view the link]

And so again Hello dear readers of the blog www.site. Today we’ll talk about how to upload and download a configuration in 1C Enterprise. We have already discussed the issue with you. But as it turned out, it will be completely empty. In order to start working in it, you need to load the configuration from a file. The process of uploading and loading the configuration is quite simple but very important.

For example, I will use 1C 8.2, but for version 8.3 this instruction will also work. Let's take a closer look at what configuration is. I will try to explain this to you in my own words. A configuration in 1C is a set of documents, tables, various reports, etc. only unfilled, empty without data. An analogy can be drawn with Excel documents, an empty table filled with various formulas and diagrams is a configuration. There are a lot of configurations: Accounting, Salaries and HR, document flow, Retail, etc. There are also a lot of different self-written configurations.

How to upload a configuration from 1C to a file

How can we upload the 1C configuration to a file. And so, first of all, we need to go into the configurator itself, to do this, launch 1C and select the desired database, click the Configuration item.

In the configurator, go to the Configuration item and select Save configuration to file.

That's it, the configuration upload is complete. Now let's talk about how to download it.

How to load a configuration into 1C from a file

We've sorted out the uploading, let's now look at loading the configuration from a file. To do this, you also need to go to the configurator. And select the Configuration item and look for Loading a configuration from a file.

In the window that opens, you need to specify the configuration file and click Open. Then we wait for the configuration to load.

Close the configurator and launch 1C in normal mode.

As you can see, everything turned out to be quite simple.

There was a question:
How many configurations are there in information base?
Correct answer 3

The IS structure includes:
1. Basic configuration.
2. Database configuration.
3. Provider Configuration(may be absent).

4. Plus user data (documents, directories, etc.)

The configuration determines the structure of the database and contains algorithms that ensure work with data.

Developers work with the main configuration. Users work with the database configuration.

Vendor configuration – the initial configuration of the standard solution vendor.

If the infobase is installed from a template and is supported by the supplier, then inside the information security the vendor configuration will be located.

If the configuration is under support and changes to objects are prohibited, then two configurations are stored in the infobase – the based configuration and the database configuration.

When you enable the ability to change the configuration (command Enable edit option in the dialogue " Setting up support"), platform from the main configuration creates the provider configuration. The size of information security is increasing.

The provider configuration is read-only.

To view the supplier configuration, select
Configuration – Support – Support settings – Open.

The information base can contain several vendor configurations, if the configuration supports multiple vendors. This scheme occurs when using industry circulation solutions.

1C support basics

The 1C update can be done in user mode, in configurator mode, and in comparison and merging settings.

Removal from support

In the “Support Settings” dialog, when you click the Remove from support button The vendor configuration is being deleted. This option must be used in cases where standard solution it is used as a basis for its own development and its maintenance is not planned.

If you need to download the provider configuration. This can be done from Support – Support Settings. In the “Support Settings” dialog, click the Save to file button.