Guide "Electronic Signature and Encryption Programs" — Technical Description

1. Identification

Purpose. The catalog is intended for centralized storage and management of settings for cryptographic providers (electronic signature and encryption programs) used in the system for signing electronic documents and encrypting data. It stores a list of both built-in (supplied with the configuration) and third-party cryptographic programs, indicating their technical names, types, as well as signature, hashing, and encryption algorithms.

It is used by administrators and those responsible for electronic document management during the initial setup of the system, as well as when transitioning to new cryptographic providers (for example, when regulatory requirements for algorithms change). The frequency of use is episodic: setup during implementation and when changing cryptographic requirements.

In the context of "Accounting for Kazakhstan," the catalog facilitates working with electronic signatures when exchanging electronic documents: issuing/receiving electronic invoices (ESF) (ESF IS) and statements, as well as when signing other regulated electronic documents.

Where to find in 1C: section "Administration" / "Standard subsystems" → "Electronic signature and encryption programs".

Navigation link: e1cib/list/Catalog.ElectronicSignatureAndEncryptionPrograms

Accessing the catalog usually occurs through the general electronic signature settings form, rather than through the standard list, which provides a single point of control for the cryptographic subsystem.

2. Header Attributes and Table Parts

2.1 Header Attributes

Standard attributes: Code, Name, DeletionMark, Predefined. Built-in cryptographic providers are usually defined as predefined elements.

2.2 Table Parts

The catalog does not have table parts — all information is stored in the header attributes of the element.

3. Forms

The catalog contains 5 forms. Three key forms are detailed in the evidence:

4. Key Module Procedures

The attached evidence does not contain BSL exports (path: string). Below are typical handlers for catalogs of this type within the "Electronic signature and encryption" subsystem of BSP; specific names/existence of procedures require verification against the modules of the current version 3.0.74.2.

Object Module (CatalogObject.ObjectModule):

• FillProcessing — filling in the attributes of a new element with default values (program type, algorithms) when created from a provider template.
• FillCheckProcessing — control of mandatory attributes (ProgramName, ProgramType, three algorithms). For elements with the attribute IsBuiltInProvider = True, some checks are skipped (mandatory requirement is lowered to DontCheck).
• BeforeWrite — normalization/control of the uniqueness of the technical name of the program, protection of predefined built-in providers from incorrect modification.

Form Module ElementForm:

• OnCreateOnServer — setting the availability of fields: for built-in cryptographic providers, fields are switched to view mode, for third-party ones — opened for editing.
• Handlers for setting/removing the deletion mark.

Form Module ErrorAccessingProgram:

• Filling the table with diagnostic errors received from the cryptographic subsystem.
• Commands: setting the extension for working with cryptography in the browser/client, going to electronic signature settings, closing the form.

Manager Level Logic / General Modules of the Subsystem:

• Searching and selecting the appropriate cryptographic provider by certificate algorithms (interaction with ElectronicSignature, ElectronicSignatureService BSP).
• Considering UsageMode when selecting available programs (excluding those prohibited by the administrator).

5. Posting and Movements

The catalog is not a document: it is not posted and does not generate movements in registers (accumulation/summary/accounting), and does not generate accounting entries. It is a configuration (regulatory and reference) object of the cryptographic subsystem.

Impact on accounting — indirect: the selected cryptographic provider ensures correct signing/encryption of electronic documents (ESF, statements), the posting of which already generates corresponding movements. For reference, according to the typical chart of accounts of the RK, documents of sales/purchases generate entries of the following types:

• Dr 1210 Cr 6010 — reflecting income from sales to the customer;
• Dr 3130 (VAT payable) — VAT accrual at a rate of 16% (Kazakhstan rate for 2026);
• Dr 7010 Cr 1330 — write-off of the cost of sold goods;
• Dr 1030 Cr 1210 — receipt of payment to the current account;
• Dr 1330 Cr 3310 — receipt of goods from the supplier.

All amounts are in tenge (₸). The catalog itself does not participate in these movements — it only configures the means for signing documents that initiate postings.

Reference values for RK in 2026 (for context of the configuration, not for this object): MRP = 4,325 ₸, MZP = 85,000 ₸, VAT rate 16%, basic tax deduction for individual income tax — 30 MRP/month (not more than 360 MRP/year), individual income tax 10% up to 8,500 MRP of annual income and 15% above; OPE 10% (base ceiling 50 MZP), OPEW 3.5%, VOSMS 2%, OSMS 3%, CO 5%, social tax 6%.

6. Related Objects and Input Based On

Input Based On: not provided for the catalog (it is not a source/receiver of the "Input Based On" mechanism).

Related Objects and Subsystems:

7. Extension Points

• Adding a third-party cryptographic provider. Creating a new element by filling in ProgramName, ProgramType, and three algorithms; IsBuiltInProvider = False.
• Managing availability. The attribute UsageMode — programmatic/administrative permission or prohibition of the program without deleting it.
• Extending the configuration (without removing from support). Subscriptions to events BeforeWrite / FillCheckProcessing of the object module for additional validation (for example, an allowed list of algorithms under RK requirements).
• Overridable BSP modules. Using standard points of the "Electronic signature and encryption" subsystem (...Overridable) to configure the behavior of selection and verification of providers.
• Diagnostics. Form ErrorAccessingProgram — an extension point for scenarios of setting cryptography extension and going to settings in case of failures when accessing the provider.

Version-specific (requires verification for 3.0.74.2): the exact composition of predefined built-in providers, the presence/names of BSL handlers, and the complete list of values of the enumeration UsageModesOfElectronicSignatureProgram.