Theme "neat" modifications to standard configurations is always up to date.

With the help of extensions, it becomes possible to make modifications without leaving the configuration Without changes(that is without removing the lock).

As an example we let's expand the standard functionality“1C: Accounting 8” – we will add checks for completeness of document details. As a result, the system will issue diagnostics if the details are filled in with “incorrect” values.

Literally in 15 minutes You will learn techniques that you can use to solve different problems.

Moreover, in the second video we will show universal mechanism, based on extensions. And having developed such a mechanism once, it can be connected to any standard configuration.

Dreams of own imperishable can become reality :)

So let's get started:

Video 1. Techniques for working with extensions - using the example of “1C: Accounting 8”

After studying the video, you will learn:

• Create and connect extensions to configuration
• Fulfill debugging extensions
• Improve standard forms processing/documents using extensions
• Intercept events standard configuration forms
• Store data not in information security tables (settings storage)
• Use treatments as algorithm repository

We will also look at optimization composition of extension objects and extension restrictions in current platform releases.

Video 2. Creating universal mechanisms using extensions

In this video we will show:

• Connecting an extension in user mode ( without configurator)
• Example universal verification filling
• Features of the implementation of extensions - creating forms with arbitrary selections and storing data in extensions

Cost of work and options for translations from different releases

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 transferring 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:

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

Colleagues, hello everyone.

The other day a test Enterprise Accounting was released with the compatibility mode for the 8.3.6 platform disabled.
This means that this version uses a new engine that renders forms in a new way.
You can read about this in Through the Looking Glass.

Along with the standard ones, you should also convert your own extensions to the new platform.
During the translation process, I created a small checklist or reminder for myself about what needs to be done.

Memo:

1. Transfer the extension to a new platform

To do this, change the extension compatibility mode to the configuration compatibility mode.
The Enterprise Accounting version has the following properties:

In the extension, you can set exactly the same properties or clear all the checkboxes.
No checkboxes mean that the extension will not check these properties when connecting.
Then if these properties change in the main configuration, the extension will still start:

2. Fix connection problems

To do this, we launch the configuration in enterprise mode and see if it takes off or not.
Errors due to which the extension could not be connected can be viewed in the log
(Administration - Support and Maintenance - Logbook)
We are interested in events - “Session. Error applying configuration extension":

Most often, the connection problem is solved by removing unnecessary details or objects.

The main difficulty is that the extension does not display all errors at once (by the way, this problem was solved in 8.3.9).
Therefore, it is necessary to run the configurations sequentially after fixing each error.
To make it convenient to launch the logbook, add it to your favorites:

3. Update forms in the extension

To do this, in each changed form, click on “Update form extension”
Using this command, we re-load the main configuration form into the extension.

In principle, it will work without this, but this is necessary so that in the extension the form looks the same as in the main configuration.
In version 3.0.44, almost all forms have undergone changes, so it would be nice to include these changes in the extension.

4. We adapt the form to the rules of the new engine.

I recommend that you read the article - Recommendations for adapting forms to 8.3.7.
It examines the features of the new engine and gives specific recommendations on how to ensure that everything is fine in the new platform.

I came up with the following procedure:

• We remove all the decorations, which were used for indentation.
  Groups are now used instead.
• Let's see that everything looks good.
  If something goes wrong, then look at the article.
  If everything is good, then we move on.
• Checking the new platform properties“Combined”, “AutomaximumWidth” and “AutomaximumHeight”.
  Just see that these properties are set to platform defaults and the form does not move apart because of this.

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 at least to 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 expansion 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:

A new release of the platform 8.3.11 has been released, which allows you to add and change metadata objects through an 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 test completely (or at least in part of 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.