General modules 1C- an object of configuration metadata 1C 8.3 and 8.2, which stores the program code that is often called in the configuration. A function/procedure can be called from anywhere in the configuration (if it is exported).

How to use the shared module

It is good practice to put a procedure or function in a common module if it is called in more than one place. First, if a procedure is corrected, it only needs to be corrected in one place. Secondly, it achieves greater order in the code.

A typical example of a common module is the processing of posting according to some register, getting the amount of the difference in working days, converting exchange rates, recalculating the quantity/price/amount in the tabular section, and other functions.

General Module Properties

One of the main differences between shared modules and other modules is that you cannot declare shared variables.

Get 267 1C video lessons for free:

Let's take a closer look at the properties palette of the common module:

• Global- if the flag is set, functions and procedures from this module become available in the global context. Those. they can be called anywhere in the configuration without the name of the common module. However, a condition is added - the names of procedures and functions in this common module must be unique within the global context.
• Server- The procedures and functions of this common module can be executed on the server.
• Outer join- the program codes of this common module can be executed when connected by an external source (for example, COM).
• Client (managed application)— Procedures and functions of this common module can be used in a thick client in managed application mode.
• Client (regular application)— the program codes of this common module can be used in the thick client in the normal application mode.
• Server call- a flag that allows the client to use the procedures and functions from this common module.
• - if set to True, access rights checking will be disabled in this common module.
• Reuse— determines the settings for returned values, if the option is enabled, then after the first execution the system will remember the value for these input parameters and will return a ready-made value. It can take the following values: not used- shutdown, at the time of the call- for the duration of a certain procedure, during the session- until the user has closed the session (program).

If you are starting to learn 1C programming, we recommend our free course (do not forget

1.1. Common modules are created to implement procedures and functions that are combined according to some criteria. As a rule, procedures and functions of one configuration subsystem (sales, purchases) or procedures and functions of similar functionality (working with strings, general purpose) are placed in one common module.

1.2. When developing shared modules, you should choose one of four code execution contexts:

2.1. Server Common Modules are intended to host server procedures and functions that are not available for use from client code. They implement all the internal server business logic of the application.
For the configuration to work correctly in external connection, managed and regular application modes, server procedures and functions should be placed in common modules with the following characteristics:

• Server(checkbox Server call dropped),
• Client (regular application),
• Outer join.

In this case, it is guaranteed that server procedures and functions can be called with mutable type parameters (for example, DirectoryObject, DocumentObject etc.). As a rule, this is:

• handlers for subscriptions to events of documents, directories, etc., which take a mutable value (object) as a parameter.
• server procedures and functions, to which an object is passed as a parameter from modules of directories, documents, etc., as well as from modules with event subscriptions.

Server common modules are named according to the general rules for naming metadata objects.
For example: Working With Files, General Purpose

In some cases, a postfix may be added to prevent name conflicts with global context properties. "Server".
For example: ScheduledTasksServer, Data ExchangeServer.

2.2. Server common modules to be called from the client contain server procedures and functions available for use from client code. They make up the client API of the application server.
Such procedures and functions are placed in common modules with the attribute:

• Server(checkbox Server call installed)

Server common modules to be called from the client are named according to the general rules for naming metadata objects and must be named with a postfix "Server Call".
For example: Working With FilesCalling The Server

Note that export procedures and functions in such common modules must not contain mutable type parameters ( DirectoryObject, DocumentObject etc.), since their transfer from (or to) the client code is impossible.

See also:Restriction on setting the "Server call" flag for common modules

2.3. Client Shared Modules contain client business logic (functionality defined only for the client) and have the following characteristics:

• Client (managed application)
• Client (regular application)

The exception is when client procedures and functions should only be available in managed application mode (only in normal application mode or only in outbound mode). In such cases, another combination of these two features is acceptable.

Client common modules are named with a postfix "Client".
For example: WorkFilesClient, General PurposeCustomer

See also: minimizing client-side code

2.4. In some cases, it is possible to create client-server common modules with procedures and functions, the content of which is the same on both the server and the client. Such procedures and functions are placed in common modules with features:

• Client (managed application)
• Server(checkbox Server call reset)
• Client (regular application)
• Outer join

Common modules of this kind are named with a postfix "ClientServer".
For example: WorkFilesClient, General PurposeClientServer

In general, it is not recommended to define common modules for the server and the client (managed application) at the same time. The functionality defined for the client and for the server is recommended to be implemented in different common modules - see p. 2.1 and 2.3. Such an explicit separation of client and server business logic is dictated by considerations of increasing the modularity of the applied solution, simplifying the developer's control over client-server interaction and reducing the risk of errors due to fundamental differences in the requirements for developing client and server code (the need to minimize the code executed on the client , different availability of objects and platform types, etc.). At the same time, one must keep in mind the inevitable increase in the number of common modules in the configuration.

A special case of mixed client-server modules are form and command modules, which are specifically designed to implement server and client business logic in one module.

3.1. The names of common modules are recommended to be built according to the general rules for naming metadata objects. The name of a common module must match the name of a subsystem or a separate mechanism whose procedures and functions it implements. It is recommended to avoid such common words as "Procedures", "Functions", "Handlers", "Module", "Functionality", etc. in the names of common modules. and apply them only in exceptional cases, when they more fully reveal the purpose of the module.

In order to distinguish between common modules of one subsystem that are created to implement procedures and functions performed in different contexts, it is recommended to give them postfixes described earlier in paragraphs. 2.1-2.4.

In new versions of 1C:Enterprise system configurations, many functions and procedures have been moved from object modules (documents, directories, etc.) to manager modules. Let's take a look at the differences between these two modules.

According to the theory of object-oriented programming, methods of objects are divided into two groups: static and simple. Simple methods only have access to a specific instance of the class. Static methods do not have access to object data, but operate on the class as a whole.

If we translate all this into terms of the 1C: Enterprise system, then Object module contains simple methods. To use them, you first need to get a specific object: an element of a directory, document, etc. Manager module contains static methods. To use it, there is no need to separately obtain each specific object, it allows you to work with the entire collection at once.

Object module may have procedures and functions that can be used externally. To do this, such a procedure or function is denoted by the word Export.

Function NewFunction() Export

In order to use such a function from an object module, you must first, having a reference to the required object, get it using the function GetObject().

Per= Object. NewFunction() ;

Similarly, you can create new variables that can be used from various configuration objects.

Variable NewVariable Export

DirectoryItem = Directories. Nomenclature. FindByCode("000000001" ) ;
Object = Directory Element. GetObject() ;
An object. NewVariable= ) ;

Thus it is possible to supplement standard procedures, functions and properties (variables) of objects. Such variables are dynamic, they are not stored in the infobase and exist only while working with the received object.

Manager module has all the same features, the only difference is that you do not need to get a specific object to use it, the manager module allows you to work with the entire collection of objects of a certain type.

Procedure NewProcedure() Export

DirectoryItem = Directories. Nomenclature. NewProcedure() ;

Or for a variable:

Variable NewVariable Export

DirectoryItem = Directories. Nomenclature. newVariable;

Let's consider the differences in the use of the object module and the manager module on the example of the procedure for creating a printed form of a document.

When using the object module, the code would look like this:

Function PrintDocument (Link) Export
//This function must be passed a link to a specific document
Return TabDoc;
EndFunctions

On the document form, you need to create a procedure that would pass a link to the document to the print function.

&AtClient
Procedure Print(Command)
TabDoc = PrintOnServer() ;
TabDoc. Show() ;
EndProcedure
&On server
Function PrintOnServer()
Doc = FormAttributeToValue("Object" ) ;
Return Doc. PrintDocument(Object. Link) ;
EndFunctions

The disadvantage of this method is that it only allows you to print one object. If you need to print several documents at once, then you need to get each of them, and then call the function from the object module. This requires significant system resources, since when an object is received, it fits entirely into RAM.

From a performance standpoint, it's much better to use the manager module whenever possible. In our example, the solution to the problem will look like this.
Function PrintOnServer()
Return Documents. OurDocument. PrintDocument(ArrayReferences) ;
EndFunctions

In the case of using the manager module, the print procedure can be called both from the document form and from the list form, passing links to several documents in the array. In this case, the system does not need to receive each document from the array, which significantly saves system resources.

So when should you use the object module and when should you use the manager module?

Everything depends on the task. If a reference to an object is sufficient for its execution (for example, a print task), then it is better to use the manager module. If the task is to change the data, for example, filling out a document, then you need to get it and use the object module.

Program 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. Also in program modules we can describe our own methods (procedures and functions).

Typically, a software module consists of three sections:

• variable declaration area;
• procedure and function description area;
• main text of the program.

An example of the structure of a program module:

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

Rem Surname Export; / /this is a global variable
Variable Name, Patronymic; //this is a module variable
Change name; //this is also a module variable and can be accessed

//from any procedure and function of our module

//*************** PROCEDURE AND FUNCTION DESCRIPTION AREA ****************

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

Total = Surname + "" + First name + " "+ Patronymic;

EndProcedure

Function Function1 ()

// function statements

Return(Last name + " " + First name );

EndFunctions

//************************* PROGRAM MAIN TEXT *********************

Surname = "Ivanov";
Name = "Ivan";
Middle name = "Ivanovich";

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

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

Description area of ​​procedures and functions is placed from the first statement of a Procedure or a Function statement to any executable statement outside the body of a procedure or function declaration.

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 area of ​​the main text of the program is executed at the time of module initialization. Usually, in the main program section, it makes sense to place statements to initialize variables with some specific values ​​that must be assigned before the first call to the procedures or functions of the module.

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

Each separate program module is perceived by the system as a whole, so all the procedures and functions of the program module are executed in a single context.

The execution context of modules is divided into client and server contexts. In addition, some software modules can be compiled both on the client side and on 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 you start an application, you can update some configuration data, and when you exit, you can ask if you should exit the program at all. In addition, this module intercepts events from external equipment, such as trading or fiscal equipment. It is worth noting that the application module is executed only in the case of an interactive launch of the application, that is, when the program window is launched. This does not happen if the application is launched in mode com connections.
There are two different application modules in the 1C 8 platform. These are the Common Application module and the Managed Application module. They are triggered when different clients are started. For example, the Managed Application module is triggered when the web client is launched, thin client and thick client in managed application mode. And the regular application module is triggered when the thick client is launched in the normal application mode. The application launch mode setting is set in the "Main launch mode" configuration property.

The 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 severely restricts us from using many types of data. You can extend the context of an application module with the methods of shared modules that have the Call Server property set. All variables and methods of the application program module marked as export will be available in any client-side configuration module. 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 startup time.

As noted above, the application module handles the start and end events of the application. To handle each of these events in the application module, there are a couple of handlers Before ... and When ... The differences between them are as follows: when the code in the handler Before ... is executed, the action has not yet taken place and we can refuse to execute it. This is what the Refusal 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 handles 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, the program works with information base and the application window does not open, which imposes certain restrictions on the use of methods intended for interactive work. In this mode, you cannot use calls to dialog forms, warnings and messages to the user, etc. They simply won't run.

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

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

This is a highly specialized module designed solely to initialize 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 various modes(causing either a managed application module, a normal application module, or an outer connection module to execute), and session parameters must be initialized regardless of the startup mode. In order not to write the same program code in all three of these modules, we needed additional module, which is executed regardless of the application's startup mode.

There is one single "SetSessionParameters" event in the session module, which is fired very first, even before the application module's PreSystemBegin event. It does not have a variable declaration section and a main program section. And also it is impossible to declare export methods. The module is compiled on the server side.

General modules

• may contain an area for describing procedures and functions
• executed on the server or client side (depends on module settings)
• located in the branch of the tree of 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 body of the program. 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 declaration section is not available, it is not possible to define global variables in shared modules. You can use the application module for this.

The behavior of a shared 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 shared modules:

It is good practice not to use the "Global" flag everywhere. This will reduce the application startup time, as well as 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 performed in different contexts, and if such methods are nevertheless required, then a separate common module can be allocated for them;
- the "Server call" flag makes sense only if the module is compiled "On the server". Therefore, all other compilation flags should be removed in order to avoid various problems;
- if in the module methods there is a mass processing of data, 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
• performed on the server and client side

The form module is designed to process user actions with this form (handling the button click event, changing the form attribute, etc.). There are also events related directly to the form itself (for example, its opening or closing). Modules of managed and regular forms differ primarily in that the module managed form clearly separated by 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 the usual form, all code is executed on the client side.

The managed form structure contains a variable declaration section, descriptions of procedures and functions, and the body of the program (executed when the form is initialized). 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 the form has the 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
• performed on the server side

This module is available for most configuration objects and is intended, in general, to process events directly related to the object. For example, events of recording and deleting objects, checking that the details of an object are filled in, posting a document, etc.

Some object module events duplicate form module events. For example, events related to the record. However, it should be understood that the events of the form module will only be executed on 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 time of program 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
• performed 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 extend the functionality of an object by introducing (writing) procedures and functions that do not refer to a specific instance of the database object, but to the configuration object itself. The object manager module allows you to place common procedures and functions for a given object and access them from outside, for example, from processing (of course, if this procedure or function is with the Export keyword). What does this give us new? In general, nothing but organizing procedures by objects and storing them in separate places - Object Manager Modules. We can just as well place these procedures and functions in common modules, but 1C advises placing common procedures and functions of objects in the Object Manager Module. Examples of using the procedures and functions of the Object Managers Module: initial filling of individual details of a directory or document under certain conditions, checking the filling 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 configuration as a whole. Each command has a command module in which you can describe a predefined CommandProcess() procedure for executing that command.

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 both in the properties of the 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 declaration section and a main program section. For example, Session Module and any General Module.

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

Application module

The module is designed to catch the moments of application launch (configuration loading) and its completion. And in the corresponding events, you can arrange the verification procedures. For example, at the start of the application, update any configuration reference data, at the end of the work, ask if it is worth leaving it at all, maybe the work day has not ended yet. In addition, it intercepts events from external equipment, such as trading or fiscal equipment. It is worth noting that the application module intercepts the described events only in the case of an interactive launch. 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 Common Application module and the Managed Application module. They are triggered when different clients are started. This is how the managed application module fires 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 the normal application mode.

All sections can be placed in the application module - 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 severely limits us in the availability of many types of data. You can extend the context of an application module with the methods of shared modules that have the Call Server property set. All variables and methods that are marked as export will be available in any client-side configuration module. However, as tempting as it is, don't put too many methods here. The more code it contains, the longer the compilation time, and, consequently, the application startup time, which is very annoying for users.

As noted above, the application module handles the start and end events of the application. To handle each of these events in the application module, there are a couple of handlers Before ... and When ... The difference between them is that when the code in the handler Before ... is executed, the action has not yet taken place and we can refuse to execute it. This is what the Refusal 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 handles 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 not an interactive process. In this mode, programmatic work with the infobase occurs and the application window does not open, which imposes certain restrictions on the use of methods intended for interactive work. In this mode, you cannot use dialog form calls, warning messages, etc. 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 takes place 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 the initialization of 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 can be launched under different clients (which leads to the execution of various application modules or external connection module), and session parameters must be initialized in any launch mode. Therefore, an additional module was required, which is executed in any application launch mode.

There is a single "SetSessionParameters" event in the session module, which is fired very first, even before the application module's PreSystemBegin event. It does not have a variable declaration section and a main program section. And also it is impossible to declare export methods. The module is compiled on the server side.

Avoid the temptation that this module is executed every time the application starts, and place in it code 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 when we access non-initialized parameters. And although it is possible to catch the moment of the first launch of this event (RequiredParameters has the Undefined type), however, it should be noted that this module is compiled in privileged mode, i.e. it does not control access rights. And the second point, we still cannot be one hundred percent sure that the system will be launched. Suddenly, the application module will fail, and we are trying to perform some action with the database.

General modules

The modules are intended to describe some common algorithms that will be called from other configuration modules. The general module does not contain a variable declaration 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 declaration section is not available, it is not possible to define global variables in shared modules. To do this, you need to use the functions of common modules with return value caching or an application module. It should be borne 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 the cached values ​​does not exceed 20 minutes from the moment they were last accessed.
The behavior of a shared 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 property flags are set unreasonably. This is a topic for a separate article. Let's dwell on just a few points that should be followed when setting flags:

• It's a good rule of thumb not to use the "Global" flag everywhere. This will reduce the application startup time, as well as 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 performed in different contexts, and if such methods are nevertheless required, then a separate common module can be allocated for them.
• The "Call Server" flag is only meaningful if the module is compiled "On the server". Therefore, all other compilation flags should be removed in order to avoid various problems.
• If in the module methods there is a bulk 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

It is intended to process user actions, i.e. various events related to data entry and processing of the correctness of their entry. Module regular shape compiled entirely on the client. A managed form module, on the other hand, 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. In the form module, sections for describing variables and methods are available, as well as a section for the main program.

Object module

This module is typical for many configuration objects and is intended, in general, for processing object events. For example, the events of writing and deleting objects, the event of posting documents, etc.

Some object module events duplicate form module events. For example, events related to the record. However, it should be understood that the events of the form module will only be executed on a particular form object. 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 time of program work with the object. Therefore, if it is necessary 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. With the help of 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 at the time of input by line and to expand the manager's functionality. The module is compiled on the server side. It is possible to define export properties and methods. Calling the manager's export methods does not require the creation of the object itself.

To all of the above, you can add a picture of some configuration modules and methods of mutual method calls in managed application mode. The arrow indicates the direction in which you can go 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 scheme: O.M. Client - Client common module; O.M. Server - Server common module; M.F. Client - Client procedures of the form module; M.F. Server - Server procedures of the form module.