1. Identification
| Parameter | Value |
|---|---|
| Full name | Document.UniversalReport |
| Object type | Document (according to metadata classification and navigation link) |
| Name | UniversalReport |
| Synonym | — (not set) |
| Configuration | Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 |
| Country / currency | Republic of Kazakhstan, tenge (₸) |
Important note about the nature of the object. According to the evidence, the object is classified as a Document and is opened via the link e1cib/list/Document.UniversalReport, however, its actual content and purpose correspond to a universal report based on the data composition scheme (DCS): there are no user-defined attributes, no tabular sections, no custom forms, the entire structure is built dynamically through DCS. This discrepancy between the object type (Document) and the implemented functionality (report) is the only place that requires verification in a specific assembly: it may be a technical wrapper/registration object, rather than a classic posted document. The description below is strictly based on the attached evidence; where the evidence is silent, the typical behavior of the corresponding type of object is provided.
Purpose. A flexible tool for data analytics of any configuration objects — directories, documents, information registers, accumulation, accounting, and calculations. Dynamically generates DCS based on the selected metadata object and automatically provides available dimensions, resources, and attributes for grouping and selection. Used by accountants, analysts, and administrators for ad-hoc construction of arbitrary reports without programming. Supports saving user variants with individual settings for selections, groupings, and formatting.
Where to find in 1C: e1cib/list/Document.UniversalReport (in the interface — section "Administration" → "Universal report").
2. Attributes and Tabular Sections
2.1 Header Attributes
The object does not contain user-defined attributes in metadata.attributes. All construction settings are passed through data composition scheme parameters.
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| (no attributes) | — | — | All parameters are passed through DCS |
Only standard attributes inherited from the object type are present (for the document —
Reference,Date,Number,DeletionMark,Posted; actually used for service purposes).
2.2 Tabular Sections
The object does not contain tabular sections (metadata.tabular_sections is empty). The data structure is formed dynamically in the composition scheme.
3. Forms
The list of forms in metadata.forms is absent. An automatically generated standard form based on DCS is used.
| Form | Type | Purpose |
|---|---|---|
| Main report form (auto) | DCS / auto-generation | Selecting the source object, configuring structure, selections, groupings, formatting; launching and outputting the result |
Key form for the user: main (automatic) report form.
4. Key Module Procedures
In the evidence, BSL code is not attached — specific procedures with paths and strings cannot be provided. Below is a typical set of handlers for an object of this kind (report on DCS).
| Handler / Procedure | Where | What it does (typical logic) |
|---|---|---|
OnResultComposition |
Report form module | Intercepts the output of the DCS result, fine-tunes before output |
OnVariantUploadToServer / OnVariantSaveToServer |
Form module | Serialization and restoration of user variants |
Formation of DCS (DataCompositionScheme) |
Report object module | Dynamically builds the scheme based on the selected metadata object: data set, fields, available dimensions/resources |
| Source object selection handler | Form module | Rebuilds available fields, groupings, and selections when changing the analyzed object |
For the document as such, typical would be
ProcessingPosting,ProcessingFilling,OnSettingNewNumber— but according to the evidence, the object does not have the logic of posting/filling.
5. Posting and Movements
According to the evidence, the object does not generate application movements: there are no tabular sections and attributes, no data for postings — the functionality is reporting, not accounting. The registers of accounting and accumulation are not moved by the object.
Below is for reference what the universal report shows when analyzing accounting data of the RK (chart of accounts and norms — Kazakhstan 2026), so that the developer understands the context of the output indicators:
Typical chart of accounts of the RK (analysis objects):
| Account | Purpose |
|---|---|
| 1030 | Money in current bank accounts |
| 1210 | Short-term accounts receivable from customers |
| 1330 | Goods |
| 3130 | VAT payable (on sales) |
| 3310 | Short-term accounts payable to suppliers |
| 6010 | Revenue from sales |
| 7010 | Cost of goods sold |
Example of postings for sales that the report aggregates (VAT rate RK 2026 — 16%):
Dr 1210 Cr 6010 — revenue excluding VAT
Dr 1210 Cr 3130 — VAT 16%
Dr 7010 Cr 1330 — write-off of cost of goodsTax/salary norms RK 2026 encountered in report samples:
| Indicator | Value 2026 |
|---|---|
| MPR | 4,325 ₸ |
| MZP | 85,000 ₸ |
| VAT rate | 16% |
| Basic deduction for PIT | 30 MPR/month, not more than 360 MPR/year |
| PIT | 10% up to 8,500 MPR annual income, 15% above |
| OPV | 10% (base ceiling 50 MZP) |
| OPVR | 3.5% |
| VOSMS | 2% |
| OSMS | 3% |
| SO | 5% |
| Social tax | 6% |
These numbers are the context of the analyzed data, not the movements of the object itself.
6. Related Objects and Input Based On
- Input based on: not provided — the object is reporting, there are no sources/receivers for input based on.
- Related objects: any metadata object of the configuration selected by the user as a source (directories, documents, information registers/accumulation/accounting/calculation). There are no explicit static links in the metadata — the link is established dynamically when building DCS.
- Electronic document flow of the RK (ESF through IS ESF, SNT) is not directly generated by the object; ESF/SNT data can serve as a source of analysis as records of the corresponding configuration objects.
7. Extension Points
- User report variants — the main standard way of adaptation: saving settings for structure, selections, groupings, and formatting without changing the configuration.
- Configuration extensions (adapters/BSL extensions) — intercepting form handlers (
OnResultComposition, variant handlers) for fine-tuning the output. - External reports/additional processing — registering custom variants of the universal report through the subsystem of additional reports and processing.
- Enhancing DCS — expanding the set of available fields/data sets when refining the object module.
Changing behavior through overriding posting/filling is not applicable: the object does not have the corresponding accounting logic.