Integration with 1C - External data processors - User

External data processors is a tool for creating modifications to 1C application solutions without changing the typical configuration structure.

All external processing code is stored in separate files with *.epf extension.

If it becomes necessary to extend the functionality of the configuration using processing, then external processing should be used. This will leave the configuration structure unchanged and make it easier to maintain later.

Using external data processor for 1C for Moldova

• External processing as a "regular application" can be used starting from version 1C: 8.1. Allows you to exchange with the directories "Accounts payable" and "Invoice" - details.
• External processing as a "managed application" has been working steadily since version 1C: 8.3. Allows you to exchange with the directories "Accounts payable" and "Invoice" - details.
• External processing as a "regular application" can be used with restrictions for certain configurations 1C: 7.7 Allows you to exchange with the directory "Accounts payable" - details.

To open external processing in 1C, you need to perform the following sequence of actions:

• Transfer the external processing file to the server
• Connect external processing
• Open external processing form

To upload a file to the server, it must be placed in temporary storage. To do this, first on the client, in the external processing open command handler, we place the file from the local file system into temporary storage using the ПоместитьФайл() (en. PlaceFile()) global context method.

External processing can be called in 2 ways:

• call whenever the need arises see details here
• add external processing to the 1C menu

Choose from a regular or managed app

The choice of a regular or managed application indicates to the 1C platform:

• what forms to display information you need to run (regular or managed);
• which "client application" will be used by default ("thick client" or "thin client").

We can say that a regular and managed application are types of launching the 1C system.

Integration of e-Cont.md with 1C:8 using the "Forms" interface mechanism.

In this case, no configuration changes are made.

Forms can be of two types: "Unmanaged Forms" and "Managed Forms".

We offer an integration module with 1C:8 starting from versions 8.2.

For information, integration with 1C: 7.7 is not supported.

The best results for forming forms will be obtained when working in the "Taxi" interface, which is available starting from version 1C:8.2.

Unmanaged and Managed forms in 1C:8

• "Unmanaged forms" for 1C:8.2

  Up to version 1C:8.2 inclusive, the 1C: 8 system used the so-called "Unmanaged Forms" ("Ordinary Forms"), which were developed at a fairly low level of the application architecture. It was like developing web forms in the HTML markup language.

• "Managed forms" for 1C:8.3 and higher

  Starting with version 1C:8.3, you can create "Managed Forms" in managed application mode. These forms operate in different modes and separate application execution into client and server parts. The creation of such Managed forms is possible in the program designer mode, which allows you to create "Forms" from a set of building blocks. At the same time, a significant part of the work of validating form data and protecting the application from erroneous or malicious use is done by the application itself, both on the client side and on the server side. In version 1C:8.3, it is still possible to use "Unmanaged Forms".

Information for developers

For ordinary users, the managed form of the 1C document differs from the usual one only in appearance. For the developer, this is a new mechanism with its own rules, laws and conditions. Many areas have undergone a change, but the following innovations are considered key among experienced 1C developers:

• Independent formation of the form structure and placement of fields by the platform. If earlier developers described the position of the field by specifying pixels, now it is only possible to specify the type of grouping;
• The form consists of attributes representing the form data, and commands - procedures and functions performed;
• The form code is executed on both the server and client sides. After all, the form itself is a configuration object created on the server and displayed on the client. This means that it combines the client and server parts;
• On the client side, many types of data have become unavailable and now there is no way to change the data in the infobase;
• For each procedure or function, a special setting must be specified - a compilation directive. It is responsible for the place where the code is executed and can take the following values:
  • Наклиенте;
  • НаСервере;
  • НаСервереБезКонтекста;
  • НаКлиентеНаСервере;
  • НаКлиентеНаСервереБезКонтекста.

External data processors in 1C - Information for developers