The structure of a program module in 1c consists of. Common modules. Project data can be entered into the system in several ways

Any program consists of program code, that is, actually from the sequence of actions written in any language that must be performed.

However, this very program must be written somewhere, that is, somewhere to be. In most cases, the program code is written in ordinary text files. The only difference is that the extension in them is not .txt, but .cpp or .php.

Where is the 1C program written?

What is 1C Module?

Of course, the 1C code could also be written in some text file. However, there is the concept of 1C Configuration - which includes not only a list of settings, form templates and other things, but also the 1C program code. Therefore, the 1C code is stored in the configuration.

The configuration consists of 1C objects, as we have already discussed in previous lessons. Each 1C object contains nested objects, for example, a directory has several forms.

Each 1C object, including some nested ones, has its own Module - a certain text file which contains the program code.

There are also object-independent modules in which object-independent program code can be written.

Thus, there is no "single" program in 1C. There is a set of modules for writing program code for each 1C configuration object.

How are 1C Modules used?

The entire program can be roughly divided into two types:

Object method
Reaction to events.

Methods... As we said earlier, a 1C object is an integral structure that includes both data and methods of processing it. These methods are a set of actions (methods) that can be called to process data. An example of such an action DirectoryObject.Write () - writes a dictionary item to the database.

Methods of many 1C objects can be standard (i.e. programmed in the 1C platform) and written by a programmer in the 1C language. With the help of the second, you can expand the functionality of 1C objects at will.

Developments... Events are found in many other development tools. The purpose of the program is not only to compute something at startup, but also to keep the user working.

Custom Events - The user pressed the button. In response, some part of the code will be executed, reacting to user actions.

System events - we have written the 1C object to the database. The system event "Object recording" has occurred. It is possible to configure the reaction that will occur to events caused not by the user (who pressed the button or did something else), but by the system itself. A striking example of such an event is when the program starts.

The order of execution of 1C modules

In many languages there is such a thing as "entry point". This is the very first line or function that will be executed when the program starts.

There are several such entry points in 1C - for each type of client. That is, when you start a thick client, the entry point is one, when you start a thin client, it is different. This allows you to program features that are different for different types of clients.

The entry point in the corresponding module is the handlers of the system events BeforeSystemWorkingStart () and AtSystemWhenStarting (), respectively (i.e., in order). These functions are executed first, they can start something automatically.

If nothing was started automatically, then the 1C interface opens in front of the user and then everything depends on it. He clicks on a button - the handler for pressing this button is executed (which, in turn, can also start something automatically).

Working with 1C modules

Produced in the configurator. The module can be opened using the Configuration window.

Today we will figure out what the common modules are, what they are, why they are needed and how to use them. In a common module, you can take out functions that are used in several documents. For example, calculating the amount in the tabular section of the document.

Let's take our old configuration that I used in previous articles as an example. We have two documents in it: Arrival of goods to the warehouse and Release of goods to the warehouse. Both documents have procedures that calculate the amount in the row of the tabular section.

Each document contains the same code for calculating the amount.

Procedure MaterialsPriceOnChange (Item)
TabularSectionRow = Items.Materials.CurrentData;
TabularSectionRow.Sum = TabularSectionRow.Quantity * TabularSectionRow.Price;
End of Procedure

Today we will transfer it to the general module, and from the document we will call it.

We create a general module for calculating the amount

And so let's start, first you need to create a common module. To do this, go to the configurator, look for the General modules item, click right click and add a new one, write the name WorkSDokumentami. We enter the following code into it.

Also, be sure to check the boxes opposite Client (Managed Application) and Server in the properties window.

Now you need to slightly change the code in the document form module. On the left in the configuration, we are looking for the document Arrival of goods, expand the windows to the Forms window, double-click on the Document Form and in the form window that opens, go to the Module tab below. We have a code like this

This procedure works when you change the Quantity in the tabular section of the document Receipt of goods and calculates the amount.

& OnClient

End of Procedure

And this procedure starts to work when the price changes in the tabular section of the document Arrival of goods and calculates the amount.

& OnClient

TabularSectionRow = Items.Materials.CurrentData;
TabularSectionRow.Sum = TabularSectionRow.Quantity * TabularSectionRow.Price;
End of Procedure

We replace it with this

& OnClient
Procedure Materials Quantity On Change (Item)
TabularSectionRow = Items.Materials.CurrentData;

End of Procedure
& OnClient
Procedure MaterialsPriceOnChange (Item)
TabularSectionRow = Items.Materials.CurrentData;
WorkWithDocuments.CalculateSum (TabularSectionRow);
End of Procedure

As you have noticed, only one line changes at first glance, it may seem that one line has been replaced by another. But don't forget that this is an example. In fact, the amount of code can be much more if, for example, you performed calculations using a complex formula, in this case the code will be noticeably reduced.

We do the same for the document Release of goods from the warehouse, run and check the functionality of the code. Here we are with you and made the first common module, I hope my article will be useful to someone.

Print (Ctrl + P)

Objects located in the General modules configuration tree branch are intended to contain texts of functions and procedures that can be called from any other configuration module.
ATTENTION! A common module can only contain definitions of procedures and functions.
Common module procedures and functions for which the headings indicate keyword Exports are one of the constituent parts of the global context. You can learn more about writing procedures in a common module in the sections "Format of source codes of program modules" and "Operators" in the help for the embedded language.
To edit a common module, in the properties palette of an object of the Common Modules type of the Configuration window, in the Module property, click the Open link. The text of the general module will be issued for editing in the text editor of the 1C: Enterprise system in the mode of editing the text of the program module.
The common module, being part of the configuration, is stored only as part of the configuration.
The Global property determines whether the exported methods of the shared module are part of the global context.
If the Global property is set to True, the exported methods of the common module are available as methods of the global context.
If the Global property is set to False, then a property is created in the global context with a name that matches the name of the common module in the metadata. This property is read-only. The value of this property is the CommonModule object. The exported methods of this common module are available through this object. Thus, calling the methods of non-global common modules looks like XXXXX.YYYYY, where XXXXX is the name of the property corresponding to the context of the common module, and YYYYY is the name of the exported method of the common module.
Example:

WorkSales Equipment.ConnectBarcode Scanner ();

Different context and common modules

Using the properties of common modules and preprocessor instructions, you can organize the execution of various methods of common modules in the desired context.
Each property of a common module is responsible for compiling (and executing) a common module in a particular context.
The following properties are available that are responsible for the context in which the methods of the common module are available:
● Client (regular application)- methods of the common module will be available for the fat client in the normal application mode;
● - methods of the common module will be available for the thin client, web client, as well as for the thick client in
managed application mode;
● Server - methods of the common module will be available on the server;
● External connection- the methods of the common module will be available in the outer join.
If several properties are set at the same time, this means that the methods of the common module will be available in several contexts.
If a common module has the Server property and some other property set, this means that the common module will be available simultaneously on the server and in the selected client. It should be understood that in fact it will be several versions of the compiled code (according to the number of selected clients and for the server itself).
In this case, if the method located in such a common module is called from the client side, then the client copy of the common module will be used, and if from the server - the server copy. In this case, using preprocessor directives (see details here), you can "shield" the server from the code that cannot be executed on it.
Let's look at an example. In a common module (which can run on the thin client and on the server), there is a method that has slightly different behavior on the thin client and server side. Let's see how you can do this:

# If Thin Client Then
// Show a warning
Show User Alert(“On the client”);
# EndIf
End of Procedure
Then, on the server side, the code will look like this:
Procedure CommonModule () Method Export
// Various important code goes here
End of Procedure
On the thin client side, the code will look like this:
ProcedureCommonModuleMethod () Export
// Various important code goes here
// Show a warning
ShowUserNotification (“On client”);
End of Procedure

There are several ways to transfer control from the client to the server:
● call a method of the server common module;
● call a method in a form or command module, which is preceded by compilation directives & AtServer, & AtServerWithout Context

At the same time, it is impossible to call methods of client common modules (for which the Server property is not set) and client methods of a form module or a command module from server procedures. Control will return to the client after the outermost call to the server method completes.
The exception is the methods of the form module and the command module, which are preceded by compilation directives. & OnClientOnServer, & OnClientOnServerWithout Context
Also worth mentioning the following points:
● If a common module is available to more than one client, then when writing the code, consider the maximum restrictions that clients may impose, or use preprocessor instructions to "isolate" client-specific code.
● The preprocessor instructions also make sense when one common module has several execution contexts, for example, an external connection and a thin client or (which is much more common) a client and server. In this case, the preprocessor instructions will frame interactive code that cannot be used on the server, but is possible on the client (see example above).
For more information on preprocessor instructions and compilation directives, see the Executing Procedures and Functions section of the embedded language help.
The Call server property is used to control the ability to call the exported methods of the server common module from the client code.
If the property is set, then the exported methods of the server common module are available for call from the client. If the property is not set, then such exported methods can only be called from server-side methods (both methods of server-side common modules and server-side methods of the form module and command modules).
Advice . It is recommended to set the Call server property to False in cases where the server common module contains methods that you do not want to call from the client (for example, for security reasons).
Note... If properties are set at the same time Client (regular application), Client (managed application), External connection, then the Server Call property is automatically cleared. If the Call server property is set, then the properties are automatically reset. Client (regular application), Client (managed application) and External connection if these properties were set at the same time.
Property Privileged is intended to disable access control when executing methods of a common module.
NOTE. If the property Privileged is set, then the Server property is automatically set to the common module and the rest of the properties are reset ( Client (regular application), Client (managed application) and in external connection). A privileged shared module can only run on the server.

Reusing return values

If the shared module is not global, then the Return value reuse property becomes available. This property can take the following values:
● Do not use - Reuse of return values is not used for functions of this common module.
● At Call Time and At Session Time — The method for determining data reuse is used for the common module. The essence of this method is that during the execution of the code, the system remembers the parameters and the result of the function after the first call of the function. When the function is called again with the same parameters, the stored value is returned (from the first call) without executing the function itself. If the function changes the values of the parameters during its execution, then a second call of the function will not do this.
The following features of saving call results can be distinguished:
● if the function is executed on the server and is called from the server code, then the parameter values and the call result are stored for the current session on the server side;
● if the function is executed on a thick or thin client, then the values of parameters and call results are stored on the client side;
● if the function is executed on the server side, but is called from the client code, then the values of the call parameters are remembered both on the client side and on the server side (for the current session).
Stored values are deleted:
● if the property is set to At the time of the call:
● on the server side - when control is returned from the server;
● on the client side - when the procedure or function of the embedded language terminates top level(called by the system from the interface, not from another procedure or function of the embedded language);
● if the property of the common module is set to For the duration of the session:
● on the server side - at the end of the session;
● on the client side - when the client application is closed.
The stored values will be deleted:
● on the server, in the fat client, in the external connection, in the thin client and in the web client at normal connection speed - 20 minutes after the stored value is calculated or 6 minutes after the last use.
● in a thin client and a web client with a low connection speed - 20 minutes after calculating the stored value;
● if there is a shortage random access memory in the server workflow;
● when restarting a workflow;
● when a client switches to a different workflow.
After deleting the values, the call to the exported function is performed as in the first call.
This property of common modules does not affect the execution of procedures - procedures are always executed.

If a common module is set to reuse return values, then a number of restrictions are imposed on the parameter types of the exported functions. Parameter types can only be:
● Primitive types ( Undefined, NULL, Boolean, Number, String, Date).
● Any references to database objects.
● Structures with property values of the above types. In this case, the identity of the parameters is controlled "by the content" of the structures.
If the exported function returns any object, then in fact a reference to the object stored in the cache is returned. If, after receiving this reference, a change in the state of the object occurs, then a subsequent call to the same function will result in the return of a reference to the already changed object without actually executing the function. This behavior will continue until the stored value is deleted (for whatever reason). In other words, changing the state of an object resulting from a function call from a shared module with reusing return values is not a reason for an actual function call. It should also be remembered that the cache of returned objects is indifferent to
the state of the privileged mode at the time of the function call with reuse of return values. This feature can lead to the following behavior:
● The actual execution of the function call with reuse of return values (first call) was done with privileged mode enabled.
● When executing the function, an object was received that cannot be received with the privileged mode disabled.
● Subsequent function calls were made without setting the privileged mode.
● However, until the cache of returned objects is cleared or the actual call is repeated, the function will return a formally inaccessible object.
● The opposite behavior is also true, when the first call is made without setting the privileged mode, and in the privileged mode the object that could have been obtained in the privileged mode is not returned.

If a common module has the property Reusing return values is set to For the duration of the session, then values of the type TemporaryTable Manager.
If a function of a common module, with a set reuse, is called from the same common module (for example, with the name CommonModule), then remember the following peculiarity: if the function is called by the name MyFunction (), then the function will be executed every time the function is called ... In order to use the stored values, the function should be called by its full name:
CommonModule.MyFunction ().
The global context method removes all reusable values, both server and client side, regardless of where the method is called. After executing the method RefreshReusedValues () the first call to the function will be executed completely.

The module is designed for integration with solutions containing the configuration "ERP Enterprise Management 2". Indispensable for project-oriented enterprises and organizations!

Functionality systems:
Project management Planning the content and timing of the project Scheduling of volumes and deliveries of the project Planning for subcontracting and material costs of the project Personnel and project labor planning Workload and time management by projects Logging actual data and project events Project finance management Dispatching design work Project versioning	Plan-fact analysis of the project Project communications management Knowledge management Project evaluation and contract price calculation Project contract management Project document management Project Risk Management Portfolio and program management Resource management of the project organization

Project data can be entered into the system in several ways:

manually through the project control panel;
load / unload data from / to MS Project;
load data from a template stored in the system;
in a combined way: part by hand, part from MS Project.

You can schedule work in different ways:

so that the project manager manages the project plan, and the functional manager manages the work. Labor resources are allocated taking into account the roles performed;
the project manager manages the project plan and work execution. Labor resources are assigned without regard to roles.

The visual toolkit of the system allows the manager to get information about the project in different views: tabular, data tree, Gantt charts, map of project milestones, network diagram. The system allows you to assign a manager to a specific project task, and automatically its subtasks, different from the project manager as a whole.

The solution is intended for owners of commercial real estate, management companies, construction and development organizations. The product makes it possible to increase the efficiency of companies' business by automating the processes for maintaining the register of real estate objects, managing lease agreements and settlements with tenants, and operating real estate objects. The program provides solutions to problems of accounting, management, legal and administrative accounting.

Solution possibilities:

settlement of accounts with tenants on the basis of issued invoices (planned debt), control of payment of invoices with analytics for objects, services and periods;
separate assignment and control of payment terms for fixed and variable parts of the rent;
the possibility of calculating penalties for late payment on the basis of both actual (according to acts) and planned (according to invoices) debt;
the use of arbitrary formulas to calculate the cost of variable part services (for example, the accrual of interest on the tenant's trade turnover according to various algorithms);

use of several meters of consumption volumes for one variable part service;
the possibility of assigning both individual and uniform tariffs for variable part services;
management of real estate inspections;
the possibility of joint use with the upcoming solutions "ERP Management of a construction organization 2.0" and "Module 1C: Realtor. Real estate sales management for 1C: ERP" within a single configuration.

Possibilities of the solution "Module 1C: Vehicle management for 1C: ERP":

Accounting for orders for vehicles;
Issue and processing of waybills;
Calculation of standard and actual fuel consumption. All algorithms for calculating the standard fuel consumption are implemented in accordance with the order of the Ministry of Transport dated July 14, 2015 N NA-80-r. The solution allows you to keep track of fuel consumption for vehicles with an unlimited number of equipment and trailers.

Accounting for the receipt, consumption and write-off of fuels and lubricants;
Accounting for license plates and batteries;
Integration with satellite monitoring systems.
Calculation of production in waybills for various parameters. The main parameters (mileage, cargo weight, cargo turnover, time in order, idle time, etc.) are predefined in the system. Using the reference books, you can customize any arbitrary production parameters and further analyze this information;

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 ().

There is no variable section in such modules.

The execution of common modules depends on the parameters set 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 the 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 calls on the client to the export functions of this module (to be executed on the server).

Outer join flag

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

Flag "Privileged"

In a module with such a flag, rights checking will be disabled. Suitable for productivity or administration actions.

Reuse option

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

Application module

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

Do 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 the code in different application modules.

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

Best regards, (teacher and developer).