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). In view of the intricacies common modules between each other in a typical way, 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 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 opportunity automatic mode updates.
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 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 UPPs 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 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.
[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. 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 we launch 1C and select the necessary base Click on Configuration.
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 the infobase?
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 the configurator mode and in the 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.
This article is based on many years of experience in developing and supporting accounting solutions on the 1C:Enterprise platform. The article describes some fairly common situations that cause difficulties when updating non-standard 1C:Enterprise 8 configurations.
This article does not describe techniques for using automatic and automated configuration updates using external components and/or software products. You can find information on them on this and other Internet resources.
You may have noticed that with each update, the number of objects requiring your attention only increases. At the same time, you know for sure that, for example, only one document has been changed, and when updating, a list of several dozen changed objects is given. Of course, you can use the technique described in the article “Technology for updating non-standard configurations of 1C: Enterprise 7.7” dated June 27, 2003. Yes, it will work. Many people perform updates this way. But I consider this approach ineffective and time-consuming when updating configurations on the 1C:Enterprise 8 platform. Unlike the 1C:Enterprise 7.7 platform, the 1C:Enterprise 8 platform allows you to open several configurations simultaneously (*.cf files) and perform several comparisons of configurations in one copy configurator. The only exception is, perhaps, configurations built on PPM (Manufacturing Enterprise Management) - they are too heavy, the platform falls.
The process of updating 1C:Enterprise 8 configurations is more automated compared to 1C:Enterprise 7.7. Enough high level automation can significantly reduce the labor intensity of work when updating non-standard configurations. Unfortunately, most often the process of updating non-standard configurations cannot be performed completely automatically and requires the intervention of a specialist.
Is it possible that the update process will be completed completely automatically? Certainly. To do this, mutable objects must be added and must not use the functionality of the existing configuration. Those. these objects must solve completely different accounting problems that expand the functionality of the standard supplier configuration. Agree that the situation described is extremely rare. Changes almost always affect standard vendor configuration objects.
Please note that the database can contain up to three types of configurations:
- database configuration- this is the configuration with which users work;
- working configuration (main) is a configuration that we can make changes to and users can continue to work;
- vendor configuration is the initial vendor configuration from which the production and database configurations are typically created. A database can have multiple configurations from different vendors. The configuration supplier can be not only 1C.
Let's look at the update process and analyze possible mistakes using the example of updating the UPP configuration (the supplier of the standard configuration is the 1C company, modifications by the Inform Service company). Initially, this configuration was updated not using the technology described in this article, so the errors discussed in this article are the most common in practice. The update will be from version 1.2.6.2 to version 1.2.14.1.
Stage 1. Preparation
At the first stage, we will match the working configuration to the supplier’s configuration. This is a very important stage, which will significantly reduce the amount of work required to analyze the changes we have previously made.You can skip this step if Last update passed through “support” (Menu “Configuration” → “Support” → “Update configuration”) or was performed according to the method described in this article.
A discrepancy between the versions of the working configuration and the vendor configuration may occur when using *.cf files for updating that are not from the vendor’s distribution or when using update methods different from those described in this article. For example, objects were added to the working configuration by copying via the clipboard or Drag&Drop.
1. Comparison of versions.
Let's check the version numbers of the working configuration and the supplier configuration. We look at the working configuration number in the “Configuration” menu → “Open configuration” of the “Edit” menu → “Properties”. In the “Development” block, select “Version”. (Picture 1).
We look at the vendor configuration number in the menu “Configuration” → “Support” → “Support Settings...” item “Version”. (Figure 2).
If the numbers match, then move on to the next stage. See Stage 2.
In this example, it is necessary to reconcile the operational and vendor configurations with the provisioning of support for objects removed from support or added without provisioning for support. To do this, perform the following steps:
2. Saving the working (main) configuration.
Let's save the working configuration to a file, for example work.cf. To do this, select the menu item “Configuration” → “Save configuration to file...”.
3. Obtain the update file for the provider configuration.
To bring the configurations into line, we need a *.cf file from the supplier's distribution with the same version number as the working configuration (Figures 3 and 4). This file can be obtained by installing the appropriate distribution. By default, the configuration distribution is installed in the C:Program Files1cv81tmplts directory. For more information about installing configuration templates, see the documentation.
Let's check the template directory. If there is a *.cf file of the required version in the templates directory, then go to point 4 of Stage 1.
What can be done if there is no *.cf file for the required version of the vendor configuration? In this case, you can use *.cfu files and, repeating the procedure described in Stage 1 several times, successively raise the version number to the required release, in this case to 1.2.6.2. It should be noted that using *.cfu files may not fix errors made earlier during the update. Which, you see, is quite strange, given the fact that first the supplier file is compiled based on the old supplier configuration and *.cfu file, and then the update is performed. This may be due to the fact that for some reason not all configuration objects are included in the comparison. Therefore, I suggest using a possibly longer path, but also a more reliable one.
You need to create an empty database with the "old" vendor configuration. Update the supplier’s configuration to the required version and use it when performing work at stage 1. To get the "new" provider configuration you need to do the following:
Creating the "old" supplier file for the current configuration. The 1cv8.cf file can be taken from the supplier's distribution or saved from the working database if the configuration is under support. To save the 1cv8.cf file from the working database, go to the “Configuration” → “Support” → “Support Settings...” menu, click the “Save to file” button and specify the directory and file name. For example, on the desktop.
Create a database with the new provider configuration. The database can be created using the supplier's distribution from the ITS disk or using the 1cv8.cf obtained earlier from the desktop. In the first case, we follow the instructions included in the distribution kit. In the second case, to create a database from a file located on the desktop, create a new one information base without configuration and launch the configurator. In the menu “Configuration” → “Load configuration from file...” we specify the file previously saved on the desktop. We open the configuration through the menu “Configuration” → “Open configuration” and update to the desired release through the menu “Configuration” → “Support” → “Update configuration” using *.cfu files.
Create a "new" provider configuration file. To do this, select the menu item “Configuration” → “Save configuration to file...”. We specify the location and name of the file 1cv8.cf. Click “Save”.
Using the received *.cf vendor configuration file, we will perform the update. To do this, select the menu item “Configuration” → “Support” → “Update configuration”, “Select update file”, “Finish” (Figure 5), “Run” (Figure 6).
Solutions:
- unmark an object that is in the supplier configuration;
- remove the reference to the object that is in the provider configuration.
5. Restoring settings partially lost at the previous stage.
To restore partially lost settings, we will merge with the previously saved working configuration file work.cf. To do this, select the menu item “Configuration” → “Compare, merge with configuration from file...”.
6. Saving the update results.
Let's save the changes to the working configuration and update the database configuration. To do this, select the menu item “Configuration” → “Update database configuration”.
Here another problem awaits us (Figure 8).
To solve this problem, let's look at the cause of its occurrence. There may be several reasons, but the most likely are the following. These objects were copied to the working configuration from the supplier's configuration, or the supplier previously deleted these objects and later added new ones with the same names, but with different internal identifiers. As a result, objects with different internal identifiers, but with the same names, appear in the configuration.
We deal with roles simply - we delete them, because the roles have not changed (this can be verified by comparing the old vendor configuration and the production configuration). We act differently with document details. The attribute must be renamed, for example OrderReserve1, and after updating, the values from the renamed attribute must be transferred to the new one. To do this, you can use the processing of UniversalSelectionAndProcessingObjects.epf from the ITS disk.
Let's consider another situation similar to the previous one, but which arose during the update of 1C: Enterprise Accounting 8.1. What to do with forms? (Figure 9)
In the picture we see that the ListForm was removed from the supplier and then added by the supplier new form with the same name. Accordingly, you need to mark both forms for updating and click the “Run” button.
If you receive a message that there are links to objects to be deleted, you must, without closing the update form, clear the links to the form to be deleted in the object properties. In this case, in the register properties. After this, you need to click the “Update” button in the update form, mark the register properties for updating and click the “Run” button again.
Let’s save the changes to the working configuration and update the database configuration “Configuration” → “Update database configuration”.
If necessary, transfer the values of the OrderReserve1 attribute to OrderReserve using external processing in 1C:Enterprise mode.
Stage 2. Update
After carrying out the preparatory work at Stage 1, we proceed to updating the main configuration and transferring previously made modifications to the standard supplier configuration.To update the configuration, we need a *.cfu file or a *.cf file from the supplier's distribution.
If the update is performed through several configuration versions, then you should pay attention to the situation described in the article “Updating 1C: Enterprise 8 configurations. Jumping through 20 versions.” If the update is not performed on a working base, then after completing the preparation of each new stage, we save the *.cf files. They will be needed when updating the configuration of the customer's production database.
If the update is carried out through several versions, then during the update you should definitely pay attention to the objects that are deleted and to objects with changed names, as well as to the actions performed during the first launch after the update. If these objects are used in processing at the first start after the update, then they should not be deleted, and for objects with changed names, appropriate changes should be made to the text of the processing module. In this case, the objects left behind may be deleted during the next or next update.
If the update is performed through several versions, then to reduce the labor intensity of the update, you can use the method of calculating key releases described in the article “Updating 1C:Enterprise 8 configurations. Jumping through 20 versions.”
1. Preparation of databases.
So, based on the results of the first stage, we prepare two identical databases. The first (main) is our future result. The second (auxiliary) is for performing comparisons, opening configurations and other preparatory actions. For the file version, this is simply copying the files of the main database to another directory and connecting this directory to the list of databases; for the client-server version, it is uploading/downloading.
2. Three-way comparison of configurations.
Let's open both databases in Configurator mode and perform a three-way comparison of configurations in both databases using the existing file new configuration supplier. To do this, in both databases, select the menu item “Configuration” → “Support” → “Update configuration”, “Select update file”, “Finish” (Figure 10).
As a result of comparing three configurations (old supplier configuration, new supplier configuration and working configuration), we obtain a list of changed objects. Set the filter “Show only twice changed properties” (Figures 11 and 12).
It is these objects that need to be dealt with first, because... After the update, previously made settings may be lost.
At this point, we suspend work in the second (auxiliary) database and continue in the main one. There is no need to click the “Run” button in the auxiliary database. We need this database exactly in this form until the update process is completed.
So, as a result, we get a list of objects that were changed twice during the modification of the standard configuration and in the new supplier configuration. If you agree to the update, then previously made improvements to these objects will be lost. Therefore, for each object it is necessary to make a decision on how it will be updated (Figure 13). At this stage, we perform a preliminary comparison solely in order to reduce the amount of work in the future. The assessment is not accurate and quick - “by eye”.
If there are more changes in the object in the new supplier configuration, then we leave the instance of the supplier object. Leave a checkmark. Then we will transfer the changes from the working configuration.
If there are more changes in the object in the working configuration, then we leave an instance of the working configuration object. Uncheck the box. Then we will transfer the changes from the supplier configuration.
We deal with modules a little differently, because... We have the opportunity to compare modules procedurally. Those. If various module procedures are changed in our configuration and in the supplier’s configuration, then by correctly checking the boxes we will save ourselves from manually transferring code changes. To get to this, press the button as shown in Figure 14.
After we have decided on the objects that will be updated immediately and on which there are still checkmarks, we duplicate the state by checkmarks in the auxiliary database, and in the main database we press the “Run” button. In the main database we get an almost ready-made configuration.
Next, we perform all comparisons in the auxiliary database. We already have one comparison - a three-way one. To determine previously made changes, we perform an additional second comparison of the old supplier configuration with the main configuration. To do this, select the menu item “Configuration” → “Compare configurations:”, select “Supplier configuration” and “Main configuration” for comparison (Figure 16).
Similarly, we compare the old supplier configuration with the new one. For comparison, we will need the new provider configuration file. If there is no such file, now it can be obtained from the main database. To save the new supplier configuration to a file in the main database, in the “Configuration” → “Support” → “Support Settings:” menu, click the “Save to file” button. (Figure 2). Specify the file name, for example, new.cf. Next, we make a third comparison of configurations and when comparing, specify the new.cf file as the second configuration.
So, we received a list of twice changed objects in the additional database. And two more comparisons that will help us more effectively transfer previously made settings from old version to a new one. In the main database we have an almost ready-made configuration, in which we need to deal with twice changed objects.
To reduce the time for analyzing changes to a standard configuration and, accordingly, for updating, it would be appropriate to comment on all changes made to the configuration, noting not only the changed text of the modules, but also the purpose of the changes made. For a number of reasons, this is very often not done. When performing an update, you are not interested in the reasons for making changes, but in their consequences. Namely, the need to preserve the functionality of the changed configuration. This may require not transferring the changed lines, but completely reworking the added (changed) code to fit the functionality of the new vendor configuration.
Comparison of forms, tables, and modules of objects in the configuration is performed with a sufficient degree of detail (Figure 17). This is quite enough for making decisions.
But in some cases, the data in comparison reports is presented in a way that makes it difficult to make a decision quickly. For example, in the case of changing the type of details that have a composite data type, the composition of those entered based on objects, etc. It is at this stage, due to its complexity, that improvements are lost during the update. Let's consider this situation using the example of details that have a composite data type. When generating a report on object comparison (Figure 17), the differing data in the compared configurations is presented in the form of lists containing the composition of data types, separated by commas. However, the report does not show at all what types of data were added or deleted. Of course, the report can be printed and “hidden” to identify differences. In the example under consideration, there are about 200 such objects. Obviously, the comparison process seems to be quite labor-intensive and will take about 50 hours.
To reduce the labor intensity of work when comparing objects, you can use the “Compare Cells” configuration developed by the Inform Service company. The labor intensity of work when comparing composite objects can be reduced by approximately 20 times.
The “Cell Comparison” configuration is launched in 1C:Enterprise mode and allows you to present information from the object comparison report in a visual form (Figures 18 and 19). For comparison, the capabilities of 1C:Enterprise 8 are used.
The configuration scheme is simple. In the configurator we create a report on comparison of objects (Figure 17) and save it to a file, for example Comparison Report.mxl. Open 1C:Enterprise and in the dialog (Figure 18) select the saved file and indicate the cells to be compared. To do this, double-click the right mouse button on the selected cell of the spreadsheet document. By clicking the “Compare” button, we get the result of the comparison, in which the different positions are highlighted in color (Figure 19).
Further, based on the fact that the comparison is performed according to the same principles of comparing objects, the action diagram will look like this. Save the next report under the same file name. Click the “Update” and “Compare” buttons. More detailed description This processing can be viewed here “Comparison of cells”.
Particular attention should be paid to RLS templates for changed user roles.
After completing the update and transfer of previously made changes to the standard configuration, we will perform syntactic control of the modules and check the operation of the changed objects. After successful testing, the configuration update process can be considered complete. Now all that remains is to update external printed forms, reports and processing. For some configurations, it is necessary to check the reporting forms connected as external ones.
Stage 3. Delivery of work
In the example given, the amount of work to correct errors made during previous updates, as well as updating to version 1.2.14.1 and transferring changes previously made to the standard configuration is about 100-150 hours. It is not possible to carry out such a volume of work by updating directly in the customer’s database. Accordingly, preparatory work must be performed on a copy of the database, and the result of the update must be transferred to the customer’s working database.First, we carefully study the instructions from the distribution kit. We carry out the necessary work before updating the working database.
If no configuration changes were carried out in the customer’s working database during the preparation of the update, and the update was prepared on a current copy of the working database, then to transfer the settings, save the working configuration to a file, for example work_2.cf, by selecting the menu item “Configuration” → “ Save the configuration to a file...".
- Using the work_2.cf file, we transfer the changes. To do this, select the menu item “Configuration” → “Load configuration from file...”;
- When asked about updating the database configuration, we will answer yes.
If the update was not prepared on a current copy of the working database, then to transfer the settings we will use the technique used in the first stage. To do this, we need a *.cf file of the standard configuration of the supplier (1.2.14.1) and the result of the update in the form of also a *.cf file. To do this, save the working configuration to a file, for example work_2.cf, by selecting the menu item “Configuration” → “Save configuration to file...”.
Further actions on the customer’s side will be as follows:
- create a database backup;
- Using the *.cf file of the standard configuration of the supplier, we will perform the update. To do this, select the menu item “Configuration” → “Support” → “Update configuration”, “Select update file”, “Finish” (Figure 10), “Run”;
- Using the work_2.cf file, we transfer the changes. To do this, select the menu item “Configuration” → “Compare, merge with configuration from file...”;
- Let's save the changes to the working configuration and update the database configuration. To do this, select the menu item “Configuration” → “Update database configuration”.
Proper execution this stage will allow you to avoid the work described in Stage 1 in the future.
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.
Loading...
