Configuration extensions. Useful tips for development

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

Having studied the experience of using previous versions of the program, and taking into account the fact that no matter how universal and comprehensive a specific solution is, ultimately in 90% of cases it requires modification for the end user. The developers of version 8 of the 1C program have implemented several fundamentally new solutions to minimize the need to change standard configuration mechanisms:

• Literally from the first versions of the program, elements of many directories now have the ability to create additional properties and categories using the appropriate plan for types of characteristics and information register;
• Additional printed forms and forms for filling out tabular parts, as well as additional reports and processing can now be called from the corresponding directory;
• Processing of standard object procedures is carried out not by making changes to the module, but by subscribing to events;
• And finally, with platform version 8.3.6, configuration extensions appeared in 1C.

What are 1C configuration extensions, how to work with them, limitations in use - this is the range of issues that we will try to cover in our article.

A little theory

Before the advent of the extension mechanism, the process of updating standard configurations largely depended on whether the configuration was under support or changes had been made to it. In the latter case, the developer had to:

1. Compare the typical and existing metadata structure;
2. If there are significant differences between standard elements, ensure that they are updated correctly;
3. Make appropriate changes after updating.

All this greatly complicated the update process, increasing the processing time and, often, depriving the organization of the opportunity to update standard modules of expensive software.

The extension mechanism allows you to modify many of its elements without removing the standard configuration from support. In fact, the developer, based on the standard solution, creates his own configuration, which is a shell for the standard solution. In this case, the process of updating the standard part occurs automatically, and when launched by the end user, the platform combines both solutions for the user.

Situations in which extensions can be used

Like any other tool, the extension mechanism has a number of characteristics and limitations that determine the scope of their use:

• Extensions can work with managed forms;
• The mechanism supports modification and addition of existing subsystems;
• Before the release of platform 8.3.8, extensions could only change existing roles; after the update, they allowed adding new ones, limiting access even to main database objects;
• The existing mechanism allows you to change the command interface of subsystems and the main configuration section at your own request;
• This toolkit also allows you to add processing and reports without making changes to the database structure;
• In platform version 8.3.9.718, the mechanism for diagnosing the compatibility of the extension and the main configuration has been significantly redesigned.

From the above it becomes clear that:

1. When working with regular forms, the functionality of extensions is significantly limited;
2. Although the process of updating the main configuration has been simplified, the ability to use a specific extension (including as production solutions) can be seriously limited by both changes in the original structure and several extensions used in parallel;
3. It is advisable to use this mechanism in cases where there is a need to differentiate the appearance and functionality used by different users, or when the standard configuration that is being supported is modified on its own.

Let's move on to practice. We will use the “Salaries and HR Management” configuration version 3.1.3.223 as the initial base, the work will be carried out on the platform 8.3.10.2561, the operating mode is file.

Creating an extension

In the configurator, go to the Configuration->Configuration Extensions menu, the form will open (Fig. 1).

This is where you can create a new extension. Click the “Add” button. Here is the window of the new extension (Fig. 2)

Fig.2

Let's look at its elements:

• Name – unlike other configuration elements, it is not created according to system standards, i.e. may begin with a number or symbol, may contain a space;
• Synonym – just like for other metadata elements, it contains an expression representing an object;
• Prefix – allows you to identify event handlers in a form module, since the main configuration form module and the extension form module are combined when the platform operates in a common context (by default, the extension is processed first, that is, handlers with a prefix, then the main handlers);
• Purpose.

The list of the “Destination” field consists of three values; we will describe them in the order of execution:

1. Correction - extensions of this purpose are created to correct minor inaccuracies and errors in borrowed objects;
2. Adaptation – the default value, extensions of this type are designed to adjust standard objects to the requirements of a specific user (if the extension was created in a program version lower than 8.3.9, after updating the platform it will have exactly this purpose);
3. Addition – they introduce completely new functionality into a standard solution.

Launch of the extension

Double clicking on the extension name in the window from Fig. 1 opens the extension window (Fig. 3)

As we can see, it is a tree similar to the tree of the main configuration. And here one question arises: in what cases should an object be borrowed?

It is necessary to borrow only those objects (directories, documents, details, etc.) that will be used in the form extension, or in the code of its module, and without borrowing which an error may occur in the operation of the extension.

That is, if our development requires the “TIN” attribute of the “Individuals” directory, if it is used in the form module, we must borrow it from the main database. In this case, each time the extension is launched, a check will be made for the presence of this attribute in the main configuration directory and for the correspondence of the data type in the source database and in the extension.

If after an update or during the development of new functionality there is an inconsistency between the extension and configuration data types or any other errors, the system will inform the user about this (Fig. 4)

The window in the lower right corner indicates an unusual situation when connecting an extension; double clicking on it opens detailed information. In this case, we simply changed the value type of the TIN attribute from the “String” value to the “Boolean” value for the borrowed object, but much more often the opposite situation occurs - when updating a standard product leads to a change or elimination of the main database attribute.

Having worked and tested the extension on a copy of the database, you can upload it to a separate file; to do this, in the window (Fig. 5) you need to click the “Configuration” button and select the “Save to file” option. Unlike regular configuration files that have a cf extension, the configuration addition file will have a *.cfe mask.

As you can see from the above figure, you can download new functionality from the same window, or from the main program window.

To connect the extension in 1C.Enterprise mode, the user must have the “All functions” mode enabled and log into the program with Administrator rights.

The path to connect the modification is as follows: All functions->Standard->Manage configuration extensions. The window that opens is shown in Fig. 6

Fig.6

Clicking on the “Add” button opens a file selection dialog box in which you need to select our upload. If the checkbox for processing is checked (Fig. 7) and the extension contains an error, the functionality will be canceled and the program will report an exception.

Fig.7

In order for our functionality to work after successful addition, the program must be restarted.

Borrowing objects and the order in which modules fire

In order to trace the sequence of execution of the handlers, we will enable the ability to change our configuration and add a new processing to it, the functionality of which will consist of only one thing - it will report that it was launched from the main configuration, code in Fig. 8.

Fig.8

Let's add this processing to the extension.

To do this:

• Right-click to activate the context menu of the processing form (Fig. 9);

Fig.9

• Select “Add to extension”;
• In the additional configuration tree, both the treatment itself and a duplicate of its form will appear;
• Having opened the form, we find that the command that causes the message is also there, but it is not assigned a handler;
• Adding a command action brings up a dialog box (Fig. 10) in which, in addition to the main directives for where the command is executed, there is also a “Call Type” group.

Fig.10

We have three types of call for the existing procedure;

• Call before – execution of the extension code will be started before the main configuration is executed;
• Call after – the modified procedure will be number two;
• Call instead – the procedure from the main configuration will not be executed at all.

Let's leave the call type in the “Call after” position and add the “Ext1_NotifyAfter(Command)” procedure (Fig. 11).

Fig.11

The result of launching our processing will be two phrases reported sequentially (Fig. 12), that is, the additional configuration message will be displayed after the main one. If we had selected “Instead”, we would not have seen the first line at all.

Fig.12

Starting from version 8.3.9.1818, the program functionality included a mechanism for changing standard modules, as well as adding your own modules. And here the developers were faced with a very specific task: how to determine in what order the borrowed procedures and functions should be executed not only in relation to the main configuration, but also in relation to the extensions already connected in the configuration.

Annotation engine

Let's imagine a situation where several extensions are connected to one configuration, that is, the window for selecting them in the configurator looks like in (Fig. 13)

Fig.13

When adding each new extension, the system independently builds the order of their execution.

The order of execution of additional modules is configured based not only on the time the module was added (later added, later executed), but also based on the purpose of the modification (“Execution” will always come before “Adaptation”).

In addition, the sequence of execution of procedures of added modules can be adjusted using annotations:

• &Before("ProcedureName");
• &After("ProcedureName");
• &Instead of("ProcedureName").

As you can see, their set is similar to what was demonstrated in the previous section, and the functionality is also similar.

Since the borrowed module and the donor module are in the same namespace, no additional definitions for type variables and methods are needed in this case.

The situation with functions is somewhat different than with procedures. The fact is that the execution of a standard procedure can be, as it were, edged with extension code, that is, you can insert some actions before the procedure code, some algorithms after, but this will not work for functions. If the main function is executed after the extension code, the return value of the replacement function will not be received, but if before the modified algorithm, then the value of the main function will not be received and the &After annotation will work as &Instead.

To eliminate this “injustice”, the ContinueCall() method was created.

Generally speaking, using the “Instead” annotation is a little incorrect, although sometimes it is necessary. Using it, we significantly limit the functionality that can be significantly changed and modified in standard configurations.

Making changes to an object module

The event subscription mechanism made the work of developers a lot easier, but there was one serious BUT.

But to use it, you often had to create your own common module, which would store procedures for processing certain actions with data. Currently, the use of extensions has made it possible to significantly revise this functionality.

Let's say that in the process of work we needed to add some kind of processing for the standard “Hiring” document when recording it. Previously we would have gone into subscriptions and worked from there, now we can add this document to the extension:

• Let’s select “Reception for Work” in the configurator and from its context menu we will add it to our extension (by the way, this mechanism has a hotkey combination Alt+Shift+F2);
• After selecting the appropriate add-on, we will receive a picture as in Fig. 14;

Fig.14

• We will be interested in the “Object Module” element highlighted in yellow; we will open it by first activating the corresponding checkbox (Fig. 15);

Fig.15

• We will receive a blank sheet of the software module, pay attention to the top panel, or more precisely, to the element presented in Fig. 16, the drop-down list here presents events that can be processed for this object;

Fig.16

• Let's try to display the document number in the message when it was recorded by selecting the corresponding event;
• We will receive a call type selection form (Fig. 17), determine when the number will be displayed;

Fig.17

• The procedure code is shown in Fig. 18;

Fig.18

In some cases, due to the “Safe Mode” checkbox being checked, the extension fails to connect.

A small announcement

In the near future, 1C is planning to release platform 8.3.11, in which they announced the possibility of adding their own:

• Documents;
• Directories;
• Exchange plans;
• Registers of information.

The ability to add details and tabular parts should also be implemented. At the same time, the developers took into account the possibility of changing standard solutions, which could lead to a malfunction of the extension.

The data entered into the extension will not be lost anywhere, and until the compatibility problem is resolved, the main configuration directory modified by the extension will not be writable.

Implemented in version 8.3.6.1977.

We have implemented a fundamentally new mechanism for adapting application solutions to a specific user - the extension mechanism.

What are extensions good for?

Extensions offer a different strategy for changing typical configurations than the existing one. Using this new strategy will greatly facilitate the support of standard solutions that you want to adapt to the needs of a specific implementation or a specific customer.

What does this process look like now? There is a standard configuration. It is fully supported by the supplier. This means that it cannot be changed. Periodically, the vendor releases new (improved) versions of this configuration. In such a situation, updating the old version of the configuration to the new version is completely automatic. This is convenient and does not require any special skills or knowledge from the customer.

But often the customer wants to add something or change something in the standard configuration “for themselves.” To do this, the support mode is changed, the configuration is removed from full support. The implementation partner or the customer’s own IT specialists make the necessary changes to it. From this point on, a fully automatic update of the standard configuration to a new version released by the supplier becomes impossible.

Now, updating the configuration requires the participation of a specialist. Moreover, if the changes made at the request of the customer were significant, then the specialist performing the configuration update may require a significant amount of time. And often a very good knowledge of both the typical configuration itself and the modifications made may be required.

The strategy offered by the extensions is as follows. If you want to change a standard configuration, you do not touch the configuration itself. You make all changes in the extension, which, in fact, is also a configuration.

In 1C:Enterprise mode, you simply connect your extension to the standard configuration. The platform automatically, in 1C:Enterprise mode, combines your extension with the standard configuration. As a result, the customer works with a standard solution modified according to his wishes.

When a vendor releases a new version of a reference configuration, an automatic update occurs because the reference configuration support mode has not changed. She remained fully supported by the supplier. And when you launch the updated application solution, the platform will again automatically merge the changed standard configuration with your extension. And the customer will continue to work with the standard solution modified, according to his wishes.

When should you use extensions?

The extension mechanism is tempting due to its versatility. Therefore, it is important to have a correct idea of ​​what tasks it is intended to solve.

Firstly, extensions are indispensable when the application solution operates in data sharing mode. For example, in the service model. One of the subscribers wants to have a couple of additional reports. While other subscribers want to work with an unchanged standard configuration.

Then it is for this subscriber that you can develop an extension in which to implement all his wishes. The subscriber will connect this extension and will work with the changed configuration. While for other subscribers no changes will occur. Because all extensions are connected and launched based on the current separator values.

Another situation is when a standard configuration is modified for a specific customer during implementation. Or modifications to the standard configuration that the customer’s IT specialists perform for themselves on their own. If all these improvements are made in the extension, then the standard configuration will remain fully supported, which will greatly simplify its further maintenance.

There is a temptation to use extensions to create mass-produced application solutions, but this should not be done. Firstly, because the extensions were not designed for such tasks. And secondly, because other platform mechanisms, such as delivery and support mechanisms, do not know anything about extensions.

If you look a little into the history of the appearance of extensions, then, of course, we have seen before, and we see now, that configurations are becoming more complex. We see that additional support is needed at different levels of development: library, modular and industry, etc. We analyzed all these tasks and came to the conclusion that the highest priority at the moment is to adapt configurations to the wishes of users during implementations.

It is for this task that we created the extension mechanism. Of course, you can notice different features of the other listed areas of development in it. But they are not its main purpose and should not confuse you.

What can you change now using extensions?

So far, not much has been done that is planned to be done. The mechanism will, of course, develop. But what has already been done can be useful in many cases during implementations. Now:

• Can be changed managed forms, existing in a standard configuration;
• You can add new ones subsystems. You can change the composition of subsystems available in a standard configuration;
• Can be changed roles standard configuration, adding objects created in the extension to them;
• Can be changed command interface typical configuration (main partition, subsystems);
• You can add new ones reports And processing.

In the future, we plan to gradually increase the functionality of the extensions and will be glad to get your opinion on what functionality is most in demand in implementations with minor modifications.

How does the extension work?

The extension is very similar to the regular configuration. It is also represented as a tree of objects. To work with the extension, the same working methods are used as with the regular configuration.

An important feature of the extension is the presence borrowed objects. You can borrow any standard configuration object using the context menu command:

Borrowed objects are not always needed. This is best explained using a “everyday” example, if we draw an analogy with lunch in a restaurant.

The first situation is when borrowed objects are needed.

You are used to having lunch at the same restaurant. You always order steak and tea. For example, because they are very good in this restaurant. Or for another reason. It doesn't matter. The only important thing is that you are going to eat them, and nothing else.

Then the restaurant is a typical information base. You are an extension. The restaurant menu is an expandable standard configuration. Beefsteak and tea are borrowed objects. You borrowed them (remembered that they were on the menu).

How does the extension connect to the configuration and work? You come to a restaurant and ask for a menu. On the menu you see that there is steak and tea. That is, you establish a correspondence between borrowed objects and objects of a standard configuration. Naturally, you match by name :). They bring you steak and tea, you eat them. That is, the extension connects and works.

A week later you come, but the restaurant menu has changed (the standard configuration has been updated). However, steak and tea are still on the menu. They are exactly what you need. They bring them to you, you eat them. That is, the extension continues to work with the updated standard configuration.

A week later you come to the restaurant and see that steak and tea have disappeared from the menu. You get up and leave (extension connection error message). Because that's what you wanted. And you have no idea about other dishes (objects). The developer did not teach you how to properly eat snails or lobsters.

Another situation when you can do without borrowed objects.

You go to a restaurant, but the availability of specific dishes does not interest you. Because you're not going to eat them anyway. You only want to photograph them. And you know how to photograph any dish. Then you just connect to the configuration and say: bring all the snacks that you have on the menu (you get a collection of documents from the metadata). I will redirect them (take photographs).

If we describe this in the dry language of developers, it turns out that you need to borrow objects:

• When they are needed for visual design. For example, you extend the form and add form props like DirectoryCurrencies.Link. Then of course you should borrow the reference book Currencies, so that when connecting to a standard configuration, you can be sure that such a directory is still there.
• When they are needed for the code to work. For example, in the extension code you access the directory attribute Nomenclature - Importer. Then this attribute must also be borrowed so that when connecting, you can be sure that in the standard configuration such attribute still exists in the directory Nomenclature.

Connecting an extension

You create an extension in the configurator. Once it has been debugged and tested, you can reject it by saving the extension to a *.cfe file.

You can send this file to the customer. The customer will independently upload it to his information base in 1C:Enterprise mode using the standard function Managing Configuration Extensions.

Working with extensions is available from the built-in language, so in the application solution you can create your own processing that will load extensions. To prevent everyone from playing around with extensions, we have added a new right - Administering Configuration Extensions.

When loading an extension from a file, it is saved in the infobase. Moreover, it is saved in the context of the current separator values ​​used in this session.

For the extension to work, the session must be restarted. When the session starts, just before the event is called SettingSessionParameters, all extensions stored in the infobase and corresponding to the current separator values ​​for this session will be connected.

As a result, when working in data sharing mode, the extension will be applied only to users of this specific subscriber. And if data separation is not used, then the extension will work for all users of the infobase.

When connecting an extension, as we have already said, it is checked that borrowed objects exist in the standard configuration. Objects are matched by name.

In addition, finer control is possible. You can control not only the very fact of the existence of objects, but also the state of their individual properties. That is, if you think about a restaurant and a steak, what may be important for you is not just the presence of a somehow cooked steak, but precisely the fact that here it is cooked rare, “rare.”

Returning to the extension, by default it does not control the properties of borrowed objects. But if necessary, you can make some properties controllable. For example, it is important for your algorithm that not only does there exist a directory Nomenclature, but also that its code has the type Line.

Then, if in a typical configuration the supplier changes the code type of this directory to Number, your extension will detect this at the time of connection and report an error.

An interesting point is related to the renaming of standard configuration objects. For example, you came to a restaurant, and instead of Steak written Steak. That is, when connecting to the configuration, the extension does not find a directory in it Nomenclature, because the vendor renamed it to Goods.

Now this situation is not a problem for you. And you don’t need to “shovel” all the extension code so that instead Nomenclature write Goods. It also works. Therefore, you just need to change the name of the borrowed object to Goods, and the platform will make the rest of the changes in the extension itself. Or with your minimal help.

Extension operation

You can talk for quite a long time about the features of expanding various objects, about the features of the operation of the extensions themselves. But we are limited by the scope of the review article, so we will only touch on the key and most revealing points.

The main “beauty” of extensions is, of course, not that you can add something to a standard configuration that is not there. And the fact is that in the extension you can change what is already in the standard configuration. That is, you can change the properties of borrowed objects.

The basic concept used when configuration and extension work together can be described as follows. In those places where they do not intersect, the extension complements the configuration. In those places where they “intersect”, expansion is applied.

This can be seen in more detail using managed forms as an example. You can borrow a form from the main configuration and edit it in the extension without restrictions. For the visual part of the form and for its module, two different combining strategies are used.

The visual part of the form is fixed in the extension at the time of its borrowing. And in 1C:Enterprise mode, for each form element, changes relative to this state are analyzed in the standard configuration and in the extension.

If there were no changes, or they were only in the standard configuration, the value from the standard configuration is applied. In other cases, the value from the extension is used.

Thus, if you added a new command to the form in the extension, you will see it along with the other commands of the form. And if you changed the title of an existing group, then you will see your title even if the title of this group in the standard configuration is changed by the supplier.

Form modules use a different approach. For the borrowed form, the extension creates its own module with its own handlers for all events. In 1C:Enterprise mode, both form modules (from the standard configuration and from the extension) are combined in one context. For this reason, each extension has its own prefix, which is added to all event handlers in the form module. So that there are no coincidences with handlers from the standard configuration. After this, event and command handlers are called sequentially and synchronously. First the handler from the extension. Then from the standard configuration. You can change this sequence, or completely prohibit the execution of the handler from the standard configuration.

In general, as for the joint operation of configuration and extension in 1C:Enterprise mode, they exist in a common namespace. This applies not only to individual modules, but also to the metadata trees themselves. Therefore, there is no way in 1C:Enterprise mode to determine whether this object is “native” for the standard configuration, or whether it came from an extension.

As for the other objects that you can use in the extension, everything looks much simpler for them.

In the extension you can create your own subsystems. Using borrowed objects, you can expand existing subsystems: add to them objects and subsystems that are already in the standard configuration, or those that you created in the extension. You cannot remove something from an existing subsystem.

You can expand roles only by adding objects created in the extension to them. You also cannot delete anything from an existing role. The same applies to the command interface.

Expansion is almost configuration

We said at the beginning that the extension is similar to the regular configuration. Therefore, in conclusion, I would like to say a few words about how integrated the extensions are with other platform mechanisms.

An extension (like a regular configuration) has a main configuration and a database configuration. The mechanism for comparing and merging configurations works with extensions in the same way as with regular configurations.

You can upload the extension to a file (though with a different extension *.cfe), and load from the file. Extensions can be uploaded/loaded in XML.

Mechanisms for global search, replacement, and editing of interface texts also work with extensions.

There are new command line parameters for working with extensions, as well as new events in the log.

In the built-in language, the main object for working with extensions is ExtensionManagerConfiguration.

Error connecting extension... for 1C:Accounting 8.3, edition 3.0

2016-12-08T16:04:02+00:00

In this instruction I’ll tell you how to deal with an error like this: “Error connecting extension: NameExtensions..." for 1C:Accounting 8.3, edition 3.0.

Download":

6. After that, click the “Restart” button:

1C will restart and the new version of the extension will work, without errors.

Disable extension

If it is impossible to get a new version of the extension or you decide to abandon it for other reasons, then you need to:

1. Log into the database in user mode.

2. Open the "All functions" menu ():

3. In the dialog that opens, expand the “Standard” item and select the “Manage configuration extensions” processing:

4. Here, among the installed extensions, find the one you need (by its name in the error message), select it and press the button " Delete":

After this, the extension will be removed from the database (it no longer worked) and the error message will no longer appear when opening the program.

Sincerely, Vladimir Milkin(teacher and developer).

We present to your attention a new mechanism for customizing applications in the 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 via 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 for payment, individual design);
• add new processing (processors for filling out documents and tabular parts, printed forms, custom 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 ():

1. 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.
2. Extension development. A configuration extension developer develops an extension on his computer and tests the extension. Requirements for configuration extensions are given After 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 a configuration extension or a new version is added to the service, the extension is automatically sent to audit. The audit is performed by employees of the service provider (administrator).

3. 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.

4. 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.
5. 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"(it can be downloaded) shows how an application can provide data to an 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 the received news feed is displayed on a mobile device, 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.