Updating non-standard configurations 8 2. Personal experience: how to quickly and cost-effectively update a changed configuration. Exchange plan 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 emerging difficulties.

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

General concepts

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

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

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

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

Mixing

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

Comparison of versions

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

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

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

Saving the configuration (working)

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

Retrieving the Provider File

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

Receiving a file via update

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

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

Restoring settings

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

Saving and adjusting

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

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

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

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

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

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

Preparation of bases

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

Comparison

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Further instructions for action look like this.

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

We work with 1C 7.7

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

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

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

Creating a backup copy

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

Preparing catalogs

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

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

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

Initially, the directories are identical in pairs:

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

Combining elements

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

Others

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

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

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

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

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 the website 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 look for update files in automatic mode);
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 are intended for updating. this file. 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 standard, 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, 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 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. Bottom part 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 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 context menu select point O 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 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 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 will 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.
  - Version ControlConfiguration 1.1.2 MyTestProcedure Procedure MyTestProcedure() Export //Procedure text EndProcedure
  - 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 If a window appears with the text “There are objects changed in the main configuration...”, click the button;
  - In the next window, Setting up support rules, do not change any settings, but simply click the button 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. Let's copy it from text document
  - and insert 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:
  - 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 by adding your own changes manually, or not updated by 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.

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

Defining the Configuration Type

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

Standard (typical) configuration - preparation for update

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

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

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

Updating a non-standard (modified) 1C configuration

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

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

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

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

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

Possible when updating 1C

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

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

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

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

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

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 required 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 tick. Then you will need to transfer changes from the working configuration. If there are more changes in the object in the working configuration, then we leave an instance of the working configuration object. Uncheck the box. You will then need to migrate the changes from the provider configuration. You can do things a little differently with modules, because... It is possible to compare modules procedurally.

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

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

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

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

Several rules that simplify future updating of 1C configurations:

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

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

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

Using standard configuration functionality

Programmatic creation of form elements (In the FormCreationOnServer event)

Thank you!

Leave your name and phone number, the operator will contact you at work time within 2 hours.

Moscow St. Petersburg Samara

Step-by-step instructions with photos

Many users of standard 1C configurations are afraid to make changes and update programs on their own. In many ways, these fears are justified, since incorrect updating of a non-standard 1C configuration can lead to loss of data or loss of completed settings. That is why we have compiled the most detailed step by step instructions, in which we will show how to correctly update a non-standard 1C configuration.

Attention : Before you begin the update, be sure to create backup copies of all information databases. This will allow you to return to the original state if problems arise with the update.

Making a backup copy of information databases is quite simple. To do this, launch the 1C program in the “Configurator” mode. In the “Administration” tab, select the “Download infobase” function. If you wish, you can additionally save the databases on disk or removable media.

Step-by-step instructions for updating a non-standard 1C configuration

The first stage completely coincides with updating the standard 1C configuration. We launch the “Configurator” mode, which is available only to users with full rights access. In the “Configurator” tab, select “Support” and click “Update configuration”.

In the next dialog box, you need to check the “Search for updates in catalogs” checkbox. Click "Next".

Attention: 1C updates are available only to users of licensed programs “1C:Enterprise”; to receive updates, users of PROF versions must additionally conclude a 1C:ITS (Information Technology Support) agreement. You also need to register on the site technical support users https://users.v8.1c.ru/. Users of licensed 1C programs can register on the site either independently, using the instructions included with the program, or with the help of our managers.

Attention: For many configurations, there are several program reactions (for example, Accounting 2.0 and Accounting 3.0). When choosing an update, pay attention to which edition the update will be applied to.

In the window that appears, check that the selected update is correct. If all the data is correct and you agree with them, click the “OK” button.

The update process may take several minutes. After which a window will appear with the result of comparing the new and current configuration so that you can see which systems will be updated. Click the Run button.

Attention : 1C:Enterprise 8 allows you to automatically update even changed configurations. If the changes made do not intersect with objects developed by 1C (for example, additional details have been added to the document or the new kind directory), the update will be completed correctly. However, if the settings made “intersect” with standard objects for updating, it is recommended to invite a 1C specialist.

If you are sure that all changes made to the configuration do not intersect with 1C objects, in the subsequent windows that appear, we agree with the program.

After this, the program will offer to update the database configuration. We agree with the program
In the process of updating non-standard 1C configurations, the structure of the information base changes. The program informs the user about this in a separate dialog box. You need to accept these changes, so just click the “Accept” button.

The difficulty of maintaining non-standard 1C configurations is that they are individual for each individual organization. That is why the company “1C:Franchisee Victoria” assigns to each company with a non-standard configuration of 1C programs a personal specialist who knows the specifics of setting up programs. In addition, our technical support team is always ready to answer your questions.