There are a lot of instructions for updating modified standard configurations of the 1C platform. Therefore, in order not to increase the essence, I will not fully describe the entire process. In addition, it is assumed that this text is for a person who has already updated modified configurations and knows the main points and pitfalls. This method only simplifies this process, essentially suggesting the use of automated comparison of configuration changes and changes in modules at the level of comparison of text files. With this approach, the likelihood of errors (“overwriting” important changes due to inattention) associated with the “human factor” is greatly reduced.

ANY configuration update begins with unloading the information security. This is the “golden rule”, this must always be remembered, this must be done with any method (even if they forgot to say about it). Next, you can go in two ways: either update in the test database, or update in the production database. Here important point as follows: usually changed configurations are updated not for every release (as this can easily be done with standard ones), but for several at once, since this process is labor-intensive. The first method (update on a test database) involves the final transfer of the update to the working database by downloading a cf file. In this case, errors related to deleted details may occur (you can find many articles about this). Therefore, there are some risks, but during the update (which can take a whole day or even longer), users can safely work, changing the database. In the second method (update on a working basis) - these risks are excluded, but for the entire duration of the update key users will not be able to work in this database. There are enough discussions in the forums about which method is good and whether it is worth transferring the update through a configuration file. I can only say: based on my experience using the first method, such errors did not occur when loading a cf file. In any case, you can restore the database using a backup. It is the first method that will be considered here, but this does not affect the essence of the method and, if desired, you can proceed according to the second method using the proposed method.

So, having deployed a test database using a fresh backup, we make sequential release updates to the latest. After each release, we run “Debug” to save configuration changes and reorganize data. In all dialog boxes Click OK/Next/Accept/Yes/Continue...

Thus, we have updated the configuration on the test base to the latest release, but we need to check whether we have overwritten any changes, and if we have overwritten them, we need to transfer them to this release. Now the fun begins, so I’ll describe it step by step. Each step will have some explanation: that is, the essence is described first, and then more detailed description. If the essence is clear, then the description can be omitted.

1. We save configuration changes BEFORE and AFTER the update in text files. Open the working and test databases in Configurator mode. We open the configurations in them. And in both databases we start processing the configuration comparison ("Configuration - Compare configurations..."). IMPORTANT: in both databases it is the same to select configurations:

Moreover, we save it as follows: in the working database (where the configuration BEFORE the update) - into a file with the ending "old", and in the test database (where the configuration AFTER the update) - into a file with the ending "new".

2. Incorporating lost changes into the updated configuration. Let's move on to the key stage of the method. Since this is the main point, for a little explanation of what is happening there is a little bit of material. On the 1C 7.7 platform, the update file was a complete configuration. And the update in 1C 7.7 consisted of loading a new configuration and reorganizing the database for this configuration. Thus, both the configuration and the update were essentially the same md file. Unlike the 1C 7.7 platform, on the 1C 8.x platform: the configuration is transferred via a cf file, and the update via a cfu file. The difference between these files is that the cf file contains all configuration objects, and the cfu file contains only those that are changed by this update. And thus, when updating on the 1C 8.x platform, only those configuration objects that actually changed in the new release are affected. As a result, if such an object was changed by us, then after the update it will be completely replaced with a standard one, and we will need to repeat in it the changes that it had before the update so that this object contains both our changes and the changes of the new release, at the same time . But if the configuration object we changed was not affected by the update, our changes will remain in it after the update. To make it easier to understand, I’ll depict it in the form of a diagram:

This diagram shows some typical configuration in the process of change and update. Strings are its objects (documents, directories, processing, and so on). First (under number I) is just a typical configuration: all objects without any changes. Then, under number II, we already see a typical changed configuration: some objects have been changed and these changed objects are indicated in red. Number III is the next update for typical configuration: in fact, it contains only objects affected by the changes in the new release, which are indicated in green, but for clarity, I also added all other objects. And we need to get an updated standard configuration (shown in diagram I), but with changes to both diagram II and diagram III. On in this example- this final configuration is shown as number IV and contains one object that was changed both by us and by the update. The rest of the objects we changed obviously remained untouched by this update. Now the question is: how to make ALL our changes to the object that was affected by the update? Obviously, we need to take two steps: firstly, find this object, and secondly, find the places in it where our changes should be and make them again. I note that, naturally, there may be several such objects and you need to find and fix them all. So let's move on to this last step of the update. At this point, we should have a test database open in Configurator mode. If the result of processing the comparison of configurations or some other window is still open there, we’ll close them all so as not to get confused. Next, we open the working database in Configurator mode (it was possible to close it while updating the test database) and start comparing configurations there. And I will place the description of the last two steps (find and fix) in separate subparagraphs:

2.1. Search for an object with changes erased by the update. It's time to remember about txt files with the endings old/new. In fact, these files reflect all configuration changes (relative to the standard one) BEFORE and AFTER the update, respectively. Thus, if we have overwritten some change with an update, it will only be in the “Comparison Report_old.txt” file. That is, the search for the necessary configuration objects comes down to comparing these two files. We will compare these files using file manager Total Commander and its built-in tools. I think that there is no need to explain here what Total Commander is, where to get it and how to use it... However, I will briefly describe the required stages of its use here. So, let's launch Total Commander. If the interface language is English (main menu and so on), then you can change it to Russian: “Configuration - Options...”, in the dialog box select the “Language” section in the left column, search for/select “Russian (Russian)” in the list and click "OK". Next, through Total Commander we look for txt-files of reports, select them ("Insert" or "right-click") and start comparing files: "Files - Compare by content..." (in the English interface: "Files - Compare By Content ..."). In the window that opens, the contents of the files are displayed on the left/right, respectively; the “Next difference”/“Previous difference” buttons allow you to search for differences. This tool will allow you to quickly find objects of interest to us.

Comment: the opposite situation can also happen - differences appear in the configuration AFTER the update that were not there BEFORE the update. This means that the update release removed the corresponding objects from the configuration. In principle, these objects can simply be skipped in our patches, since there were no changes to these objects.

2.2. Making changes to updated objects. After we have found an object with overwritten changes, we need to determine where exactly these changes were: in a module (program text), a dialog box (on a form) or other settings. Here I will separate two cases: a change in a module and all other changes. And let's look at these two cases separately.

2.2.1. The changes that were erased by the update were in the module. In fact, this is the main case (this happens much more often) and this case is exactly in our example: the change was deleted in the “VAT Accounting” module. As we already mentioned above, we have a configuration comparison window open in the Work Base Configurator. We are looking for the object we need there. In fact, its position in the configuration tree is described in our text file, namely: “GeneralModule.VAT Accounting.Module”. This is exactly what we are looking for in the comparison window. We expand the tree of subordination until we find the required module - on the left edge opposite it there should be a green pencil indicating that the object has been changed compared to the supplier’s configuration. Right-click on the found line and select “Show differences in modules...”:

After this, the module comparison window will open:

Here at the top are indicated procedures And functions, in which there are changes (in our case, this is one procedure “Output Invoice in Tabular Document”), and in the lower part - the texts of the selected procedure or function with highlighted changes. We need to transfer these changes to our test database. But this does not remove changes from the update. You can automate this as follows. Place the cursor in the lower left part (where the text of the selected procedure with our changes) and press sequentially Ctrl+A (select all) and Ctrl+C (copy selection to the clipboard). Then we create a file with the code name "old_izm.txt", open it in text editor and press Ctrl+V (paste the contents of the buffer). We do the same for the lower right part (where the text of the selected procedure from the standard configuration of a non-updated release) - as a result, we create a file with the code name "old_type.txt". After this, we go to the Test Base Configurator (it should be open side by side, but without any windows inside, so as not to get confused in these two configurators) - and in the configuration we look for our module (in this example it is “GeneralModule.VAT Accounting.Module”) and in it the necessary procedure (in this example it is “Output Invoice in Tabular Document”): select it all and copy it to a new one text file with the code name "new_type.txt". Thus, we have three files ("old_izm.txt", "old_type.txt", "new_type.txt"), on the basis of which we need to create a fourth file - "new_izm.txt". This fourth file should contain our changes, but taking into account the update. We will form it sequentially by comparing the existing three files. First, let's determine whether there are traces of update changes in this procedure? To do this, we compare the "old_type.txt" and "new_type.txt" files using Total Commander (see above). If the comparison shows that the files are identical or there is a difference in the number of spaces or tabs, this means we were lucky with this piece of changes and you can transfer the changes simply by copying the contents of the file “old_izm.txt” and pasting it into the open module of the test database, deleting the corresponding procedure first (in other words, replacing it). Here it is important to carefully monitor the spaces before and after the procedure so that there is no redundancy in further comparison: this, of course, will not affect the functionality, but will slightly complicate the verification. If a comparison of “old_type.txt” and “new_type.txt” showed that there are real differences, this means that this procedure contains both our changes and changes from the update. To simplify the transfer task: first, you can visually assess which changes are greater - from the update or ours. To do this, again through Total Commander, we sequentially compare “old_type.txt” with “new_type.txt” and “old_izm.txt”. And we look where there are more changes: in the comparison of “old_type.txt” and “new_type.txt” or in the comparison of “old_type.txt” and “old_izm.txt”. If there are more changes in the first comparison (the update has changed the function more), then it is easier to correct the updated file by making our changes, that is, we change “new_type.txt”. Let's call this the first case of making changes. If there are more changes in the second comparison (we had more changes), then it is easier to correct our file by making update changes, that is, we change “old_izm.txt”. Let's call this the second case of making changes. Now how exactly to transfer changes quickly and accurately. To do this, we create a fourth file and, as already agreed, call it “new_izm.txt”. Taking into account the optimization of the transfer of corrections, we copy the contents of either “new_type.txt” or “old_izm.txt” into this file (respectively, for the first or second case of making changes).
Now open two file comparison windows at once. For the first case of making changes, these are comparisons for the files "new_izm.txt"/"old_izm.txt" and "old_type.txt"/"old_izm.txt". For the second case, these are comparisons of the files "new_izm.txt"/"new_type.txt" and "old_type.txt"/"new_type.txt". In the comparison window there is an "Edit" button: click it in the comparison of the first pair. Now let's explain what we see. In the first pair of comparisons, objects from both our change and update are visible. Depending on our case, we need to transfer only our changes, or only the updates. In the second comparison window, only those changes that we need to transfer are visible. If you pay attention - in both cases, the second file of both the first and second comparisons is the same. Therefore, we focus on the lines in this file, and according to the lines in the second comparison, we make changes in the first comparison window: pressing the “Edit” button will allow us to do this.

For clarity, let’s graphically depict the actions during the transfer in the first case (we change the updated file by making our changes):

The actions in the second case are absolutely similar and the principle of action is exactly the same.

The most difficult and unpleasant case is when our changes and update changes are in ONE place. That is, in reality there were two changes in one code segment. In this case, programmer intervention is required. Also, programmer intervention, but to a lesser extent, is required if, for example, an update changes the names of the variables that are used in our changes. It is also worth noting that the file “old_type.txt” or “old_izm.txt” may contain empty lines - these are “traces” of our changes. You need to transfer them so that they are not in the final file. This does not affect the functionality, but in further comparisons (with subsequent updates) it will make the analysis of actions a little more difficult. So, after we have created the fourth file, transferring all the changes, we need to copy its contents to the configuration. In the Test Database Configurator, the required module must be opened in a new location: delete the existing procedure and insert the contents of our final file, taking into account all the spaces between previous/subsequent functions. Thus, we transferred the changes to ONE procedure of the found object. We (Fig. 6) really have only one procedure. If there are several such procedures, the described steps must be performed for each one. If the procedure is new (only in the left half), then simply add it to the corresponding module in the test database (for the correctness of further comparison, you need to maintain the order of procedures, as in the corresponding module of the working database, where there is still an old release).

2.2.2. The changes that were overwritten by the update were NOT in the module. To transfer such changes, such a comparison will not simplify the work in any way, so changes are transferred simply by visual comparison of objects in the working and test databases.

Thus, we transfer changes for each object where our changes were overwritten by the update. To check how correctly we have transferred all the changes, we save the configuration in the test database, upload the comparison of configurations to the file “Comparison Report_new2.txt” and compare it with the file “Comparison Report_old.txt”. If everything is perfect, the message “The files are identical” will appear. If some objects were deleted by the update, then if the changes are transferred correctly, only these objects will be visible in the difference. It would be correct if only spaces/empty lines/tabs are visible in the comparison, but in this case it is better to clear it out and get the message “The files are identical”. Thus, after saving the changes in the test database, we upload the comparison to a file and compare it with the changes in the old release - we repeat this until the comparison shows that we have transferred all the required changes.

3. Transferring the updated configuration from the test to the working database. At the previous stages, we updated the test base to the latest release, checked and transferred the necessary changes and saved the resulting configuration. Now we upload it to a cf file and load it into the working database. Before downloading, you must make a copy of the working database and remove the configuration from support. ALL. Users were "idling" only at the beginning, when we unloaded the database, and at the end, when we unloaded the database again and loaded the configuration.

This update is completely completed.

The original article is on the website

In this instruction for a non-standard update of the modified 1c 8.3, I will not describe basic things, such as: how to open the configurator, what the database configuration is, the supplier configuration and the 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 next update you will have to go to point 1a. 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 simple processing, which 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. Update atypical configuration 1s 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.

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 information bases may not correspond latest configuration. In the article, Dmitry Rudakov, a specialist at Siberian Agrarian Group CJSC, shares personal experience for a one-time configuration update 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 you start independent work, I decided to get an independent assessment from experts 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 version configuration: 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 necessary updates 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.The treatment can be used to prepare information base before transmission 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.

Atypical 1C configuration (modified) is automated system management of the enterprise, which has undergone a number of changes due to the specifics or needs of the business.

When the first configuration becomes popular and is used in many companies, it becomes standard.

In the second type, the developer himself makes changes, additions and improvements over time, making the settings more convenient or relevant. At the same time, if the organization is satisfied with the configuration, then there is no need to update it to a new one.

But if a number of serious changes were made to the legislation (for example, the accounting algorithm was changed), then there are 2 options for what to do with the updates:

• update to a new standard version;
• update the non-standard 1C configuration yourself, taking into account changes in legislation.

The problem with updating non-standard configurations is that this task cannot be completely automated, since there is no standard script. Therefore, when a 1C update of a non-standard configuration is carried out, a specialist must be present who can perform all the necessary manual operations.
For example, let's take the atypical configuration of 2014 “1C: Trade Management” and its update to the next available release.

Regardless of the configuration, all stages of updating the program will be the same, but for some it will take less time, for others it will take more. The duration depends on the number of modifications. At the most, a manual check may be necessary if there were a lot of modifications.

Step-by-step instructions on how to update a non-standard 1C configuration yourself

Upgrade steps:

1. Uploading the information database.
2. Go to the “Configuration” menu. There we select the “Support” menu item and then “Update configuration”.
3. After the previous step, we upload the report form, having previously configured it.
4. Let's move on to the update process itself. To do this, click the “Run” button.
5. An information window opens with data and settings selection elements. You don't change anything about it. Click "OK".
6. Let's launch Enterprise.
7. For the update to complete, you must accept the changes in the context menu that opens.
8. Using the F5 function, you receive confirmation that all updates made are legal.

After the last point, when a pop-up window opens confirming the update, you need to return to the configurator, go to the updated metadata objects and manually make changes to the program code yourself.

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", 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 the 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.

We do not need the main configuration in the form in which it currently exists. 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 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 practical experience shows, 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 report output mode in 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 best option would be not to update the form of the directory element " 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. I don’t like this option 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 look at how the form dialog is updated in this mode, 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, support will offer a window for comparing and merging 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.