---
title: "Analytical Accounting Groups of Items catalog (UT for Kazakhstan 3.4.5.21)"
country: KZ
lang: en
author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti)
date: 2026-09-23
canonical: https://buhgpt.kz/suraqtar/spravochnik-gruppyanaliticheskogouchetanomenklatury-ut-dl-en
source: BuhGPT
---

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

> **TL;DR:** 1. Identification Parameter Value Object type Catalog Name (identifier) ГруппыАналитическогоУчетаНоменклатуры Full name Справочник.ГруппыАналитическогоУчетаНоменклатуры Synonym "Item Analytical Accounting Groups" Configuration Trade Management for Kazakhstan, ed. 3.4.5.21 Subs

---

1. Identification

Parameter
Value

Object type
Catalog

Name (identifier)
ГруппыАналитическогоУчетаНоменклатуры

Full name
Справочник.ГруппыАналитическогоУчетаНоменклатуры

Synonym
"Item Analytical Accounting Groups"

Configuration
Trade Management for Kazakhstan, ed. 3.4.5.21

Subsystem placement
Service subsystems

Navigation link
e1cib/list/Справочник.ГруппыАналитическогоУчетаНоменклатуры

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)

Attribute
Type
Purpose

Код (Code)
String
Internal element code, auto-numbering

Наименование (Name)
String
Name of the analytical accounting group (e.g., "Goods", "Materials", "Services", "Packaging")

Родитель (Parent)
CatalogRef
Group hierarchy (hierarchy of groups and elements)

ПометкаУдаления (Deletion Mark)
Boolean
Deletion mark flag

Предопределённый (Predefined)
Boolean
Predefined element flag

Header attributes (application-level)

Attribute
Type
Purpose

Комментарий (Comment)
String
Arbitrary text description of the group's purpose

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

Form
Purpose

Item form (ФормаЭлемента)
View/edit a single analytical accounting group: name, parent, comment

List form (ФормаСписка)
List of groups with hierarchy; the main form when navigating via the navigation link

Selection form (ФормаВыбора)
Selecting a group when filling in accounting account settings and related registers/catalogs

Group form (ФормаГруппы)
Editing a hierarchy group element (if the catalog is a "groups and elements" hierarchy)

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:

Dr
Cr
Amount, ₸
Description

1210
6010
100,000
Sales revenue recognized (excluding VAT)

1210
3130
16,000
VAT payable accrued (16%)

7010
1330
(cost)
Cost of goods sold written off

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

Dr
Cr
Amount, ₸
Description

1330
3310
100,000
Goods received into warehouse

1420/3130
3310
16,000
Input VAT recorded (16%)

Customer payment to the current account:

Dr
Cr
Amount, ₸
Description

1030
1210
116,000
Funds received into current account, receivables offset

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.

---
_BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_