Consider a typical situation that newbies often find themselves in. Let's say there is a typical configuration 1C: Comprehensive Automation 8. Initially, the configuration was installed from the distribution kit (for example, release 1.1.20.1). Then, due to the need to adapt to the specifics of the enterprise, the ability to change was included (newcomers very often mistakenly call this action withdrawal from support, although in reality it is not).
And now, after a while, we have a highly modified, but still typical (for the purposes of regulated accounting, we regularly updated) configuration. And then we will consider several hypothetical situations:
1) After some time after the next update, we receive a message from the accounting department about an error that comes out at the time of the routine closing of the month operation. Before that, there was no such error, therefore the update is to blame. It is quite a typical situation. We begin to diagnose the error and see that the legs grow from the general module of VAT ACCOUNTING 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" to another common module). In view of the intricacies 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, 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 promptly send the distribution kit - fine, but suppose he is not there, and the problem needs to be fixed urgently. (Do not offer Varese!). Moreover, the Internet may not exist, and what to do in such a situation? I have repeatedly witnessed the process when a person, to solve this problem, installed a new base from the existing original distribution kit, and then consistently updated it to the last one in order to see "how it should really be" in a clean base. And the chest, as always, just opened :)
Now let's look at various solutions:
a) First option: Menu -> Configuration -> Compare configurations, then select the vendor configuration and compare it with the main configuration.
Surprisingly, there are those who do not know about it. Or, under any circumstances, use the Compare item, combine with the configuration from the file (having previously obtained / received a typical.cf).
b) The second method is suitable if we need not only to see the changes, but also to immediately perform the merge.
Menu -> Configuration -> Support -> Support settings and at the bottom we press the Compare, merge button.
2) Another situation: let's say we changed or deleted some piece of the typical code, and after a while it turned out that we made a mistake and we need to return everything back. And as often happens, there is no backup of the saved configuration before the changes are made. But we know for sure that this piece of code is contained in a typical one, so the vendor's configuration would solve the problem.
Naturally, you can do as in the first case. Wait until the end of the comparison process, and open a typical module from the configuration comparison window and copy the code from there.
Some do just that, but if we are dealing with a monster of the SCP type, which is also heavily modified, then the end of the comparison process can be expected for a very long time. If we had a .cf file, we could simply open it in the configuration window (by the way, not all newbies know about this feature either) and copy the required code from there.
And a reasonable question arises, how can you save the supplier's configuration to a file? Why is there no menu item similar to Save configuration to file for main configuration or Save database configuration to file for database configuration. And where is the same for the vendor configuration? In fact, he also exists, only buried a little deeper. Namely, everything is in the same form of support settings.
It's just that many open this form only once only to enable the possibility of change and never return to it.
And in our case, it was even easier to do it, even without saving the configuration to a file, by clicking the Open button. The effect is the same, but much faster.
What else might you need to save the vendor configuration to a file?
3) Consider the following situation. Let's say at the initial stage of the existence of the configuration in the standard one did not have the functionality we needed and a decision was made to revise it. The revision was minimal, but in the future it still created inconvenience when updating. But then, after some time, we discover that this functionality (as it once was with object versioning) appeared in the standard one (and, as often happens, it is implemented an order of magnitude better than the "handicraft" revision).
I will give a few more examples of real situations when a rollback to a typical configuration may be required:
1. A couple of times I came across configurations in which only layouts of printed forms were modified. Due to lack of experience or unknowingly, the programmer who accompanied the configuration, instead of creating an external printable, removed the configuration from support and modified the built-in layouts (often trivial to add a company logo), after which users were deprived of the automatic update mode.
2. Again, due to ignorance of the typical functionality (very often the former "sevens" suffer from this), instead of using properties and categories, the requisites of directories / documents were added when there was no good reason for this (for example, the data was used only for output to printable forms).
Of course, this is not a problem, if we are dealing with UT or another configuration of the management plan, where, in general, updates are not critical, but in this example we were talking about modified UPP or complex automation. And it turns out due to minor improvements that could be implemented without removing from full support, we have unnecessary hemorrhoids with standard updates.
There is a reasonable desire to abandon the modifications made and put the configuration back on full support. How to do it?
The only way to put the configuration back to full support is to load (not in the compare and merge mode, namely the Load configuration from file item) a typical.cf. For this, the ability to save the vendor configuration to the .cf file comes in handy. 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 should take care of saving / transferring the necessary data in advance, 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 turned out, simple opportunities available in the developer's arsenal, but ignorance of these techniques in practice can result in hours of unnecessary fuss, described above. So who knew - well done, and who did not know - take it into service and save your time.
There was a question:
How many configurations are in the infobase?
Correct answer 3
The IB structure includes:
1. Basic configuration.
2. Database configuration.
3. Provider configuration(may be absent).
4. Plus user data (documents, reference books, etc.)
The configuration defines the structure of the database and contains the algorithms that ensure the work with the data.
The developers work with the basic configuration. Users work with the database configuration.
Vendor Configuration — The original vendor configuration for a sample solution.
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 maintenance and object changes are prohibited, then two configurations are stored in the infobase - the base configuration and the database configuration.
When you enable the ability to change the configuration (command Enable changeability in the dialogue " Support setting"), Platform from the main configuration creates vendor config... The size of the IB is increasing.
Provider configuration is read-only.
To view the configuration of the supplier, select the item
Configuration - Support - Support Settings - Open.
An infobase can contain several vendor configurations, if the configuration is supported by several vendors. Such a scheme is found when using industry-specific production solutions.
1C support basics
Updating 1C can be done in user mode, in the configurator mode and in the comparison and merging settings.
Withdraw from support
In the "Support Settings" dialog when you click the Remove Support button the supplier configuration is deleted... This possibility must be used in cases where a typical solution is used as a basis for its own development and its maintenance is not planned.
If you need to unload the vendor configuration. This can be done from Support - Support Settings. In the "Support Settings" dialog, click the Save to file button.
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, not all beginners and even experienced specialists are familiar.
Consider a typical situation that newbies often find themselves in. Let's say there is a typical configuration 1C: Comprehensive Automation 8. Initially, the configuration was installed from the distribution kit (for example, release 1.1.20.1). Then, due to the need to adapt to the specifics of the enterprise, the ability to change was included (newcomers very often mistakenly call this action withdrawal from support, although in reality it is not).
And now, after a while, we have a highly modified, but still typical (for the purposes of regulated accounting, we regularly updated) configuration. And then we will consider several hypothetical situations:
1) After some time after the next update, we receive a message from the accounting department about an error that comes out at the time of the routine closing of the month operation. Before that, there was no such error, therefore the update is to blame. It is quite a typical situation. We begin to diagnose the error and see that the legs grow from the general module of VAT ACCOUNTING 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" to another common module). In view of the intricacies 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, 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 promptly send the distribution kit - fine, but suppose he is not there, and the problem needs to be fixed urgently. (Do not offer Varese!). Moreover, the Internet may not exist, and what to do in such a situation? I have repeatedly witnessed the process when a person, to solve this problem, installed a new base from the existing original distribution kit, and then consistently updated it to the last one in order to see "how it should really be" in a clean base. And the chest, as always, just opened (IMG :)
Now let's look at various solutions:
a) First option: Menu -> Configuration -> Compare configurations, then select the vendor configuration and compare it with the main configuration.
Surprisingly, there are those who do not know about it. Or, under any circumstances, use the Compare item, combine with the configuration from the file (having previously obtained / received a typical.cf).
b) The second method is suitable if we need not only to see the changes, but also to immediately perform the merge.
Menu -> Configuration -> Support -> Support settings and at the bottom we press the Compare, merge button.
2) Another situation: let's say we changed or deleted some piece of the typical code, and after a while it turned out that we made a mistake and we need to return everything back. And as often happens, there is no backup of the saved configuration before the changes are made. But we know for sure that this piece of code is contained in a typical one, so the vendor's configuration would solve the problem.
Naturally, you can do as in the first case. Wait until the end of the comparison process, and open a typical module from the configuration comparison window and copy the code from there.
Some do just that, but if we are dealing with a monster of the SCP type, which is also heavily modified, then the end of the comparison process can be expected for a very long time. If we had a .cf file, we could simply open it in the configuration window (by the way, not all newbies know about this feature either) and copy the required code from there.
And a reasonable question arises, how can you save the supplier's configuration to a file? Why is there no menu item similar to Save configuration to file for main configuration or Save database configuration to file for database configuration. And where is the same for the vendor configuration? In fact, he also exists, only buried a little deeper. Namely, everything is in the same form of support settings.
It's just that many open this form only once only to enable the possibility of change and never return to it.
And in our case, it was even easier to do it, even without saving the configuration to a file, by clicking the Open button. The effect is the same, but much faster.
What else might you need to save the vendor configuration to a file?
3) Consider the following situation. Let's say at the initial stage of the existence of the configuration in the standard one did not have the functionality we needed and a decision was made to revise it. The revision was minimal, but in the future it still created inconvenience when updating. But then, after some time, we discover that this functionality (as it once was with object versioning) appeared in the standard one (and, as often happens, it is implemented an order of magnitude better than the "handicraft" revision).
I will give a few more examples of real situations when a rollback to a typical configuration may be required:
1. A couple of times I came across configurations in which only layouts of printed forms were modified. Due to lack of experience or unknowingly, the programmer who accompanied the configuration, instead of creating an external printable, removed the configuration from support and modified the built-in layouts (often trivial to add a company logo), after which users were deprived of the automatic update mode.
2. Again, due to ignorance of the typical functionality (the former "sevens" often suffer from this), instead of using properties and categories, the requisites of directories / documents were added when there was no good reason for this (for example, the data was used only for output to printable forms).
Of course, this is not a problem, if we are dealing with UT or another configuration of the management plan, where, in general, updates are not critical, but in this example we were talking about modified UPP or complex automation. And it turns out due to minor improvements that could be implemented without removing from full support, we have unnecessary hemorrhoids with standard updates.
There is a reasonable desire to abandon the modifications made and put the configuration back on full support. How to do it?
The only way to put the configuration back to full support is to load (not in the compare and merge mode, namely the Load configuration from file item) a typical.cf. For this, the ability to save the vendor configuration to the .cf file comes in handy. 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 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 turned out, simple opportunities available in the developer's arsenal, but ignorance of these techniques in practice can result in hours of unnecessary fuss, described above. So who knew - well done, and who did not know - take it into service and save your time.
[you must register to view the link]
This article is based on many years of experience in the development and support of accounting solutions on the 1C: Enterprise platform. The article describes some fairly common situations that cause difficulties when updating atypical 1C: Enterprise 8 configurations.
This article does not describe how to apply 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 new update, the number of objects requiring your attention only increases. At the same time, you know for sure that only one document has been changed, and when you update, a list of several dozen changed objects is displayed. Of course, you can use the technique described in the article "Technology for updating atypical configurations 1C: Enterprise 7.7" dated 06/27/2003. Yes it will work. Many people do updates this way. But I think this approach is ineffective and time-consuming when updating configurations on the 1C: Enterprise 8. In contrast to the 1C: Enterprise 7.7 platform, the 1C: Enterprise 8 platform allows you to open several configurations (* .cf files) at the same time and perform several comparisons of configurations in one copy configurator. The only exceptions are, perhaps, only configurations built on the UPP (Manufacturing Enterprise Management) - they are too heavy, the platform crashes.
The process of updating configurations of 1C: Enterprise 8 is more automated compared to 1C: Enterprise 7.7. A sufficiently high level of automation can significantly reduce the complexity of work when updating atypical configurations. Unfortunately, most often the process of updating atypical configurations cannot be performed fully automatically and requires the intervention of a specialist.
Is it possible that the update process will be performed completely automatically? Of course. For this, mutable objects must be added and must not use the functionality of the existing configuration. Those. these objects must solve absolutely different accounting problems that expand the functionality of the standard configuration of the supplier. Agree that the described situation is extremely rare. Changes almost always affect the objects of the typical configuration of the supplier.
Please note that the database can contain up to three types of configurations:
- database configuration- this is the configuration that users work with;
- working configuration (the main) is a configuration that we can make changes to, while users can continue to work;
- vendor configuration is the original vendor configuration from which the operational configuration and database configuration are typically generated. The database can have multiple configurations from different vendors. The supplier of the configuration can be not only 1C.
Let us consider the update process and analyze possible errors using the example of updating the UPP configuration (the supplier of the standard configuration is 1C, revisions by Inform Service). Initially, this configuration was updated using a technology other than the one described in this article; therefore, the errors discussed in the article are the most frequently encountered in practice. The update will be performed from version 1.2.6.2 to version 1.2.14.1.
Stage 1. Preparation
In the first step, we will match the working configuration to the vendor configuration. This is a very important stage, which will significantly reduce the amount of work on the analysis of the changes we made earlier.You can skip this step if the last update went through "support" (Menu "Configuration" → "Support" → "Update configuration") or was performed according to the method described in this article.
The version mismatch between the working configuration and the vendor configuration may occur when using * .cf files that are not from the vendor's distribution kit to update, or when using update methods other than 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 vendor configuration. We look at the number of the working configuration in the menu "Configuration" → "Open configuration" menu "Edit" → "Properties". In the block "Development" item "Version". (Picture 1).
We look at the supplier's configuration number in the menu "Configuration" → "Support" → "Setting up support ..." item "Version". (Figure 2).
If the numbers match, then go to the next step. See Step 2.
In this example, you need to reconcile the operating and vendor configuration to support posting objects that were removed from support or added without provisioning. To do this, perform the following actions:
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. Obtaining the update file for the vendor configuration.
To align the configurations, we need a * .cf file from the vendor distribution with the same version number as the working configuration (Figures 3 and 4). This file can be obtained when installing the corresponding distribution kit. By default, the installation of the configuration distribution kit is performed in the C: Program Files1cv81tmplts directory. For more information on installing configuration templates, see the documentation.
Let's check the template directory. If the templates directory contains a * .cf file of the required version, then go to step 4 of Stage 1.
What can be done if there is no * .cf file of the required vendor configuration version? In this case, you can use the * .cfu files and repeat the procedure described in Stage 1 several times to raise the version number to the required release, in this case to 1.2.6.2. It should be noted that the use of * .cfu files may not reveal errors made earlier during the upgrade. Which, you see, is rather strange, given the fact that the vendor file is initially collected based on the old vendor configuration and the * .cfu file, and then the update is performed. Perhaps this is due to the fact that for some reason not all configuration objects are involved in the comparison. Therefore, I propose to use the longest possible path, but also more reliable.
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 a "new" vendor configuration, do the following:
Creating an "old" vendor file for the current configuration. The 1cv8.cf file can be taken from the vendor's distribution kit or saved from the working base if the configuration is under support. To save the 1cv8.cf file from the working base, click the "Save to file" button in the "Configuration" → "Support" → "Support settings ..." menu and specify the directory and file name. For example, on the desktop.
Create a database with a new vendor configuration. The database can be created using the vendor's distribution kit from the ITS disk or using the 1cv8.cf obtained earlier from the desktop. In the first case, 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 infobase without configuration and launch the configurator. In the "Configuration" → "Load configuration from file ..." menu, point to the file saved earlier on the desktop. 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" vendor configuration file. To do this, select the item in the menu "Configuration" → "Save configuration to file ...". We specify the location and name of the 1cv8.cf file. Click "Save".
Using the received * .cf vendor configuration file, we will update. To do this, select the menu item “Configuration” → “Support” → “Update configuration”, “Select update file”, “Finish” (Figure 5), “Run” (Figure 6).
Solution options:
- uncheck the object that is in the supplier's configuration;
- remove the reference to the object that is in the provider's 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 the configuration from the 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 following are most likely. These objects were copied to the production configuration from the supplier's configuration, or the supplier deleted these objects earlier 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 do it simply with the roles - delete, because the roles have not changed (this can be verified by comparing the old vendor configuration with the working configuration). We act differently with the details of the document. The requisite must be renamed, for example OrderReserve1, and after the update, transfer the values from the renamed attribute to the new one. To do this, you can use the processing of UniversalSelection andProcessingObjects.epf from the ITS disk.
Let's consider one more situation, similar to the previous one, but that arose when updating 1C: Enterprise Accounting 8.1. What to do with forms? (Figure 9)
In the figure, we can see that the ListForm was removed from the supplier and then a new form with the same name was added by the supplier. Accordingly, it is necessary to mark both forms for updating and press the "Execute" button.
If you receive a message that there are references to objects to be deleted, you must, without closing the update form, clear the links to the deleted form in the object's properties. In this case, in the properties of the register. After that, in the update form, click the "Update" button, mark the register properties for updating, and click the "Execute" button again.
Let's save the changes in the working configuration and update the database configuration "Configuration" → "Update database configuration".
If necessary, transfer the values of the OrderReserve1 variable to the OrderReserve using external processing in 1C: Enterprise mode.
Stage 2. Update
After completing the preparatory work at Stage 1, we proceed to updating the main configuration and transferring the previously made modifications to the typical configuration of the supplier.To update the configuration, we need a * .cfu file or a * .cf file from the vendor distribution.
If the update is performed after several versions of the configuration, then you should pay attention to the situation described in the article "Updating the configurations of 1C: Enterprise 8. Leap through 20 versions". If the update is not performed on a production base, then after completing the preparation of each new stage, save the * .cf files. They will be needed when updating the configuration of the customer's production database.
If the update is performed after several versions, then during the update, be sure to pay attention to the deleted objects and objects with changed names, as well as to the actions performed at the first start 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 abandoned objects can be deleted during the next or next update.
If the update is performed after several versions, then to reduce the complexity of the update, you can use the methodology with the calculation of key releases, described in the article "Updating configurations of 1C: Enterprise 8. Leap through 20 versions".
1. Preparation of databases.
So, according to the results of the first stage, we are preparing two identical bases. The first (main) is our future result. The second (auxiliary) is for performing comparisons, opening configurations and other preparatory actions. For the file version, it is just copying the files of the main database to another directory and connecting this directory to the list of databases, for the client-server one - upload / download.
2. Three-way comparison of configurations.
Let's open both bases in the Configurator mode and perform a three-way comparison of configurations in both bases using the existing file of the new vendor configuration. To do this, in both databases, select the menu item "Configuration" → "Support" → "Update configuration", "Select update file", "Finish" (Figure 10).
Comparing the three configurations (old vendor configuration, new vendor configuration, and working configuration) results in a list of changed objects. Set the filter "Show only twice changed properties" (Figures 11 and 12).
It is with these objects that you need to deal with first of all, because after updating, previously made settings may be lost.
At this, we pause the work in the second (auxiliary) base and continue in the main one. You do not need to press the Run button in the auxiliary base. We need this database in this form until the end of the update process.
So, as a result, we get a list of objects that were changed twice during the finalization of the standard configuration and in the new configuration of the supplier. If you agree with the update, then the improvements made earlier in 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, fast - "by eye".
If there are more changes in the object in the new configuration of the provider, then we leave the instance of the provider object. We leave a check mark. 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 the instance of the object in the working configuration. Uncheck the box. Then we will move the changes from the vendor configuration.
We do things a little differently with modules, because we have the ability to compare modules procedurally. Those. if various module procedures have been changed in our configuration and in the vendor's configuration, then by correctly placing the checkboxes, we will save ourselves the trouble of 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 checkmarks, we duplicate the state by checkboxes in the auxiliary base, and in the main base we press the "Execute" button. In the main database, we get an almost ready-made configuration.
Further, all comparisons are performed in the auxiliary database. We already have one comparison - a three-sided one. To determine the previously made changes, we perform an additional second comparison of the old vendor configuration with the main configuration. To do this, select the item in the menu "Configuration" → "Compare configurations:", select for comparison "Supplier configuration" and "Basic configuration" (Figure 16).
Similarly, we compare the old vendor configuration with the new one. For comparison, we need a new vendor configuration file. If there is no such file, then now it can be obtained from the main database. To save a 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). We indicate the name of the file, for example, new.cf. Next, we make the third comparison of configurations and, when comparing, specify the new.cf file as the second configuration.
So, we got a list of twice changed objects in the additional database. And two more comparisons that will help us more efficiently transfer the previously made settings from the old version to the new one. In the main database, we got an almost ready-made configuration, in which we need to deal with twice changed objects.
To reduce the time spent on analyzing changes to the typical configuration and, accordingly, on updating, it would be appropriate to comment on all changes made to the configuration, noting not only the modified 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 the changes, but in their consequences. Namely, the need to maintain the functionality of the changed configuration. Perhaps this will require not transferring the changed lines, but a complete reworking of the added (changed) code for the functionality of the new supplier 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.
However, in some cases, the data in the comparison reports is presented in a way that does not allow you to make a quick decision. For example, in the case of changing the type of attributes that have a composite data type, the composition of the input 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 attributes that have a composite data type. When generating a report on object comparison (Figure 17), the differing data in the compared configurations are presented in the form of lists containing the composition of data types, separated by commas. At the same time, the report does not show at all which types of data were added or removed. Of course, the report can be printed and "hidden" to reveal the differences. In the example under consideration, there are about 200 such objects. Obviously, the comparison process seems to be quite laborious and will take about 50 hours.
To reduce the complexity of work when comparing objects, you can use the "Comparison of cells" configuration developed by Inform Service. The labor intensity of work when comparing composite objects can be reduced by about 20 times.
The configuration "Comparison of cells" is launched in 1C: Enterprise mode and allows you to present information from the report on the comparison of objects in a visual form (Figures 18 and 19). For comparison, the capabilities of 1C: Enterprise 8 are used.
The configuration workflow is simple. In the configurator, create a report on the comparison of objects (Figure 17) and save it to a file, for example, ReportOnCompare.mxl. Open 1C: Enterprise and in the dialog (Figure 18) select the saved file and indicate the compared cells. 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 comparison result, in which the differing positions are highlighted in color (Figure 19).
Further, assuming that the comparison is performed according to the same principles of object comparison, the action diagram will look like this. Save the next report under the same file name. Press the buttons "Update" and "Compare". A more detailed description of this processing can be found here "Comparison of cells".
Particular attention should be paid to RLS templates for modified user roles.
After completing the update and transfer of the 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 it remains to update the external printing forms, reports and processing. For some configurations it is necessary to check the reporting forms connected as external.
Stage 3. Delivery of works
In the given example, the scope of work on fixing errors made during previous updates, as well as on 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, the preparatory work must be performed on the 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 in the working base.
If in the customer's working database during the preparation of the update, no work on changing the configuration was carried out, and the update was prepared on the 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 configuration to file ... ".
- using the file work_2.cf, transfer the changes. To do this, select the menu item "Configuration" → "Load configuration from file ...";
- to the question of updating the database configuration, we will agree.
If the update was not prepared on the current copy of the working database, then to transfer the settings, we will use the technique used at the first stage. To do this, we need a * .cf file of a typical vendor configuration (1.2.14.1) and the result of the update in the form of a * .cf file as well. 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 backup copy of the database;
- using the * .cf file of a typical vendor configuration, we will update. To do this, select the menu item "Configuration" → "Support" → "Update configuration", "Select update file", "Finish" (Figure 10), "Run";
- using the file work_2.cf, transfer the changes. To do this, select the menu item "Configuration" → "Compare, merge with the configuration from the file ...";
- save the working configuration changes and update the database configuration. To do this, select the menu item "Configuration" → "Update database configuration".
Correct execution of this stage will allow avoiding the work described in Stage 1 in the future.
