Directory "User Report Settings" (Accounting for Kazakhstan 3.0.74.2)

1. Identification

Purpose. The catalog is a service storage of views of user report settings. It is used by the reporting mechanism of the configuration (the BSP report variant storage subsystem) to find and manage the personal settings of each user. Importantly, the catalog only stores views — links to the report variant, the user-owner, and the textual key of the setting, but does not store the serialized data of the settings themselves. The settings themselves are placed in the platform's settings storage, and this catalog provides their addressing and access control. The user does not interact directly with the object: access is automated by the reporting subsystem and is triggered when opening any report that has saved personal settings.

Where to find in 1C: section "Standard subsystems" → "User report settings". Navigation link: e1cib/list/Catalog.UserReportSettings

2. Attributes of the header and table parts

2.1 Header Attributes

All attributes have the "Do not check for filling" (DontCheck) property, as they are filled programmatically by the reporting subsystem, not manually.

2.2 Table Parts

There are no table parts. All information is stored in the header attributes of the element.

3. Forms

No custom forms are defined in the metadata. The catalog is a service: work is done programmatically through the reporting system mechanism, without a user interface for editing elements.

When accessing the list via the navigation link, the platform will generate an automatic list form (default form). A separate element form for manual input is not provided and is not required — records are created and maintained by the BSP code.

4. Key Module Procedures

The application BSL code in evidence is not attached, so below are typical handlers and interaction points for the service catalog of settings views storage (standard BSP logic "Report Variants"):

• ManagerModule / common module of the reporting subsystem — programmatic creation/search of elements by the pair "Variant + User + UserSettingKey". Provides idempotent recording: if the setting view already exists, it is not duplicated.
• FillingHandler (typical handler) — filling attributes when programmatically creating an element with the values of the current user and the processed report variant.
• BeforeRecording (typical handler) — control of the correctness of the attribute binding and normalization of the setting key before saving.
• ScheduledCleanupHandlers — removal of "orphaned" views (for deleted users or report variants) as part of the subsystem maintenance.

Requires verification (version-specific): exact names of procedures and presence of handlers in the specific assembly 3.0.74.2 should be checked in the configurator, as the implementation relates to the supplied BSP and may change between releases.

5. Posting and Movements

The object is a catalog — it has no mechanism for posting and movements in registers. Records do not generate accounting entries and do not affect accounting/accumulation registers.

Accordingly, the catalog does not participate in reflecting economic operations and tax calculations. For comparison — accounting documents of the configuration generate movements according to the standard chart of accounts of the RK, for example:

• sale of goods: Dr 1210 (short-term receivables from buyers) — Cr 6010 (revenue from sales); Dr 7010 (cost of goods sold) — Cr 1330 (goods); VAT at the rate of 16% — Cr 3130 (VAT payable);
• payment from the buyer: Dr 1030 (money in current accounts) — Cr 1210;
• receipt from the supplier: Dr 1330 — Cr 3310 (payables to suppliers).

This catalog has no relation to these movements — it only serves the personalization of report forms, including user settings of regulated and standard reports, where the specified amounts are indicated (MPR = 4,325 ₸, MZP = 85,000 ₸, deduction for individual income tax 30 MPR/month, etc.), but does not store or calculate them.

6. Related Objects and Input on the Basis

Direct links by attributes:

• Catalog.ReportVariants — the report variant to which the setting relates.
• Catalog.Users, Catalog.ExternalUsers — owner of the setting.

Functional links:

• Subsystem "Storage of Report Variants" (BSP) — the main consumer of the catalog; creates, reads, and deletes setting views.
• Platform Settings Storage — stores the actual setting data, addressed by the key UserSettingKey.
• All configuration reports (regulated and standard) — indirectly use the catalog when opened with saved personal settings.

Input on the basis: not provided and makes no sense for a service object. The catalog does not act as a basis/subordinate to other objects.

7. Extension Points

• Configuration Extensions — you can add your own attributes (for example, labels/groupings of settings) through an extension without removing the object from support; the standard BSP logic must remain unchanged.
• Event Subscriptions — if necessary for auditing the creation/modification of setting views, you can subscribe to BeforeRecording/OnRecording of the catalog.
• Programmatic API of the Reporting Subsystem — recommended integration point: work with settings should be done through the standard BSP methods, not by directly modifying catalog elements, to avoid disrupting synchronization with the settings storages.
• Scheduled Maintenance Tasks — overriding/complementing procedures for cleaning outdated views.

Requires verification (version-specific): the composition of export methods of the report variant storage subsystem in assembly 3.0.74.2 should be checked against the common modules of the supplied BSP.