Technology for updating non-standard configurations 1s enterprise. Personal experience: how to quickly and cost-effectively update a changed configuration. Getting a file via update

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 the difficulties that arise.

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

General concepts

When updating (update, English) a non-standard platform, changes always affect the elements of the typical configuration (configuration, English) of the provider.

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;
• provider configuration (ConfigP - on its basis, both the working and the database configuration are created by the user.

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

Mixing

At the first stage, you need to remove the differences between the working and supplied configurations. This will reduce the evaluation of the improvements we have previously introduced. Inconsistencies between them occur when extraneous files (not from the supplied distribution kit) were used during the update or the update methods differed from the standard ones.

Version comparison

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 Setting"/"Version":

If the numbers match, you can skip ahead to Get a file through an update.

The next steps demonstrate how to match the operating and vendor 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 with a name, for example, work.cf. To do this, select "Configuration" / "Save ...".

Getting a vendor file

To match ConfigOR with ConfigP, you need a cf file from the vendor's distribution kit (of the 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 if the required vendor configuration version file does not exist? Then you need to create an empty database from the old one, update it to the required version, and only then use it.

Getting a file via update

To execute the update cf-file ConfigP, the command is selected in the menu: “Configuration / Support / Update ... / File selection / Done / Run” (Sequentially in the pictures):

To solve it, you need to uncheck the object for deletion in the provider's configuration. Then, after deleting, we perform the comparison again - click the "Update" button in the update window.

Restore settings

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

Saving and adjusting

To save the ConfigOR and update the database, select “Update…DB” in the “Configuration” menu item. Here we meet 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 other identifiers. As a result, objects of the same name appeared, but with different identification keys.

Roles can simply be deleted, since they have not changed. The requisite must be renamed, for example, to OrderReserve1. And after the update, make the values ​​from the renamed to the created one. Another update issue. What about forms?

From the figure, you can see that the ListForm was removed by the supplier, and then re-added under the same name. You need to mark both of them for updating and click "Execute".

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 register properties for updating now, and click "Run" again.

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

Base preparation

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 the directory and connect them to the IB list, with the client-server option, we do the upload/download.

Comparison

After opening both databases with the Configurator, we will perform their three-way comparison. We use the new ConfigP file for this - “Configuration / Support / Update ... / File selection ... / Done":

Comparison of the working, old and new provider configurations gives us a list of changed objects by the "Show properties changed twice" filter. With them, you need to solve the problem first of all:

At this point, work with the auxiliary base is suspended until the end of the entire process, the “Run” button is no longer pressed. We proceed to work in the main database with the resulting list of twice changed objects. Agreeing with the update will result in the loss of previously made improvements. Therefore, for each of the objects it is required to make a decision - how it will be changed.

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

Check the boxes to indicate procedures and functions to replace or delete:

Now you need to duplicate the state of the checkboxes in the auxiliary database. In the main - click "Run". At this point in the main we get an almost finished configuration.

Subsequent comparisons are performed again in the auxiliary database. We find the previously made changes by additional comparison of the old ConfigP with ConfigOR - "Configuration / Compare ...":

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

So, twice changed objects are received. In the main database, an almost ready-made configuration has been received. It needs 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 preserve the functionality. Perhaps this will require not the transfer of 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 the data in the reports are presented in such a way that does not allow you to quickly make a decision. At this step, the loss of improvements occurs if the changes concern the object attributes of the composite type.

In a comparison report, different data is given in the form of a list, from which it is not clear what types of data were added / removed. If the number of lines of the report reaches two hundred, then the process of "manual" comparison seems to be quite time-consuming (about fifty hours).

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

The scheme of work 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 compared cells are indicated (by double-clicking the right mouse button on the selected cell of the spreadsheet document). By clicking "Compare" the result of the comparison is given, while different positions are 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 the modifications of the standard configuration are transferred, the 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. It remains to update the printing forms, reports and processing. In some cases, check external reporting forms.

We work with 1C 7.7

Upgrading a typical platform to the same one usually does not cause difficulties. Just follow the directions in the instructions. They are located in UPDATE.TXT in the distribution directory.

Also, there are no difficulties if additional accounting elements are added to the platform (directories, constants, selections, reports, registers, calculation logs, etc.). They will fit when the platforms are combined. The added documents will also not introduce disharmony if there were no changes in the signs for entering “based on” such added documents.

It is recommended to run the update on a fast PC with plenty of RAM. With its lack, 1C may refuse to work out some of the functions and “freeze”. A large amount of virtual memory does not solve this problem.

Creating an archive copy

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

Catalog preparation

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

1. "WorkingNew" for preparing the update (resulting md-file);
2. "WorkingOld" for tracking changes when comparing 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 the 1C company in the new standard version;
5. Type. (new) "TypeNew_1". Improvements of the 1C company 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:

• "Working New" and "Working Old";
• "TypeOld_1 and TypeOld_2";
• "TypeNew_1" and "TypeNew_2".

Combining elements

First, we compare between 3 and 2, 4 and 5, 1 and 6. To do this, each of the first in the pair select the “Configuration / Association ...” 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 combining the elements in the updated platforms (1 and 6), in which there were changes from 1C (4 from 5), but were not reflected in 3 and 2. 1 and 4 need to be combined in override mode.

Other

This includes chart of accounts and user interfaces. If there were changes in the chart of accounts, then it must be updated in the "Combining objects" mode Working New along with Type New_2. After merging the interface, it checks for errors: duplication of menu items, duplication of toolbars, setting signs for toolbars “Location from a new line”.

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

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

Leave comments, write about your experience in updating 1C.

Let's consider an update using the example of a non-standard SCP 1.3 configuration that is under support with the possibility of changing from release 1.3.61.2 to release 1.3.62.1. Since the configuration itself is quite heavy, this imposes some features, in particular, it is not always possible to open several configuration comparison windows in one configurator.

For the upgrade, I use two identical copies of the old release database. In one of them I am preparing *.cf to update, let's call it, for example, for_updating. The other base remains untouched and serves only as an auxiliary one, for comparing configurations, let's call it base. In principle, the configuration of the working base can be used as an auxiliary one.

In base for_updating perform *.cfu new release. The update procedure starts and the update window appears.

Press the button " Run”, at this stage there is no need to look at anything yet, since the goal is only to get the configuration of the new release vendor.

During the update, a window may appear Unresolvable links", press" Proceed". We will talk about the reasons for the appearance of this window below.

A message will appear stating that the objects we have changed will be loaded from the new configuration, we agree.

The window " Setting up support rules" - for new objects (upper section) on both sides we put " The object is edited while maintaining support”, for existing supplier objects (lower section) in all four places we set the flag “ Save current mode", press" OK».

The main configuration has been updated. By itself, we do not need the main configuration at this stage, the goal is to obtain a new supplier configuration. Therefore, we do not save the main configuration, we do not update the database configuration.

We execute " Configuration» - « Support» - « Support Customization". In the window that opens, select " Save to file» and save to *.cf new release vendor configuration.

We do not need the main configuration in the form in which it is currently available. We close the configuration. " Configuration» - « Close configuration". We refuse to save changes.

In configuration for comparison base run a comparison of the vendor configuration (old release) and vendor configuration from a file (new release).

Thus, we will see only those changes that will be made in the configuration when updating to a new release.

In base for_updating run configuration update again via support "Configuration" - "Support" - "Update configuration", in the window that opens, select *.cfu new release. The update procedure starts and the update window appears.

By pressing the button " Filter» window will open « Setting View Filters". In this window, set the flag " Only show properties that have changed twice».

When updating without our intervention, the following happens:

• - the object is not changed by us, changed in the new release - updated from the new release;
• - the object is changed by us, not changed in the new release - our object remains;
• - the object is changed by us, changed in the new release - this is the object changed twice, if nothing is changed - it will be loaded from the new release.

Thus, the closest attention should be paid to the objects that have been changed twice, and we will consider them.

In this example, several common modules have been changed, including the common module "VAT accounting».

By default, the update window shows the differences between the main and new provider configuration and the old provider configuration.

If you look at the configuration differences in the common module " VAT accounting”, then we will see the following picture:

If we compare these modules in the database for comparisonbase, then the picture will be different:

Obviously, the functions CollectDataForPrintCorrectionInvoicesInvoices», « Collect DataToPrintAdjustment InvoiceInvoice” and others contain our improvements, but do not change during the update, which means that there is no point in wasting time viewing and analyzing them.

Therefore, performing a procedural update from the selected procedures and functions, you can remove the flags:

Many will say that you can see the differences between the old vendor configuration and the new one by changing the view filters settings in the current configurator, without using the comparison of configurations in the databasebase.

For example, like this:

However, as practical experience shows, this is not the case, procedures and functions are still displayed in the module comparison window, even with the filter " show the differences between the new vendor configuration and the old vendor configuration».

Having made not a big mental effort, we will reveal the procedures and functions that have been changed twice, only they will need to be improved after the merging process. With these procedures and functions, you need to decide which is easier:

• - either take a procedure or function from a new supplier configuration and then, after merging, make our improvements;
• - either remove the update flag, thereby saving our improvements, and only then add the required code from the vendor's configuration.

Merging with the priority of the main configuration and combining with the priority of the new configuration of the supplier I rarely use, in principle, even without using these modes, the result will be of high quality.

After the common modules have been analyzed and the update flags have been cleared for some of the procedures, we see that the modules now have the merge mode set - an individual setting:

We move on. Among the objects that have been changed twice, there is a form of the reference element " BasicMeans". Before deciding whether to update a given form from a new provider configuration, you need to find out what actually changes when you update.

For this, in the database base using the context menu, call " Object comparison report…”. All flags in the "Objects" group should be in the window that opens.

I like the report output mode in a spreadsheet document, when the differences are shown graphically, but this is a matter of taste.

As a result of comparing the form of the reference element " BasicMeans» we see that there are changes only in the form module, and there are no changes in the form dialog in the update.

But since the form of the element got into twice changed objects, our improvements are either in the form dialog or in the module.

Performing a similar comparison in the database for_updating you can see that there are improvements in the form dialog.

The reason for this is that the addition of the directory " BasicMeans» to the plan of types of characteristics « PropertiesObjects". If you update the form of the reference element " BasicMeans"We will get unresolvable links, as the window will indicate:

In this case, the best option would be not to update the form of the reference element " Main facilities” and only then add the necessary code to the element form module. In this case, the window Unresolvable links” will not appear during the update.

Let's make a digression and imagine that the dialog of the form element of the directory " Main facilities' changes when updating to a new release, then the best option would be to update the form. Later, after the merging, we would need to add our changes to the form, both in the module and in the dialog. If the module has a lot of our improvements and little from the supplier, then after the merger, you can completely return our module and add changes to the supplier.

In this case, during the merging process, the window “ Irresolvable tags". There are two options in this window: 1) " Mark All for Merge"; 2) " Proceed».

In my opinion, it is better to choose Mark all for merging».

In this case, the plan of types of characteristics " PropertiesObjects” will be added as an object to merge in the tree in the newly opened window “ Update…»

Naturally, after updating the plan of types of characteristics " PropertiesObjects» will need to add our changes, make it better by comparing and merging with the current configuration.

Consider what would happen if we chose " Proceed" in the window " Unresolvable links". In this case, the form of the reference element " BasicMeans” would become new, and the plan of types of characteristics “ PropertiesObjects' would have remained old. In this case, we will overwrite the changes in the form dialog of the reference element, namely on the page " PropertiesFValues”, see the figure below.

This problem is also not insurmountable, unless of course we forget about it.

Of course, it is best to try to make as few changes as possible to form dialogs , for example, to create details and buttons on the form programmatically.

Many generally recommend not changing the standard forms, but creating copies of them with our modifications and making them the main ones. I don't like this option because if the supplier added something in the form dialog, it will not appear on my form and I will have to make additions manually, and the supplier's changes can be much more than ours.

I would like to pay special attention by procedural updating forms (I take some of the procedures from the supplier's configuration, and some of them are not - individual settings). Let's consider how, in this mode, the form dialog is updated, in contrast to the mode "take from vendor config».

The example is not relevant to this configuration update, but is indicative, so let's look at it.

In the handbook " Counterparties» a few props are added and they are placed on the form of the element.

When updating a configuration to a new release through support, a compare and merge configuration window will be offered, in which you can make various settings. Let's compare several options:

1. The form update flag is set, but the update is done by procedural , i.e. in fact, customization is done

Many people think that the form dialog should be taken from the provider's configuration, and the procedures, depending on the settings made. Let's see how it is after the union. Let's compare the vendor configuration with the main configuration.

It is obvious that bindings and so on were broken on the forms, i.e. the form dialog was not completely taken from the provider's configuration. In this case, our objects remained in the form dialog, on the one hand, this is good, on the other hand, the location of our elements on the form is not always optimal, especially in connection with the addition of new supplier elements, there is a change in bypass positions and violation of bindings. In some cases, it's easier to manually add our elements to the form dialog than it is to make corrections.

2. The form update flag is set, the update is done in the " Take from new provider configuration»

In this case, the form dialog of the element is fully aligned with the form dialog of the supplier's element.

Let's get back to the update. We treat object modules and document manager modules in the same way as with common modules, updating them procedurally. We act with the forms of documents in the same way as we did with the forms of directories.

Separately, it is necessary to highlight the work with roles. Despite the fact that in the example it is not required to update the roles, it is worth talking about. Let's consider the simplest case, when the provider's configuration contains a new object. In this case, you will need to update the role "Full rights”, but this role may contain some objects created by us, for example, directories, documents, and so on.

It seems that with the role Full rights» everything is simple, we combine them completely, the rights to non-standard objects will be preserved in them anyway. So it is, the rights to non-type objects will never be lost, but all these objects will have the flag " Interactive removal", which is not always good. When comparing the configurations of the old release and the prepared new release, this is clearly visible:

We proceed with the rest of the roles in the same way as we work with modules - if there are more of our changes, then we do not merge the role, after updating we add to it what the supplier added in the new release.

After we have worked through all the twice changed objects in the update window, click " Run»

To the question that the objects we have changed will be loaded from the new configuration, we answer in the affirmative.

In the opened window " Setting up support rules"Check if the flags are set, although they should be correct by default, press" OK».

At the end of the merging process, we save the main configuration; we do not update the database configuration yet.

Now to configfor_updatingwe add those minimal improvements that could not be correctly updated by regular means.

To make it easier to control the execution of this process, in the database base Let's start comparing the vendor configuration and the main configuration of the old release.

In base for_updating let's do the same. We control twice modified objects, there should be no differences.

After updating the databasefor_undatingwill be completed, we update the database configuration and test some points, what exactly would be good to test will become clear during the upgrade process, everything is individual here.

It is advisable to update the working database with the help of support"Configuration" - "Support" - "Update configuration".In this case, twice modified objects will be loaded from the new release, i.e. our changes will be overwritten (we don’t save the configuration!), but then, when combined with the prepared configuration, we restore them. After that, you can save the configuration, update the database configuration.

The 1C licensing policy provides for the possibility of making and saving improvements to standard configurations, and, accordingly, the possibility of updating them.*

* Modified or non-standard configurations 1C is a software product based on the 1C:Enterprise platform, which is part of or constitutes the entire automated enterprise management system, 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., so 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 making changes and additions due to legislation. 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", there are more updates of the second type.

The specifics of updating non-standard configurations is the need to make all changes to the latest release of 1C, while fully preserving the previously made improvements. This is a non-trivial task, the solution of which does not have a standard script, which means that 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 available improvements. Briefly, they can be described as follows:

• Search and comparison of changed objects;
• Making updates from the new release;
• Introduction of previously made changes, "overwritten" at the previous stage;
• Checking the compatibility and operation of processes.

The difference will be in the implementation time: if there are a lot of improvements, the process will accordingly take more time, require focus, attention and manual verification.

Consider updating a non-standard configuration for the 1C environment using the example of "1C: Trade Management" (release 2014) for 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 it will have the same stages - updating (to a new standard configuration), working with reconciliation of the entered and changes made, etc.

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

Infobase unloading completed:

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

In the Configuration menu, select "Support" and "Update configuration". In fact, at this stage, the actions are completely the same as the process of updating a typical configuration:

Depending on the size of the database and its modifications, the automatic search for available updates may take some time. Therefore, despite the recommendations, it is worth choosing the option “Select an update file” and independently, having previously unpacked the archive with updates and saving them, specify the path manually:

Window with help information, instructions and the order of updates:

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

In order to find out which typical metadata objects have been changed before and will also be changed when a new provider configuration is installed, select "Show only twice changed properties":

There are only objects that meet this condition:

Expanding the metadata tree, you can see which specific objects will be changed. To get 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 make after installing updates, we create two reports: "Report on comparing objects of the main configuration with the old vendor configuration" (available improvements) and "New Vendor Configuration Object Compared to Old Vendor Configuration Report" (Updates).*

*Let's get some terminology out of the way:

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

Set up the report form and upload it. The list of previously made changes is fixed:

After unloading the reports, go directly to the update and click "Run". The configurator offers the update rule "Take from the new vendor configuration" (it is indicated in the third column). This means that all improvements will be erased and replaced with standard updated objects. Changing this rule to the tempting "Merge Mode" is not worth it, because. automatic merging will lead to chaos. Still, it's better to spend time and make changes manually:

In the window with general information about removing a configuration from support, you do not need to change anything. Clicking "OK" will merge the objects. Next, we launch the "Enterprise" and write down the changes in order to accurately complete the update process:

We accept the list of changes:*

*If the "Accept" button is inactive, you should run "Patch Testing":



We start debugging through F5 and get confirmation of the legality of the updates:

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

This article does not describe methods for applying 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 that require 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 displayed. Of course, you can use the technique described in the article. Yes, it will work. Many do updates this way. But I consider this approach to be inefficient 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 (*.cf files) at the same time and perform several configuration comparisons in one copy configurator. The only exception is, perhaps, only configurations built on SCP (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 sufficiently 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 performed completely automatically? Certainly. To do this, mutable objects must be added and must not use the functionality of an existing configuration. Those. these objects should solve completely different accounting tasks that expand the functionality of the supplier's typical configuration. Agree that the described situation is extremely rare. Almost always, the changes affect the objects of the typical configuration of the supplier.

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

• database configuration is the configuration that users work with;
• working configuration (main) is a configuration that we can make changes to, while users can continue to work;
• vendor configuration 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 provider can be not only 1C.

In the case when the configuration is removed from support, vendor configuration will not. 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 SCP configuration (the supplier of a typical configuration is 1C, improvements by Inform Service). Initially, updating this configuration was not performed using the technology described in this article, so the errors discussed in the article are the most common in practice. The upgrade will be performed from version 1.2.6.2 to version 1.2.14.1.

Stage 1. Preparation.

At the first stage, we will harmonize working configuration to vendor configuration. This is a very important stage, which will significantly reduce the amount of work on the analysis of the changes we made earlier.

This step can be skipped if the last update went through "support" (Menu "Configuration" U94; "Support" U94; "Update configuration") or was performed according to the method described in this article.

Version Mismatch working configuration And vendor configuration may occur when using *.cf files for updating, not from the vendor's distribution kit, or when using update methods that differ 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.

Checking 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 go to the next step. Cm. .

In this example, you need to match working configuration And vendor 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 such as work.cf . To do this, select the menu item "Configuration" U94; "Save configuration to file...".

3. Get the update file for the vendor configuration.

To match the configurations, we need a *.cf file from the vendor distribution with the same version number as working configuration(Figures 3 and 4). This file can be obtained when installing the appropriate distribution. By default, the configuration distribution package is installed to 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 template directory, then go to .

What can be done if there is no *.cf file of the required version vendor configuration? In this case, you can use the *.cfu files and repeat the procedure described in Step 1 several times to sequentially increase 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 uncover errors made earlier during the upgrade. Which, you see, is rather strange, given the fact that the vendor file is first assembled based on the *.cfu file, and then the update is performed. Perhaps this is due to the fact that for some reason not all configuration objects participate in the comparison. Therefore, I propose to use the longest possible path, but also more reliable.

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

Creating an "old" vendor file for the current configuration. The 1cv8.cf file can be taken from the vendor's distribution or saved from the working base if the configuration is supported. To save the file 1cv8.cf from the working base, you must in 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 a new provider configuration. The database can be created using the vendor distribution from the ITS disk or using the 1cv8.cf obtained earlier from the desktop. In the first case, follow the instructions included in the distribution. In the second case, to create a database from a file located on the desktop, create a new infobase without configuration and run the configurator. In the "Configuration" menu U94; "Load configuration from file ..." specify 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.

Creating a "new" vendor configuration file. To do this, select the item in the "Configuration" menu U94; "Save configuration to file...". We specify the location and file name 1cv8.cf. Click "Save".

4. Aligning the working configuration with the vendor configuration through an update.

Using the resulting *.cf file vendor configuration let's do the update. To do this, select the menu item "Configuration" U94; "Support" U94; "Update configuration", "Select update file", "Finish" (Figure 5), "Run" (Figure 6).

Solution options:

• uncheck the object that is in the provider's configuration;
• remove the reference to the object that is in the provider's configuration.

Based on the fact that the link in the added interface "Head of Department" is made to the object vendor configuration, support from which was withdrawn by the supplier (possibly due to a change in the accounting methodology), then the correct solution in this situation would be to remove the link to this report from the "Head of Department" interface. We do not close the configuration comparison window, we delete the link to the “Payment for Orders” report in the “Head of Department” interface. After deleting the link, let's re-compare the configurations. 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, let's merge with a previously saved file working configuration work.cf. To do this, select the menu item "Configuration" U94; "Compare, merge with the configuration from the file ...".

6. Saving the results of the update.

Save changes working configuration and update database configuration. To do this, select the menu item "Configuration" U94; "Update database configuration".

Here we face another problem (Figure 8).

To solve this problem, let's look at the cause of its occurrence. There may be several reasons, but the following are the most likely. These items have been copied to working configuration from vendor configuration or the provider has removed previously given objects, and later added new ones with the same names, but with different internal identifiers. As a result, objects with different internal identifiers but the same names appear in the configuration.

We act simply with roles - we delete them, because the roles have not changed (this can be checked by comparing and working configuration). We act differently with the details of the document. The attribute must be renamed, for example, OrderReserve1, and after the update, transfer the values ​​from the renamed attribute to the new one. To do this, you can use the processing of UniversalSelectionAndProcessingObjects.epf from the ITS disk.

Consider another situation similar to the previous one, but that arose when updating 1C: Enterprise Accounting 8.1. What to do with forms? (Figure 9)

In the figure, we can see that the ListForm has been removed from the provider, and then a new form with the same name has been added by the provider. Accordingly, it is necessary to mark both forms for updating and click the "Run" button.

If a message is displayed stating that there are links to objects to be deleted, it is necessary to clear the links to the form to be deleted in the object properties without closing the update form. In this case, in the properties of the register. After that, in the update form, click the "Update" button, mark the register properties for updating, and click the "Run" button again.

Save 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 transferring previously made improvements to the vendor's typical configuration.

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

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

If you upgrade across multiple versions, you should be sure to pay attention to the objects that are deleted and the objects with changed names, as well as the actions performed on the first start after the upgrade, during the upgrade. If these objects are used in processing at the first start after the update, then they should not be deleted, and for objects with changed names, appropriate changes should be made to the text of the processing module. In this case, the abandoned objects may be deleted during the second or next update.

If the update is performed through several versions, then to reduce the complexity of the update, you can use the technique with the calculation of key releases, described in the article.

1. Preparation of databases.

So, according to the results of the first stage, we are preparing two identical bases. The first (main) is our future result. The second (auxiliary) is for performing comparisons, opening configurations and other preparatory actions. For the file version, this is simply copying the files of the main database to another directory and connecting this directory to the list of databases, for the server client - uploading / downloading.

2. Three-way comparison of configurations.

Let's open both databases in the Configurator mode and perform a three-way comparison of the configurations in both databases using the existing vendor's new configuration file. To do this, in both bases, select the menu item "Configuration" U94; "Support" U94; "Update configuration", "Select update file", "Finish" (Figure 10).

As a result of comparing three configurations ( old vendor configuration, new provider 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 with these objects that you need to deal first of all, because. After the update, the settings made earlier may be lost.

On this work in the second (auxiliary) base we suspend and continue in the main one. The "Run" button in the auxiliary base does not need to be pressed. We need this database in this form until the end of the update process.

So, as a result, we get a list of objects that have been changed twice during revision typical configuration and in . If you agree with the update, then the improvements made earlier in these objects will be lost. Therefore, for each object, a decision must be made 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. Evaluation is not accurate fast - "by eye".

new provider configuration, we leave an instance of the provider object. We leave a checkmark. Then we 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. We uncheck the box. Then we transfer the changes from vendor configuration.

We deal with modules a little differently, because we have the ability to compare modules procedurally. Those. in case in our configuration and various module procedures have been changed in the vendor configuration, then by correctly ticking 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 the checkboxes remain, we duplicate the state by the checkboxes in the auxiliary database, and in the main database we press the "Run" button. In the main database, we get an almost finished configuration.

Further, all comparisons are performed in the auxiliary database. We already have one comparison - a three-sided one. To determine the previously made changes, we perform an additional second comparison old provider configuration from basic configuration. To do this, select the item in the menu "Configuration" U94; "Compare configurations:", choose to compare " Vendor configuration" And " Basic Configuration

In a similar way, we compare old provider configuration with new . For comparison, we need a file new provider configuration. If there is no such file, then now it can be obtained from the main database. To save to file new provider configuration in the main database in the "Configuration" menu U94; "Support" U94; "Support settings:" click the "Save to file" button. (Figure 2). Specify the file name, for example, new.cf. Next, we make the third configuration comparison and, when comparing, specify the new.cf file as the second configuration.

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

To reduce the time for analyzing changes to a typical configuration and, accordingly, for updating, it would be appropriate to comment on all changes made to the configuration, noting only the changed text of the modules, but also the purpose of the changes made. For a number of reasons, this is 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. Perhaps this will require not the transfer of changed lines, but a complete reworking of 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 decision making.

But in some cases, the data in the comparison reports is presented in a way that does not allow you to make a decision quickly. For example, in case of changing the type of attributes that have a composite data type, the composition of inputs based on objects, etc. It is at this stage, due to its complexity, that there is a loss of improvements during the update. Let's consider this situation using the example of attributes that have a composite data type. When generating a report on the comparison of objects (Figure 17), different data in the compared configurations are presented as lists containing the composition of data types separated by commas. At the same time, the report does not show at all what types of data have been added or removed. Of course, to identify differences, the report can be printed and "hidden". In the example under consideration, there are about 200 such objects. It is obvious that the comparison process seems to be quite laborious and will take about 50 hours.

To reduce the complexity of work when comparing objects, you can use the configuration developed by Inform Service. Approximately 20 times the labor intensity of work can be reduced when comparing composite objects.

The “Comparison of cells” configuration is launched in the 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 the 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 specify 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 differing 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 the previously made changes to the typical configuration, we will perform syntactic control of the modules and check the operation of the changed objects. After successful testing, the process of updating the configuration can be considered completed. Now it remains to update external printing forms, reports and processing. For some configurations, it is necessary to check the reporting forms connected as external.

Stage 3. Delivery of works.

In the given example, the amount of work to correct errors made during previous updates, as well as to update to version 1.2.14.1 and transfer changes previously made to the standard configuration is about 100-150 hours. It is not possible to perform 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 should be transferred to the customer's working database.

First, carefully study the instructions from the delivery distribution kit. We perform the necessary work before updating in the working database.

If in the customer's working database during the preparation of the update no work was done to change the configuration, and the update was prepared on the current copy of the working database, then to transfer the settings, we will save the working configuration to a file, for example work_2.cf, by selecting the menu item "Configuration" U94; "Save configuration to file...".

• using the work_2.cf file, transfer the changes. To do this, select the menu item "Configuration" U94; "Load configuration from file...";
• we will answer the question about updating the database configuration with yes.

If the customer's production database underwent configuration changes during the preparation of the upgrade, then these changes must also be reflected during the upgrade.

If the update was not prepared on the current copy of the working database, then to transfer the settings, we will use the technique used at the first stage. To do this, we need the *.cf file of the typical vendor configuration (1.2.14.1) and the result of the update in the form of a *.cf file as well. To do this, let's save the working configuration to a file, for example work_2.cf, by selecting the menu item "Configuration" U94; "Save configuration to file...".

The next steps on the client's side are as follows:

• create a database backup;
• Let's update using the *.cf file of the vendor's typical configuration. 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, transfer the changes. To do this, select the menu item "Configuration" U94; "Compare, merge with the configuration from the file...";
• save the changes to the running configuration and update the database configuration. To do this, select the menu item "Configuration" U94; "Update database configuration".

This article will talk about updating a non-standard 1C configuration (editions 8.2 and 8.3), saving all the changes made by you (or other developers) to a typical 1C 8 configuration.

Consider an example of a configuration update Accounting 2.0 with non-standard changes in modules, roles, event subscriptions, exchange plans, etc. The cases discussed here will not be too difficult to update, with their help I will only show the update technique, which will allow you to deal with your cases.

Updating a non-standard 1C configuration step by step instructions

Consider step by step the algorithm for updating the 1C 8 configuration. This algorithm is universal, its first eleven steps describe the process of updating any typical 1C 8 configuration, and all the points together describe updating a non-standard 1C 8 configuration:

• Download the configuration update file from the site users.v8.1c.ru or get it from any other available sources (for example, from the ITS disk);
• Unpack and install the 1C 8 update file to any folder on your hard drive;
  
• In the folder with the release number 1C 8, find the file 1cv8.cfu - it is this file that contains configuration updates;
  
  
• Run 1C:Enterprise in mode Configurator;
• Go to menu Configuration -> Support -> Update Configuration.
  
  
• In the opened window "Configuration update" set the flag on the item Selecting an update file and press the button Further(if you want, you can use the first paragraph Search for available updates and search for update files automatically) ;
• In the "Specify the update file" field, select the .cfu file from the folder with the release number. Note that you can not update the configuration of the 1C 8 base for any release. For each update file there is a list of releases for which it is intended. Therefore, you may have to install several update files in sequence;
• In the next window, you will see a description of this update. You can also see which versions of the configuration this file is intended for updating. Click the button Continue update;
• If this version of the configuration cannot be updated with the selected file, then you will be given a window with a hint about which releases to install;
• If the selected file is suitable for updating the configuration, a window with information about the version of the update will appear. Click the button to continue updating. OK;
  
• After that, the update process will start. If your configuration is typical, then upon its completion, all that remains is to agree to change the current configuration and run 1C 8 in mode Company;
• If you are updating a configuration with changes (non-standard), then after the update process is completed, a window for comparing and merging the old and new configurations will appear.

Updating a non-standard configuration 1C analysis of an example

Let's move on to a detailed analysis of the correct update of a non-standard 1C 8 configuration. The whole problem of updating such a configuration is that third-party changes have been made to typical metadata objects (common modules, roles, documents, directories, etc.). It is necessary to make sure that all your changes remain in their place, safe and sound, but at the same time, all the changes of the 1C company contained in the update file were also applied. For this, when updating the changed configuration, a comparison window appears. Main Configuration(with your changes) and New provider configuration(updated typical configuration).

This window has two columns, each containing a metadata tree. The first shows the current database configuration metadata, and the second shows the updated provider configuration metadata (updated generic configuration). Changed objects are marked with green pencils, the typical metadata objects that you have changed are marked in the first column, and the typical metadata objects that have been changed by the update are marked in the second column. Thus, in order to correctly update a non-standard 1s configuration, you need to find all metadata objects that have been changed by both you and the update (that is, changed twice).

To do this, click the button at the bottom of the window. Filter, set the flag in the opened window and press OK.

Now only the objects we need will be visible in the comparison window, which greatly simplifies the update process. It should be noted that if new non-standard documents, directories, roles, modules, etc. are added to your configuration, then updating the configuration will not overwrite them, they will remain in their place and nothing will happen to them. The problem is only modified generic objects.

To properly update different metadata objects, you need your own approach, so let's look at various situations using simple examples. I also note that updating heavily rewritten configurations is a difficult task and requires maximum care and concentration.

Shared module update.

• Consider an example: To a common module Version ControlConfiguration you made the following changes:
  • In procedure CheckConfigVersion() commented out the line: //OpenFormModally("CommonForm.DeprecatedConfigurationVersion", Parameters);
  • We added our own procedure to the module with the name MyTestProcedure().

  When updating, this module has changed, putting a filter on twice changed in the comparison window, we will see that it is included in the list.
  
  Let's take a closer look at this window, and understand what information we can get from it. First, we can see that the common module has changed in both the main configuration and the updated vendor configuration, as indicated by the green pencils in both columns. Secondly, in the first column we see a checked box next to the name of the common module, it indicates that the modules will be merged (what we have changed and the standard updated one). Thirdly, in the last column we see in what mode the modules will be combined. In this case, the value is set to: Take from the new provider configuration, this means that our changes will be completely overwritten, and the changes made by the update will be fully applied.

  Other merge modes offer partial merge of modules, with different priorities. But I strongly recommend that you do not use these modes, since after that your module may end up with a natural "porridge": some of your changes will be overwritten, and some typical changes will not be applied. So change the values ​​in the column Merge mode... we never will. Fourth, if you uncheck the checkbox in the first column opposite the module, then the merging will not be performed and the module will remain as it was before the update. Based on the above points, there are two ways to update the common module:

  • Overwrite your changes by setting the default ones. Then manually make the overwritten changes to the updated module;
  • Do not update the module and make typical changes manually.

  Configuration Comparison Mechanisms

  To compare changes in a module, you can use the following built-in mechanisms of the configuration comparison-merge window:

  • View module differences. To do this, in the comparison window, right-click on the module, select the item Show Differences in Modules… After that, a module comparison window will open, in which you can see exactly which procedures differ in the module that you updated and changed. The upper part of the screen is divided into two columns: on the left is a list of the main configuration procedures that have been changed, and on the right is a similar list of procedures for the updated typical configuration. The lower part of the window is also divided into two parts, according to the same principle. It displays the code of the selected procedures. Lines that are present only in the main configuration are highlighted in blue. Lines that are present only in the updated typical configuration are highlighted in green. Lines that are present in both configurations, but do not match, are highlighted in red.
    
    
    
    
    
    
    
  • . You can also use the object comparison report to compare modules. To call it in the comparison window, right-click on the module select item In the window that opens, in the area Format, set the flag Detailed. In the report that opens, you can see which lines of the module have changed and how they look in both configurations.
    
    
    Despite the fact that this report provides all the information about the changes, it is not convenient to use (at least when updating modules). Two of its modifications are much more interesting: O report on comparison of objects of the main configuration with the old configuration of the supplier(only changes made by you are visible in this report) and (only only the changes made to the module by the update are visible in this report).
    
    
    
    With the help of the first report, you can see in how many places your changes have been made in the module, this will allow you to quickly find them in the window View differences in modules. In the second report, you can see in how many places a typical update has made its changes.

  We have sorted out all the tools needed to update the module. In order to show their practical application, let's take a step-by-step process of updating the module. Version ControlConfiguration with the above changes. Let's update the module in two ways:

  • Let's update the module, overwriting the changes made to it. We will enter them manually after the update;
  • We will not update the module. Changes received in the update will be made later.

  First way:

  • • Before describing the algorithm, I note that we are considering a very simple update example so that the description does not take up a lot of space, but the update process in a complex case consists of exactly the same steps, although it requires more concentration and care;
    • Before updating the configuration, let's create a text document. In it, we will record the changes that will need to be made manually after the update. Data in a text document should be presented in the most understandable way, that is, be structured. In our example, we will write like this: 1. Common modules 1.1 Version ControlConfiguration
    • Let's find a common module Version ControlConfiguration Module. Right-click on it and select O from the context menu Report on comparison of objects of the main configuration with the old one. In the window that opens, set the flag Detailed. Also I set the flag Output to text document, because it is more convenient to watch the changes, but this is already a matter of habit. Let's press the button OK. The report that opens will look like this:
      
      
    • The report shows that two changes have been made to the module (before each new change, the numbers of the lines in which it was made are written):
      • Line 34 has been changed, it is commented out in the main configuration, but not in the old vendor configuration;
      • A procedure has been added, in the old configuration of the supplier it is empty in its place, but in the main configuration it is. We do not close the report, it will be useful to us;
    • Now let's find the first difference in the module comparison window. To do this, right-click on the branch again Module and select the item in the context menu Show Differences in Modules… Since the line numbers (global numbering) are not visible in the module comparison window, in order to find the first change, we scroll through all the procedures in the upper half of the window. We also know from the report that the first change is associated with a line change, so we are looking for the text highlighted in red. The changed line can be found in the CheckConfigVersion() procedure.
      
      
    • Let's open the text document created to record the changes. In paragraph "1.1.1" we write down the name of the procedure in which the change is located. After that, we need to enter the found change into it so that we can easily find it in the text of the module. To do this, I usually copy into the document not one, but several lines of the procedure at once, before and after the changes. But in this case, the procedure is small and therefore it is enough to copy the changed line itself. The following record will be obtained: 1. Common modules 1.1 ConfigurationVersion Control 1.1.1 CheckConfigVersion //OpenFormModally("CommonForm.DeprecatedConfigurationVersion", Parameters);
    • Now let's open the configuration comparison report again, look at the next change and also find it in the module comparison window. This time it's an added new procedure. Since this procedure is completely absent in the old vendor configuration, its text will be highlighted in blue:
      
      
    • Let's reopen the text document created to record the changes. In paragraph "1.1.2" we write the name of the added procedure. After that, copy the entire text of the added procedure there. 1.1.2 MyTestProcedure Procedure MyTestProcedure() Export //Procedure Text EndProcedure
    • Version ControlConfiguration a flag is set, which means that this module should be updated, overwriting all the changes made;
      
    • Next, you need to write changes to other twice changed metadata objects into a text document. But since in this example we are considering a specific common module, we will skip this step;
    • After the work on the twice modified objects is completed, in the comparison / merging window, press the button Run;
    • If a window appears with the text "There are objects changed in the main configuration ...", press the button Yes;
      
      
    • In the next window Setting support rules, do not change any settings, but simply click the button Yes;
      
      
    • The last message to appear is: "Configuration merging complete." Click the button OK;
      
    • Save the configuration using the menu File -> Save, pictograms Save(blue floppy disk) or keyboard shortcuts ctrl+s;
    • After the configuration is saved, restore the overwritten module changes. Find and open the module in the metadata tree Version Control Configuration;
    • Let's open a text document in which changes have been made to this module;
    • Paragraph "1.1.1" specifies the procedure CheckConfigVersion, find it in the module and open it;
    • The text document indicates that the line should be commented out: OpenFormModally("CommonForm.DeprecatedConfigurationVersion", Parameters);

      Find it in the module and set the comment;

    • Paragraph "1.1.2" specifies the procedure My Test Procedure, to be added to the module. Copy it from a text document and paste it at the end of the module;
    • We save the configuration in one of the above ways;
    • The configuration update is completed on this, it remains only to update the configuration using the keys F5 or F7 or the corresponding icons, and in the 1C:Enterprise mode, confirm the legality of the update;
      
      
  • Second way:
    • The second method completely repeats the first, except that it acts from the opposite. Therefore, I will describe it briefly;
    • We create a text document with the same structure;
    • Let's generate a report Report on comparing objects of the new supplier configuration with the old supplier configuration;
    • Using the generated report and the module comparison window, we write out the changes introduced by the new supplier configuration into a text document;
    • In the window for comparing / merging configurations, we check that next to the module Version ControlConfiguration FLAG OFF. This means that this module will not be updated;
    • Update the configuration, make changes from the text document to the module Version Control Config.

Exchange plan update.

Consider an example: as part of an exchange plan ByOrganization you have included the guide External Processing. When updating the non-standard configuration 1c, the composition of this exchange plan has changed and we are faced with the task of correctly updating the exchange plan without losing either the standard changes or our own. The tools used to compare changed metadata objects have been described in detail in the previous paragraphs, so for this case everything will be described briefly.

Consider the steps to update the composition of the exchange plan ByOrganization with the following changes:

• Add new lines to the text document created when updating the common module: 2. Exchange plans 2.1 By Organization
• Let's find an exchange plan ByOrganization in the comparison / merge window, expand it to a branch Composition. I note that in the exchange plan, the module can also be changed by you, it must be updated according to the rules described for the general module. In this case, we are interested in updating the composition of the exchange plan;
  
• As in the case of the common module, the composition of the exchange plan can either be updated, then adding your changes manually, or not updated, adding typical changes manually. If there are more of your changes in the composition than typical ones, then it is better to update the second way, if there are fewer, then the first. You can see what changes are more using the same reports:
  
• In our example, there are more typical changes, so we will write out our changes in a text document: 2. Exchange plans 2.1 By Organization - *** Directories - --> Directory. External Processing
• Check that the checkbox next to the exchange plan is checked in the comparison / merging window By Organization;
• We save the configuration;
• After the configuration is saved, we will restore the overwritten changes to the exchange plan. Find and open the exchange plan in the metadata tree By Organization;
• In paragraph "2.1" of the text document, a reference book is indicated External Processing, find it in the metadata tree of the exchange plan composition and set the flag indicating the participation of the directory in the exchange;
  
  
• Save and update the configuration;

Update an event subscription.

Consider an example: to an event subscription source Before Deleting Directory For Exchange By Arranging you have included the guide External Processing. When updating, the composition of the sources has changed, the task is similar to the previous ones - to update the non-standard 1c configuration correctly.

Let's take a look at updating the composition of event subscription sources with the indicated changes step by step:

Updating roles in 1C

Before you start talking about updating roles in 1C 8, I would like to note that it is better not to change typical roles, there is no need for this, and updating a non-standard 1c configuration is also very difficult. If you are finalizing any typical configuration and adding your documents, directories, etc. to it, then create your own role (or several, depending on the situation), in which you include new metadata objects. If you do not do this, then over time it will be very difficult for you to update typical roles (and it is impossible in an hour), since they change a lot in almost every release and configuration comparison reports may not look very clear.

But still, there are often cases when the role has already been changed, and more than once, but there is no time to figure out why and why. Therefore, consider an example: in a typical role Accountant for reference Tax authorities the rights to read and view have been added, while updating the set of role rights has also been changed.

Consider updating the role step by step:

• Let's find a role Accountant in the comparison / merge window, expand it to a branch The rights;
  
• In this example, there is only one change to the role, but this is usually not the case. Therefore, it is much easier not to update the role, but to make standard changes manually;
• Let's form Report on comparing objects of the new provider configuration with the old provider configuration. Usually there is a lot of information in it, but not all is needed for updating:
  
• Either new metadata objects have been added, or rights have been changed for old ones:
  • The added objects look like this: - -->

    When adding a new object, the report does not display information about what rights must be set for it. Therefore, after the update, you can either see their arrangement in the vendor's configuration, or install all available ones.

  • The modified objects look like this: - ***References - ***Tax Authorities - ***Permissions - ***Read - ***Value -->Allowed<--Запрещено - ***Просмотр - ***Значение -->Allowed<--Запрещено

    It details which rights have changed;

• In our example, there is only one line of useful information in the comparison report, we add it to the text document: 4. Roles 4.1 Accountant - --> Object - Regulated Report Statistics Form 11HA

  In this case, you can specify which metadata object it is, but in this case it is already clear that the report;

• In the compare / merge window, uncheck the box next to the role Accountant;
• After that, it is necessary to write changes to other twice changed metadata objects into a text document and update (the process is described in detail above);
• We save the configuration;
• After the configuration is saved, you need to make typical changes to the role Accountant. Find and open this role in the metadata tree;
• Paragraph "4.1" of the text document says that an object has been added to the role RegulatedReportStatisticsForm11NA, find it in the role metadata tree, check the boxes on the rights Usage And View;
  
  
• Save and update the configuration.

This article about Updating a non-standard 1C configuration is completed. If after reading you have any questions, feel free to ask them in the comments! At the request of readers, in the next article I can talk about other interesting and complex aspects of updating a non-standard 1C 8 configuration.