Platform modules 1C:Enterprise 8.3, 8.2

Common modules

Functions that are declared with the "export" flag in such a module can be called from anywhere in the configuration. The call is made via CommonModuleName.FunctionName().

Such modules do not have a variable section.

The execution of common modules depends on the settings in their properties:

Flag "Global"

If this flag is set, then the context of such a module becomes global. That is, when accessing its export functions, you do not need to specify the module name. But the names of its export functions must be unique within the global configuration context.

Server flag

The functions of such a module can be executed on the server.

"Client (regular application)" flag

The functions of such a module can be executed on the client in normal application mode.

"Client (managed application)" flag

The functions of such a module can be executed on the client in managed application mode.

"Server Call" flag

The flag is available for modules with the "Server" flag set. Allows the client to call the export functions of this module (which will be executed on the server).

External Join flag

The export functions of such a module can be called when connecting from an external source.

Flag "Privileged"

In a module with this flag, rights checking will be disabled. Suitable for productivity or administrative activities.

Reuse option

If you enable this option, the return values ​​of export functions will be cached immediately after the first call. Caching is possible for the duration of the call (the execution time of a specific procedure) or for the duration of the user session.

Application module

Designed to handle application startup and termination events. There are two types: for regular and managed applications.

You should not overload it, as this affects the application startup time.

Session module

A special module that is used to initialize session parameters. It is necessary in order not to duplicate code in various application modules.

It should be used carefully, since the module can be executed several times, and can also be executed without further starting the database. Executed before application modules.

Sincerely, (teacher and developer).

Software modules contain executable code in the 1C language, which is necessary in order to respond in a certain way to the actions of the system or user when visual development tools are not enough. We can also describe our own methods (procedures and functions) in software modules.

Typically a software module consists of three sections:

• variable declaration area;
• area of ​​description of procedures and functions;
• main text of the program.

Example of a program module structure:

//***************** VARIABLE DECLARATION AREA **********************

Perem Last Name Export; / /this is a global variable
Change Name, Patronymic; //this is a module variable
Perem full name; //this is also a module variable and can be accessed

//from any procedure and function of our module

//*************** AREA DESCRIPTION OF PROCEDURES AND FUNCTIONS ****************

Procedure Procedure1 ()
Variable Total ; / /Result is a local variable (procedure variable)

Total = Last name + " "+ First name + " "+ Middle name;

End of Procedure

Function Function1()

// function operators

Return(LastName + " "+ FirstName);

EndFunction

//******************* MAIN TEXT OF THE PROGRAM ***********************

Last name = "Ivanov";
Name = "Ivan";
Patronymic = "Ivanovich";

//******************************************************************************

In a particular software module, any of the areas may be missing.
Variable declaration area placed from the beginning of the module text to the first Procedure or Function statement or any executable statement. This section can only contain Variable variable declaration statements.

Area for describing procedures and functions placed from the first Procedure or Function statement to any executable statement outside the body of the procedure or function description.

Main program text area is placed from the first executable statement outside the body of procedures or functions to the end of the module. This section can only contain executable statements. The main program text area is executed at the moment of module initialization. Usually, in a section of the main program, it makes sense to place operators for initializing variables with any specific values ​​that must be assigned before the first call to procedures or functions of the module.

Software modules are located in those places in the configuration that may require a description of specific operating algorithms. These algorithms should be formalized in the form of procedures or functions that will be called by the system itself in predetermined situations (for example, when opening a directory form, when pressing a button in a dialog box, when changing an object, etc.).

Each individual software module is perceived by the system as a single whole, so all procedures and functions of the software module are performed in a single context.

The module execution context is divided into client and server. In addition, some software modules can be compiled on both the client side and the server side.

Application module (managed or regular)

The application module describes the procedures (handlers) of events that are initialized at the start and end of the system. For example, when the application starts running, you can update some configuration data, and when you exit the application, you can ask whether it is worth exiting the program at all. In addition, this module intercepts events from external equipment, for example, trading or fiscal. It is worth noting that the application module is executed only when the application is launched interactively, that is, when the program window is launched. This does not happen if the application is launched in com connection mode.
In the 1C 8 platform there are two different application modules. These are the Regular Application module and the Managed Application module. They are triggered when different clients are launched. Thus, the Managed Application module is triggered when the web client, thin client and thick client are launched in managed application mode. And the regular application module is triggered when the thick client is launched in normal application mode. The application launch mode setting is specified in the "Basic launch mode" configuration property.

An application module can contain all 3 sections - declarations of variables, descriptions of procedures and functions, as well as the main text of the program. The application module is compiled on the client side, which greatly limits our use of many data types. You can extend the application module context using methods of common modules that have the “Server Call” property set. All application module variables and methods that are marked as export will be available in any configuration module running on the client side. However, as tempting as it may be, you should not place a large number of procedures and functions here. The more code there is in a given module, the longer the compilation time, and, consequently, the application launch time.

As noted above, the application module handles application startup and termination events. To handle each of these events in the application module, there are a pair of handlers Before... and When... The differences between them are as follows: when executing code in the Before... handler, the action has not yet taken place and we can refuse to execute it. This is what the Reject option is for. In the On.. handlers, the action has already taken place, and we cannot refuse to launch the application or exit it.

External connection module

• can contain all 3 areas
• located in the root section of the configuration

The purpose of the module is similar to the purpose of the application module. It processes the start and end events of the application. The external connection module is triggered when the application is launched in com connection mode. The outer join process itself is not an interactive process. In this mode, programmatic work with the information base occurs and the application window does not open, which imposes certain restrictions on the use of methods intended for interactive work. In this mode, calls to dialog forms, warnings and messages to the user, etc. cannot be used. They simply won't be executed.

As in the application module, all three areas are available here: variable declarations, descriptions of procedures and functions, as well as the main text of the program. The main difference from the application module is that in com-connection mode all work with the infobase occurs on the server side, so the external connection module is compiled on the server side. Accordingly, export variables and methods of common client modules are not available in it.

Session module

• runs on the server side
• located in the root section of the configuration

This is a highly specialized module designed exclusively for initializing session parameters. Why did you need to make your own module for this? Its use is due to the fact that the application itself can be launched in different modes (resulting in the execution of either a managed application module, a regular application module, or an external connection module), and initialization of session parameters must be done regardless of the startup mode. In order not to write the same program code in all three of these modules, we needed an additional module that runs regardless of the application launch mode.

In the session module, there is one single event “SettingSessionParameters”, which is executed very first, even before the application module event BeforeSystemStartOperation. The variable declaration section and the main program section are not available in it. You also cannot declare export methods. The module is compiled on the server side.

Common modules

• may contain an area describing procedures and functions
• executed on the server or client side (depending on the module settings)
• is located in the tree branch of the configuration objects “General” - “General modules”

Common modules are intended to describe some common algorithms that will be called from other configuration modules. The general module does not contain variable declaration areas and the main program text. You can declare export methods in it, the availability of which will be determined by the module settings (on which side it is executed: on the server or client side). Due to the fact that the variable description section is not available, global variables cannot be defined in common modules. You can use an application module for this.

The behavior of a common module depends on the parameters set (global or not, various compilation flags, whether a server call is available, etc.). Here are some tips for setting up common modules:

It is good practice not to use the Global flag everywhere. This will reduce the startup time of the application, and also improve the readability of the code (of course, if the common module has a completely meaningful name);
- It is not advisable to use more than one compilation flag. There are not so many methods that need to be executed in different contexts, and if such methods are still required, then a separate common module can be allocated for them;
- the “Call server” flag makes sense only if the module is compiled “On the server”. Therefore, all other compilation flags should be removed to avoid various problems;
- if the module methods involve massive data processing, reading and writing to the database, then to increase the speed of work it is better to disable access control by setting the “Privileged” flag. This mode is only available for shared modules compiled on the server.

Form module

• can contain all 3 areas
• executed on the server and client sides

The form module is designed to process user actions with this form (processing a button click event, changing form attributes, etc.). There are also events associated directly with the form itself (for example, its opening or closing). Modules of managed and regular forms differ, first of all, in that the module of a managed form is clearly divided into context. Every procedure or function must have a compilation directive. If the compilation directive is not specified, then this procedure or function is executed on the server side. In its normal form, all code is executed on the client side.

The structure of a managed form contains a section for declarations of variables, descriptions of procedures and functions, and the main text of the program (executed at the time of initialization of the form). We can access standard form events through the list of expected procedures and functions of the form (Ctrl+Alt+P), or through the properties palette of the form itself.

If a form has a main attribute assigned, then the properties and methods of the application object used as the main attribute become available in the form module.

Object module

• can contain all 3 areas
• runs on the server side

This module is available for most configuration objects and is generally intended for processing events directly related to the object. For example, events of recording and deleting objects, checking the completion of object details, posting a document, etc.

Some object module events duplicate the form module events. For example, events associated with a recording. However, it should be understood that the events of the form module will be executed exclusively in the specific form of the object, that is, when the specific form is opened. And the events of the object module will be called in any case, even at the moment of programmatic work with the object. Therefore, if you need methods associated with an object without being tied to a specific form of the object, then it is better to use the object module for this.

Object manager module

• can contain all 3 areas
• runs on the server side

The object manager module appeared only starting from version 1C 8.2. The manager module exists for all application objects and is designed to manage this object as a configuration object. The manager module allows you to expand the functionality of an object by introducing (writing) procedures and functions that relate not to a specific instance of a database object, but to the configuration object itself. The object manager module allows you to place general procedures and functions for a given object and access them from outside, for example, from processing (of course, if this procedure or function has the Export keyword). What new does this give us? In general, nothing except organizing procedures by objects and storing them in separate places - Object Manager Modules. We can just as successfully place these procedures and functions in general modules, but 1C recommends placing general procedures and functions of objects in the Object Manager Module. Examples of using the procedures and functions of the Object Managers Module: initial filling out individual details of a directory or document under certain conditions, checking the completion of details of a directory or document under certain conditions, etc.

Command module

• may contain a section describing procedures and functions
• executed on the client side

Commands are objects subordinate to application objects or the configuration as a whole. Each command has a command module in which a predefined CommandProcess() procedure can be described to execute that command.

Managed Application Module

Designed mainly to catch the moment the application starts and the moment it shuts down. There are also handlers here that allow you to intercept an external event from the equipment. In the managed application module, it is the interactive startup of the system that is monitored.

Managed application module events fire when the thin client, web client, and thick client of the managed application are launched. In the control module applications can be accessed from the properties palette of the root configuration node or from the context menu called on the root configuration node.

Regular Application Module

The regular application module plays the same role as the managed application module, only the events of the regular application module are triggered when the thick client of the regular application is launched.

The regular application module will become available from the properties palette of the root configuration node after setting the “Edit configuration for launch modes” option in the configurator parameters on the “General” tab to “Managed application and normal”.

External connection module

The external connection module is designed to handle the login event (not interactive, but in COM connection mode) and logout. There are corresponding handlers. With a COM connection, an interactive window does not open, so functions for dialogue with the user will not work. It is possible to describe export variables and methods in the module. The external connection module is compiled on the server. Those. it is possible to access the corresponding configuration objects, for example, directories.

Session module

There is such a general configuration object as “Session Parameters”. The session module is created to initialize session parameters (there is a specific event for this; when the application starts, it starts first).

Runs in privileged mode (access rights are not checked when accessing the database). The session module is compiled on the server. There is no section for describing variables and a section for the main program; export methods cannot be described; it is used only for setting session parameters. As you can see, the session module has a very narrow purpose.

Common modules

Common modules describe some common algorithms and contain functions that can be called from various places. Common modules can be compiled on both the client and the server.

In general modules, ONLY the section describing procedures and functions is available. If you need to use a global variable, you can use either session parameters or an export variable of a managed application module.

In the general module, you can set some parameters that will affect its behavior. If the “Global” checkbox is checked in the general module, then its export functions will participate in the formation of the global context. And they can be accessed directly from another context (without mentioning the name of the common module): CommonModuleMethod();

You should not use the “Global” property of common modules everywhere, because such modules are compiled at system startup and slow down the start of the program

Object module

Many configuration objects (directories, documents, etc.) have an object module. You can enter standard events into it, such as creating a new directory item, recording a new object, deleting, processing a document posting, etc. The record event exists both in the form module (occurs during the interactive recording process when the user clicks on the “record” button) and in the object module.

It must be remembered that one object can have several forms. Therefore, the recording event must be processed in the object module. This is where the correctness of the recorded data is checked.

An object module can be called from the properties palette of a given object, or from the context menu. The structure of an object module is no different from a form module. The object module is compiled on the server, so no compilation directives are required.

Form module

The form module is designed to handle user actions (handling a button click event, etc.). There are also events associated directly with the form itself (for example, the event of its opening, closing). Managed and regular form modules differ primarily in that the managed form module is clearly separated into context. Every procedure must have a compilation directive. In normal form, all code is executed on the client.

The structure of a managed form contains a section for describing variables, a section for procedures and functions, and a section for the main program (executed at the time the form is initialized). We can access standard form events through the list of procedures and functions (Ctrl+Alt+P) or in the properties palette of the form itself. You can also process the element recording event in a managed form (this event is present only for objects: directories, documents).

Object manager module

The manager module appeared only in 1C 8.2; it exists in many configuration objects. The main purpose of the object manager module is to override the standard event “Processing Receiving Selection Data”, and in it we can also

Value manager module

The constant configuration object does not have an object module, but there is a very similar module - the value manager module. In the constant value manager module, you can describe various procedures (including export ones), as well as process 3 events: BeforeWrite, OnWrite, ProcessingFillCheck. This module is compiled on the server.

Recordset modules

The recordset module is analogous to the object module and is inherent in registers. There are standard events in the recordset module:

• Before recording
• When recording
• Processing padding check

In the recordset module there is a section for descriptions of variables, procedures and functions (including export ones), a section for the main program.

Almost all configuration objects have a manager module, and for most objects an object module. Often, novice programmers do not understand the differences in the purpose of these two modules.

Understanding the difference in their purpose allows you to write program code that is more correct in structure, and in some cases save 1C server resources and increase the performance of the application solution.

In this article we will look at the fundamental differences between these modules, both from a theoretical perspective and using a specific practical example.

Theory

Let's turn to the basics of object-oriented programming (OOP) and draw an analogy with our example. In OOP, methods for objects can be divided into static and simple. Simple methods can only be called on a specific object that we have access to in the current code context. Static methods do not have direct access to object data. To access an object, you first need to create an instance of it. The same applies to the 1C:Enterprise 8.x platform.

In the object module, the platform stores procedures and functions that can be called only when working with a specific object, for example, with the object of the “Nomenclature” directory element. The manager module contains procedures and functions that can be applied to all objects of a given type, but with the initial creation of an instance of that object. That is, to change an item of nomenclature from this module, first execute the “GetObject()” method to reference the element and then work with it.

Let's move on from theory to practice.

Practice

Let's move on to a practical example. Let's assume that we need to solve the problem of printing a list of products. The user prints a product either directly from a directory element or from the product list form. Let's consider two ways to complete the task.

Print procedure in object module

In the directory object module, add the following function:

// Pass a reference to a directory element to the function Function PrintSelectedProducts(Link) Export TabDoc = New TabularDocument; Layout = Directories. Goods. GetLayout("Layout"); Request = New Request; Request. Text = " SELECT | Products . Presentation AS Product,| Goods . MarkDeletion,| Goods . vendor code |FROM| Directory . Products AS Products|WHERE | Goods . Link B(&Product Array)" ; Request. SetParameter(" Array of Products ", Link); //Select by link

The program code is completely generated by the print designer. The only thing worth noting is the display by reference to the “Products” directory element in the request. The reference is passed as a parameter to the function. As a result of calling the "PrintSelectedProducts" function, a spreadsheet document with the completed product position will be returned.

The program code for calling the "PrintSelectedProducts" object method using the "Print" form command is presented in the following listing:

&OnClient Procedure Print(Command) // Contact the server procedure to receive the generated spreadsheet document TabDoc = PrintServer(); // Show the generated spreadsheet document TabDoc. Show() ; EndProcedure & OnServer Function PrintServer() // Convert the form object into a directory object "Products" to call a function from the object module ObjectItem = FormAttributeValue("Object" ) ; // Call the object module procedure, passing there a link to the current directory element. Result // return to the client side Return ObjectProduct. PrintSelectedProducts(Object.Link) ; EndFunction

Thus, we printed the current directory element by working with its object. But the task said to print a list of products that the user himself must select. When working with an object, it is not possible to give the user such an opportunity in a simple way. The most correct way would be to print from the list of items in the “Products” directory.

Printing procedure in the manager module

Let's add the following export procedure to the directory manager module:

// Pass an array of links to products Function PrintSelectedProducts(ArrayProducts) Export TabDoc = New TabularDocument; Layout = Directories. Goods. GetLayout("Layout"); Request = New Request; Request. Text = " SELECT | Products . Presentation AS Product,| Goods . MarkDeletion,| Goods . vendor code |FROM| Directory . Products AS Products|WHERE | Goods . Link B(&Product Array)" ; Request. SetParameter(" Array of Products ", Array of Products) ; // Set selection by array Result = Request. Run(); HeaderArea = Layout. GetArea("Title"); AreaFooter = Layout. GetArea(" Basement "); TableHeadArea = Layout. GetArea("Table Header"); TableFooterArea = Layout. GetArea("TableFooter"); DetailRecordsArea = Layout . GetArea("Details"); TabDoc. Clear() ; TabDoc. Output(AreaTitle) ; TabDoc. Output(TableHeadArea); TabDoc. StartAutoGroupingRows() ; SelectionDetailRecords = Result. Choose() ; While SelectionDetailedRecords. Next() LoopDetailRecordArea. Options. Fill(SelectionDetailRecords) ; TabDoc. Output(DetailedRecordsArea, DetailedRecordsSelection.Level()) ; EndCycle ; TabDoc. FinishAutoGroupingRows() ; TabDoc. Output(TableFooterArea); TabDoc. Output(AreaFootground) ; Return TabDoc; EndFunction

The main difference from a function in an object module is the function parameter. Now an array with links to products that need to be printed is passed as a parameter.

The program code of the “Print” form command module looks like this:

& On the Client Procedure Print(Command) TabDoc = PrintServer() ; TabDoc. Show() ; EndProcedure & OnServer Function PrintServer() // Pass an array of links of selected products in the directory list // into the manager module function "PrintSelectedProducts" Return Directories. Goods. PrintSelectedItems(Items.List.SelectedRows) ; EndFunction

In this case, the result of executing the command in 1C:Enterprise mode will be as follows:

If we use the method from the manager module, we can access the data in the “Products” directory without obtaining an object for each link. Since getting an object means getting all the data from the database for a directory element and placing the received data in RAM, implementing the task in the second way will have a positive effect on performance. After all, in this case we will use a minimum of resources (RAM) of the server machine.

What to use?

As always, it all depends on the specific task. If you need to print a document, then the best option is to use the manager module. If you need to fill an object, for example, by external processing of filling tabular parts, then in this case it is better to place procedures and functions in the object module, since they work specifically with the object.

In the standard configuration of "Trade Management" version 11, the manager module is used everywhere for printing documents. If you look at the “Manufacturing Enterprise Management” configuration, the manager module is practically not used, since the configuration was written in older versions of the platform, where there was no full support for this mechanism.

Configuration with examples from the article.

What are modules and what exactly are they intended for? The module contains the program code. Moreover, it is worth noting that, unlike the 7.7 platform, where the code could be located in the properties of form elements and in the cells of the layout tables, in the 8.x platform any line of code must be located in some module. Typically, a module consists of three sections - a section for describing variables, a section for describing procedures and functions, and a section for the main program. This structure is typical for almost all platform modules, with some exceptions. Some modules do not have a variable description section or a main program section. For example, Session Module and any General Module.

The execution context of modules is generally divided into client and server. In addition, some modules can be compiled both on the client side and on the server side. And some are exclusively on the server side or client side. So:

Application module

The module is designed to catch the moments of application launch (configuration loading) and termination of its operation. And verification procedures can be placed in the corresponding events. For example, when starting an application, update some reference configuration data, and when finishing work, ask whether it’s worth leaving it at all, maybe the working day is not over yet. In addition, it intercepts events from external equipment, for example, trading or fiscal. It is worth noting that the application module intercepts the described events only when launched interactively. Those. when the program window itself is created. This does not happen if the application is launched in com connection mode.

There are two different application modules in the 8.2 platform. These are the Regular Application module and the Managed Application module. They are triggered when different clients are launched. This is how the managed application module is triggered when the web client, thin client, and thick client are launched in managed application mode. And the regular application module is triggered when the thick client is launched in normal application mode.

An application module can contain all sections - descriptions of variables, procedures and functions, as well as descriptions of the main program. The application module is compiled on the client side, so this greatly limits us in the availability of many types of data. You can extend the application module context using methods of common modules that have the “Server Call” property set. All variables and methods that are marked as export will be available in any configuration module running on the client side. However, as tempting as it may be, you should not post a large number of methods here. The more code it contains, the longer the compilation time, and therefore the application launch time, which is very annoying for users.

As noted above, the application module handles application startup and termination events. To handle each of these events in the application module, there are a pair of handlers Before... and When... The differences between them are such that when executing the code in the Before... handler, the action has not yet taken place and we can refuse to execute it. This is what the Reject option is for. In the On.. handlers, the action has already taken place, and we cannot refuse to launch the application or exit it.

External connection module

The purpose of the module is similar to the purpose of the application module. It processes the start and end points of the application. The external connection module is triggered when the application is launched in com connection mode. The outer join process itself is a non-interactive process. In this mode, programmatic work with the information base occurs and the application window does not open, which imposes certain restrictions on the use of methods intended for interactive work. In this mode, calls to dialog forms, warning messages, etc. cannot be used. They just won't work.

As in the application module, sections for describing variables, methods, and a section for the main program are available here. You can also declare export variables and methods. The difference is that in com connection mode all work with the infobase occurs on the server side, so the external connection module is compiled exclusively on the server. Accordingly, export variables and methods of common client modules are not available in it.

Session module

This is a highly specialized module and is intended solely for initializing session parameters. Why did you need to make your own module for this? This is due to the fact that the initialization process may require the execution of some code, and in addition, the application may be launched under different clients (which leads to the execution of different application modules or an external connection module), and initialization of session parameters must be done in any launch mode. Therefore, an additional module was required that runs in any application launch mode.

In the session module, there is a single event “SettingSessionParameters”, which is executed very first, even before the application module event BeforeSystemStartOperation. The variable declaration section and the main program section are not available in it. You also cannot declare export methods. The module is compiled on the server side.

You should not be tempted by the fact that this module is executed whenever the application is launched, and you should not place code in it that is not directly related to the initialization of session parameters. This is due to the fact that the SetSessionParameters handler can be called repeatedly during system operation. For example, this happens in cases where we access uninitialized parameters. And although it is possible to catch the moment of the first launch of this event (RequiredParameters is of type Undefined), it should be taken into account that this module is compiled in privileged mode, i.e. it does not control access rights. And the second point is that we still cannot be one hundred percent sure that the system will be launched. Suddenly, a failure occurs in the application module, and we are trying to perform some actions with the database.

Common modules

Modules are intended to describe some common algorithms that will be called from other configuration modules. The general module does not contain a variable description section and a main program section. You can declare export methods in it, the accessibility context of which will be determined by compilation flags. Due to the fact that the variable description section is not available, global variables cannot be defined in common modules. To do this, you need to use the functions of common modules with caching of return values ​​or an application module. It is worth keeping in mind that even if the shared module reuse property is set to “For the duration of the session”, then in this case the lifetime of cached values ​​does not exceed 20 minutes from the moment of the last access to them.
The behavior of a common module depends on the parameters set (global or not, various compilation flags, whether a server call is available, etc.). In this article we will not consider all kinds of settings, as well as behavioral features and pitfalls that arise when setting property flags unreasonably. This is a topic for a separate article. Let us dwell on just a few points that should be followed when setting flags:

• A good rule of thumb is to not use the Global flag everywhere. This will reduce the startup time of the application, and also improve the readability of the code (of course, if the common module has a completely meaningful name).
• It is not advisable to use more than one compilation flag. There are not many methods that need to be executed in different contexts, and if such methods are still required, then a separate common module can be allocated for them.
• The "Server Call" flag only makes sense if the module is compiled "On the server". Therefore, all other compilation flags should be removed to avoid various problems.
• If module methods involve massive data processing, reading and writing to the database, then to increase the speed of work it is better to disable access rights control by setting the “Privileged” flag. This mode is only available for shared modules compiled on the server.

Form module

It is designed to process user actions, i.e. various events related to data entry and processing the correctness of their entry. A module of the usual form is compiled entirely on the client. A managed form module is clearly demarcated by execution context, so all variables and methods must have a compilation directive. If the directive is not explicitly specified, then this variable or method will be compiled on the server side. The form module contains sections for descriptions of variables and methods, as well as a section for the main program.

Object module

This module is typical for many configuration objects and is generally intended for processing object events. For example, events for recording and deleting objects, events for posting documents, etc.

Some object module events duplicate the form module events. For example, events associated with a recording. However, understand that form module events will be executed exclusively on the object's specific form. In general, there may be several of these forms. And the events of the object module will be called in any case, even at the moment of programmatic work with the object. Therefore, if you need to execute some code in all cases, then it is better to use an object module event for this.

The object module is compiled exclusively on the server. In it you can define export variables and methods that will be available in other configuration modules. Using these properties and methods, we can significantly expand the functionality of the object.

Object manager module

This module exists for many configuration objects. The main purpose of this module is to redefine the standard selection event that occurs when entering a line and to expand the functionality of the manager. The module is compiled on the server side. It allows you to define export properties and methods. Calling the manager's export methods does not require creating the object itself.

To all of the above, you can add a picture of some configuration modules and ways of mutually calling methods in managed application mode. The arrow indicates the direction in which you can turn to call the corresponding method. As can be seen from the diagram, the server context is completely closed. But from the client context it is possible to access server methods.

Symbols on the diagram: O.M. Client - Client common module; O.M. Server - Server shared module; M.F. Client - Client procedures of the form module; M.F. Server - Server procedures of the form module.