Report "Extension of Electronic Signatures Validity" — Technical Description

1. Identification

Purpose. The report is intended for monitoring and controlling the validity periods of electronic signatures (ES), used in electronic document management. It allows tracking the validity of electronic signature key certificates, identifying signatures with expiring validity, and planning their timely renewal. In the RK context, this is critical for the continuous operation with electronic invoices (ESF) in the ESF information system and accompanying goods waybills (SNT): with an invalid certificate, the sending and signing of these documents is blocked.

Who Uses It. Administrators of the information base, IT department staff, and those responsible for electronic document management. Usage is periodic (weekly/monthly) for proactive control.

Where to Find in 1C. Section for working with electronic signatures (subsystem "Electronic Signature and Encryption" / "Report Options" DCS). Direct access is via the navigation link above.

2. Header Attributes and Table Parts

2.1 Header Attributes

The report does not contain header attributes. As an object of type "Report," it does not store its own data: all parameters (period, selection by certificate owner, organization, ES status) are set through DCS settings and passed dynamically during formation.

2.2 Table Parts

There are no table parts in the metadata. The resulting tabular data is built dynamically by the data composition scheme when the report is executed.

2.3 Parameters and Fields of Composition (Standard Composition)

The following fields are output as results in reports of this kind:

The "Expiring" thresholds are typically set by a parameter (e.g., 30 days). The numerical parameters of the report are calendar-based (days/dates) and are not related to monetary standards.

3. Forms

No custom forms are listed in the metadata. The report uses the standard report form of DCS, generated automatically by the platform. It includes:

• Settings Panel — parameters, selections, groupings, conditional formatting, report variant selection;
• Result Area — generated table (tabular document);
• Command Panel — buttons "Generate," selection and saving of variants, settings, print/save.

If necessary, a custom main report form can be added to the report — then the standard one is replaced by it.

4. Key Module Procedures

Evidence with source code (BSL) for the object is not attached — the object/form module is absent in the provided metadata. Below is the standard set of handlers for the report in the DCS configuration based on BSL.

Report Object Module:

• OnResultComposition(DocumentResult, DecryptionData, StandardProcessing) — intercepts the output of the result: calculates the "Days Remaining" field relative to the current date, colors rows based on status (expiring/expired), prohibits standard processing during custom output.
• ReportSettings(...) / defining variants through ReportVariants (BSL) — registration of predefined report variants and their placement.

Form Module (if added):

• OnCreationOnServer — setting default period, initial selections, restoring user settings.
• OnParameterChange / selection handlers — resetting field availability.

General Logic of Construction. The data source of the scheme is a query to the electronic signature key certificate directory (and related information registers of the "Electronic Signature and Encryption" subsystem BSL). The query calculates the remaining validity period, forms groupings by organization/owner, and selection by status.

5. Posting and Movements

The object is a report and is not posted: it does not have the ProcessingPosting procedure, does not generate movements in accumulation/information registers, and does not create accounting entries. The report only reads data and outputs it in a tabular document.

Accordingly, the typical chart of accounts of the RK (1210 "Short-term receivables from buyers," 1030 "Cash in current accounts," 1330 "Goods," 3310 "Payables to suppliers," 3130 "VAT payable," 6010 "Revenue from sales," 7010 "Cost of sales") and calculations for taxes/contributions of RK 2026 (VAT 16%, PIT 10%/15%, OPE 10%, OPEI 3.5%, WOSMS 2%, OSMS 3%, SO 5%, social tax 6%; MRP 4,325 ₸, MZP 85,000 ₸, basic deduction for PIT 30 MRP/month and no more than 360 MRP/year) are not applicable for this object. These standards relate to accounting documents and calculation registers, not to the service report on ES validity periods.

Practical Connection to Accounting (Indirect). The report helps avoid downtime in electronic document management: when the certificate expires, the signing of ESF and SNT stops. Timely renewal of ES ensures correct VAT document flow (including reflecting VAT payable on account 3130 and revenues on 6010 based on issued ESF), but the report itself does not perform these operations.

6. Related Objects and Input Based On

• Directory of Electronic Signature Key Certificates (subsystem "Electronic Signature and Encryption" BSL) — the main data source.
• Information Registers of the ES/encryption subsystem, storing information about certificates and settings.
• Subsystem "Report Variants" (BSL) — placement of the report in the interface and storage of variants.
• EDO Mechanisms of the RK — ESF (electronic invoices), SNT; ES controlled by the report are used during their signing and sending.

Input Based On for reports is not supported (this is a document function). The logical continuation of work is the transition from the report to the certificate directory element for its renewal/replacement.

7. Extension Points

• Report Variants (DCS) — adding user variants (grouping by organizations, filter "expiring within N days") without changing the configuration.
• Configuration Extension — refinement of the composition scheme (new fields/parameters), adding a custom report form, overriding OnResultComposition.
• Conditional Formatting — setting up color indication of statuses (expired/expiring) through DCS settings.
• Regulatory Mechanisms of BSL — integration with scheduled report distribution (e-mail notifications to responsible parties about upcoming certificate expirations).
• Parameterization of Warning Threshold — moving the number of days "until expiration" to a DCS parameter for flexible configuration.