Personal experience: how to quickly and cost-effectively update a changed configuration. Personal experience: how to quickly and cost-effectively update a changed configuration Procedure for updating a non-standard configuration 1s 8.3

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

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

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

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

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

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

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

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

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

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

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

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

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

Several rules that simplify future updating of 1C configurations:

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

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

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

Using standard configuration functionality

Programmatic creation of form elements (In the FormCreationOnServer event)

Thank you!

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

Let's look at an example of updating a configuration 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

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

Download the configuration update file from users.v8.1c.ru or get it from any other available sources (for example, from an ITS disk);
Unpack and install the 1C 8 update file to any folder on your hard drive;
In the folder with the 1C 8 release number, find the file 1cv8.cfu - this is the file that contains configuration updates;
Run 1C:Enterprise in mode Configurator;
Go to menu Configuration -> Support -> Update configuration.
In the “Update configuration” window that opens, set the flag to the item Selecting an update file and press the button Further(if you want, you can use the first point Find available updates and search for update files automatically) ;
In the “Specify update file” field, select the .cfu file from the folder with the release number. Please note that it is not possible to update the 1C 8 database configuration 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 sequentially;
In the next window you will see a description of this update. You can also see which configuration versions 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 prompting you which releases should be installed;
If the selected file is suitable for updating the configuration, a window will appear with information about the update version. To continue updating, click the button OK;
After this, the update process will start. If your configuration is typical, then upon completion all that remains is to agree to change the current configuration and launch 1C 8 in mode Company;
If you are updating a configuration with changes (non-standard), then after the update process is completed, a window will appear comparing and merging the old and new configuration.

Updating a non-standard configuration 1C example analysis

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 standard metadata objects (common modules, roles, documents, directories, etc.). You need to make sure that all your changes remain in their place, safe and sound, but at the same time all the changes from 1C contained in the update file are also applied. It is for this purpose that when updating a changed configuration, a comparison window appears Basic configuration(with your changes) and New vendor configuration(updated standard configuration).

This window contains two columns, each of which contains a metadata tree. The first shows the current database configuration metadata, and the second shows the updated vendor configuration metadata (updated typical configuration). Green pencils indicate changed objects, the first column shows the typical metadata objects you changed, and the second column shows the typical metadata objects changed by the update. Thus, in order to correctly update a non-standard 1c configuration, you need to find all metadata objects that were changed by both you and the update (that is, changed twice).

To do this, click the button located at the bottom of the window Filter, in the window that opens, set the flag 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. have been added to your configuration, then updating the configuration will not overwrite them, they will remain in their place and nothing will happen to them. It is only the modified type objects that are the problem.

To correctly 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 complex task and requires maximum care and concentration.

General module update.

Let's look at an example: To a common module Version ControlConfiguration you made the following changes:
- In procedure CheckConfigurationVersion() commented out the line: //OpenFormModal("GeneralForm.DeprecatedConfigurationVersion", Parameters);
- We added our own procedure to the module with the name MyTestProcedure().
During the update, this module changed; by 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 glean from it. First, we see that the common module has changed in both the main configuration and the updated vendor configuration, this is indicated by the green pencils in both columns. Secondly, in the first column we see a checkbox next to the name of the common module; it indicates that the modules will be merged (the one we changed and the standard updated one). Thirdly, in the last column we see in what mode the modules will be merged. In this case the value is set to: Take from the new supplier configuration, this means that our changes will be completely overwritten, and the changes made by the update will be fully applied.

Other merging modes offer partial merging of modules, with different priorities. But I strongly recommend that you do not use these modes, since after doing this your module may end up in a mess: some of your changes will be overwritten, and some standard changes will not be applied. Therefore, change the values in the column Merge mode... we never will. Fourthly, if you uncheck the checkbox in the first column opposite the module, the merge will not be performed and the module will remain in the form in which it was before the update. Based on the above points, there are two ways to update the common module:
- Overwrite your changes by installing standard ones. Then manually make the overwritten changes to the updated module;
- Do not update the module and make standard changes manually.
Mechanisms for comparing configurations

To compare changes in a module, you can use the following built-in mechanisms of the configuration comparison-merging window:
- View module differences. To do this, in the comparison window, right-click on the module and select Show module differences... After this, the module comparison window will open, in which you can see which procedures differ in the updated and modified module. The upper part of the screen is divided into two columns: on the left there is a list of procedures for the main configuration that have been changed, and on the right there is a similar list of procedures for the updated standard 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 standard 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 and select In the window that opens, in the area Format, set the flag Details. In the report that opens, you can see which module lines have been 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). Much more interesting are its two modifications: O report on comparison of main configuration objects with old vendor configuration(only the changes you made are visible in this report) and (in this report only changes made to the module by the update are visible).
  
  Using 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 module differences. In the second report you can see in how many places the typical update made its changes.
We have sorted out all the tools needed to update the module. In order to show their practical application, let’s consider the module update process step by step. Version ControlConfiguration with the changes listed above. Let's update the module in two ways:
- Let's update the module, erasing the changes made to it. We will enter them manually after the update;
- We will not update the module. We will make the changes received in the update 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 too much 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 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 this: 1. General modules 1.1 Version ControlConfiguration
  - Let's find a common module Version ControlConfiguration Module. Right-click on it and select O in the context menu A report on comparing objects of the main configuration with the old one. In the window that opens, put a flag Details. Also I set the flag Output to Text Document, because it’s more convenient to see changes, but this is 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 line numbers 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 supplier configuration;
    - A procedure has been added; in the old supplier configuration its place is empty, but in the main configuration it is there. We don’t 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 in the context menu select the item Show module differences... Since line numbers (global numbering) are not visible in the module comparison window, in order to find the first change, let’s 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 look for the text highlighted in red. The changed line will be found in the CheckConfigurationVersion() procedure.
  - Let's open the text document created to record changes. In paragraph “1.1.1” we write down the name of the procedure in which the change is located. After this, 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. You will get the following record: 1. General modules 1.1 ControlVersionConfiguration 1.1.1 CheckVersionConfiguration //OpenFormModal("GeneralForm.Not RecommendedVersionConfiguration", 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 is a new procedure added. Since this procedure is completely absent in the old provider configuration, its text will be highlighted in blue:
  - Let's open the text document created to record the changes again. In paragraph “1.1.2” we write down 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 indicating that this module should be updated, erasing all changes made;
  - Next, you need to record changes to other twice-changed metadata objects in a text document. But since in this example we are considering a specific general module, we will skip this step;
  - After the work on the twice changed objects is completed, in the comparison / merging window, click the button Execute;
  - If a window appears with the text “There are objects changed in the main configuration...”, click the button Yes;
  - In the next window, Setting up support rules, do not change any settings, but simply click the button Yes;
  - The last message to appear is: “Configuration merging complete.” Press the button OK;
  - Save the configuration using the menu File -> Save, pictograms Save(blue floppy) or keyboard shortcuts Ctrl+S;
  - After the configuration is saved, we will restore the overwritten changes to the module. Find and open the module in the metadata tree ControlVersionConfiguration;
  - Let's open a text document in which the changes of this module are entered;
  - Paragraph “1.1.1” specifies the procedure CheckConfigurationVersion, let's find it in the module and open it;
  - The text document indicates that the line should be commented out: OpenFormModal("GeneralForm.DeprecatedConfigurationVersion", Parameters);
    Let's find it in the module and set a comment;
  - Paragraph “1.1.2” specifies the procedure MyTestProcedure, which needs 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 using one of the above methods;
  - The configuration update is now complete, all that remains is to update the configuration using the keys F5 or F7 or the corresponding icons, and in 1C:Enterprise mode confirm the legality of the update;
- Second way:
  - The second method completely repeats the first, except that it works in reverse. Therefore, I will describe it briefly;
  - We create a text document with the same structure;
  - Let's generate a report Report comparing objects of the new supplier configuration with the old supplier configuration;
  - Using the generated report and the module comparison window, we will write down the changes made by the new supplier configuration into a text document;
  - In the configuration comparison / merging window, check that next to the module Version ControlConfiguration THE FLAG IS REMOVED. This means that this module will not be updated;
  - We update the configuration, make changes from the text document to the module VersionConfiguration

Exchange plan update.

Let's look at an example: as part of an exchange plan By Organization you have included the directory ExternalProcessing. When updating a non-standard 1C configuration, the composition of this exchange plan 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.

Let's take a step-by-step look at updating the exchange plan By Organization with the following changes:

We will add new lines to the text document created when updating the general module: 2. Exchange plans 2.1 By Organization
Let's find an exchange plan By Organization in the compare/merge window, expand it to a branch Compound. I note that in terms of exchange, you can also change the module; 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 general module, the composition of the exchange plan can either be updated, then adding your own changes manually, or not updated, adding standard changes manually. If there are more changes in your composition than standard ones, then it is better to update using the second method; if there are fewer, then the first. You can see what changes there 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 ByOrganization;
Save the configuration;
After the configuration is saved, we will restore the overwritten changes to the exchange plan. In the metadata tree we will find and open the exchange plan ByOrganization;
In paragraph “2.1” of the text document the reference book is indicated ExternalProcessing, we will find it in the metadata tree of the exchange plan composition and set a flag indicating the participation of the directory in the exchange;
Let's save and update the configuration;

Update event subscription.

Let's look at an example: to an event subscription source Before Deleting the Directory for Exchange within an Organization you have included the directory ExternalProcessing. During the update, the composition of the sources changed, the task is similar to the previous ones - to update the non-standard 1c configuration correctly.

Let's take a step-by-step look at updating the list of event subscription sources with the following changes:

Updating roles in 1C

Before we start talking about updating roles in 1C 8, I would like to note that it is better not to change standard roles, there is no need for this, and besides, updating a non-standard 1C configuration is very difficult. If you are modifying any standard 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 don’t do this, then over time it will be very difficult for you to update standard roles (and sometimes impossible), since in almost every release they change a lot and reports on comparing configurations may not look very clear.

But still, there are often cases when the role has already been changed, and more than once, and there is no time to understand why and why. Therefore, let's look at an example: in a typical role Accountant for reference book Tax authorities read and view rights were added; during the update, the set of role rights was also changed.

Let's look at updating the role step by step:

Let's find a role Accountant in the compare/merge window, expand it to a branch Rights;
In this example there is only one change in the role, but this is not usually the case. Therefore, it is much easier not to update the role, but to make standard changes manually;
Let's form Report comparing new vendor configuration objects with old vendor configuration. Usually it contains a lot of information, but not all of it 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 need to be set for it. Therefore, after the update, you can either look at their arrangement in the provider configuration, or install all available ones.
- The changed objects look like this: - ***Directories - ***Tax Authorities - ***Permissions - ***Reading - ***Value -->Allowed<--Запрещено - ***Просмотр - ***Значение -->Allowed<--Запрещено
  At the same time, it is indicated in detail 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 - RegulatedReportStatisticsForm11NA
In this case, you can indicate which metadata object it is, but in this case it is already clear that the report;
In the comparison/combination window, uncheck the box next to the role Accountant;
After this, you need to write the changes to the other twice changed metadata objects into a text document and perform an update (the process is described in detail above);
Save the configuration;
After the configuration is saved, you need to make typical changes to the role Accountant. In the metadata tree we will find and open this role;
In paragraph “4.1” of the text document it is said that an object has been added to the role Regulated ReportStatisticsForm 11NA, find it in the role metadata tree, check the permissions Usage And View;
Let's save and update the configuration.

This completes the article about Updating a non-standard 1C configuration. If after reading you still have 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.

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

*Modified or non-standard configurations 1C is a software product on the 1C:Enterprise platform, which is part of or constitutes a fully 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 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 the infobase. 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 database and its modifications, automatic search for 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 reference 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. To obtain 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.

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

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

In the database for_updating we carry out *.cfu new release. The update procedure begins and the update window appears.

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

During the update process, a “ Unresolved links", click " Continue" We will talk about the reasons for the appearance of this window below.

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

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

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

Execute " Configuration» - « Support» - « Setting up support" In the window that opens, select “ Save to file"and save it in *.cf new release vendor configuration.

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

In configuration for comparison base we start comparing the supplier configuration (old release) and the supplier configuration from the file (new release).

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

In the database for_updating we start updating the configuration again through support “Configuration” - “Support” - “Update configuration”, in the window that opens, select *.cfu new release. The update procedure begins and the update window appears.

When you press the button " Filter"window will open" Setting up viewing filters" In this window, set the flag “ Show only twice changed properties».

When updating without our intervention, the following happens:

- the object has not been changed by us, changed in the new release - updated from the new release;
- the object is changed by us, not changed in the new release - our object remains;
- the object was changed by us, changed in the new release - this is a twice changed object, if you don’t change anything, it will be loaded from the new release.

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

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

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

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

If we compare these modules in the comparison databasebase, then the picture will be different:

It is obvious that the functions " Collect data for printing, corrections, invoices, invoices», « Collect data for printing the adjustment invoice" and others contain our improvements, but do not change during the update, which means there is no point in wasting time viewing and analyzing them.

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

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

For example, like this:

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

With a little mental effort, we will identify the twice changed procedures and functions, only they will need modifications after the merging process. With these procedures and functions, you need to decide which is easier:

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

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

After the common modules have been analyzed and the update flags for some procedures have been cleared, we see that the modules are now set to the merging mode - individual settings:

Let's move on. Among the twice modified objects there is the form of the directory element " BasicMeans" Before deciding whether to update this form from the new supplier configuration, you need to find out what actually changes during the update.

To do this in the database base Using the context menu, call " Object Comparison Report...” All the flags in the “Objects” group should be in the window that opens.

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

As a result of comparing the shape of the directory element " BasicMeans“We see that there are changes only in the form module, and there are no changes in the form dialog in the update.

But since the form of the element ended up in twice changed objects, our modifications are either in the form dialog or in the module.

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

The reason for this is the addition of the directory " BasicMeans» in terms of types of characteristics « Object Properties" If you update the form of a directory item " BasicMeans"we will get unresolved links, which will be indicated by the window:

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

Let's take a step back and imagine that the dialog of the directory element form " Basic facilities" changes when updating to a new release, then the best option would be to update the form. Only then, after merging, we would need to add our changes to the form, both in the module and in the dialog. If a module contains a lot of our modifications and little from the supplier, then after merging we can completely return our module and add the supplier’s changes.

In this case, during the merging process the window “ Unsolvable tags" There are two options in this window: 1) “ Mark all for merging"; 2) " Continue».

In my opinion, it is more correct to choose " Mark all for merging».

In this case, the plan of characteristics types " Object Properties" will be added as an object to be combined in the tree in the newly opened window " Update…»

Naturally, after updating the characteristics types to the plan, “ Object Properties"We will need to add our changes, make it better by comparing and merging with the current configuration.

Let's consider what would happen if we chose " Continue" in the window " Unresolved links" In this case, the form of the directory element " BasicMeans"would become new, and the plan of types of characteristics " Object Properties"would remain old. In this case, we will overwrite changes in the directory element form dialog, namely on the page “ PropertiesValues", see picture below.

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

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

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

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

The example is not related to this configuration update, but it is indicative, so let's consider it.

To the reference book " Counterparties» several details have been added and placed on the element form.

When updating the configuration to a new release, support will offer a window for comparing and merging the configuration, in which you can make various settings. Let's compare several options:

1. The form update flag is set, but the update is done procedurally , i.e. in fact, individual settings have been completed

Many people think that the form dialog should be taken from the vendor configuration, and the procedures depending on the settings made. Let's see how this is true after the merge is completed. Let's compare the supplier configuration with the main configuration.

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

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

In this case, the element form dialog is completely brought into line with the supplier element form dialog.

Let's get back to the update. We treat object modules and document manager modules in the same way as with general modules; we update them procedurally. We deal with document forms in the same way as we did with directory forms.

Separately, it is necessary to highlight the work with roles. Despite the fact that the example does not require updating roles, it is worth talking about it. Let's consider the simplest case, when the provider 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, etc.

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

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

After we have processed all the twice changed objects in the update window, click “ Execute»

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

In the window that opens " Setting up support rules"check whether the flags are set, although they should be set correctly by default, click " OK».

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

Now to the configurationfor_updatingWe add those minimal improvements that could not be updated correctly using standard tools.

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

In the database for_updating we'll do the same. We control twice changed objects, there should be no differences.

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

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

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

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

We will find out the answer to this question today.

What is a non-standard 1C configuration

An atypical 1C configuration is when:

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

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

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

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

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

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

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

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

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

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

1C update files can be of the following form:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a) if we check the box

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

b) if we don’t check the box

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

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

c) if we selected “Merge”

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

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

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

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

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

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

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

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

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

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

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

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

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

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