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. that are just not filled out, 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.
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.
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 from 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.
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 casket, as always, simply opened (IMG:)
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.
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 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?
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 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!
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.
[you must register to view the link]
In my case, “Trade Management”, edition 10.3 is supplemented by the industry solution “BIT: Auto Service Management 8”. Companies using industry-specific solutions, as a rule, modify the configuration to suit their needs and do not update them to new releases from the supplier. Therefore, what remains is Trade Management, release 10.3.13.2. Plus, although the supplier’s configuration is called “Trade Management”, nevertheless, objects related to the configuration “BIT: Auto Service Management 8” are also supported (Fig. 1). This is the case when the vendor configuration releases and the database configuration (hereinafter referred to as the DB) formally coincide, but in fact the vendor configuration is not Trade Management, edition 10.3.
Consequently, when updating to the next release of Trade Management, the update mechanism will offer to delete all objects that belonged to the industry solution (Fig. 2).
Thus, the task of restoring the configuration provider arises. Also, this task may occur if the database was updated through “Compare, Merge” with a new configuration file.
The problem is solved in two stages. To do this, you will need a cf configuration file that corresponds to the database release. The database release can be viewed in “Help” - “About the program” (Fig. 3).
Attention! Before performing the following operations, make a backup copy of the database.
1) Click “Configuration” - “Support” - “Support Settings”. The “Support Settings” window will appear, click “Remove from support” (Fig. 4). In the dialog box with the message that removal from support will lead to the inability to receive an update from the vendor, answer “Yes”.
Please note that the yellow cube icon is no longer visible in the configuration tree.
2) Click “Configuration” - “Compare, merge with configuration from file”. A window will appear asking you to put the configuration on support. We answer “Yes” (Fig. 5).
Now, in order not to lose changes to standard objects in the configuration, uncheck the root node and click “Run”. In the support rules settings, answer “OK” (Fig. 6).
The provider configuration now matches the database configuration. However, there is a small technical note - objects that have had changes are not supported (Fig. 7). Such objects will not change during the update. So, you need to put them on support with the ability to edit.
3) Click “Configuration” - “Support” - “Support Settings”. In the window that appears, click “Compare, combine.” In the comparison and merging window, uncheck all the boxes, select the object that we want to support, and click “Change”. In the window that appears, select “Supplier object is edited while maintaining support”, click “OK” and “Run” (Fig. 8). The “Install for subordinate objects” checkbox is useful if the change being made is valid for all subordinate objects. The 1C:Enterprise 8 platform will not allow changes if, for example, details have been added to subordinate objects and you put them on support.
We select the object that we place on support.
Now the information base is based on supporting the required configuration.
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 from 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.
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 look at different 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 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?
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 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 (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 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 :) 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!
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.
