Updating a non-standard configuration 1s 8.2 step by step instructions. Personal experience: how to quickly and cost-effectively update a changed configuration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

When updating without our intervention, the following happens:

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

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

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

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

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

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

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

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

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

For example, like this:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Personal experience: how to quickly and cost-effectively update a changed configuration

Updating the configuration for several releases at once is very dangerous. The point is that after each configuration update, the infobase update is started in 1C:Enterprise mode. Therefore, if you update only the latest release, infobases may not match the latest configuration. In the article, Dmitry Rudakov, a specialist of the Siberian Agrarian Group CJSC, shares his personal experience in a one-time configuration update for 12 releases.

Checking the configuration change mode

Let's imagine such a situation. The developers of "Manufacturing Enterprise Management" (hereinafter referred to as PPM) in release 1 (release numbers hereinafter are assigned conditionally) to the dimension (indicator) of the calculation register, they assigned the type "DirectoryReference.Individual" with the name "Individual". In release 2 they added one more dimension - "Employee" with type "ReferenceReference.Employees". When 1C:Enterprise is launched, processing is enabled that fills in the "Employee" dimension in the same way as the "Individual" dimension. And then in release 3, the "1C" developers removed the "Individual" dimension and left only the "Employee". If you update the configuration from release 1 immediately to release 3, you can clear the entire calculation register.

And if the configuration is supported with the possibility of change, and regulated reporting is generated in the same database, then it is necessary to update the configuration for each release, which can be very expensive in terms of man-hours. For example, updating a heavily modified "SCP" for 1 release can take 30 hours of working time for an experienced specialist.

Therefore, before proceeding with the update, you need to determine: are you working in a typical configuration with the possibility of change or in a configuration without the possibility of change? To do this, go to the configurator, where in the menu, follow the steps "Configuration - Support - Support settings".

Fig.1. Calling the configuration support setting window

If it is set to "On support", then this configuration is typical, and if "Changeable is enabled" - the configuration is most likely changed (at least such a possibility is included). The third state is "Configuration is deprecated". The various configuration states are shown in Figures 2, 3, 4.

Rice. 2. Typical configuration without the possibility of changes

Rice. 3. Typical configuration with change enabled

Rice. 4. Configuration removed from support

Algorithm for updating changed configurations

Recently, I faced the task of updating the changed configuration "Trade Management", release 10.3.13.2. The configuration has been changed as a result of merging with the industry solution "BIT: Car Service Management 8" and has been continuously refined for two years. Now the configuration had to be updated to release 10.3.25.1, that is, 12 releases. I have broken the whole update procedure into several steps.

Stage 1. Estimation of the cost and timing of the renewal procedure

Before embarking on independent work, I decided to get an independent assessment of experts in this field. The only company that has the ability to update changed configurations by automated methods is 1C-IzhTiSi LLC. I contacted the specialists of this company with a request to estimate the cost of updating my configuration. To estimate the time and cost of the work, I provided the current configuration that needs to be updated. A day later I received an email with a report.

Report on the results of the assessment of the cost and timing of the configuration update:

Configuration: Trade Management Revision 10.3
Current config version: 10.3.13.2
Update to version: 10.3.25.1
Number of upgradeable modules: 1,847
Number of control releases: 8

The results of the assessment surprised me, since the price per share was indicated on the company's website - 1000 rubles. for one release update. Comment "1C-IzhTiSi":

"The cost of updating for each missed release is no higher than 2,000 rubles. Now there is a promotion, so the cost does not exceed 1,000 rubles. But the final price of services is determined by the results of an assessment of labor costs for updating and may be lower than 1,000 rubles per release."

I also clarified how the releases needed for the update were selected. In response to my question, I received a screenshot in which this was clearly demonstrated (Fig. 5). The Version Number column indicates the configuration version to which you want to upgrade. The 'Upgrade Version' column indicates which release you can upgrade from. As a result of the evaluation, the number of required updates was reduced to 9.

Rice. 5. Selection of releases that must be used to correctly update the configuration

After studying the 1C-IzhTiSi report, I calculated the personal time spent on the same amount of work. Each update procedure takes me approximately 6 hours. Therefore, the total time spent is 56 (9x6) working hours, that is, approximately seven working days. In addition, there is a possibility that after the update some shortcomings will be revealed: for example, the user will complain that the configuration changes he needs are lost, and then the time costs will seriously increase. Meanwhile, the specialists of the company "1C-IzhTiSi" offer to do the entire amount of work in three to four working days. So I decided to use their services.

Now I will briefly explain what exactly was changed in the configuration.

Heavily modified objects. These are objects in which many typical properties have been changed. The adjustments are complex. The details of the object are added to the tabular part, displayed on the form of the object and on the list form. Added handlers for added details in forms. The typical mechanism for posting a document or recording a set of movements for the register has been changed.

Heavily modified documents:
"Order to the supplier";
"Movement of goods";
"Requirement-invoice";
"Receipt of goods and services".

Heavily modified registers:
"Consignments of goods in warehouses";
"Goods in warehouses".

Significantly modified objects. Objects in which details have been added, either the forms of objects or the modules of the object have been changed (as a rule, the document is not typed).
Document "Incoming cash order";
Register of information "Component nomenclature";
Register of information "Write-off goods";
General modules.

Slightly changed objects. In the objects, only the forms have been changed and details have been added.

Reference books:
"Types of nomenclature";
"Contracts of counterparties";
"Contractors";
"Nomenclature";
"Nomenclature price types";
"A number of information registers".

Changed subscriptions to events, layouts, roles, common modules in the "General" section. Almost everything has been changed by an industry decision.

Stage 2. Removing confidential information

Before providing 1C-IzhTiSi employees with an information base for testing, it is necessary to delete confidential information in it. For such cases, 1C recommends using the "Change of confidential information" processing, which is not very widely known.

Processing "Change of confidential information" is intended for selective change or cleaning of information in the infobase.Processing can be used to prepare an infobase before passing it on for testing, where it is necessary to hide (clear, change) some information.

Processing ChangePrivateInformation.epf is on the ITS disk in the directory 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Also, this processing can be downloaded from the link: http://its.1c.ru/db/method81#content:1644:1.

Naturally, confidential information in each company is different, but I draw your attention to the data that most likely needs to be changed:

• Directories: Individuals, Contact persons, Contact persons of counterparties, Counterparties, Price types.
• Information registers: Passport data of an individual, full name of individuals.

Your list will probably be longer, but these are the most common data. Changing them is unlikely to affect the ability to test your infobase. You can also delete all those objects with which the service company is not supposed to work with by group processing.

Stage 3. Get the results of the update

Three days later, I was provided with cf files and comprehensive instructions for installing them. For control releases, cf files are provided that cannot be used for user work, since only metadata has been updated in them. They are only intended to correctly upgrade to the latest version.

As a result of the work done, I can say that all changes in the configuration were saved; when visually viewed, all objects that were changed retained their features and differences from the typical configuration. During operation, none of the users reported that any changes were lost.

As a result of the update, I identified two small tasks for an independent solution.

First. Due to the fact that the update is carried out using the "Compare, Merge" mechanism, the database configuration is really updated, and updated correctly, without technical risks due to the control releases. However, the vendor configuration is not updated. Of course, a technically competent specialist will easily supplement this work, but I asked 1C-IzhTiSi to send more complete instructions for updating. In accordance with it, even an inexperienced specialist can update.

Second. As a result of the update, all objects remain supported with the possibility of change, which can also be an indirect disadvantage. If you need to use these services at a time, then you need to put all objects on support again. So far, I can do this only by enumeration of all metadata objects. Unfortunately, while this process is carried out manually, but in the future it will be automated.

In addition to the two tasks mentioned, one small flaw was discovered, which, in principle, does not affect the quality of the update and rarely manifests itself. As a result of the update, the code lines of the original configuration and the updated one visually coincide, but for some reason spaces are added at the end of the lines. This is a disadvantage, as it slightly increases the amount of modified code. And in the case of further manual updates, it would be better not to have such code sections. On fig. 6 shows an example before the update, and in fig. 7 is an example after the update.

In this instruction for a non-standard update of the modified 1s 8.3, I will not describe basic things, such as: how to open the configurator, what is the database configuration, supplier configuration and main configuration. Much has been written about this and there, and you can independently find this information on the Internet. I will try to describe the main points of the upgrade process and what you need to pay attention to.
I took atypical accounting 3.0.51.22 as an example and will show how to upgrade it to version 3.0.53.29. On platform version 8.3.10.2561 (no big difference on older platforms, just the comparison window looked a little different before).
I will say right away that there will be a lot of pictures and little text. I find it visually easier to memorize a process than to read a sea of ​​text.

1. Check the compliance of the database configuration with the vendor configuration.

For this you need

If you agree, you can safely proceed to point 2.

1a. Setting the configuration for support.

If you have a different version of the database and the version of the vendor configuration, then you need to delete the current configuration all through the same menu: configuration - support - support settings. And click the "Withdraw from support" button.

After a "short" wait, remove all checkmarks. Well, you can uncheck the "Save settings automatically" checkbox. And click to execute.

As a result, we will get a supported configuration with the same database versions.

2. Database update.

Now you can proceed to the update.

I will say right away that you need to update ONLY through the menu "Configuration" - "Support" - "Update configuration ...".
Use "Compare, merge with configuration from file..." DO NOT!!! When using this mechanism, you will have to go to step 1a the next time you upgrade. Therefore, let's not do this and create unnecessary problems for ourselves (or the one who will update the database next time).

Next, select the update file.
I would like to say about the update after several releases. 1C does not recommend updating files to CF, jumping through several releases at once. This must be done in sequence. In theory, this is correct.
Let me explain why this is not recommended. If programmers want to remove any props, they first attribute the prefix “delete” to it, then remove it after a few releases. And they can transfer information from it in some release. By skipping this release, you may lose data. But in practice, over my 10 years of working with 1c databases, I had such one case. When, for some reason, the developers decided to transfer data from the enumeration to the directory. However, it didn't end up being critical for me. I wrote a simple processing that transferred this data from the archive to the current database. There was no need to re-update.
You can throw stones at me, but I always update the database through cf files for several releases.
So we pressed the update, we got a message with which version to which the update will be made. We click OK.

We are waiting for the objects to be compared.
Next, we need to select the item “show only properties that have changed twice” at the bottom of the list.

I also want to say about the old versions, before it was a flag.

So, we now see much fewer objects.

If yours is empty, then you are incredibly lucky, and you can safely press the "execute" button and consider the update completed. Well, not everything is so simple here, so I'll go over the main objects.

The first thing I want to say. Never switch the merge mode. It should be "Take from the new vendor configuration". Otherwise, you will get garbage in the database with the MGR comment.
No "show module differences..." buttons!
Click on the gear icon next to the module

A window opens in which there are a lot of changes in functions and procedures.

In order to understand in which function there were changes, we will either need to take a copy of the database, or save the configuration to a file through the configuration menu. And then load into an empty database. Next, go to the "configuration" menu and click "Compare configurations ..."
Select to compare the main configuration with the supplier's configuration.

And now you can already see the changes through "show differences in modules ...". Because we are not going to change anything, we just want to see what has been changed.

And we see that a piece of code has been added to the Decline function. All changes can be viewed by clicking on the blue arrows.

Let's return to the updated configuration. There, through the gear icon, we entered the mode of combining modules. Next, we put all the checkboxes ... manually .. saying “thank you” to the platform developers :)

We find our function to decline. Find the changed element. I hope now it has become clear why you need to separate any of your added code with comments - right, so as not to guess when updating where this code came from.
Click the magnifying glass icon, and the platform will highlight the line of code where you want to add this text.

Copy it from the top window and paste it into the bottom window.

Do this for all modules. If the module has not been changed, as in our case with the currency reference. We simply set the mode to “Take from the new vendor configuration” and DO NOT click on the gear (there should not be a green checkmark next to the gear, this means that the code will be completely taken from the new configuration, without manual configuration).

Fine. Now, having run through all the objects, you can uncheck "save settings automatically" and then "execute"

To the message “There are objects that have been changed in the main configuration in relation to the old configuration….. These objects will be replaced during the update! Execute?" Feel free to press YES.

In the next window, leave the checkboxes as shown in the picture. And nothing else!!! Both checkboxes should be checked - "objects are edited while maintaining support." We press OK.

Everything. The update of the non-standard configuration 1s is completed.
This method is not ideal, but I think many people make mistakes in these steps.
Of course, I have not told everything, there are still many pitfalls. But I think 90% of updates can be safely updated according to this instruction.

1C software products are specific in the sense that their work is greatly influenced by the legislation of the country in which these programs are used. That is why it is very important to be able to update these products, because in addition to legislative issues, the updated configurations will contain the correction of critical errors, the acceleration of 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 (typical) configuration, which happens quite quickly and does not require much effort, while the second option, when you need to update the modified assembly, is longer and more complicated.

Determining the type of configuration

Usually, the user knows exactly what version he has, since the standard assembly is characterized by the absence of interference with the internal objects of the program. Another thing is that, as a rule, programmers are engaged in modification, respectively, the user receives an already modified product, which he may not be aware of. There is a simple way to understand whether changes were made there or not. To do this, you need to enter the Configurator mode, the corresponding button of which is in the start window of the program. There at the top there is a Configuration tab, in which there is a Support item. After clicking on it, you should select Support Setup. In the open window, the “Enable modification options” button should be active, and a sign of a standard build is the presence of a lock icon next to the build 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 it is possible that 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. Partial modification does not completely remove the program from support, since it will be possible to update untouched objects.

Standard (typical) configuration - preparation for the upgrade

In addition to these problems, such as changes in legislation or a 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 site or using the ITS disk. To begin with, it is very important to make a backup copy of the database 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 USB flash drive. After starting 1C, the base is selected, and the path to it will be indicated in the window. In case of problems, this folder is moved to the place of the non-working database. You can also act 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 later 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. You can do everything through the ITS disk, which arrive at the enterprise on a monthly basis, and this disk can also be taken 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: service packs are installed strictly sequentially, and some releases were missed, the system will require you to install them first. found in the Help menu, where you need to click the About section.
If everything is in order with the Internet, then you need to go to the site usersv8.1c.ru, in which you enter your login and password. Next, the required configurations are selected, which are located on the Download updates link. The next step is the selection of specific releases, taking into account the very first and those that came out 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, and from the ITS disk. Now you need to enter the Configurator mode, after which the 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 options provided, select Search in current update catalogs, then indicate the available release or the one whose name will be highlighted in bold. For all other suggestions, click Yes, including the last window Reorganize information. 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 the changes made by the programmers are not lost, and the changes by the developers take effect. All the listed steps described in the previous instruction 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 the search, you can use the Filter button, which is located below, and then check the box Show twice modified properties. 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 the changes have occurred in both cases, since there are pencil icons, since there is also an icon next to the module name, which means that they will be merged. The last column on the right indicates that when the process ends, all user code will be changed in favor of the developer update.

There are other modes with partial merging (priority), but these modes are used by experienced users, as a beginner will turn all the developments into confusing modules. Accordingly, there is no point in changing something in the last column. On the other hand, by removing the checkbox in the first column, the forced merging can be canceled. Based on this, you can either manually add the code to the updated module, or leave the code alone and manually make the updates themselves. To understand what exactly you need to make, you should right-click on the selected module and select Show differences. This step will show 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 module changes, if the configuration has been radically rewritten, then it will be extremely difficult to update everything on your own, without the help of a programmer.

Possible when updating 1C

Most mistakes are made when the base 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 for backup recovery before making any changes, and then once again make sure that everything was done correctly. The classic mistake is to update a non-generic assembly as if it were a standard one. But even if you follow the described instructions, it is far from a fact that the program will immediately work as it should. It is likely that additional configuration is indispensable. The configurator does not display the changes made in the controls of the dialog forms, respectively, this moment will have to be checked manually, otherwise the updates will overwrite all this. After updating, the configurator may display a ban on updating the old infobase, since document numbers are no longer unique, the same applies to information registers.

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

In the process of updating, one should not forget about updating interfaces and user rights, which is often overlooked. The importance of the sequential update of releases has already been described, it is also extremely important to use the 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 interests of the user to monitor the match of internal object identifiers or details, otherwise the update may overwrite all developments. Even after careful preparation of a new configuration, you cannot immediately proceed to combining it with the working base used, since it also needs to be updated, after which everything is 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, by downloading the release over the Internet. The program is removed from support after the introduction of modified modules into the product. Removing these modules will return the program to its original state, but it is impossible to completely get rid of them, since the normal operation of 1C will be impossible, because for some reason the modules were programmed with these. Accordingly, these modules can be taken out 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. It is problematic to do this on your own without the necessary knowledge, so the programmer must return the program to the framework of the standard assembly, if necessary.

There are also several tips to facilitate the process of updating 1C software products in the future. First of all, you should try to modify the program as little as possible, and unless it is absolutely necessary, then do not introduce anything third-party there, but try to solve problems with those typical tools that are available. Without exception, all changes in the configuration must be commented 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 type objects, you should move it into your own common module, while you need to understand that calls to procedures and functions cannot be touched - they must remain in type objects so that the program can work correctly. For optimization purposes, it makes sense to replace all calls to standard procedures and functions that are both in the "self-written" code of objects and in the code of external modules with calls to procedures from their own module. These procedures are a simple shortcut by which procedures from generic modules will be called. Thus, when comparing changes, the user will not need to search for the necessary lines in the modified code for a long time. The update time, subject to these recommendations, is reduced to several hours of work, and if everything is left as it is, the process may drag on for several days.

Updating a non-standard, heavily modified configuration is a very time-consuming and responsible task. Typically, a release update is performed for configurations that contain a regulated reporting block. For example, .

Consider the easiest way to make a non-standard update without errors, using the example of the 1C Enterprise Accounting configuration.

The beginning of any update is described in the article. We will consider only the most important thing - the nuances of an atypical update.

A little theory about non-standard configurations:

• The unsupported configuration contains 2 configurations: the database configuration and the main configuration.
• The configuration on support without the possibility of editing contains 2 configurations: the database configuration and the main configuration (aka the supplier).
• A supported configuration with the ability to change already contains 3 configurations: a database configuration, a main configuration, and a vendor configuration.

1. Preparing for the update

Before starting all the steps, make sure that the vendor configuration matches the main configuration - this will greatly facilitate atypical upgrade. If the provider's configuration is an older version, then the configuration was previously updated incorrectly. You can update a vendor's release by running the update one at a time and not selecting any object for comparison.

First of all, I deploy 2 bases with the initial configuration. One for making changes, the second for comparing with the new one.

Get 267 1C video lessons for free:

If your configuration is not typical, then by pressing the “update” button in the configurator, the system will start comparing the main and new supplier configuration:

Outwardly, it seems that we have changed a large number of objects. However, let's imagine the situation: you changed the document, but it did not change in - do you need to update it manually? Of course not. To select such objects after comparison, be sure to click the button Filter and check the box

After filtering, we see that there are much fewer changed objects:

We received a list of objects on which we will work. In our case, there was only one complex object - the RecordKUDiR document.

2. Transfer of 1C update changes

To transfer changes, I open 2 configurators - in one I run comparisons and pick up changes, and in the second I make improvements.

The next step is to transfer the changes directly. Consider the basic techniques for updating non-standard configurations.

3. Differences in modules

A fairly simple, but very responsible operation - we simply transfer modules from a new release to an old one. If the code is commented, then there should be no problems:

4. Comparisons of Forms and Layouts

Here the process is much more complicated. You need to catch the slightest changes on the forms. I recommend generating a detailed report on the differences with a graphical reflection:

After you have transferred all object changes from the new configuration, start the comparison and merging again, removing the objects that you changed manually for comparison.

Atypical update of the modified 1C configuration is completed!

Note! If you do not know how to program in 1C 8, the chance of successfully updating a non-standard configuration is extremely small. You will spend a lot of time and end up with a configuration that doesn't even run. I recommend contacting for prompt assistance.