Directory "PredefinedReportOptionsExtensions" — Technical Description

1. Identification

Purpose. The catalog stores and manages predefined report variants, which are supplied not by the configuration itself, but by connected extensions. The purpose of the object is to "register" reports from the extension in the navigation panel and report panel of the standard configuration, setting their visibility, grouping, and affiliation to a specific report.

This is a system catalog. Users do not directly edit it: elements are created and updated programmatically during the installation/update of the extension and when filling in predefined data. It has no relation to accounting and tax records (VAT, PIT, chart of accounts of the RK) — it pertains to the reporting infrastructure.

Where to find in 1C: section “Standard subsystems” → “Predefined report variants of extensions”. Navigation link: e1cib/list/Catalog.PredefinedReportVariantsExtensions

2. Attributes of Header and Table Parts

2.1 Header Attributes

The natural key of the element is formed by the pair Report + VariantKey — it uniquely identifies the report variant from the extension.

Standard fields Code, Name, DeletionMark, Predefined are present as in any catalog; predefined status is used here by the mechanism for filling in predefined data of BSP.

2.2 Table Parts

The object does not contain its own application table parts. All information about the variant is stored in the header attributes; the relationship “many variants — one report” is implemented through the attribute Report, not through a table part.

3. Forms

As with a system catalog, the set of forms is minimal and serves mainly for administration/diagnostics, rather than for the daily work of the user.

The object generally does not have specialized user forms for data entry — filling is done programmatically.

4. Key Module Procedures

No separate application evidence for BSL modules of this object is attached. Below are typical handlers characteristic of the system catalog of the “Report Variants” BSP; specific procedure names depend on the BSP version and require verification in the manager module during refinement.

• Object Module → FillProcessing — initialization of default values (e.g., Enabled, DefaultVisibility) when creating a new element.
• Object Module → BeforeSaving — validation of the natural key: control of the completeness of the attribute Report (validation in code noted in the description of attributes) and consistency of the pair Report + VariantKey.
• Manager Module → procedures for filling in predefined data — registration/updating of report variants from extensions: reading metadata of extension reports, recalculating SettingsHash, filling in search attributes (FieldNames, ParameterAndFiltersNames, Keywords).
• Handlers of the “Report Variants” subsystem — placement of the variant in the navigation panel according to GroupByReport and DefaultVisibility, synchronization with user variants.

5. Posting and Movements

The catalog is not a document and is not posted. It does not generate accounting entries and movements in registers — neither in the accounting register (standard chart of accounts of the RK: 1210, 1030, 1330, 3310, 3130, 6010, 7010, etc.), nor in the VAT/tax accumulation registers.

Accordingly, the object does not participate in the calculation of VAT (rate 16% in 2026), PIT (basic deduction 30 MRP per month, but not more than 360 MRP per year; rates 10% up to 8,500 MRP annual income and 15% above), contributions and deductions (OPV 10% with a base cap of 50 MZP, OPVR 3.5%, VOSMS 2%, OSMS 3%, CO 5%, social tax 6%) and is not related to electronic documents ESF/SNT. Current benchmarks of the RK for 2026 — MRP 4,325 ₸, MZP 85,000 ₸ — are provided here only for the context of the configuration; they do not apply to this system object.

The "movement" of this object is purely infrastructural: inclusion/exclusion of the report variant in the navigation panel and report panel based on the flags Enabled, DefaultVisibility, GroupByReport.

6. Related Objects and Input Based On

• Catalog.ExtensionObjectIdentifiers — source of the attribute value Report; links the variant to a specific report of the extension.
• Catalog.ReportVariants (standard, BSP) — the "main" registry of report variants of the configuration; the described catalog is its extended analog for reports from extensions.
• Subsystem “Report Variants” and the mechanism of predefined data of BSP — manage the lifecycle of elements (creation, update, marking for deletion when the extension is disabled).
• Navigation Panel / Report Panel — data consumers: use visibility and grouping attributes to display reports.

Input based on is not provided for the object — elements are created programmatically, not through the "Create Based On" commands.

7. Extension Points

• Filling in predefined data — the main standard way to add/change variants: the report of the extension is registered through the mechanism of predefined variants, after which the element appears automatically.
• Managing visibility and grouping — through the attributes Enabled, DefaultVisibility, GroupByReport one can programmatically manage the placement of the report in the interface without changing the report itself.
• Search attributes (FieldNames, ParameterAndFiltersNames, Keywords, as well as their language versions …Language1/…Language2) — an extension point for configuring full-text and multilingual search for variants.
• SettingsHash — a mechanism for tracking changes: recalculating the hash allows detecting modifications of the variant and correctly performing synchronization during the update of the extension.
• MeasurementKey — integration with the performance measurement subsystem for monitoring report generation time.

Practical recommendation: do not manually edit elements of this catalog. Make changes on the extension side (in the description of the predefined report variant), otherwise they will be overwritten during the next filling of predefined data.