Configuration extensions - how to add functionality to a standard configuration without removing support (20 minutes video). Changing or disabling compatibility mode What are extensions used for?

Cost of work and options for translations from different releases

	Translation 8.1 → 8.2.13	Translation 8.2.13 → 8.2.16	Translation 8.2.16 → 8.3.10
price, rub. *	54,000 ₽	12,000 ₽	76,800 RUR

A list of all changes in different versions of the platform is available at the following links:
For platform 8.2:
http://downloads.v8.1c.ru/content/Platform/8_2_19_106/1cv8upd.htm

Before starting work on the translation to 8.3 you need:

Check the controlled blocking mode. If “Automatic” is used, then when migrating to 8.3, additional costs may be required to switch to managed locking mode.
If you are using compatibility mode with 8.2.16 and higher, you need to check whether the tables have been restructured
Determine what types of clients are used (thin, thick, web client)
Determine if there are machines that run Linux

Translation of configuration 8.1 → 8.2.13

Cost of work: 54,000 rub.

Translation of configuration 8.2.13 → 8.2.16 (including restructuring)

Key changes:
The mode of storing constants and settings of accumulation registers has been changed. Each object has its own database table
The implementation of the managed locking mechanism has been reworked.
For the technological log event "TLOCK", the "Txt" property is written only in compatibility mode with version 8.2.13
The influence of the debugging mode on the speed of operation in 1C:Enterprise mode for the thin client, thick client, server and external connection has been reduced.
The execution of a query of the form “ValueType(Field1) = ValueType(Field2)” has been optimized if “Field1” and “Field2” contain values of a reference type.
For managed form fields that display attributes of a complex type, the opening of the quick selection list has been accelerated in cases where the complex type includes reference types with different quick selection settings.
For the new independent and non-periodic information register, the dimension index is clustered

Changes requiring configuration changes:

When compatibility mode is disabled, the “Period” parameter of the periodic information register manager method “Get()” is required. In compatibility mode with version 8.2.13 and version 8.1, the behavior is unchanged (the method can be used without specifying a parameter, but the result is undefined).
When using the “SetValue()” and “UseFromDataSource()” methods of the “DataLockElement” object at the same time, an exception is thrown. In compatibility mode with version 8.2.13, the behavior has not changed (the value set by the “UseFromDataSource()” method takes precedence).
It is not supported to store data values that do not support serialization. In compatibility mode the behavior has not changed.
If the database is file-based, then the infobase must be converted. After the conversion begins, working with this information base with previous versions of the 1C:Enterprise 8 platform will not be possible. If development is carried out using a configuration repository, you must make a copy of the repository before converting the infobase

IMPORTANT. To get the effect of changing the compatibility mode, you need to do a restructuring through the configurator: “Administration → Testing and correction → Restructuring infobase tables.”

It is first necessary to perform restructuring on a test base and measure the execution time of this operation.
If you are using a 1C server version older than 8.2.19, for example, version 8.3, then the following errors may occur when performing restructuring:

In this case, you need to do the following:
Install a separate 1C server version 8.2.19 and deploy the database under investigation on it
Open the database in the configurator on the 1C server version 8.2.19, change the compatibility mode to “Do not use”
Restructure infobase tables
After the restructuring is completed, move the information base to the original 1C server version 8.3

The cost of transferring the configuration from 8.2.13 compatibility mode to 8.2.16 mode (non-compatible mode when using the 8.2.16, 8.2.19 platform and 8.2.16 compatibility mode when using the 8.3 platform) is 12,000 rub.

A work contract template can be downloaded.

Translation of configuration 8.2.16 → 8.3.10

The configuration translation work includes the following configuration modifications:

1. Eliminate property name conflicts. Changing variable names to match the new properties that appeared in 1C:Enterprise 8.3.
2. Eliminate conflicting picture names. Renaming the names of pictures with names that match the names from the picture library.
3. Refinement of the code when changing the properties of the fixed structure. Replacing the indication of the properties of a fixed structure with the re-creation of a fixed structure or replacing its use with a similar “Structure” type.
4. Replacing the placement of non-serializable values in temporary storage with code supported in 1C:Enterprise 8.3.
5. Replacing the use of calling the “Show” method for managed form details with the use of the “CurrentElement”, “CurrentPage” properties, and the “Activate” method
6. Replace metadata object names longer than 80 characters with names of 80 characters or less for metadata objects
7. Renaming methods and properties, according to the methodology for migrating to version 8.3.
8. Improvement of mechanisms for working with selections, conditional formatting, groupings and order in dynamic lists.
9. Refinement of the code for queries with the keyword “GENERAL RESULTS”, unloaded in the “Bypassing Query Result. By Grouping”, in order to preserve the previous logic of work.
10. Changes in COM object class names. Replacing the names "V82.COMConnector" with "V83.COMConnector", and "V82.Application" with "V83.Application".
11. Refusal in the program code of the “Start of Selection From List” event for input fields in the mode of selection from a list
12. Refusal in the program code from the “ChoiceList Button” property for input fields by setting the “Dropdown List Button” property.
13. Changing the code to take into account the change in the type of value returned by the global context method “SafeMode()”
14. Changing the code to take into account a change in the result of a query for constants (when accessing the “Value” field of the constant table, if the constant stores a value of the type “Value Storage”, “UniqueIdentifier” or “External DataSourceTableReference”.
15. Replacing the “MainRole” configuration property with “MainRoles”
16. Refusal of the “User” and “Password” properties for the “InternetProxy” object and replacement with the “Set()”, “User()”, “Password()” methods.
17. Refinement of the code to support the “Show in list” command, according to the method of transition to version 8.3.
18. Refinement of the code to maintain the previous logic of system operation when the return value of the SystemInformation.OSVersion property has changed,
19. Refinement of the code to maintain the previous logic of the system when refusing to use the system enumeration OptionOpenWindow, which is no longer available in version 8.3.
20. Refinement of the code taking into account the refusal to use modal windows.
21. Improvement of the code to support the web client, namely, refusal of server calls and opening windows in “Before Closing”, refusal of server calls in “When Closing”.
22. Improvement of the code to make it possible to correctly use the RoleAvailable() function when passing the function as a parameter to a missing role.
23. For a managed application: starting from version 8.3.8 in event handlers of a managed application BeforeSystemShutdown, WhenSystemShutdown, as well as in event handlers of a managed form that is in closing mode, BeforeClosing, WhenClosing, It is forbidden to open windows and make any server calls. The configuration needs to be improved so that forms can be closed correctly - without server calls.
24. Variable name conflict: you cannot use the variable name FormParameters in a form module. Therefore, it is necessary to modify all managed forms modules that use variables named FormParameters by renaming these variables.

The price for these works is preliminary and valid for most configurations. Before starting work when concluding a contract, we check the configuration and After checking, we confirm the price and terms of work. Checking is necessary because configurations can be very different, including heavily rewritten.

Cost of work: 76,800 rub.

A work contract template can be downloaded.

The cost of transferring the configuration to compatibility mode with 8.3.10 may be increased, If:
Configuration uses managed forms
It is necessary to abandon the use of modality
It is necessary to maintain the functionality of the configuration in Linux OS

We have released a new release of the telephony panel for 1C.

version 1.2.24.10 For ordinary applications
version 1.4.26.17 For managed applications

In the release version for a managed application, it became possible to embed a telephony panel with minimal modifications basic configuration using expansion mechanism configurations.

Benefits of using the extension

The extension is very similar to the regular configuration. To work with it, the same working techniques are used as with the regular configuration. Extensions are created primarily to make it easier to make changes to the program. You no longer have to insert “pieces of code” into certain modules and add new metadata objects, you just need to add an extension to the configuration.

A huge advantage of using extensions is automatic update main configuration. Now there is no need to change support settings for a typical configuration.

Features of embedding a telephony panel for 1C

Such features became available to extensions for the platform starting from version 8.3.9.1818 . So to take advantage of this, we have disabled compatibility mode for the extension since version 8.3.9 not yet supported. Accordingly, it becomes necessary to disable compatibility mode for the main configuration, otherwise an error will appear: " The compatibility mode of the configuration extension is greater than the compatibility mode of the main configuration".

2) We add a role to the main configuration MIKO_Softphone, for which we withdraw all rights.

When adding a new metadata object, in this case a role, it is necessary to update the directory MetadataObjectIdentifiers. When we added this role to the extension, the standard configurations ignored it, that is, when updating the MetadataObjectIdentifiers directory, the role did not appear in it. Because of this, the telephony panel settings profile mechanism did not work correctly and the error appeared: " The metadata object identifier for the MIKO_Softphone role was not found".

Moreover, this situation did not arise in all configurations, but in "Trade Management, 11.2.3.218" And "Complex automation, 2.0.3.222" There were no problems with the role when it was added to the extension itself. To provide some versatility to our solution and ensure trouble-free operation in most of the configurations we support, we decided to add the role MIKO_softphone into the main configuration and borrow it in the extension, and then implement the settings for this role in the extension.

A very important feature is the fact that if, having once installed our extension, you want to embed the panel according to our old instructions, you need to disable the extension and remove the MIKO_softphone role. If you want to use the extension again, you must first add the role and then add the extension.

Let's summarize

Even by including the ability to change the basic configuration and making minimal changes to the configuration, we have made the process of embedding a telephony panel easier. Now you do not need to make changes to the modules of the managed application, add processing and subsystems to the configuration, or configure roles. The extension will do all this for you! We will continue to improve the process of embedding a telephony panel for 1C!

Instructions for embedding a telephony panel for 1C using the extension mechanism can be found.

Ask your questions via the feedback form.

A new release of the platform 8.3.11 has been released, which allows you to add and change metadata objects through the extension. Can we really now implement any improvements without removing the configuration from support? Is it worth promising a client mountains of gold without any consequences?

First of all, you need to be aware of the limitations that extensions have.

Limitation on created objects

At the moment you can create:

Directories
Documentation
Information registers
Exchange plans

You can add details to:

Directories
Documentation

What do we end up with? Not all types of metadata objects can be added. The most common and popular, but still not all. Additionally, new dimensions and resources cannot be added to information registers. You can only create a completely new register.

The functionality of extensions depends on the compatibility mode of the configuration to which the extension is applied.

Compatibility mode 8.3.8- you can only change the forms of objects and their modules, add your own reports and processing.

Compatibility mode 8.3.10- you can change general modules, object and manager modules, roles, use the “Before”, “After”, “Instead” directives for any modules.

Compatibility mode "Do not use"- you can use all the functionality of extensions, including adding new objects.

At the moment, the standard UT 11.3 has compatibility mode 8.3.8. In UT 11.4, the compatibility mode is 8.3.10, that is, for example, for UT, most of the extension functionality is not available, including the creation of metadata objects.

This would seem to beg the question: why not just unsupport the root, set the compatibility mode to "Do not use" and quietly use the extensions? When changing the compatibility mode, the behavior of forms and query results may change, i.e. behavior of the system as a whole. It is strongly recommended not to change the compatibility mode without first testing. But it is obvious that it seems possible to fully test (or at least partially test the documents used) an entire application solution. Therefore, you should not use this option.

When connecting an extension to a standard configuration and borrowing standard objects, the extension controls the compatibility mode of the main configuration and the types of borrowed objects and their details. If the monitored properties do not match, the extension is disabled and does not work until the cause is eliminated. That is, with a major update, there is a high probability of changing at least one of the controlled properties and causing the extension to lose functionality.

In addition, if the modifications are significant, many procedures and functions of the standard configuration are replaced, it will be necessary to carefully monitor them and, if necessary, bring them into line with the standard configuration, preserving the previously made changes.

In the above cases, you will still need the help of a programmer and, possibly, significant time for modification (but still less than when updating a configuration that has been removed from support).

conclusions

The new release of the platform provided new opportunities for using extensions, it became possible to add metadata objects, but despite this, the functionality has certain limitations.
The compatibility mode of the configuration to which the extension is applied greatly limits the extension's capabilities; changing the compatibility mode is not recommended.
Large updates still require developer attention, as there is a high probability of changing controlled properties.

In this article, I propose to consider what a “configuration extension” is, how to add an extension or disable it. Starting from version 1C 8.3.6.1977 a new mechanism was introduced into the platform - configuration extensions. First, a little theory.

In 1C, extensions are something like parallel configurations that are automatically combined with the main vendor configuration. Moreover, in extensions you can add both your own objects and borrow objects of the main configuration.

What are extensions for?

First of all, extensions are created to make it easier to make changes to the program. That is, if users ask to add any functionality, then before the appearance of extensions, programmers had to remove the configuration from full support and change the standard configuration.

Removal from full support entails a number of inconveniences:

the possibility of automatic updating disappears, which leads to at least an increase in the time it takes to;
a highly qualified specialist servicing the program is required;
if changes were made to standard objects of a standard configuration, then during an update they may disappear, that is, they may be replaced again with standard ones from the supplier.

When using extensions, when making changes, the programmer will not touch the standard configuration. All changes will be made using extensions, which (as I wrote above) are also configurations. This way the main configuration will remain fully supported.

After updating the main configuration, if in the new release there are any changes to an object that was previously changed by the extension, then the changes will still be taken from the extension. That is, extensions have higher priority than the main configuration.

Video - extensions in 1C in 45 minutes

Get 267 video lessons on 1C for free:

An example of adding an extension to 1C

To show what an extension is, it is better to give an example of its creation in the 1C configurator.

In the configurator, go to the “Configuration” menu and select “Configuration extensions”. A window will open with a list of extensions (if any). Click the “Add” button and add a new extension. Now you can open the extension configuration:

As you can see, the extension configuration has exactly the same structure as the main one. Only it is initially completely clean, without objects.

I recently wrote an article about how to make it yourself. Using her example, I want to make it built-in using an extension.

In processing I have a field with a link to the “Organizations” directory. That's why I need this guide. But we will not create a new “Organizations” directory, especially since the platform will not allow this. It is impossible for an extension configuration to contain objects of the same name as objects in the main configuration.

Therefore, we will borrow the reference book from the main configuration:

Now right-click on “Processings” and select “Insert external processing, report...” Thus, we will add a new processing to the extension configuration. If you use my processing, then immediately rename it, since the main configuration already has a processing with the same name.

Well, the final touch. I want my processing to be reflected in the Administration menu. To do this, we will borrow the subsystem of the same name from the main configuration. Don't forget to indicate in the processing that it belongs to this subsystem.

This is the structure I came up with:

Let's see what we got. We update the database configuration and launch the program in 1C: Enterprise mode, and go to the “Administration” menu. Yes, I almost forgot, the extension configuration must be closed, otherwise the program will not start:

All about mobile technology