Analytical Accounting Groups of Items catalog (UT for Kazakhstan 3.4.5.21)

1. Identification

Purpose. The catalog is a classifier-aggregator that combines items and (in some cases) item types into consolidated groups for regulated and management accounting purposes. It serves as an intermediate dimension to which account settings are attached. Instead of specifying accounting accounts for each item card separately, accounts are set once for an analytical accounting group, and specific items inherit the setting through their membership in the group. This drastically reduces the amount of configuration required in a trading database with a large item catalog and ensures consistent posting when data is transferred to regulated accounting (including integration with "Accounting for Kazakhstan").

Typical usage scenarios:

• separating items by the nature of accounting (goods for resale → account 1330, materials, packaging, services);
• assigning different income/expense and VAT accounts for different product lines;
• unifying the rules for generating postings when exchanging data with the regulated system.

2. Attributes and Tabular Sections

The catalog is a simple hierarchical classifier. It carries almost no business logic data of its own — its value lies in the very existence of an element as a dimension value to which account settings are "attached" in separate information registers.

Standard attributes (platform-level)

Header attributes (application-level)

Note "version-specific": the exact set of additional application attributes (e.g., service flags such as "Use as …") may differ between builds of branch 3.4 — verify in the configurator of the specific 3.4.5.21 release.

Tabular sections

The catalog has no tabular sections — it is a flat/hierarchical classifier. All "group → accounting account" bindings are stored not in the catalog itself but in external information registers (see section 5), where this catalog serves as a dimension.

3. Forms

If specific forms are not explicitly defined in the release, the platform uses auto-generated forms of the corresponding types.

4. Key Module Procedures

The attached evidence contains only the "purpose" facet; the source code of the modules (BSL) is not provided. Therefore, below are typical handlers characteristic of this type of classifier catalog. Specific path:line references should be checked in the configurator of the 3.4.5.21 release.

Object module (ОбработкаОбъекта):

• ПередЗаписью (BeforeWrite) — validates record correctness (prevents hierarchy cycling, checks that the name is filled in).
• ОбработкаЗаполнения (FillingProcessing) — populates attributes when creating a new element (including entry based on / copying).
• ПроверкаЗаполнения (FillCheckProcessing) — checks that Наименование (Name) is required.

Manager module (МодульМенеджера):

• Functions for retrieving predefined values and service methods for substituting a default group when selecting accounting accounts.

Item/list form module:

• ПриСозданииНаСервере (OnCreateAtServer) — configures field availability, conditional formatting of the list.
• Selection handlers (ВыборНачало, ОбработкаВыбора) when using the selection form in places where accounts are assigned.

Since this is a catalog and not a document, there is no "heavy" business logic (calculations, movements) in its modules — this logic is concentrated in objects that reference the group.

5. Posting and Movements

The catalog is not posted and does not generate movements in registers on its own — it is a classifier, not a document. Its role in accounting is to serve as a dimension in the mechanism for determining accounting accounts.

How the group participates in postings

Account settings are specified in information registers of the accounting subsystem (typical names: "Item Accounting Accounts" / "Settlement Accounting Accounts" and similar), where this catalog is one of the dimensions. When posting trade documents (sales, receipts, transfers), the account determination mechanism identifies the analytical accounting group by item and takes the corresponding accounts.

Example of a typical posting scheme under the Chart of Accounts of Kazakhstan (figures — Kazakhstan, 2026):

Sale of goods (VAT rate 16%), sale for 116,000 ₸ including VAT:

Receipt of goods from a supplier for 116,000 ₸ including VAT:

Customer payment to the current account:

It is precisely accounts 1330, 6010, 7010, 3130, etc. in these postings that are taken from the settings tied to the item's analytical accounting group. Changing an item's group automatically changes the accounts in subsequent postings.

Electronic documents (ESF via the ESF IS and SNT) are generated based on trade documents; correct item classification via analytical accounting groups indirectly affects how amounts and VAT rates are allocated in these documents.

6. Related Objects and Entry Based On

Reference the catalog (used as a dimension):

• Справочник.Номенклатура (Items catalog) — each item belongs to an analytical accounting group (directly via an attribute or through an item type).
• Справочник.ВидыНоменклатуры (Item Types catalog) — sets the default analytical accounting group for items belonging to the type.
• Information registers for accounting account settings — use the catalog as a dimension when determining accounts for postings.

Entry based on: for a service classifier, entry based on and subordinate documents are not provided. Elements are created manually or transferred during initial data filling/exchange.

Interaction with regulated accounting: group values are used when exporting/synchronizing data to the regulated system, where they form the basis for generating accounting entries according to the Chart of Accounts of Kazakhstan.

7. Extension Points

• Additional attributes and information — via the "Properties" mechanism (characteristic types plan for additional attributes), without losing support status.
• Event subscriptions — ПередЗаписью/ПриЗаписи (BeforeWrite/OnWrite) of the object for custom validation or auto-filling according to corporate rules.
• Configuration extensions — adding form attributes, changing field visibility/availability, additional fill-in checks without modifying the standard configuration.
• Account determination registers — when refining account determination rules, extend the information registers that use the catalog as a dimension, not the catalog itself.
• Data exchange — when setting up synchronization, map analytical accounting groups between databases (conversion rules) so that accounts are determined consistently.

Recommendation for implementers: do not store account business logic in the catalog module — keep it in the account determination registers, so that the catalog remains a "clean" classifier and does not interfere with updates to the standard configuration.