Directory "GeneralExternalComponents" — Technical Description

1. Identification

Purpose. The catalog is designed for centralized storage and versioning of external components (DLL, OCX/COM, ZIP packages Native API) that extend the functionality of the configuration through external libraries. Typical use cases in the RK: working with electronic digital signatures (cryptoproviders), generating and signing electronic documents — electronic invoice (ESF) (ESF IS) and SN, exchanging with government systems, reading specific data formats. The catalog is filled and maintained automatically by the BSP subsystem during the initialization/update of the information base, as well as programmatically — when searching for and connecting the required version of the component to the client or server. Ordinary users do not work with it directly; access is available to administrators and developers through service interfaces.

Where to find in 1C: section "Administration" → "Maintenance" / BSP service processing. Direct navigation link:

e1cib/list/Catalog.CommonExternalComponents

2. Header Attributes and Table Parts

2.1 Header Attributes

The standard attribute Name is used as a human-readable representation of the element in lists; Code — standard numeric/string code of the catalog.

2.2 Table Parts

The catalog does not contain table parts. All information is stored in the header attributes of the element. The absence of table parts is typical for service catalogs of BSP storages: one version of the component = one catalog element.

3. Forms

In the object's metadata, custom forms are not defined (the array of forms is empty). The catalog uses automatically generated platform forms for the element, list, and selection. Specialized UI is not required, as work with components is done programmatically — through the catalog manager module and common modules of the BSP subsystem "ConnectingExternalComponents". Management of filling (loading/updating versions) is performed by service processing, not manual input.

4. Key Module Procedures

The object's own BSL code in evidence is not attached. Below are typical handlers and API of this type of object as part of the BSP mechanism "External Components". Specific lines are clarified by the delivery code.

Object module / catalog manager module:

• CheckFillingProcessing — checks the filling of mandatory attributes Identifier and Version before writing.
• BeforeWriting — controls the correctness of the version and content of ComponentStorage.
• Search functions: obtaining an element by identifier (analogous to FindByIdentifier) and selecting the current version by VersionDate/Version.

Common BSP modules (external API for working with the catalog):

• ConnectingExternalComponents / ConnectingExternalComponentsClient — connecting the component to the client or server, parsing TargetPlatforms and selecting the build for the current architecture.
• ConnectingExternalComponentsService — extracting binary content from ComponentStorage, placing it in temporary storage/directory, checking version compatibility.
• Loading/updating procedures — creating and updating catalog elements when delivering new versions of components.

5. Posting and Movements

The catalog is not a document and does not participate in posting — it does not generate movements in accumulation, summary, and accounting registers. It is a service storage of binary data.

Accordingly, for this object there are no postings according to the standard chart of accounts of the RK. The component only provides the technical side of processes, the results of which are reflected by other objects. For example, when generating and sending electronic invoices (ESF)/SN, signing is performed by the cryptocomponent from this catalog, while the actual implementation is carried out by the registering document and generates standard movements for the RK — for example (for summary, not related to the catalog):

• Dr 1210 "Short-term accounts receivable from customers" — Cr 6010 "Revenue from sales";
• Dr 7010 "Cost of sales" — Cr 1330 "Goods";
• Dr 1210 — Cr 3130 "VAT payable" at a rate of 16% (current VAT rate of the RK for 2026);
• receipt of payment: Dr 1030 "Cash in current accounts" — Cr 1210;
• settlements with suppliers: Dr 1330 — Cr 3310 "Short-term accounts payable to suppliers".

These movements generate documents of sales/receipts, not the catalog of external components.

6. Related Objects and Input Based On

• Input based on for the service catalog is not provided — neither as a basis nor on its basis are documents entered.
• Consumers of the component: electronic document management subsystems (ESF, SN), EDS/encryption mechanisms, exchange with government systems. They access the catalog through the BSP API, without having direct reference links in the attributes.
• Data connection: service processing for maintenance and the mechanism for updating the IB, which fill and update elements.

7. Extension Points

• Loading/updating components — procedures of common modules ConnectingExternalComponents* (registration of a new version, replacement of content in ComponentStorage).
• Logic for selecting version/platform — rules for parsing TargetPlatforms and selecting the current build by Version/VersionDate.
• Configuration extensions — adding custom attributes (e.g., certified build flag, link to source) and subscriptions to events BeforeWriting/CheckFillingProcessing without removing the object from support.
• Access rights — restricting work with the catalog to the administrator role; in the user interface, the element is generally hidden.

Requires verification (version-specific for 3.0.74.2): the exact composition and names of common BSP modules servicing the catalog, and the presence/absence of managed forms — clarified by the specific delivery release.