Updating a non-standard configuration. Personal experience: how to quickly and cost-effectively update a changed configuration Non-standard configurations 1C 8.3 examples

A non-standard 1C configuration is when: 1) the 1C configuration was written from scratch by the programmer independently, 2) the 1C configuration was standard, but changes were added to it, even if one property was added.

In this article we will look at how it is necessary to correctly update 1C configurations, as well as several techniques for softly changing standard configurations, i.e. correct change, which will not affect the possibility of further updating.

In order to make any changes to the standard 1C configuration, it is necessary to unlock the change to the standard 1C configuration, and in some cases “remove it from support”.

In the most optimal update option, the 1C configuration can be updated in a fully automatic mode, this is possible when configuration changes are prohibited. Quite often it is necessary to include configuration changes, since it is necessary to adapt application solutions to the customer’s business requirements; we will focus on this option.

Before you update It is highly recommended to make a backup copy database, this can be done through the Administration/Upload infobase menu.

There are 2 update options: a) Updating 1C through support (call through the Configuration/Support/Update configuration dialog) and b) through Comparison merging with the configuration from a file. It should be noted that the difference between these two points is that in the first case, both the main configuration and the supplier configuration are updated, and when comparing merging configurations, only the main configuration is updated, the supplier configuration remains the old one. Therefore, the most recommended option is to update via Update Configuration. To update via Configuration Support, the vendor's CF or CFU delivery files are used, which can be found by searching, in the template directory by specifying the path on the Internet, or by directly specifying the path to the desired file on your hard drive.

When updating the 1C configuration without the ability to make changes, the update after selecting the update file occurs automatically; if the ability to make changes is enabled in the configuration, then after selecting the update file a configuration comparison window will be displayed. In this dialogue we can see how the system offers us to update our non-standard 1C configuration. At the bottom of the dialog box there is a corresponding legend for object statuses: “Object Compliance Statuses” indicate a comparison of the “Main Configuration” and the “New Configuration”, “Object History Statuses” indicate a comparison of configuration objects with the “Old Supplier Configuration” objects.

By checking the boxes next to objects, you can choose whether the current configuration object will change or remain old, as well as how to change the object. In the action menu, you can check boxes for subsystems (this is useful if the configuration is supported by several suppliers). This menu also allows you to specify the priority of aggregation for all objects at once; by default, the system considers the supplier’s configuration to be a higher priority. The filter settings allow us to specify which configuration objects we should display in order to be able to specify the merging mode in detail. There are several standard filter templates, and you can also specify filters for each pair of configurations being compared. It is possible to set the “Show only twice changed properties” checkbox in the “Filter” settings; this will allow you to filter out objects whose updating did not result in conflicts between supplier changes and modifications to these objects:

So, the result will be a list of objects that were changed twice during the finalization of the standard configuration and in the new supplier configuration. If you agree to the update, then previously made improvements to these objects will be lost. Therefore, for each object it is necessary to make a decision on how it will be updated. At this stage, a preliminary comparison should be performed solely to reduce the amount of work later. The assessment is not accurate and quick - “by eye”. If there are more changes in the object in the new supplier configuration, then we leave the instance of the supplier object. Leave a checkmark. Then you will need to transfer changes from the working configuration. If there are more changes in the object in the working configuration, then we leave an instance of the working configuration object. Uncheck the box. You will then need to migrate the changes from the provider configuration. You can do things a little differently with modules, because... It is possible to compare modules procedurally.

Those. if in our 1C configuration and in the supplier’s configuration various module procedures are changed, then by checking the boxes correctly we will save ourselves from manually transferring code changes. To get to this, you need to click the button in the form of a magnifying glass next to the name of the mode for combining modules:

When displaying a menu of actions on an object (for example, by clicking the right mouse button), we can call up a report on object comparison.

To confirm the 1C update, you need to select the menu item Configuration/Update database configuration.

To refuse the 1C update, you need to select the menu item Configuration/Return to DB configuration.

Several rules that simplify future updating of 1C configurations:

The basic rule for updating 1C: you need to add new objects, because... When updating, new objects are not affected by the system

When changing the texts of modules, it is also advisable to add your own new procedures and functions, and call your new ones from existing ones

Using event subscriptions, thanks to this you can modify standard mechanisms without changing the standard code

Using standard configuration functionality

Programmatic creation of form elements (In the FormCreationOnServer event)

Thank you!

1C software products are specific in the sense that their operation is greatly influenced by the legislation of the country in which these programs are used. That is why it is very important to be able to update these products, since in addition to legislative issues, the updated configurations will contain corrections of critical errors, acceleration of the entire operation of the program and other useful details. There are two options for the development of events: the first option is an update of the standard (standard) configuration, which happens quite quickly and does not require much effort, while the second option, when you need to update a modified assembly, is longer and more complex.

Defining the Configuration Type

Usually, the user knows exactly which version he has, since the standard build is characterized by the absence of interference with the internal objects of the program. Another thing is that modification, as a rule, is carried out by programmers; accordingly, the user receives an already modified product, which he may not even be aware of. There is a simple way to understand whether changes have been made there or not. To do this, you will need to enter the Configurator mode, the corresponding button for which is in the start window of the program. There is a Configuration tab at the top, in which there is a Support item. After clicking on it, you should select Support Settings. In the open window, the “Enable modification capabilities” button should be active; also, a sign of a standard assembly is the presence of a lock icon next to the assembly name. These signs indicate that the program modules have not changed, which means that you can perform a centralized update from the official website via the Internet. In the absence of these signs, it can be argued that the programmer worked on editing this product, while a situation is possible when the modification was partial, that is, a number of objects were left in their original form. All modified objects remain without identification icons, and standard elements are marked with a yellow cube. A partial modification does not remove the program from support completely, since it will be possible to update untouched objects.

Standard (typical) configuration - preparation for update

In addition to the indicated problems, such as changes in legislation or deterioration in the performance of the program, you need to update it when the 1C program issues a corresponding message. It will say that this build was released some time ago, now there is an improved configuration, and that it can be updated right now through the website or using the ITS disk. To begin with, it is very important to make a backup copy of the database so that you can restore everything if something goes wrong. This is done in three ways. You can simply copy the root folder with the database to a disk or flash drive. After launching 1C, a database is selected, and the path to it will be indicated in the window. In case of problems, this folder is moved to the location of the non-working database. You can also operate through the configurator, for which you need to select this mode in the program. In the Administration section there is a button Upload infobase. After selecting a folder, a .dt file will appear there, which can subsequently be opened with the corresponding button in the same section.

The third method occurs a little later, at the stage of updating via the Internet. Everything can be done through the ITS disk, which is received by the enterprise every month; you can also take this disk from an employee who has an agreement with the ITS, you just need to make sure that the configurations match. Otherwise, everything is done over the Internet. There is an important nuance: update packages are installed strictly sequentially, and if any releases were skipped, the system will require you to install them first. contained in the Help menu, where you will need to click the About section.
If everything is in order with the Internet, then you need to go to the website usersv8.1c.ru, where you enter your login and password. Next, select the required configurations located on the Download updates link. The next step is to select specific releases, taking into account the very first and those that have been released recently. All files are saved one by one on the computer. Before updating, you need to open all archive files and install each release. Releases can be downloaded, as described, from the ITS disk. Now you need to enter the Configurator mode, after which objects should be displayed on the left; if they are not there, then you will need to click the Open configuration tab.
To update, the user goes to Configuration-Support-Update configuration. In the new window, click Search.

From the proposed options, select Search in current update catalogs, then indicate the available release or the one whose name will be highlighted in bold. You must click Yes on all other suggestions, including the last Reorganize Information window. The final step is to run the program in production mode for the updates to take effect.

Updating a non-standard (modified) 1C configuration

The point of updating a modified assembly is to ensure that changes made by programmers are not lost, and changes made by developers take effect. All of the listed steps described in the previous instructions are performed this time, only at the final step a comparison table will appear, where in one column there will be a configuration with modified objects, and in the second column there will be a list of updates. These columns contain metadata trees. With a green marker, the program will mark which specific objects the programmer makes adjustments to, and which ones the product developers made changes to. At this stage, you need to find those objects that are marked in these two columns.

To simplify your search, you can use the Filter button, which is located below, and then check the Show twice changed properties option. If everything is done correctly, then only the objects we need will be displayed in the working window. The procedure for updating non-standard modules will not affect the configuration.

We need to analyze this table. In this case, it is clear that changes occurred in both cases, since there are pencil icons, since there is also an icon next to the module name, this means that they will be merged. The last column on the right indicates that when the process is completed, all user code will be changed in favor of the update from the developers.

There are other modes with partial merging (priority), but these modes are used by experienced users, since a beginner will turn all the developments into confusing modules. Accordingly, there is no point in changing anything in the last column. On the other hand, by unchecking the first column, the forced merger can be canceled. Based on this, you can either manually enter the code into the updated module, or leave the code alone and manually make the updates themselves. To understand what exactly needs to be added, right-click on the selected module and select Show differences. This step will show the differences in specific procedures. At the bottom of the window there is also a division into two columns, but the code itself is already displayed there.

Further actions depend on the level of change in the modules; if the configuration has been radically rewritten, then it will be extremely difficult to update everything yourself, without the help of a programmer.

Possible when updating 1C

Most errors are made when the database is heavily modified, since several pages of code, various reference books and other objects can confuse an inexperienced user. It is very important to create and save a backup archive before making any changes, and then double-check that everything was done correctly. A classic mistake is updating a non-standard assembly as if it were standard. But even if you follow the described instructions, it is far from a fact that the program will immediately work as it should. It is likely that additional configuration is not necessary. The configurator does not display the changes made in the controls of the dialog forms, so this point will have to be checked manually, otherwise the updates will all be overwritten. After updating, the configurator may prohibit updating the old infobase, since document numbers are no longer unique, the same applies to information registers.

To solve the problem you will need:
— change the number of characters in codes;
— change codes in the information base;
— change the uniqueness control property in all directories.

During the update process, we must not forget about updating interfaces and user rights, which is often overlooked. The importance of sequential update of releases has already been described; it is also extremely important to use built-in processing of configuration updates, which will allow you to convert the necessary data and fill the databases with information if necessary. It is in the user's interest to ensure that the internal identifiers of objects or details match, otherwise the update may overwrite all developments. Even after carefully preparing a new configuration, you cannot immediately move on to combining it with the working base in use, since it also needs to be updated, and then everything must be thoroughly tested.

You need to understand that there are options when the configuration will be returned for support, that is, its update process will occur in the standard mode for the program, through downloading the release over the Internet. The program is removed from support after modified modules are introduced into the product. Removing these modules will return the program to its original state, but it is impossible to completely get rid of them, since normal operation of 1C will be impossible, because for some reason this is how the modules were programmed. Accordingly, these modules can be moved outside the scope of the program - the work will be performed using external modules, but this will not affect the operation of the program. Thus, directories and other objects will remain in place. Doing this on your own without the necessary knowledge is problematic, so the programmer must return the program to the standard assembly framework, if required.

There are also several tips that will make the process of updating 1C software products easier in the future. First of all, you need to try to modify the program as little as possible, and unless this is absolutely necessary, then do not introduce anything third-party there, but try to solve problems with the standard tools that are available. Without exception, all configuration changes must be commented out and recorded in a separate document so that nothing important is missed during the recovery process. In order to reduce the amount of program code in standard objects, you should move it into its own common module, but you need to understand that calls to procedures and functions cannot be touched - they must remain in standard objects so that the program can work correctly. For optimization purposes, it makes sense to replace all calls of standard procedures and functions that are found both in the “self-written” code of objects and in the code of external modules, with calls to procedures from its own module. These procedures are a simple shortcut that will be used to call procedures from standard modules. Thus, when comparing changes, the user will not have to search for the necessary lines in the modified code for a long time. If you follow these recommendations, the update time is reduced to several hours of work, and if everything is left as is, the process can drag on for several days.

This article does not describe methods 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 performed completely automatically and requires the intervention of a specialist.

Is it possible that the update process will be completed completely automatically? Certainly. To do this, mutable objects must be added and must not use the functionality of the existing configuration. Those. these objects must solve completely different accounting problems that expand the functionality of the standard supplier configuration. Agree that the situation described is extremely rare. Changes almost always affect standard vendor configuration objects.

Please note that the database can contain up to three types of configurations:

database configuration – this is the configuration with which users work;
working configuration (main) is a configuration that we can make changes to and users can continue to work;
vendor configuration – 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 consider the update process and analyze possible errors using the example of updating the UPP configuration (the supplier of the standard configuration is the 1C company, modifications by the Inform Service company). Initially, this configuration was updated not using the technology described in this article, so the errors discussed in this article are the most common in practice. The update will be from version 1.2.6.2 to version 1.2.14.1.

Stage 1. Preparation.

At the first stage, we will 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.

This step can be skipped if the last update went through “support” (Menu “Configuration” U94; “Support” U94; “Update configuration”) or was performed using 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 step. 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 when installing the corresponding 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, we create a new infobase 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 perform the 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 for which has been withdrawn by the supplier (possibly due to a change in accounting methodology), then the correct solution in this situation would be to remove the link to this report from the “Department Head” 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 figure, we see that the List Form was deleted from the supplier, and then a new form with the same name was added by the supplier. 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 main 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 the old version to the 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 external printed forms, reports and processing. For some configurations, it is necessary to check the reporting forms connected as external ones.

Stage 3. Delivery of work.

In the example given, the amount of work to correct errors made during previous updates, as well as to update to version 1.2.14.1 and transfer the 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 a database backup;
Using the *.cf file of the standard configuration of the supplier, we will perform the update. To do this, select the menu item “Configuration” 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."

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 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 click 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're 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.

The 1C update is carried out by pressing “one” button; the typical configuration itself can download the 1C update and install it. The user will only be required to enter registration information.

What to do if the configuration is atypical? Or a standard one, but some modifications have been made to it - a directory, a couple of details, a report have been added?

We will find out the answer to this question today.

What is a non-standard 1C configuration

An atypical 1C configuration is when:

The configuration was written from scratch by the programmer himself
The configuration was standard, but changes were added to it
Even if you added one prop.

In order to make any changes to the standard configuration, you must.

When updating 1C of a non-standard configuration that has been removed from support, 1C will offer to “put the non-standard configuration back on support.” Then all changes will be canceled (erased).

In order to ensure that when updating 1C to a non-standard (changed) 1C configuration, the changes remain, and the 1C update is applied, you can use a different 1C update mode.

Let's look at an example of a changed configuration that we want to update. This is a typical 1C Accounting configuration (left), to which changes have been made (right):

4) In the “Individuals” directory, in the form module, in the ReadPlace of Birth() function, a program line was added

How will all these changes work at the time of updating 1C to a non-standard 1C configuration?

Updating 1C with saving changes to the non-standard 1C configuration

1C configuration updates are usually distributed as a self-extracting archive. After unpacking, you need to run the installation file to install the 1C update on your computer (not in 1C!).

When installing the update, you choose where the 1C update will be installed. Usually this . You can install to any other folder on the disk, and 1C indicate where the .

1C update files can be of the following form:

file with CF extension – contains a completely new type of configuration
file with the CFU extension – contains only changes from the previous version.

Both files are stored in the 1C update directory, in the folder with the version name.

Be careful when using the CFU file - it only allows you to update from !

So, to update 1C, select one of the menu options:

Configuration/Compare merge with configuration from file – for CF files
Configuration/Support/Update configuration/Select 1C update file – for CF or CFU files.

First of all, 1C will compare the two configurations. The configuration of your database is called “Main Configuration”, and the configuration from the update is called “Configuration from File”.

1C will display all the differences in the form of a familiar tree, where the changes are displayed on the right.

Look - in our example, directories that have been changed or added are highlighted.

Since we are updating a 1C non-standard configuration that has been changed - that is, it was once standard, it is necessary to enter some settings.

Click the Settings button. Select “The loaded configuration is a descendant of the main one” (that is, it is a modified standard one).

The “Allow deletion of main configuration objects” checkbox allows you to delete if they were deleted in the 1C update. Since we added details and directories to the configuration, but they are not in the 1C update, 1C will consider that they were removed in the 1C update. Therefore, there is no need to check this box.

Let's take a closer look at the differences detected by the platform.

Let's expand the branch of the Nomenclature directory. In the Details branch we see that the standard configuration does not have the details, but we add them. A minus sign means that it will be deleted.

Since we do not need the props that we added ourselves to be removed, we need to do the following (options):

In the “Settings” button DO NOT check the “Allow deleting main configuration objects” checkbox
If the checkbox is still checked, then uncheck the box next to this attribute. In the picture there is no check mark next to the props, since deleting objects is not allowed.

Also, the form of the Nomenclature directory has been changed. 1C saw this and shows us the directory form in the list of changed objects too.

To see what changes have been made to the form, you can do the following (options):

Right-click first on the form in the left column and select the menu item “Open form”, and then in the right. Visually compare the two forms.
Right-click on the form and select the menu item “Object comparison report” (details, spreadsheet document)

The object comparison report, when comparing shapes, shows many differences. This is due to the fact that when we add just one field to the form, many adjacent elements are automatically changed - indents, anchors, etc.

In the list of changes we see our changes - changes to the label and replacement of the field.

We can agree or refuse to change the form by selecting the checkbox next to it. This has the following consequences:

a) if we check the box

the form will be replaced with a new one
our changes to the standard configuration will be erased
changes from the 1C update will be applied
then we will need to manually revert our changes

b) if we don’t check the box

the form will be left as is
our changes remain
new changes from the 1C update are not applied
Next, you will need to manually add changes from the 1C update.

You can use the third option. Expand the Form branch to the end and in the “Merge Mode” column, select “Merge”.

c) if we selected “Merge”

there will be some new form, in which there will be new changes and old ones
our changes remain
new changes appear
if a field was removed and another field was put in its place, as a result of the merger, both fields will appear in the same place at once - both the old and the new
there are chances that the form will look normal
then you need to manually check that no “excesses” have occurred

2) In the “Individuals” directory, in the form module, in the ReadPlace of Birth() function, a program line was added

To see the changes in the form module that 1C detected, expand the form branch to the end, right-click on it, and select the “Show differences in modules” menu item.

Changes are shown in the context of each function, but in this viewing mode you can either choose to update 1C of the entire module or refuse it.

Another way is to use the magnifying glass button in this line.

Then we will not only see changes in the context of each function, but we can also use checkboxes to select which function we want to update and which not.

3) Several details have been removed from the “Electronic Submissions..” directory

1C has determined that we have deleted the details of the standard directory and offers us to restore them.

The directory that we added, 1C suggests deleting. In this case, the same rule applies as in the case of the props we added (see earlier).

So, our task is to carefully study the detected 1C changes and use the checkboxes to agree or refuse them. After that, click the Run button.

Please note that if you deleted an attribute as a result of updating 1C, you also deleted the data that was entered into it by users, which means adding the same attribute again will not restore this data.

If the configuration has several related objects - for example, props and form; At the same time, you allowed the update of the 1C form, but unchecked the checkbox, then a contradiction occurs.

After clicking the Run button, 1C finds such situations and reports from them.

After clicking the Run button, you have one more opportunity to think.

To confirm the 1C update, you need to select the menu item Configuration/Update database configuration.

To refuse the 1C update, you need to select the menu item Configuration/Return to DB configuration.

Third option (the sequence of menu items is indicated):

Select File/Save
Configuration/Save configuration to file
Configuration/Database Configuration/Return to DB Configuration.

Thus, you upload the resulting combined configuration to a file and refuse the changes. You can analyze the resulting configuration, make manual edits, and later simply load it using the Configuration/Load configuration from file menu.