Catalog "Item Types" (Catalogs.ВидыНоменклатуры) — UT for Kazakhstan 3.4.5.21

Catalog "Item Types" (Catalogs.ВидыНоменклатуры)

A classifier that defines the type and accounting parameters of items. It does not post documents itself, but determines which attributes are available in the item/service card, how inventory accounting is maintained, which VAT rate applies, and which accounts are substituted into movement documents.

1. Identification

Where to find in 1C: Section "GISM UT Integration" → "Item Types". Navigation link: e1cib/list/Справочник.ВидыНоменклатуры

The catalog is a predefined classifier: some types (e.g., "Item", "Service") may be shipped as part of the configuration and used in standard mechanisms, so renaming/deleting such items is not recommended.

2. Header Attributes and Tabular Sections

The catalog has standard attributes (Code, Description, Parent, DeletionMark, IsFolder) and a set of applied attributes controlling the behavior of related items.

Header attributes — field purposes:

Tabular sections. In the standard delivery, the catalog generally does not contain its own applied tabular sections — parameters are stored in header attributes. If a specific build adds a tabular section (e.g., a list of available additional attributes/properties), its content is of a settings nature and does not generate movements.

Requires verification (version-specific): the exact composition of attributes for characteristics/batches and the presence of settings tabular sections may differ between 3.4.x sub-releases — verify against the configurator of build 3.4.5.21.

3. Forms

4. Key Module Procedures

No specific BSL evidence for this build is attached, so below are typical handlers characteristic of a catalog of this kind in UT 3.4. Verify exact names/lines in the configurator.

Object module:

• BeforeWrite(Cancel) — checks the correctness of the settings combination (e.g., prohibiting inventory/batch accounting for the "Service" type; consistency of characteristics and packaging attributes).
• FillCheckProcessing(Cancel, CheckedAttributes) — verification of required fields (item type, VAT rate for taxable types).
• BeforeDelete(Cancel) — protection of predefined/used types from deletion.

Item form module:

• OnCreateAtServer / OnOpen — initial configuration of field visibility and availability depending on ItemType (hiding inventory settings for services, etc.).
• ItemTypeOnChange — reconfiguring the availability of attributes (characteristics, batches, packaging, accounts) when the type changes.
• UseOfCharacteristicsOnChange / UseOfBatchesOnChange — enabling/disabling dependent settings.

If the build has a common module for item maintenance, part of the logic (substituting accounts, VAT rate into the card) is implemented there and called from the item card upon type selection.

5. Posting and Movements

The catalog is not a document and does not perform posting — it does not create its own register movements. Its role is a source of settings inherited by the item card, and it is the movement documents that generate register records and postings. Below is how the type's parameters affect accounting (accounts according to the standard RK chart of accounts, VAT rate 16% for 2026).

Impact on registers (via items and documents):

• Inventory accounting registers ("Goods in Warehouses", "Organizations' Goods") — filled only for types with inventory accounting (type "Item", "Packaging"); for "Services"/"Works" no quantitative movements are generated.
• Cost/batch accounting registers — use the cost of sales account inherited from the type.
• VAT and ESF/SNT accounting registers — use the VAT rate and labeling/traceability attributes of the type.

Typical sales document postings (RK accounts), for a taxable item with a 16% VAT rate:

Typical goods receipt postings:

• The input VAT account is given according to the standard RK methodology; the specific recoverable VAT account is taken from the organization's accounting settings.

VAT calculation example. Goods shipped for 1,000,000 ₸ excluding VAT. VAT at 16% rate = 160,000 ₸. Total payable by the customer — 1,160,000 ₸ (Dt 1210 1,160,000 ₸; Ct 6010 1,000,000 ₸; Ct 3130 160,000 ₸).

Electronic documents. For taxable types, an ESF (ESF IS) at a 16% rate is generated upon sale; for goods subject to traceability/labeling (attributes set on the item type), an SNT is additionally issued.

6. Related Objects and Entry Based On

• Catalog.Items — the main consumer: the "Item Type" attribute in the item/service card references this catalog and inherits from it the accounting type, VAT rate, accounts, group, and characteristics/batch/labeling attributes.
• Item characteristics, batches, packaging — the availability and rules for maintaining these objects are determined by the type's settings.
• Movement documents (sales, receipt, transfer, posting/write-off) — use accounting parameters inherited from the type via the item.
• ESF and SNT mechanisms / GISM integration — use the type's labeling/traceability attributes.

Entry based on. For a classifier catalog, entry based on in the standard sense is not provided; items are created manually in the list or via classifiers. Conversely — documents are entered based on items in the usual way, but this relates to Catalog.Items, not to types.

7. Extension Points

• Configuration extension: adding custom type attributes (e.g., an additional accounting policy attribute), new form handlers via plugins (&After, &Instead, &Before).
• Additional attributes and information (BSP "Properties" mechanism) — for storing industry-specific attributes without changing metadata.
• Event subscriptions BeforeWrite/OnWrite of the object — for controlling settings integrity and automatically updating related items.
• Overridable common modules for item maintenance — a point for customizing account and VAT rate substitution upon type selection.
• Data exchange/KD 2/EnterpriseData — during synchronization, the item type participates as a classifier catalog; conversion rules are set in the exchange node.

For any modifications, preserve predefined types and do not hard-code the VAT rate — use the DefaultVATRate attribute so that rate changes (16% in RK for 2026) remain manageable from data.