Configuration extensions. Useful tips for development. Publications How to work with 1c configuration extension

We bring to your attention a new mechanism for customizing applications in cloud service“1C:Enterprise via the Internet” (website): configuration extensions platform "1C:Enterprise 8".

1. Why configuration extensions are needed

When working with application solutions, users often present additional requirements and wishes that are not provided by standard functionality out of the box. For application solutions implemented on the basis of the 1C:Enterprise 8 technology platform, there is a universal and convenient mechanism for adapting and adding new capabilities - configuration extensions. Developers can read about this mechanism in the documentation for the 1C:Enterprise 8 platform.

2. Configuration extension options

With configuration extensions you can:

implement the integration of the application solution with other programs, including mobile applications through web services;
change the managed forms of the application solution;
add new subsystems, change the composition of application solution subsystems;
change the roles of the application solution by adding objects created in the extension to them;
change the command interface of the application solution (main section, subsystems), for example, remove “unnecessary details” and place frequently used commands “in the foreground”;
change the behavior of the system, for example the logic of document processing, through event subscriptions;
automate the execution of any operations in the program through routine tasks;
add printed forms(invoice, individual design);
add new processing (processors for filling out documents and tabular parts, printed forms, arbitrary processing);
add new reports;
and much more.

Many of these tasks are difficult or even impossible to implement using additional reports and processing.

3. Comparison with additional reports and processing

Previously, the functionality of application solutions based on the 1C:Enterprise 8 platform could be expanded with the help of additional reports and processing. This mechanism is still supported (see link), but it is preferable to use configuration extensions:

they allow you to do everything that is possible with the help of additional reports and processing, and much that cannot be done with the help of additional reports and processing;
they are simpler and more convenient to develop: the same configuration extension that is used for the “boxed” version of the application is loaded into the service. For extensions loaded into the service, there is no need to add a special software interface and there is no need to prepare a “delivery kit”. You just need to ensure that the service requirements are met.

4. Procedure for development and use

The procedure for developing and using configuration extensions in the service is similar to that used for additional reports and processing ():

Authorization of developers. The right to add configuration extensions to the service is issued by 1C to employees of service organizations website with the status “1C:CSK” according to their applications. Employees of these organizations who have received the right to add configuration extensions to the service receive the status configuration extension developer. For more information about this, see the article at the link.
Extension development. A configuration extension developer develops an extension on his computer and tests the extension. Requirements for configuration extensions are given. Once a configuration extension has been developed and tested, the developer adds it to the service, as described in the article at the link. The extension is placed in the centralized directory of service extensions.

Expansion audit. When adding a configuration extension or its new version extension is automatically sent to audit. The audit is performed by employees of the service provider (administrator).

Publication in the service. After successfully passing the audit, the configuration extension receives the status “Published in the service” and can be used - that is, built into applications.
Providing access to clients (subscribers). If the owner of the configuration extension is a service organization, then it can:
- use the extension in your applications;
- provide access to the extension to your clients (serviced subscribers) - one, some of your choice, or all (see the article at the link).
If the owner of the configuration extension is the client (subscriber), at whose request the extension was developed, then:
- the client gains access to this configuration extension automatically;
- The configuration extension can only be used in this client's applications.
Installation in applications. Owners of subscribers who have access to the configuration extension can install it in their applications (see the article at the link).

Each service organization determines the conditions for developing, providing clients and maintaining configuration extensions independently.

5. Maintenance and update

Escort Configuration extensions are performed by the service organization. The client must contact its service organization regarding error corrections, changes and improvements to the configuration extension functionality.

Every time the application is updated published in the service, the service organization is recommended to check the functionality of the configuration extension published in the service and, if necessary, modify it. In the event of significant changes in applications, 1C will try to notify service organizations (partners with the “CSK” status) in advance, in particular, publish trial versions of applications on the 1C: Software Update website so that service organizations can adapt the developed ones in advance they extend the configuration to the new version of the application.

6. Examples of configuration extensions

6.1. Example 1: Displaying weather information

Configuration extension "Demo:Weather"(you can download it) shows how an application can display information received from an external system by making an HTTP request.

The extension displays weather information received via a public API from a weather site on the application's home page http://api.wunderground.com.

As part of the extension, a general form is implemented, when opened, an HTTP request is made to obtain the location. Based on the received location, data about the current weather and weather pictures are also obtained using HTTP requests. Information is displayed on the form and updated every hour. The result can be seen in the figure:

The configuration extension requires access to external resources (Internet resources), so its functionality is ensured only when connected in an insecure mode. When installing the extension, you must perform an insecure connection mode request requiring access to external resources:

http://api.wunderground.com - determining location and obtaining weather information;
http://icons.wxug.com - getting weather pictures.

The extension is compatible with any configuration, since it does not borrow objects from the configuration being extended.

6.2. Example 2: Providing a news feed

Configuration extension "Demo:RSS"(you can download it) shows how the application can provide data external system- for example, a mobile application.

The application creates an external software interface for receiving information in RSS format, used by news feeds, about the last ten receipts at the cash desk for the Enterprise Accounting, edition 3.0 configuration. The extension includes an XDTO package (URI of the namespace http://www.w3.org/2005/Atom):

as well as an HTTP service that returns information about the last ten receipts to the cash desk, obtained from the data of the “Cash receipt order” documents.

To make it easier to connect to the RSS feed, the extension displays on the application’s home page:

hyperlink with the address of the news feed;
QR code with the address of the news feed - for reading using the camera of a mobile device.

When displayed on mobile device the received news feed, the user will receive information about the latest receipts at the cash register:

To generate a QR code, the configuration extension accesses the external resource http://api.qrserver.com, so this extension must also connect in insecure mode.

It turned out to be quite relevant :)

Ok, let's make this weekend useful too.

So, today is another topic of “applied operation of 1C”:

Extension mechanism in platform 8.3.6

What are we talking about?

In platform 8.3.6, a new mechanism was implemented - an extension mechanism that facilitates the adaptation of an application solution to a specific customer.

When using extensions configuration modification is carried out in a new entity– configuration expansion:

An extension is essentially also a configuration, but with some limitations
The prepared extension can be connected to the customer’s working database in user mode
The most important - the configuration being modified does not need to be removed from support, i.e. it remains standard, without changes
Updating the modified configuration can be performed automatically by the user

Thus, the customer receives as a result possibility of improvement configurations and at the same time - simple automatic update .

So that you can understand this in more detail, we are publishing several more videos + PDF on extensions.

So, here we go:

Purpose of configuration extensions

The video discusses the new configuration extension mechanism that appeared in platform 8.3.6. It is intended for refinement and adaptation of solutions during implementation. In this case, the customer receives a simple automatic configuration update and the ability to make modifications.

Objects that can be modified in the extension

This video covers existing restrictions extension mechanism. Currently, only a limited number of objects can be used in extensions.

Working with extensions in the configurator

This video discusses the development of extensions in the configurator. The extension is a configuration, albeit somewhat limited. Work with the extension is also performed in the metadata object tree. The resulting extension can be saved to a file on disk.

Borrowing objects

This video looks at borrowing basic configuration objects into an extension. This is the main mechanism required to perform development of the extension itself. It also talks about controlled properties, the value of which is checked when the extension is connected.

Creating your own objects in a configuration extension

This video explains how you can create your own objects in the extension. The list of such objects is still limited - these are reports, processing and subsystems. The development of such objects in the extension is carried out by analogy with the main configuration.

Working with extensions in user mode

This video discusses how to connect a prepared extension to a customer’s working database. In this case, the connection can be made from user mode without accessing the configurator.

Working with managed forms in configuration extensions

This video looks at how to work with managed forms in the extension. Please note that the source form does not automatically sync with the extension. Explains how the system generates the resulting appearance forms if there is an extension.

Managed Form Module and Event Handlers in Configuration Extensions

This video covers how to work with event handlers in managed configuration extension forms.

The order of execution of event handlers in the main configuration and in the extension is demonstrated.

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.

Extensions in 1C are something like parallel configurations, which are automatically merged with the main provider 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 typical configuration, then during the 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 at full support.

After updating the main configuration, if there are any changes in the new release 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:

The need for software customization, i.e. its modifications to suit needs specific user, appeared, probably, simultaneously with himself software. It is difficult to write a program that will satisfy everyone, and therefore include the possibility of changes in it without involving the program manufacturer - good idea. Especially when it comes to business applications, because... business processes, even in the same areas, may differ from one organization to another.

Changing the source code

There are different customization strategies. If the application is supplied in source code, then the most obvious approach is to rewrite the source code to suit your needs. And the most obvious problem in this case is the transition to a new version of the application, because... it entails merging the source codes of the version modified on the client side and the new version from the vendor. And this can be a non-trivial task, especially if the client-side code is highly customized.

Plugins

A safer strategy in this regard is plugins. The source application provides the plugin fixed dial interfaces, as well as the ability to register yourself in the application. When a new version of the application is released, plugins written for previous version, will continue to work in the new version (provided the interfaces remain unchanged). Plugins may behave differently in a new version than in the previous version if the software vendor has changed the behavior of the application. The concept of plugins is used in a wide variety of software classes - office and business software, development environments (Visual Studio, Eclipse, ...), graphic and sound editors, etc.

Subscriptions

Another customization technology is the ability to subscribe to events in the application and execute custom code in a well-known or proprietary language during these events. Events can be of various types - opening a window, loading an image (for graphic editor), order processing (for a business system).

One variation of this approach is to build into the main program the ability to perform custom scripts in languages like Visual Basic for Application (VBA). Custom code can, in particular, be executed in response to application events. The same VBA has proven to be a very powerful and flexible means of customization; it's built in Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS and other products.

Customization in 1C solutions: the beginning

The 1C:Enterprise platform implements various customization strategies. Since 1C application solutions are supplied in source code, naturally, one of the most obvious scenarios is changing the source code.

Changing the source code of 1C applications

When a client changes the source code of a 1C solution to suit his needs, he needs to remember that the application supplier is also not idle and releases new versions, adding functionality and fixing errors. To ensure that when installing a new version of the application the changes made to suit the client’s needs are not lost, you need to somehow merge the modified previous version of the application and the new version.

Naturally, we at 1C paid great attention to this task and developed a delivery and support mechanism to facilitate its solution. Before I tell you how it works, a couple of details about internal structure 1C solutions.

The source codes and metadata of the 1C application solution (configurations) are stored in a database, the same one in which the data of the application itself is stored (postings, data from directories and documents, etc.), i.e. the program is stored along with the data. A database with configuration (and application data) in 1C terminology is called an information base (abbreviated as infobase).

During the development process, the configuration provider determines which configuration objects (directories, documents, etc.) the client can change and which cannot.

Setting up delivery on the supplier side

The client, on its side, using this mechanism, can also determine the rules for supporting the objects of the implemented configuration of the supplier - for example, it can refuse support by the supplier for a particular object if it assumes responsibility for further modification of this object. Or, on the contrary, you can prohibit editing an object of “your” configuration (even if the supplier allows it) in order to insure against accidental changes.

Setting up client-side support

When a client starts to change something in the standard configuration, two configurations are created in the infobase:

Original vendor configuration.
Current configuration modified on the client side.

And now the supplier releases a new version. It can be delivered as a complete application, or as an update package with modified objects. When moving to a new version, we have 3 configurations on the client side, on the basis of which the so-called three-way merging of configurations is carried out:

Old configuration from the vendor.
The client's current configuration (the old configuration from the vendor plus changes made to it by the client).
New configuration from the supplier.

It is clear that in some cases, objects modified by the supplier can be updated automatically:

Objects that have not been modified by the client.
Simple changes to objects on the client side (for example, adding additional details to an object).

In the case where the object has been changed both on the client side and in the new version from the supplier, manual intervention is necessary. We have a powerful comparison and merging mechanism not only for code modules, but also for models (metadata, forms, reports...), but even with this mechanism, merging configurations can be a non-trivial task.

External reports and processing

Another customization mechanism that is relatively safe from the point of view of migrating to new versions is the mechanism of external reports and processing. As the name suggests, both types of objects - external reports and external processing - are external to the application solution and are stored in separate files and are loaded into the application solution at the time of execution. Thus, the process of switching to a new version does not affect them at all. But if in the new version the details of an object were deleted or renamed, and processing or a report refers to them, the report or processing will not work on the new version without modification.

External reports and processing are essentially plugins. They are well suited for “custom” reports and specific operations on data (for example, for importing information from other systems), but, of course, they do not cover all customization scenarios. If the client needs to add specific code that should be executed when posting a document, external processing is not enough - it is necessary to edit the source code of the document module.

Customization in the clouds

With the advent of cloud technology 1cFresh, the task of customization has reached a new level. The fact is that in the “cloud” users of an application solution from different organizations can physically work with one information base (i.e., one instance of the application), but at the same time, thanks to the data sharing mechanism, they see only the data of their organization . Customization through changing the source code becomes unacceptable here - each organization needs its own customizations, and there is absolutely no need for customization of its “neighbors” in the information base.

In the cloud, only the use of external reports and processing is applicable for customization, but, as mentioned above, external reports and processing do not cover all the scenarios that users need.

Configuration extensions

So, we needed to come up with a customization mechanism that would satisfy the following requirements:

It would allow you to easily update a custom solution to a new version, avoiding the manual work of merging configurations.
Allowed us to enable customization under certain conditions (for example, if we work in the context of a specific organization).
Reduced the likelihood of customization losing functionality when switching to a new version of the original configuration.
Had the ability to disable customization in case of problems to preserve the functionality of the application.

Such a mechanism, in addition to being used in cloud solutions, would make life much easier when switching to a new version when implementing standard configurations where customization is necessary.
We came up with such a mechanism and called it extensions. This mechanism, in a sense, combines two approaches to customization - the ideology of plugins and the subscription mechanism.

Extensions are a way to keep configuration changes separate from the configuration itself. An extension is, in fact, itself a separate configuration containing modified objects. It, just like the configuration, is represented as a tree of objects. To work with the extension, the same working methods are used as with the regular configuration:

If we want to use an object from the main configuration in an extension (for example, add a new form to a document existing in the main configuration), we first need to borrow the object into our extension using the “Add to Extension” command. Immediately after adding an object to the extension, it is “empty” in the extension object tree - it has only those properties that are in the main configuration. You can also borrow an existing form from the main configuration and, for example, add a new button to it that performs a specific action. It is not yet possible to add new details to objects in extensions, but we are working on it.

Basic configuration and extension with the borrowed document InvoiceIssued

The extension also has an analogue of event subscription - the ability to process events of objects of the extended configuration, for example, record processing. You can specify exactly how our code will be called in the extension:

Before the standard procedure for recording a document, we can call our code, which, for example, will check whether the field of the employee responsible for the document is filled in, and if not, write the current user to this field:

&After("BeforeWrite") Procedure ExpandAndromeda_BeforeWrite(Failure, WriteMode, PostMode) If (ThisObject.Responsible = Directories.Users.EmptyLink()) Then ThisObject.Responsible = ModuleUsers.GetCurrentUser();
endIf; End of Procedure In the new version of the configuration, the implementation of document recording may change, but our code in the extension will still be executed before standard code

record the document and do your work.

During execution, the standard configuration and extensions (there may be several of them) “add up”, resulting in a new, customized configuration with which the end user works.

Extension execution order When developing extensions, be aware that the platform does not guarantee that extensions will run in the same order when you add multiple extensions to a configuration. We deliberately abandoned explicitly specifying the order in which extensions are executed, because this, in our opinion, complicates setup and ultimately introduces more problems

If we add several extensions to the configuration, each of which has processing for processing the same document with the “&After” directive, then all handlers will be executed, but the platform does not guarantee that the order of their execution will always be the same. This must be taken into account when developing extensions.

If there are handlers for the same event in several extensions with the “&Instead” directive, only one handler will be executed, and which one cannot be said in advance. This needs to be remembered and monitored so that no more than one extension to the configuration has an “&Instead” handler for the same object/event.

Customizing forms in extensions

We can borrow the form of an object from the configuration into our extension (for example, the form of a document). At the same time, in visual editor forms in the extension we will see the same form as in the main configuration. And in the form code editor, the extension will be empty - all the code for the form is currently contained only in the main configuration.

You can add a new button (or even several) to the form. If several extensions add their own buttons to the same form, all of them will be present on the final form during execution.

But it is not recommended to remove standard elements from the form - this may break the code existing in the original configuration (if it accesses form elements). If there is such a need, it is better to make elements invisible through the “Visibility” property.

It must be taken into account that an application on 1C:Enterprise is not just code in a programming language. Most of the application is described in the form of declarative models. And for different tasks are used different types models (forms, reports, rights, ....). For each type of model, we select our own customization method in extensions, which provides the most convenient change for typical cases.

Benefits of extensions

Extensions have an ideological difference from the delivery and support mechanism. In the delivery and support mechanism, the developer edits the vendor configuration as he wants, as if he were simply finalizing his configuration, and then (when updating) figures out how to synchronize conflicting changes. In extensions, the developer initially develops the extension itself - in terms of added functionality. The extension is stored by the system as an add-on and the system takes care of the most secure update.

Easy migration to a new configuration version

When a vendor releases a new version of a standard configuration, an automatic update is performed because the standard configuration's support mode has not changed - it remains fully supported by the vendor. And when you launch the updated application solution, the platform will again automatically combine the changed standard configuration with the extension. And the client will continue to work with a standard solution modified to suit his needs.

Sometimes, after updating the version of a standard configuration, it may be necessary to adapt the extension to the new version, for example, if in the new version the objects or details of the objects involved in the extension are renamed. A little more about this below, in the section “Early notification of errors”.

Changes are separate

The first obvious advantage of extensions is that all customizations made for the client are separate from the standard configuration, and now you do not need to compare the changed configuration with the standard one to understand what exactly has been changed.

It has already been mentioned that in order to use an object from the main configuration in an extension, it must be borrowed into the extension from the main configuration. Thus, in the extension there appears something like a link to an object from the main configuration.

At the same time, there is a way to understand which borrowed objects in the configuration have actually been changed, and which are borrowed in read-only mode - for example, for use in reports. In the tree of extension objects there is a filter button “Changed and added in the extension”, after clicking which only borrowed objects modified in this extension and new objects created in this extension remain in the tree.

Early warning of errors

Let's assume that we borrowed the Contracts directory from the main configuration into the extension to use it in a report. In the meantime, a new version of the standard configuration was released, in which the Contracts directory was renamed to Agreements. Naturally, after switching to the new version, our report in the extension will not work. If we had used the old customization technology - an external report, then the error would have occurred only at the time the report was executed. In the case of extensions, we have the opportunity to check the correctness of extensions in design-time after updating the standard configuration version, and fix all problems before users start working.

This is especially true in implementations, where in one information base many extensions are used, and updating the configuration version is done centrally (for example, in cloud implementations, where different organizations using the same configuration but working in different data areas may use different sets of extensions). The administrator can update the version of the standard configuration on a test basis and check the correctness of all user extensions relative to the new version. In case of problems, he will report them to the owners of extensions, and the transition of the working base to a new version of the standard configuration will be made only when all extensions are brought into line with the new version of the configuration.

What's next?

We consider the development of extensions to be one of the main directions for the development of customization tools in the 1C:Enterprise platform. Extensions, originally conceived to facilitate customization in the cloud service, were designed to facilitate both customization situations and non-cloud implementations.

While you can customize not everything you want in extensions. For example, it is not yet possible to create new application objects (directories, documents, etc.) and it is not possible to add new details to existing application objects. We are working on this (and on other features too) and in almost every new version of the 1C:Enterprise platform we add new features to extensions: Add tags

The configuration extension mechanism is a special mechanism designed to modify an expandable configuration without changing this configuration (including without removing support).

When considering the configuration extension mechanism, the following terms will be used:

Expandable Configuration– the main configuration of the infobase for which the extension is used or for which the extension is being developed.
Configuration extension– a set of configuration objects connected to the extensible configuration and containing a set of objects added to the extensible configuration. An extension can include both objects of the extended configuration and objects that are not in the extended configuration.
Own object– a self-contained configuration object that can be located both in an extensible configuration and in an extension (report, processing or subsystem).
Borrowed object– a custom object added to the configuration extension.
Extensible object– own object for which any parameters (properties, forms, etc.) have been changed in the borrowed object.
Expanding object is a borrowed object that has been modified relative to the object being extended. Having only controlled properties in a borrowed object does not make the borrowed object extendable.
Result object– this is its own object plus the union of all extending objects (if there are several extensions). If there are no extending objects for its own object, it becomes the resulting one “without changes”. Those. in the configuration with which the user works, all objects are resultant, regardless of the presence and number of installed extensions.
Expanding property– a property of the borrowed object that changes the property of the same name of the extended object.
Controlled property– a property of a borrowed object, the value of which is checked when connecting the extension to the extended configuration. If, when connecting an extension (in 1C:Enterprise mode), the value of a controlled property in the extension does not match the value of the same property in the configuration being extended, the extension will not be connected.
Modifiable property– a property of a borrowed object, the value of which in the resulting object will be obtained from the extension.

A property of a borrowed object cannot be both controlled and modified.

The main purpose of expanding the configuration is to modify the application solution during implementation (or in the “cloud”) to suit the client’s needs. In this case, the configuration being modified does not need to be removed from support. As a result, it remains easy to update a standard application solution that is being supported, with the need to make modifications. When developing an extension, you should understand some of the features of how a configuration extension works. Thus, the expandable configuration can be changed at any time, for example, as a result of an update. At the same time, the extension developer cannot in any way influence the possibility or impossibility of updating. You should also take into account the fact that more than one extension may function on a system, and the author of each extension (in general) does not know how the other extension functions.

The extension is created in the configurator, stored in the infobase and can be saved to a file. To add (connect) an extension saved to a file to a specific client’s application solution, there is no need to use the configurator. You can connect the extension using a special standard function (All functions – Standard – Manage configuration extensions). You can also connect the extension using the application solution toolkit, which uses the programming interface provided by the platform. Connecting an extension (interactively or from the built-in language) is possible either in unsecured mode or in the case where the security profile under which the session is running allows access to the connected extension.

Extensible objects can be:

Managed forms;
Roles;
Subsystems;
Settings for the home page (desktop) of the application solution;
General modules;
Object modules for all types of objects;
Manager modules for all types of objects;
Session module;
Managed application module;
External connection module;
Command modules.

The following can act as your own extension objects:

Subsystems;
Processing;
Reports;
Details, tabular parts and details of tabular parts in borrowed processing and reports;
Roles;
XDTO packages;
Web services;
HTTP services;
WS links;
General layouts;
General commands;
Common modules (except for global server and privileged common modules);
Team groups;
General pictures;
Forms, layouts and commands of borrowed objects:
Exchange plans;
Selection criteria;
Settings storage;
Directories;
Documents;
Document logs;
Transfers;
Reports;
Processing;
Registers of information;
Accumulation registers;
Accounting registers;
Calculation registers;
Plans for types of characteristics;
Charts of accounts;
Plans for calculation types;
Business processes;
Tasks;
Tables external sources data;
Cubes of external data sources;
Dimension tables from external data sources.

Among the controlled properties, special mention should be made:

Composition of the exchange plan;
Predefined elements for reference books, plans of characteristic types, charts of accounts and plans of calculation types.

Basic versions of application solutions do not support working with extensions.