Directory "Certificates of Electronic Signature and Encryption Keys" (Accounting for Kazakhstan 3.0.74.2)

1. Identification of the object

Purpose. The directory stores information about certificates of electronic signature (ES) and encryption keys used for signing and protecting electronic documents in accordance with the legislation of the Republic of Kazakhstan. The records of the directory store the public part of the certificate (X.509) and service attributes; the private key is not stored in the information base — it remains in the cryptographic provider/token and is used through the configured cryptography program (typically NCALayer / CryptoPro CSP for the RK). The directory is involved in signing electronic invoices (ESF), tax returns, regulated reporting to government agencies, and exchanging electronic documents with counterparties through secure channels.

Where to find in 1C:

• Navigation link: e1cib/list/Directory.DigitalSignatureAndEncryptionKeysCertificates
• Through the interface: Administration → Electronic signature and encryption settings → tab “Certificates”. When opening the standard list, the user is automatically redirected to this settings form (the “Certificates” page).

2. Header attributes and table parts

2.1 Header attributes

All attributes are optional (the “Check for completion” property is not checked); most fields are filled automatically when reading the certificate data.

Standard attributes Name, Code, DeletionMark are present by default. The Name usually contains the representation of the owner (full name/organization).

2.2 Table parts

The directory does not contain its own table parts — all data is placed in the header attributes. The relationship “certificate ↔ users with signing rights” is maintained by a separate BSP mechanism (information register “Users of electronic signature and encryption keys”), not by a table part of the directory itself.

3. Forms

User access to the directory usually does not go through ListForm, but through Electronic signature and encryption settings (the “Certificates” page), where operations for adding, verifying, and configuring certificates are collected.

4. Key procedures of modules

A separate reference evidence with the BSL code of the modules for this task is not attached, so below are listed typical handlers of this type of BSP object. Specific names/signatures of procedures should be clarified according to the module of the installed assembly 3.0.74.2 — this is the only truly version-specific place in this section.

Object module (ObjectModule):

• BeforeWriting — control of filling Fingerprint/CertificateData, prevention of certificate duplicates by fingerprint.
• CheckFillingProcessing — checks the presence of certificate data and program if necessary.

Manager module (ManagerModule):

• Functions for searching the certificate by fingerprint (FindByFingerprint) and creating an element from certificate data — used by the electronic signature subsystem when adding.

Element form module:

• OnCreateOnServer / OnOpen — reading certificate data from storage, displaying owner attributes and validity period, highlighting expired/revoked.
• Commands CheckCertificate, ShowCertificateData, Renew — calls to client procedures of the electronic signature subsystem (working with the cryptographic provider through the program from the Program attribute).

Common modules of the subsystem (typical for BSP):

• ElectronicSignature / ElectronicSignatureClient / ElectronicSignatureService(Client/Server) — signing, signature verification, encryption/decryption, setting and checking the cryptographic provider.

5. Posting and movements

The directory is not a document and is not posted — it does not generate movements in accumulation registers, accounting registers, and accounting entries. It is a storage object for settings.

The impact of the certificate on accounting is indirect: it is used as a means of signing in documents and electronic document management services. The entries are generated by the documents themselves, which are signed by this certificate. For the context of Kazakhstan-2026:

• Implementation with issuance of ESF (IS ESF) and, if necessary, tax returns. Example entries according to the typical chart of accounts of the RK for the sale of goods for the amount of 1,160,000 ₸ (including VAT 16%):
  • Dr 1210 Cr 6010 — 1,000,000 ₸ (revenue from sales);
  • Dr 1210 Cr 3130 — 160,000 ₸ (VAT payable, rate 16%);
  • Dr 7010 Cr 1330 — write-off of the cost of goods sold.
• Receipt from the supplier with the receipt of incoming ESF: Dr 1330 Cr 3310; Dr 1420 Cr 3310 — “creditable” VAT (if there is a right to credit).
• Payment: Dr 3310 Cr 1030 / Dr 1030 Cr 1210.

The certificate itself does not participate in these entries — it only provides legally significant signing of ESF/tax returns/reporting. Current rates and indicators of the RK for 2026 for related calculations: VAT 16%, MRP 4,325 ₸, MSP 85,000 ₸, basic tax deduction for individual income tax 30 MRP/month (no more than 360 MRP/year), individual income tax 10% up to 8,500 MRP of annual income and 15% above, OPE 10% (ceiling base — 50 MSP), OPEP 3.5%, VOSMS 2%, OSMS 3%, SO 5%, social tax 6%.

6. Related objects and input on the basis

Input on the basis: the directory does not participate in “input on the basis” schemes.

Direct links (by attributes):

• Directory.SignatureAndEncryptionPrograms — cryptography program (attribute Program).
• Directory.Organizations — owning organization (Organization).
• Directory.Individuals — individual owner (Individual).
• Directory.Users — attributes User, AddedBy.

Using subsystems and objects:

• Electronic invoices (ESF, IS ESF) and tax returns — signing when sending.
• Regulated reporting and exchange with government agencies.
• Exchange of electronic documents with counterparties (EDO), including encryption.
• Information register BSP “Users of electronic signature and encryption keys” — matching the certificate and users with signing rights.

7. Extension points

• Configuration extension: adding attributes (for example, internal CA code, key carrier type) and commands to ElementForm; overriding form handlers through annotations &Instead/&After/&Before.
• BSP programming interfaces: using common modules ElectronicSignature, ElectronicSignatureClient, ElectronicSignatureService for signing/verifying in own handlers instead of direct work with the cryptographic provider.
• Event subscriptions: BeforeWriting/OnWriting of the directory — for auditing changes and controlling uniqueness by Fingerprint.
• Additional attributes and information (subsystem “Properties”) — if it is necessary to store arbitrary attributes without modifying metadata.
• Scheduled task for checking expiration dates — notifying owners N days before ValidUntil (typical BSP mechanism; notification logic can be adjusted).