Licensing policy 1C provides the ability to make and save modifications to standard configurations, and, accordingly, the ability to update them.*

*Modified or non-standard configurations 1C is a software product on the 1C:Enterprise platform, which is part of or constitutes the entire automated system enterprise management, which has undergone a number of changes due to the needs and specifics of the business, in terms of the forms and composition of directories, documents, roles, modules, etc., therefore updating the 1C configuration with changes is not at all the same as updating a standard solution.

Updates released by 1C are aimed at fixing bugs and introducing changes and additions required by law. New configurations that have recently entered the market are characterized by the release of a large number of updates of the first type. For configurations with functionality aimed mainly at compiling regulatory reporting, for example, “1C: ZUP”, “1C: Accounting”, more updates of the second type are released.

The specificity of updating non-standard configurations is the need to make all changes to the latest 1C release, while fully maintaining previously made improvements. This is a non-trivial task, the solution of which does not have a standard script, which means it cannot be fully automated. For this reason, manual operations that require the participation of a specialist prevail in the methodology for updating non-standard configurations.

The implementation stages of updating non-standard configurations are not affected by the amount of existing improvements. Briefly they can be described as follows:

• Search and comparison of changed objects;
• Making updates from a new release;
• Introducing previously made changes that were “overwritten” at the previous stage;
• Checking compatibility and operation of processes.

The difference will be in the implementation time: if there are a lot of improvements, the process will correspondingly take longer and require concentration, attention and manual checking.

Let's consider updating a non-standard configuration for the 1C environment using the example of “1C: Trade Management” (release 2014) to the next available release.

This is a very simple example, but as mentioned above, updating a more complex configuration, of course, will require a lot of time and concentration on the part of a specialist, but will have the same stages - updating (to a new standard configuration), working with reconciliation of entered and changes made, etc.

Before updating the configuration, you should download information base. This action is recommended to be performed before any manipulations with all databases without exception, and especially with non-standard ones:

Uploading of the infobase is completed:

Please note that if the configuration had not been finalized, that is, it was standard, then in the Configuration window opposite the name, next to the yellow cube, a lock icon would also be displayed:

In the Configuration menu, select “Support” and “Update configuration”. In fact, at this stage, the actions completely coincide with the process of updating a standard configuration:

Depending on the size of the base and its modifications, automatic search available updates may take some time. Therefore, it is worth, despite the recommendations, select the “Select update file” option and independently, after unpacking the archive with updates and saving them, specify the path manually:

Window with background information, instructions and sequence of updates:

Configuration comparison window. On the left in the tree the status of the existing configuration is displayed, on the right – information on the new, standard version. Sections that have undergone changes are also highlighted. Next, we need to find out which sections were changed on our part and simultaneously underwent changes in the new configuration:

In order to find out which typical metadata objects have been changed previously and will also be changed when installing a new provider configuration, you must select “Show only twice changed properties”:

Only objects that meet this condition remain:

By expanding the metadata tree, you can see which specific objects will be changed. For getting detailed information, right-click to select the modified object:

You can evaluate changes at the code level using “Show differences in modules”, but since they also need to be remembered in order to be made after installing updates, we create two reports: “Report on comparison of main configuration objects with the old vendor configuration” (available improvements) and “New Provider Configuration Object Comparison Report with Old Provider Configuration Objects” (updates).*

*Let's understand the terminology:

• “Main configuration” – a non-standard configuration that needs to be updated;
• “Old vendor configuration” – typical configuration from which updates were last installed;
• “New supplier configuration” is the one we are updating to now.

We customize the report form and upload it. The list of previously made changes has been recorded:

After downloading the reports, go directly to the update and click “Run”. The configurator offers the update rule “Take from the new supplier configuration” (it is indicated in the third column). This means that all modifications will be erased and replaced with standard updated objects. It’s not worth changing this rule to the tempting “Merge Mode”, because automatic merging will lead to chaos. Still, it’s better to take the time and make the changes manually:

In the window with general information about removing the configuration from support, nothing needs to be changed. Clicking "OK" will merge the objects. Next, launch “Enterprise” and record the changes to accurately complete the update process:

We accept the list of changes:*

*If the “Accept” button is inactive, you should run “Fix Testing”:



We launch debugging via F5 and receive confirmation of the legality of the updates:

After confirmation is received that the process of rolling out updates is completely completed, you should return to the configurator, go to the twice changed metadata objects and manually make the committed changes at the code level, using the downloaded reports. In conclusion, we add that after this, it is necessary to check the correctness of the settings and the adequacy of the work processes.

This is a fairly old article of mine, but it is still relevant. Therefore, I decided that it would be appropriate to publish it on www..

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 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 my article “Technology for updating non-standard configurations of 1C: Enterprise 7.7” dated June 27, 2003. Yes, it will work. Many people perform updates this way. But I consider this approach ineffective and time-consuming when updating configurations on the 1C:Enterprise 8 platform. Unlike the 1C:Enterprise 7.7 platform, the 1C:Enterprise 8 platform allows you to open several configurations simultaneously (*.cf files) and perform several comparisons of configurations in one copy configurator. The only exception is, perhaps, configurations built on PPM (Manufacturing Enterprise Management) - they are too heavy, the platform falls.

The process of updating 1C:Enterprise 8 configurations is more automated compared to 1C:Enterprise 7.7. A fairly high level of automation can significantly reduce the labor intensity of work when updating non-standard configurations. Unfortunately, most often the process of updating non-standard configurations cannot be completed completely in automatic mode and requires specialist intervention.

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

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

• database configuration - this is the configuration with which users work;
• working configuration (main) is a configuration that we can make changes to and users can continue to work;
• vendor configuration is the initial vendor configuration from which working configuration And database configuration. A database can have multiple configurations from different vendors. The configuration supplier can be not only 1C.

In case the configuration is removed from support, vendor configuration will not be. Which in turn significantly increases the complexity of the update.

Let's look at the update process and analyze possible mistakes using the example of updating the 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.

You can skip this step if Last update passed through “support” (Menu “Configuration” → “Support” → “Update configuration”) or was performed according to the method described in this article.

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 → “Open configuration” menu “Edit” → “Properties”. In the “Development” block, select “Version”. (Picture 1).

Number vendor configuration look in the menu “Configuration” → “Support” → “Support Settings...” item “Version”. (Figure 2).

If the numbers match, then move on to the next stage. Cm. .

IN in this example needs to be brought into line 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” → “Save configuration to file...”.

3. Obtain the update file for the provider configuration.

To match the configurations, we need a *.cf file from the supplier's distribution with the same version number as working configuration(Figures 3 and 4). This file can be obtained by installing the appropriate distribution. By default, the configuration distribution is installed in the C:/Program Files/1cv81/tmplts directory. For more information about installing configuration templates, see the documentation.

Let's check the template directory. If there is a *.cf file of the required version in the templates directory, then go to .

What can you do if there is no *.cf file of the required version? vendor configuration? In this case, you can use *.cfu files and, repeating the procedure described in Stage 1 several times, successively raise the version number to the required release, in this case to 1.2.6.2. It should be noted that using *.cfu files may not fix errors made earlier during the update. Which, you see, is quite strange, given the fact that first the supplier file is compiled based on the *.cfu file, and then the update is performed. This may be due to the fact that for some reason not all configuration objects are included in the comparison. Therefore, I suggest using a possibly longer path, but also a more reliable one.

You need to create an empty database with "old" vendor configuration. Update provider configuration to the required version and use it when performing work at stage 1. For getting "new" vendor configuration you need to do the following:

1. Creating the "old" supplier file for the current configuration. The 1cv8.cf file can be taken from the supplier's distribution or saved from the working database if the configuration is under support. To save the 1cv8.cf file from the working database, go to the “Configuration” → “Support” → “Support Settings...” menu, click the “Save to file” button and specify the directory and file name. For example, on the desktop.
2. 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 menu “Configuration” → “Load configuration from file...” we specify the file previously saved on the desktop. We open the configuration through the menu “Configuration” → “Open configuration” and update to the desired release through the menu “Configuration” → “Support” → “Update configuration” using *.cfu files.
3. Create a "new" provider configuration file. To do this, select the menu item “Configuration” → “Save configuration to file...”. We specify the location and name of the file 1cv8.cf. Click “Save”.

4. Matching the operating configuration and the supplier configuration through an update.

Using the resulting *.cf file vendor configuration Let's update. To do this, select the menu item “Configuration” → “Support” → “Update configuration”, “Select update file”, “Finish” (Figure 5), “Run” (Figure 6).

Solutions:

• unmark an object that is in the supplier configuration;
• remove the reference to the object that is in the provider configuration.

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” → “Compare, merge with configuration from 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” → “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” → “Update database configuration”.

If necessary, transfer the values ​​of the OrderReserve1 attribute to OrderReserve using external processing in 1C:Enterprise mode.

Stage 2. Update.

After carrying out the preparatory work at Stage 1, we proceed to the update basic configuration and transfer of previously made modifications to the supplier’s standard configuration.

To update the configuration, we need a *.cfu file or a *.cf file from the supplier's distribution. You can read more about how to obtain them.

If the update is performed through several versions of the configuration, then you should pay attention to the situation described in the article "". If the update is not performed on a working base, then after completing the preparation of each new stage, we save the *.cf files. They will be needed when updating the configuration of the customer's production database.

If the update is carried out through several versions, then during the update you should definitely pay attention to the objects that are deleted and to objects with changed names, as well as to the actions performed during the first launch after the update. If these objects are used in processing at the first start after the update, then they should not be deleted, and for objects with changed names, appropriate changes should be made to the text of the processing module. In this case, the objects left behind may be deleted during the next or next update.

If the update is performed through several versions, then to reduce the labor intensity of the update, you can use the method of calculating key releases, described in the article “Updating 1C:Enterprise 8 configurations. Jumping through 20 versions.”

1. Preparation of databases.

So, based on the results of the first stage, we prepare two identical databases. The first (main) is our future result. The second (auxiliary) - for performing comparisons, opening configurations and others 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 menu item “Configuration” → “Support” → “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 menu “Configuration” → “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 menu “Configuration” → “Support” → “Support Settings:” click the “Save to file” button. (Figure 2). Specify the file name, for example, new.cf. Next, we make a third comparison of configurations and when comparing, specify the new.cf file as the second configuration.

So, we received a list of twice changed objects in the additional database. And two more comparisons that will help us more effectively transfer previously made settings from old version to a new one. In the main database we have an almost ready-made configuration, in which we need to deal with twice changed objects.

To reduce the time for analyzing changes to a standard configuration and, accordingly, for updating, it would be appropriate to comment on all changes made to the configuration, noting not only the changed text of the modules, but also the purpose of the changes made. For a number of reasons, this is very often not done. When performing an update, you are not interested in the reasons for making changes, but in their consequences. Namely, the need to preserve the functionality of the changed configuration. This may require not transferring the changed lines, but completely reworking the added (changed) code to fit the functionality of the new vendor configuration.

Comparison of forms, tables, and modules of objects in the configuration is performed with a sufficient degree of detail (Figure 17). This is quite enough for making decisions.

But in some cases, the data in comparison reports is presented in a way that makes it difficult to make a decision quickly. For example, in the case of changing the type of details that have a composite data type, the composition of those entered based on objects, etc. It is at this stage, due to its complexity, that improvements are lost during the update. Let's consider this situation using the example of details that have a composite data type. When generating a report on object comparison (Figure 17), the differing data in the compared configurations is presented in the form of lists containing the composition of data types, separated by commas. However, the report does not show at all what types of data were added or deleted. Of course, the report can be printed and “hidden” to identify differences. In the example under consideration, there are about 200 such objects. Obviously, the comparison process seems to be quite labor-intensive and will take about 50 hours.

To reduce the labor intensity of work when comparing objects, you can use the “Cell Comparison” processing 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” processing 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 processing scheme is simple. In the configurator we create a report on comparison of objects (Figure 17) and save it to a file, for example Comparison Report.mxl. Open 1C:Enterprise and in the dialog (Figure 18) select the saved file and indicate the cells to be compared. To do this, double-click the right mouse button on the selected cell of the spreadsheet document. By clicking the “Compare” button, we get the result of the comparison, in which the different positions are highlighted in color (Figure 19).

Further, based on the fact that the comparison is performed according to the same principles of comparing objects, the action diagram will look like this. Save the next report under the same file name. Click the “Update” and “Compare” buttons.

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 menu item “Configuration” → “ Save the configuration to a file...".

• Using the work_2.cf file, we transfer the changes. To do this, select the menu item “Configuration” → “Load configuration from file...”;
• When asked about updating the database configuration, we will answer yes.

If 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 menu item “Configuration” → “Save configuration to file...”.

Further actions on the customer’s side will be as follows:

• create backup copy Database;
• Using the *.cf file of the standard configuration of the supplier, we will perform the update. To do this, select the menu item “Configuration” → “Support” → “Update configuration”, “Select update file”, “Finish” (Figure 10), “Run”;
• Using the work_2.cf file, we transfer the changes. To do this, select the menu item “Configuration” → “Compare, merge with configuration from file...”;
• Let's save the changes to the working configuration and update the database configuration. To do this, select the menu item “Configuration” → “Update database configuration”.

Correct execution of this stage will allow you to avoid the work described in Stage 1 in the future.

Updating a non-standard platform is very difficult. We will look at how to update a non-standard 1C configuration and describe a step-by-step solution to emerging difficulties.

How to update in a non-standard 1C configuration.

General concepts

When updating a non-standard platform, changes always affect elements of the standard configuration of the supplier.

The database (DB) contains up to three types of configurations:

• the database itself - logical algorithms work with it;
• working (the so-called main, ConfigOR) - which we periodically change;
• supplier configuration (ConfigP - based on it, both the working and database configurations are created by the user.

If a program is dropped from support, it will no longer be available from the supplier. However, then an increase in labor costs for updating is inevitable. Let's consider updating a non-standard 1C configuration. An example would be the PPM (Manufacturing Enterprise Management) platform.

Mixing

The first step is to remove the differences between the working and delivered configurations. This will reduce the evaluation of the improvements we previously made. Inconsistencies between them arise when foreign files (not from the supplied distribution) were used during the update or the update methods differed from the standard ones.

Comparison of versions

We check the version numbers (working and delivered). The first is checked in “Configuration” / “Open” / “Edit” / “Properties”. In the "Development/Version" section. Second in “Configuration” / “Support” / “Support Settings” / “Version”:

If the numbers match, you can proceed to the section Receiving a file through an update.

The following steps demonstrate how to match the working and supplier configuration. In order to put on support those objects that were removed or added by the user without support. For this:

Saving the configuration (working)

Let's save the ConfigOR to a file named, for example, work.cf. To do this, select “Configuration”/“Save...”.

Retrieving the Provider File

To combine ConfigOR with ConfigP, you need a cf file from the supplier's distribution (same version). By default it will be in C:/Program Files/1cv81/tmplts. Let's check the presence of the required cf file in the template table. What to do if not the desired file required vendor configuration version? Then you need to create an empty database from the old one, update it to the required version and only then use it.

Receiving a file via update

To perform an update of the ConfigP cf file, select the command from the menu: “Configuration/Support/Update.../Select file/Finish/Run” (Sequentially in the pictures):

To solve this, you need to uncheck the deletion mark from the object in the supplier configuration. Then, after deleting, we perform the comparison again - click the “Update” button in the update window.

Restoring settings

Some of the lost settings are restored by merging them with the previously saved work.cf file. To do this, select “Configuration/Compare, merge... files”.

Saving and adjusting

To save ConfigOR and update the database, in the “Configuration” menu item, select “Update...DB”. Here we encounter a new problem:

Most likely, the reason for this was that these objects were copied from ConfigP or they were deleted by the supplier, and later new ones were added under the same names. However with different identifiers. As a result, objects of the same name appeared, but with different identification keys.

Roles can simply be deleted, since they have not been changed. The attribute must be renamed, for example, to OrderReserve1. And after updating, enter the values ​​from the renamed one to the created one. Another situation during the update. What about forms?

From the figure you can see that the List Form was deleted by the supplier, and then added again under the same name. You need to mark both of them for update and click “Run”.

If during update a message is issued about the presence of links to objects to be deleted, then, without closing the form, you need to clear the links to it in the properties of the objects themselves. Here it is in the register properties. Next, in the update form, select the update option, mark the registry properties for update now, and click “Run” again.

Saving changes to the working database and updating the database configuration: “Configuration/Update...DB”. The transfer of the value of the OrderReserve1 attribute to OrderReserve is carried out by external processing of the 1C:Enterprise mode.

Preparation of bases

Based on the results of the information, we prepare two identical databases. The first (main) is our desired result. The second (auxiliary) is for performing preparatory actions. In the case of the file version, we simply copy them to a directory and connect them to the information security list; with the client-server option, we do the upload/download.

Comparison

After opening both databases with the Configurator, we will perform a three-way comparison of them. For this we use the new ConfigP file - “Configuration/Support/Update…/Select file…/Done”:

Comparing the working, old and new provider configurations gives us a list of changed objects using the “Show twice changed properties” filter. You need to solve the problem with them first:

At this point, work with the auxiliary database is suspended until the entire process is completed; we no longer press the “Run” button. Let's move on to working in the main database with the resulting list of twice changed objects. Agreeing to the update will lead to the loss of previously made improvements. Therefore, for each of the objects it is necessary to make a decision on how it will be changed.

Let's carry out preliminary assessment only to reduce work in the future. If there are more element changes contained in the new ConfigP, we leave the supplier object. We put a tick. We transfer changes from ConfigOR. If there are more element changes contained in the working configuration, we leave an instance of the ConfigOR object. Uncheck the box. Let's transfer the changes from ConfigP. Modules need to be compared procedurally. To do this, press the button as in the figure:

We check the boxes to indicate procedures and functions to be replaced or removed:

Now you need to duplicate the state of the checkboxes in the auxiliary database. In the main one, click “Run”. At this point, in the main we get an almost ready-made configuration.

Subsequent comparisons are performed again in the auxiliary database. We find previously made changes by additionally comparing the old ConfigP with ConfigOR - “Configuration/Compare...”:

Similarly, we compare the old ConfigP with the new one. If there is no new file, you can now take it from the main database.

So, twice modified objects are obtained. An almost ready-made configuration was obtained in the main database. In it you need to deal with twice changed elements.

IMPORTANT. When analyzing, the user should be interested not in the reasons for making certain changes, but in their consequences. That is, the main thing is the need to maintain functionality. Perhaps this will require not transferring the changed lines, but a complete reworking of the code for the new ConfigP.

To make a decision, it is enough to compare forms, tables, and object modules. Sometimes data in reports is presented in a form that does not allow quick decision making. At this step, the loss of modifications occurs if the changes concern object details of a composite type.

In the comparison report, the differing data is presented in the form of a list, from which it is not clear what types of data were added/removed. If the number of report lines reaches two hundred, then the process of “manual” comparison seems quite labor-intensive (about fifty hours).

Reducing labor intensity is achieved by using, for example, the “Cell Comparison” configuration from the Inform Service company. It is available for launch in 1C:Enterprise mode and presents comparison report data in a convenient form. The comparison is carried out using 1C capabilities:

The operation scheme is simple. A comparative object report is created in the configurator. Saved to a file, for example, Comparison Report.mxl. In the 1C:Enterprise dialog it opens and the cells to be compared are indicated (by double-clicking with the right mouse button on the selected cell of the spreadsheet document). By clicking “Compare”, the result of the comparison is given, with different positions highlighted in color.

Further instructions for action look like this.

1. The next report is saved with the same name.
2. After the update is completed and modifications to the standard configuration are transferred, syntactic control of the modules and testing of the operation of the changed objects is performed.
3. After successful testing, the process can be considered complete. All that remains is to update the printed forms, reports and processing. In some cases, check external reporting forms.

We work with 1C 7.7

Updating a standard platform to the same one usually does not cause difficulties. You just need to follow the instructions in the instructions. They are located in UPDATE.TXT of the distribution directory.

There are also no difficulties if additional accounting elements are added to the platform (directories, constants, selections, reports, registers, calculation journals, etc.). They will fit when the platforms are combined. Added documents will also not cause disharmony if there were no changes to the characteristics for input “based on” such added documents.

It is recommended to perform update on a fast PC with a large amount of RAM. If there is a lack of it, 1C may refuse to work out some of the functions and freeze. A large amount of virtual memory does not solve this problem.

Creating a backup copy

For this purpose, you need to use the option: “Administration/Save data...”. It is convenient to indicate the name of the archive, combining it with the creation date (for example, YYMMDD.zip).

Preparing catalogs

To work, you will need six configuration files (1cv7.md):

1. “WorkingNew” for preparing the update (resulting md-file);
2. “WorkingOld” for tracking changes during comparison and for transferring settings to TypeNew_2;
3. Typical (old) “TypeOld_1”. On its basis, a working one was previously created.
4. Types. (former) “TypeOld_2”. To track changes in 1C company in the new standard version;
5. Type. (new) "TypeNew_1". Improvements from 1C in the new version;
6. “TypeNew_2” for complex objects.

And five running configurators(all except “TypeNew_1”).

Initially, the directories are identical in pairs:

• “WorkerNew” and “WorkerOld”;
• "TypeOld_1 and TypeOld_2";
• "TypeNew_1" and "TypeNew_2".

Combining elements

First, we make a comparison between 3 and 2, 4 and 5, 1 and 6. To do this, for each of the first in the pair, select the “Configuration / Merger ...” item and specify the metadata file 1cv7.md of the second in the pair. A form with a tree of changed elements will be displayed on the screen. Next, it is necessary to analyze the results of a pairwise comparison of 3 with 2 and 4 with 5. Leave for merging elements in the updated platforms (1 and 6), in which there were changes from the 1C company (4 with 5), but were not reflected in 3 and 2. 1 and 4 need to be combined in substitution mode.

Others

This may include chart of accounts and user interfaces. If there have been changes in the chart of accounts, then it needs to be updated in the “Combining Objects” mode WorkNew together with TypeNew_2. After combining the interface, the presence of errors is checked: duplication of menu items, duplication of toolbars, setting the “Layout on new line” flags for toolbars.

The download is done over the network or on a server (preferred). First, exclusive access to the database is provided. And through the configurator mode the database is then loaded. Before and after the download, data is archived (as described at the very beginning of the section). Next you need to follow the instructions in the UPDATE.TXT file. After the download is complete, all directories except WorkNew can be deleted.

We hope our publication helped you understand updating a non-standard 1C configuration. We looked at this with regards to both the seventh and eighth versions.

Leave comments, write about your experience in the 1C update.