Let's consider the update using the example of a non-standard configuration of SCP 1.3, which is supported with the possibility of changing from release 1.3.61.2 to release 1.3.62.1. Since the configuration itself is quite heavy, this imposes some peculiarities, in particular, it is not always possible to open several configuration comparison windows in one configurator.
For the update, I use two identical copies of the old release database. I do my training in one of them *.cf for updating, let's call it, for example, for_updating. The other database remains untouched and serves only as an auxiliary database for comparing configurations, let’s call it base. In principle, the configuration of the working base can be used as an auxiliary one.
In the database for_updating we carry out *.cfu new release. The update procedure begins and the update window appears.
Press the button " Execute", on at this stage There is no need to look at anything yet, since the goal is only to obtain the vendor configuration of the new release.
During the update process, a “ Unresolved links", click " Continue" We will talk about the reasons for the appearance of this window below.
A message will appear stating that the objects we changed will be loaded from new configuration, we agree.
The window “ Setting up support rules" - for new objects (top section) on both sides set " The object is edited while maintaining support", for existing supplier objects (lower section) in all four places we set the flag " Save current mode", click " OK».
The main configuration has been updated. We do not need the main configuration itself at this stage; the goal is to obtain a new supplier configuration. Therefore, we do not save the main configuration and do not update the database configuration.
Execute " Configuration» - « Support» - « Setting up support" In the window that opens, select “ Save to file"and save it in *.cf new release vendor configuration.
Basic configuration as it appears on this moment available, we don't need it. Close the configuration. " Configuration» - « Close configuration" We refuse to save changes.
In configuration for comparison base we start comparing the supplier configuration (old release) and the supplier configuration from the file (new release).
Thus, we will see only those changes that will be made in the configuration when updating to a new release.
In the database for_updating we start updating the configuration again through support “Configuration” - “Support” - “Update configuration”, in the window that opens, select *.cfu new release. The update procedure begins and the update window appears.
When you press the button " Filter"window will open" Setting up viewing filters" In this window, set the flag “ Show only twice changed properties».
When updating without our intervention, the following happens:
- - the object has not been changed by us, changed in the new release - updated from the new release;
- - the object is changed by us, not changed in the new release - our object remains;
- - the object was changed by us, changed in the new release - this is a twice changed object, if you don’t change anything, it will be loaded from the new release.
Thus, the closest attention should be paid to twice changed objects, and we will consider them.
IN in this example several common modules have been changed, including the common module "VAT accounting».
By default, the update window shows the differences between the main and new provider configurations from the old provider configuration.
If you look at the configuration differences in the common module " VAT accounting", then we will see the following picture:
If we compare these modules in the comparison databasebase, then the picture will be different:
It is obvious that the functions " Collect data for printing, corrections, invoices, invoices», « Collect data for printing the adjustment invoice" and others contain our improvements, but do not change during the update, which means there is no point in wasting time viewing and analyzing them.
Therefore, when performing a procedural update from selected procedures and functions, you can remove the flags:
Many will say that you can see the differences between the old supplier configuration and the new one by changing the viewing filter settings in the current configurator, without using a comparison of configurations in the databasebase.
For example, like this:
However, as shows practical experience this is not the case, procedures and functions are still displayed in the module comparison window, even with the filter " show differences between the new provider configuration and the old provider configuration».
With a little mental effort, we will identify the twice changed procedures and functions, only they will need modifications after the merging process. With these procedures and functions, you need to decide which is easier:
- - either take a procedure or function from the new supplier configuration and then, after merging, make our modifications;
- - either remove the update flag, thereby saving our improvements, and only then add required code from the provider configuration.
I rarely use merging with the priority of the main configuration and merging with the priority of the new supplier configuration; in principle, even without using these modes, the result will be of high quality.
After the common modules have been analyzed and the update flags for some procedures have been cleared, we see that the modules are now set to the merging mode - individual settings:
Let's move on. Among the twice modified objects there is the form of the directory element " BasicMeans" Before deciding whether to update this form from the new vendor configuration, you need to find out what actually changes during the update.
To do this in the database base by using context menu let's call " Object Comparison Report...” All the flags in the “Objects” group should be in the window that opens.
I like the mode of outputting the report to a spreadsheet document, when the differences are shown graphically, but this is a matter of taste.
As a result of comparing the shape of the directory element " BasicMeans“We see that there are changes only in the form module, and there are no changes in the form dialog in the update.
But since the form of the element ended up in twice changed objects, our modifications are either in the form dialog or in the module.
By performing a similar comparison in the database for_updating you can see that there are improvements in the form dialog.
The reason for this is the addition of the directory " BasicMeans» in terms of types of characteristics « Object Properties" If you update the form of a directory item " BasicMeans"we will get unresolved links, which will be indicated by the window:
In this case, the most the best option will not update the directory item form " Basic facilities"and only then add the necessary code to the element form module. In this case, the window Unresolved links"will not appear during the update.
Let's take a step back and imagine that the dialog of the directory element form " Basic facilities" changes when updating to a new release, then the best option would be to update the form. Only then, after merging, we would need to add our changes to the form, both in the module and in the dialog. If a module contains a lot of our modifications and little from the supplier, then after merging we can completely return our module and add the supplier’s changes.
In this case, during the merging process the window “ Unsolvable tags" There are two options in this window: 1) “ Mark all for merging"; 2) " Continue».
In my opinion, it is more correct to choose " Mark all for merging».
In this case, the plan of characteristics types " Object Properties" will be added as an object to be combined in the tree in the newly opened window " Update…»
Naturally, after updating the characteristics types to the plan, “ Object Properties"We will need to add our changes, make it better by comparing and merging with the current configuration.
Let's consider what would happen if we chose " Continue" in the window " Unresolved links" In this case, the form of the directory element " BasicMeans"would become new, and the plan of types of characteristics " Object Properties"would remain old. In this case, we will overwrite changes in the directory element form dialog, namely on the page “ PropertiesValues", see picture below.
This problem is also not insurmountable, unless, of course, we forget about it.
Of course, it is best to try to make as few changes as possible to form dialogs , for example, create details and buttons on the form programmatically.
Many generally recommend not changing the standard forms, but creating copies of them with our modifications and making them the main ones. To me this option I don’t like it because if the supplier added something in the form dialog, it will not appear on my form and I will have to add it manually, and the supplier’s changes may be much more numerous than ours.
I would like to pay special attention according to procedural updating forms (I take some procedures from the supplier’s configuration, and some not - individual settings). Let's consider how this mode The form dialog is updated in contrast to the “take from the vendor configuration».
The example has nothing to do with this update configuration, but indicative, so let's consider it.
To the reference book " Counterparties» several details have been added and placed on the element form.
When updating the configuration to a new release through support, a window will be offered to compare and combine the configuration, in which you can make various settings. Let's compare several options:
1. The form update flag is set, but the update is done procedurally , i.e. in fact, individual settings have been completed
Many people think that the form dialog should be taken from the vendor configuration, and the procedures depending on the settings made. Let's see how this is true after the merge is completed. Let's compare the supplier configuration with the main configuration.
It is obvious that the bindings and so on on the forms have been broken, i.e. The form dialog was not completely taken from the provider configuration. In this case, our objects remained in the form dialog, on the one hand this is good, on the other hand, the location of our elements on the form is not always optimal, especially in connection with the addition of new supplier elements, there is a change in traversal positions and violation of bindings. In some cases, it is easier to manually add our elements to the form dialog than to make corrections.
2. The form update flag is set, the update is done in the “ Take from new provider configuration»
In this case, the element form dialog is completely brought into line with the supplier element form dialog.
Let's get back to the update. We treat object modules and document manager modules in the same way as with general modules; we update them procedurally. We deal with document forms in the same way as we did with directory forms.
Separately, it is necessary to highlight the work with roles. Despite the fact that the example does not require updating roles, it is worth talking about it. Let's consider the simplest case, when the supplier configuration contains new object. In this case, you will need to update the role "Full rights", but this role may contain some objects created by us, for example, directories, documents, etc.
It seems that with the role " Full rights“Everything is simple, we combine them completely, the rights to non-standard objects will be preserved in them anyway. That’s right, rights to non-standard objects will never be lost, but all these objects will have the “ Interactive removal", which is not always good. When comparing the configurations of the old release and the prepared new release, this is clearly visible:
With the rest of the roles we act in the same way as we work with modules - if there are more of our changes, then we do not merge the role, after the update we add to it what the supplier added in the new release.
After we have processed all the twice changed objects in the update window, click “ Execute»
To the question that the objects we changed will be loaded from the new configuration, we answer in the affirmative.
In the window that opens " Setting up support rules"check whether the flags are set, although they should be set correctly by default, click " OK».
At the end of the merging process, we save the main configuration; we do not update the database configuration yet.
Now to the configurationfor_updatingWe add those minimal improvements that could not be updated correctly using standard tools.
To make it more convenient to monitor the implementation this process, in the database base Let's start comparing the vendor configuration and the main configuration of the old release.
In the database for_updating we'll do the same. We control twice changed objects, there should be no differences.
After the update in the databasefor_undatingwill be completed, we update the database configuration and test some points, what exactly would be good to test will become clear during the update process, everything is individual here.
It is advisable to update the working database with the help of support“Configuration” - “Support” - “Update configuration”.In this case, twice changed objects will be loaded from the new release, i.e. our changes will be overwritten (we don’t save the configuration!), but then, when combined with the prepared configuration, we restore them. After this, you can save the configuration and update the database configuration.
In this manual atypical update changed 1s 8.3, I will not describe basic things, such as: how to open the configurator, what is the database configuration, supplier configuration and main configuration. A lot has been written about this, and you can find this information on your own on the Internet. I will try to describe the main points of the update process and what you need to pay attention to.
I took atypical accounting 3.0.51.22 as an example and will show you how to update it to version 3.0.53.29. On platform version 8.3.10.2561 (there is no big difference on older platforms, the comparison window just looked a little different before).
I’ll say right away that there will be a lot of pictures and little text. I find it easier to remember a process visually than to read a sea of text.
1. Check that the database configuration matches the vendor configuration.
For this you need
If there is a match, you can safely move on to step 2.
1a. Setting up the configuration for support.
If your database version and the vendor configuration version are different, then you need to delete the current configuration through the same menu: configuration - support - support settings. And click the “Withdraw from support” button.
After a “short” wait, we uncheck all the boxes. Well, you can uncheck the “Save settings automatically” checkbox. And click execute. 
As a result, we will get a supported configuration with the same database versions.
2. Update the database.
Now you can proceed to the update.
Let me tell you right away that the update should be done ONLY through the menu “Configuration” - “Support” - “Update configuration...”.
You CANNOT use “Compare, merge with configuration from file...”!!! When using this mechanism, you will have to go to step 1a the next time you update. Therefore, let's not do this and create unnecessary problems for ourselves (or the person who will update the database next time). 
Next, select the update file.
I would like to talk about updating after several releases. 1C does not recommend updating CF files, jumping through several releases at once. This must be done consistently. In theory this is correct.
I will explain why this is not recommended. If programmers want to delete any props, they first assign the prefix “delete” to it, then after several releases they delete it. And they can transfer information from it in some release. By skipping this release, you may lose data. But in practice, in my 10 years of working with 1C databases, I had one such case. When for some reason the developers decided to transfer data from the listing to the directory. However, this did not end in anything critical for me. I wrote a simple processing that transferred this data from the archive to the current database. There was no need to do any re-updating.
You can throw stones at me, but I always update the database via cf files for several releases.
So we clicked update, a message popped up telling us which version the update would be made to. We click OK.
We are waiting for the comparison of objects to take place.
Next, we need to select “show only twice changed properties” from the list at the bottom. 
I also want to say that according to the old versions, before it was a checkbox.
So, we now see much fewer objects.
If yours is empty, then you are incredibly lucky, and you can safely press the “run” button and consider the update complete. Well, not everything is so simple here, so I’ll go over the main objects.
The first thing I want to say. Do not switch the merge mode under any circumstances. It should be “Take from new supplier configuration”. Otherwise, you will end up with garbage in the database with the MGR comment.
No “show differences in modules...” buttons.!
Click on the gear icon next to the module
A window opens in which there are a lot of changes in functions and procedures.
In order to understand which function there were changes, we will need to either take a copy of the database, or save the configuration to a file through the configuration menu. And then load it into an empty database. Next, go to the “configuration” menu and click “Compare configurations...”
Select Compare Basic Configuration with Vendor Configuration.
And now you can see the changes through “show differences in modules...”. Because we are not going to change anything, we just want to see what has been changed.
And we see that a piece of code has been added to the “Slope” function. All changes can be viewed by clicking on the blue arrows.
Let's return to the updated configuration. There we used the gear icon to enter the mode of combining modules. Next, check all the boxes... manually... saying to yourself “thank you” to the platform developers :)
We find our decline function. Finding the changed element. I hope it is now clear why you need to separate any added code with comments - correctly, so as not to guess when updating where this code came from.
Click the magnifying glass icon, and the platform will highlight the line of code where you need to add this text.
Copy it from the top window and paste it into the bottom window.
Do this with all modules. If the module has not been changed, as in our case with the currency directory. We simply set the mode to “Take from the new supplier configuration” and DO NOT click on the gear (there should not be a green check next to the gear, this means that the code will be completely taken from the new configuration, without manual configuration).
Great. Now, after going through all the objects, you can uncheck “save settings automatically” and then “execute”
To the message “There are objects that have been changed in the main configuration in relation to the old configuration... When updating, these objects will be replaced! Execute? We boldly click YES.
In the next window, leave the checkboxes as shown in the picture. And nothing else!!! Both checkboxes must be checked - “objects are edited while maintaining support.” Click OK.
All. The update of the non-standard 1c configuration is completed.
This method is not meant to be perfect, but I think many people make mistakes in these steps.
Of course, I haven’t told you everything, there are still many pitfalls. But I think 90% of updates can be safely updated using these instructions.
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. 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. A fairly high level of 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 completed completely in automatic mode and requires specialist intervention.
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 – This is the initial configuration of the supplier, on the basis of which working configuration And database configuration. A database can have multiple configurations from different vendors. The configuration supplier can be not only 1C.
In case the configuration is removed from support, vendor configuration will not be. Which in turn significantly increases the complexity of the update.
Let's look at the update process and analyze possible mistakes using the example of updating the configuration of the soft starter (the supplier of the standard configuration is 1C, 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 bring into correspondence working configuration To vendor 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” U94; “Support” U94; “Update configuration”) or was performed according to the method described in this article.
Version mismatch working configuration And vendor configuration may occur when you use *.cf files for updating that are not from the supplier’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 working configuration And vendor configuration. Number working configuration look in the “Configuration” menu U94; “Open configuration” menu “Edit” U94; "Properties". In the “Development” block, select “Version”. (Picture 1).
Number vendor configuration look in the “Configuration” menu U94; "Support" U94; “Support Settings...” item “Version”. (Figure 2).
If the numbers match, then move on to the next stage. Cm. .
In this example, it is necessary to align working configuration And provider configuration with support for objects removed from support or added without support. To do this, perform the following steps:
2. Saving the working (main) configuration.
Let's save working configuration to a file, for example work.cf. To do this, select the menu item “Configuration” U94; “Save configuration to file...”.
3. Obtain the update file for the provider configuration.
To match the configurations, we need a *.cf file from the supplier's distribution with the same version number as 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 Files\1cv81\tmplts\ 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 .
What can you do if there is no *.cf file of the required version? 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 *.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 "old" vendor configuration. Update provider configuration to the required version and use it when performing work at stage 1. For getting "new" vendor 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, you need to go to the “Configuration” menu U94; "Support" U94; “Support setup...” 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 "Configuration" menu U94; “Load configuration from file...” indicate the file previously saved on the desktop. Open the configuration through the “Configuration” menu U94; “Open configuration” and update to the desired release through the “Configuration” menu U94; "Support" U94; “Update configuration” using *.cfu files.
Create a "new" provider configuration file. To do this, select the item in the “Configuration” menu U94; “Save configuration to file...” We specify the location and name of the file 1cv8.cf. Click “Save”.
4. Matching the operating configuration and the supplier configuration through an update.
Using the resulting *.cf file vendor configuration Let's update. To do this, select the menu item “Configuration” U94; "Support" U94; “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.
Based on the fact that the link in the added “Department Head” interface is made to the object vendor configuration, support from which has been withdrawn by the supplier (possibly due to a change in accounting methodology), then the right decision in this situation, the link to this report will be removed from the “Head of Department” interface. We do not close the configuration comparison window; we delete the link to the “Payment for Orders” report in the “Department Manager” interface. After removing the link, we will compare the configurations again. To do this, click the “Update” button in the update window (Figure 6).
5. Restoring settings partially lost at the previous stage.
To restore partially lost settings, merge with a previously saved file working configuration work.cf. To do this, select the menu item “Configuration” U94; “Compare, combine with the configuration from the file...”.
6. Saving the update results.
Let's save the changes working configuration and update database configuration. To do this, select the menu item “Configuration” U94; "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 have been copied to working configuration from vendor 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 and working 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 working configuration and update database configuration"Configuration" U94; "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 the update basic configuration and transfer of previously made modifications to the supplier’s standard configuration.
To update the configuration, we need a *.cfu file or a *.cf file from the supplier's distribution. You can read more about how to obtain them.
If the update is performed through several versions of the configuration, then you should pay attention to the situation described in the article. 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.
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 supplier's new configuration file. To do this, in both databases, select the “Configuration” menu item U94; "Support" U94; “Update configuration”, “Select update file”, “Finish” (Figure 10).
As a result of comparing three configurations ( old vendor configuration, new vendor configuration And working configuration) we get 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 revision typical configuration and in . 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”.
new supplier configuration, then we leave an instance of the supplier object. Leave a checkmark. Then we will transfer the changes from working configuration.
If there are more changes in the object in working configuration, then we leave an instance of the object working configuration. Uncheck the box. Then we will transfer the changes from vendor configuration.
We deal with modules a little differently, because... We have the opportunity to compare modules procedurally. Those. in case in our configuration and various module procedures have been changed 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 old vendor configuration With main configuration. To do this, select the item in the “Configuration” menu U94; “Compare configurations:”, select for comparison “ Provider Configuration" And " Basic configuration
In a similar way we compare old vendor configuration with new one. For comparison we need a file new supplier configuration. If there is no such file, now it can be obtained from the main database. To save to a file new supplier configuration in the main database in the “Configuration” menu U94; "Support" U94; “Support setup:” 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 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).
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 the external ones 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 “Configuration” menu item U94; “Save configuration to file...”.
- Using the work_2.cf file, we transfer the changes. To do this, select the menu item “Configuration” U94; “Load configuration from file...”;
- When asked about updating the database configuration, we will answer yes.
If configuration changes were carried out in the customer's production database during the preparation of the update, then these changes must also be reflected during the update.
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 “Configuration” menu item U94; “Save configuration to file...”.
Further actions on the customer’s side will be as follows:
- create backup copy Database;
- Using the *.cf file of the standard configuration of the supplier, we will perform the update. To do this, select the menu item “Configuration” U94; "Support" U94; “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” U94; “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” U94; "Update database configuration."
Personal experience: how to quickly and cost-effectively update a changed configuration
Updating the configuration for several releases at once is very dangerous. The fact is that after each configuration update, an update of the infobases is started in 1C:Enterprise mode. Therefore, if you update only the latest release, the infobases may not correspond to the latest configuration. In the article, Dmitry Rudakov, a specialist at Siberian Agrarian Group CJSC, shares his personal experience in simultaneously updating the configuration for 12 releases.
Checking configuration change mode
Let's imagine such a situation. The developers of “Manufacturing Enterprise Management” (hereinafter referred to as PPE) in release 1 (release numbers hereinafter are assigned conditionally) assigned the dimension (indicator) of the calculation register the type “Directory Link.Individual” with the name “Individual”. In release 2 they added another dimension - “Employee” with the type “DirectoryLink.Employees”. When you start "1C:Enterprise", processing is turned on, which fills the "Employee" dimension in a manner corresponding to the dimension for "Individual". And then in release 3, the 1C developers removed the “Individual” dimension and left only “Employee”. If you update the configuration from release 1 immediately to release 3, you can clear the entire calculation register.
And if the configuration is supported with the possibility of change, and regulated reporting is generated in the same database, then it is necessary to update the configuration for each release, which can be very expensive in man-hours. For example, updating a heavily modified "UPP" for 1 release may take 30 hours of an experienced specialist's working time.
Therefore, before you start updating, you need to determine: are you working in a standard configuration with the ability to change or in a configuration without the ability to change? To do this, go to the configurator, where in the menu follow the steps “Configuration - Support - Support Settings”.
Fig.1. Calling the configuration support setup window
If it is set to “On support”, then this configuration is typical, and if “Possibility of modification is enabled”, the configuration has most likely been changed (at least, such a possibility is included). The third state is "The configuration is no longer supported." The different configuration states are shown in Figures 2, 3, 4.
Rice. 2. Standard configuration without possibility of changes
Rice. 3. Typical configuration with the ability to change enabled
Rice. 4. Deprecated configuration
Algorithm for updating changed configurations
Recently I was faced with the task of updating the modified Trade Management configuration, release 10.3.13.2. The configuration was changed as a result of integration with the industry solution "BIT: Automotive Service Management 8" and was continuously improved over the course of two years. Now the configuration needed to be updated to release 10.3.25.1, that is, 12 releases. I have divided the entire update procedure into several stages.
Stage 1. Estimation of the cost and timing of the update procedure
Before starting independent work, I decided to get an independent assessment from specialists in this field. The only company that has the ability to update changed configurations using automated methods is 1C-IzhTiSi LLC. I turned to the specialists of this company with a request to estimate the cost of updating my configuration. To estimate the time and cost of the work, I have provided the current configuration that needs updating. A day later I received a letter with the report.
Report on the results of assessing the cost and timing of the configuration update:
Configuration: Trade Management, edition 10.3
Current configuration version: 10.3.13.2
Update to version: 10.3.25.1
Number of updated modules: 1,847
Number of control releases: 8
The results of the assessment surprised me, since the company’s website indicated the price per share - 1000 rubles. per update per release. Comment from "1C-IzhtiSi":
“The cost of an update for each missed release is no more than 2,000 rubles. There is currently a promotion going on, so the cost does not exceed 1,000 rubles. But the final price of services is determined by assessing the labor costs for the update and may be less than 1,000 rubles per release.”
I also clarified how the releases required for the update were selected. In response to my question, I received a screenshot in which this was clearly demonstrated (Fig. 5). The Version Number column indicates the configuration version to which you need to upgrade. The "Version Upgrade" column indicates from which release an upgrade is possible. As a result of the assessment, the number of required updates was reduced to 9.
Rice. 5. Selecting releases that must be used to correctly update the configuration
After studying the 1C-IzhTiS report, I calculated the personal time costs for the same amount of work. Each update takes me approximately 6 hours. Therefore, the total time cost is 56 (9x6) working hours, that is, approximately seven working days. In addition, there is a possibility that after the update some shortcomings will be revealed: for example, the user will complain that the configuration changes he needed were lost, and then the time costs will seriously increase. Meanwhile, specialists from the 1C-IzhTiS company offer to complete the entire amount of work in three to four working days. Therefore, I decided to use their services.
Now I will briefly explain what exactly was changed in the configuration.
Heavily modified objects. These are objects in which many typical properties have been changed. The adjustments are complex. Object details have been added to tabular part, displayed on the object form and on the list form. Handlers for added details in forms have been added. The standard mechanism for posting a document or recording a set of movements for a register has been changed.
Heavily modified documents:
"Order to supplier";
"Movement of goods";
"Requirement-invoice";
"Receipt of goods and services."
Heavily modified registers:
"Consignments of goods in warehouses";
"Goods in warehouses."
Significantly modified objects. Objects in which details have been added, either object forms or object modules have been changed (as a rule, document posting is atypical).
Document "Cash receipt order";
Register of information "Component parts";
Register of information "Writ-off goods";
General modules.
Slightly modified objects. Only the forms in the objects have been changed and details have been added.
Directories:
"Types of nomenclature";
"Contractors' agreements";
"Counterparties";
"Nomenclature";
"Item price types";
"A number of information registers."
In the "General" section, subscriptions to events, layouts, roles, and general modules have been changed. Almost everything has been changed by industry decision.
Stage 2. Removing confidential information
Before providing 1C-IzhTiS employees with an information base for testing, confidential information must be deleted from it. For such cases, 1C recommends using the “Change of Confidential Information” processing, which is not very widely known.
The “Change of Confidential Information” processing is intended for selectively changing or clearing information in the infobase.Processing can be used to prepare an information base before transferring it for testing, where it is necessary to hide (clear, change) some information.
Processing ChangeConfidentialInformation.epf is on the ITS disk in the directory 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Also this processing can be downloaded from the link: http://its.1c.ru/db/metod81#content:1644:1.
Naturally, confidential information Each company is different, but I would like to draw your attention to the data that most likely needs to be changed:
- Directories: Individuals, Contact persons, Contact persons of counterparties, Counterparties, Price types.
- Information registers: Passport data individual, Full NameIndividual.
Your list will likely be longer, but these are the most common data points. Changing them is unlikely to affect the ability to test your information base. You can also use group processing to delete all those objects that the service company is not supposed to work with.
Step 3: Obtaining update results
Three days later I was provided with cf files and comprehensive instructions for installing them. For control releases, cf files are provided that cannot be used for user work, since only the metadata is updated in them. They are intended only for correct updating to the latest version.
Based on the results of the work, I can say that all changes in the configuration were saved; upon visual inspection, all objects that were changed retained their features and differences from the standard configuration. During operation, none of the users reported that any changes were lost.
As a result of the update, I identified two small tasks to solve on my own.
First. Due to the fact that the update is carried out using the “Compare, Merge” mechanism, the database configuration is actually updated, and updated correctly, without technical risks due to taking into account control releases. However, the provider configuration is not updated. Of course, a technically competent specialist will easily complement this work, however, I asked 1C-IzhTiSi to send more full instructions by update. In accordance with it, even an inexperienced specialist can perform the update.
Second. As a result of the update, all objects remain on support with the possibility of change, which can also be an indirect disadvantage. If you need to use these services at a time, then you need to put all objects back on support. So far I can only do this by searching through all the metadata objects. Unfortunately, this process is currently performed manually, but in the future it will be automated.
In addition to the two mentioned tasks, one small flaw was discovered, which, in principle, does not affect the quality of the update and rarely appears. As a result of the update, the code lines of the original configuration and the updated one visually match, but for some reason spaces are added at the end of the lines. This is a disadvantage because it slightly increases the amount of modified code. And in case of further manual update it would be better not to have such sections of code. In Fig. 6 shows an example before the update, and Fig. 7 - example after update.
Loading...
