Documents "SigningRoutes" - Technical Description (Accounting for Kazakhstan 3.0.74.2)

1. Identification

Purpose. The object stores rules and schemes for approval (signature routes) of electronic documents before their signing with an electronic signature (EP) and sending to counterparties or government systems (IS ESF, SNT). The route defines who among users, in what order, and with what certificate must sign the document. It is configured and maintained by administrators and chief accountants during the initial setup of the system and when changing the signing regulations in the organization.

Requires verification (version-specific). In the metadata, the object is marked as "Document", however, its actual structure — the presence of a predefined element OneAvailableSignature, form ElementForm, absence of date/amount/movements — is characteristic of a reference book. In certain releases of the line, this object is implemented as a settings reference book. Clarify the type of object in the configurator of the specific build 3.0.74.2; this does not affect the application logic (signature routing).

2. Attributes and Table Parts

2.1 Header Attributes

2.2 Table Part "RequirementsTable"

Purpose. Stores a hierarchical (tree-like) structure of signing requirements: the sequence and logic of approvals (groups "AND", "OR", "InOrder"), specific signers, and their certificates.

Logic of groups in the requirements tree:

• AND — all nested requirements must be signed;
• OR — any of the nested requirements is sufficient;
• InOrder — nested requirements are executed strictly sequentially, according to the attribute Order.

3. Forms

4. Key Module Procedures

BSL text of modules in evidence is not attached. Below are typical handlers for an object of this type (signature route configuration) in BSP configurations; procedure names in the specific build 3.0.74.2 may differ.

Object / Manager Module:

• CheckFillingProcessing — control of the mandatory SigningScheme (ShowError flag) and consistency of the requirements tree (presence of signer/certificate in requirement rows, correctness of links Identifier ↔ ParentIdentifier).
• FillingProcessing — filling in default attributes during interactive creation and when filling by the automatic setup key.
• Procedures for forming and parsing the tree-like structure of requirements (building hierarchy by Identifier/ParentIdentifier/Order).

Form Module "ElementForm":

• Commands for adding groups AND / OR / InOrder and signer — create rows in RequirementsTable with the corresponding value of the attribute Requirement and binding to the parent.
• Move commands (up/down) — manage the Order attribute.
• Handlers for selecting Signer and Certificate — selection of the EP certificate available to the chosen user.

Form Module "ListForm" / "SelectionForm":

• FillInitialSettings — creation of standard (including predefined OneAvailableSignature) routes during initial setup.

Form Module "RouteSelection":

• Loading the route for a specific document, interactive adjustment of the list of signers/certificates, and returning the result to the electronic document signing procedure.

5. Posting and Movements

The object is not an accounting document and does not generate movements in registers. It lacks date, counterparty, monetary attributes, and table parts for goods/services; this is an object of settings for the signing regulations. Accordingly:

• it does not create accounting entries — accounts from the standard chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010) are not applicable to it;
• there are no movements in accumulation registers/information on VAT accounting, mutual settlements, etc.

Tax parameters of the RK for 2026 (VAT rate 16%, MPR 4,325 ₸, MSP 85,000 ₸, individual income tax 10%/15%, deduction on individual income tax 30 MPR/month, etc.) relate to the electronic documents themselves (ESF, SNT, implementation), the signing process of which is regulated by this route, and not to the object SignatureRoutes. The route only determines the order of applying the EP to an already formed document.

The result of applying the route is recorded not here, but in the subsystem of EDM/EP: signing statuses and the electronic signatures themselves are stored in service registers and repositories of EDM, linked to the signed document.

6. Related Objects and Input Based On

Input Based On. For the settings object, input based on is not provided and has no practical meaning. Feedback: the route is used by EDM documents at the moment of their signing (the route is selected/supplied, but a new route is not created from the document).

7. Extension Points

• Configuration Extension: adding handlers CheckFillingProcessing, BeforeWriting in the object module for custom validation rules of the requirements tree.
• Forms: extension of ElementForm and RouteSelection (additional commands, restrictions on selecting signers/certificates by organization).
• Auto-fill: refinement of the command FillInitialSettings and logic for AutomaticSetupKey for replicating standard routes during updates/migrations.
• EDM/EP Programming Interface: overriding the procedure for selecting and applying the route before signing (integration with custom approval regulations, external document management systems).
• Access Rights: through the attribute Organization and RLS — organizational separation of access to routes.