---
title: "Directory \"Versions of Supplied Extensions\" (UT for Kazakhstan 3.4.5.21)"
country: KZ
lang: en
author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti)
date: 2026-09-24
canonical: https://buhgpt.kz/suraqtar/spravochnik-versiipostavlyaemyhrasshireniy-ut-dlya-kazahs-en
source: BuhGPT
---

# Directory "Versions of Supplied Extensions" (UT for Kazakhstan 3.4.5.21)

> **TL;DR:** 1. Identification Parameter Value Object type Catalog Name ВерсииПоставляемыхРасширений Full name Catalog.ВерсииПоставляемыхРасширений Synonym "Supplied Extension Versions" Configuration Trade Management for Kazakhstan, ed. 3.4 (3.4.5.21) Owning subsystem Extension supply and 

---

1. Identification

Parameter
Value

Object type
Catalog

Name
ВерсииПоставляемыхРасширений

Full name
Catalog.ВерсииПоставляемыхРасширений

Synonym
"Supplied Extension Versions"

Configuration
Trade Management for Kazakhstan, ed. 3.4 (3.4.5.21)

Owning subsystem
Extension supply and update mechanism (SSL "Infobase version update" functionality / supplied extensions)

Purpose
Service catalog. Stores registered versions of extensions supplied together with the configuration (extensions built into the supply package), providing control over the installed and current version when updating the infobase.

This is a technical (service) object. It is not involved in inventory, cash, or tax accounting, does not reflect business transactions, and is not visible to an ordinary user during operational work. Records are created and maintained by the platform/standard code when supplied extensions are connected and updated.

Important: although the configuration keeps records for Kazakhstan (VAT 16%, MCI 4,325 ₸, MMW 85,000 ₸, Kazakhstan chart of accounts 1210/1030/1330/3310/3130/6010/7010, ESF/SNT), this catalog has no relation to these accounting objects — the numeric norms are given only as configuration context and are not used in the catalog's logic.

2. Header attributes and tabular sections

Composition of attributes of a service catalog of this kind (purpose of fields):

Attribute
Type
Purpose

Code
String/Number
Internal item code (auto-numbering).

Description
String
Name/representation of the supplied extension version.

Identifier / ExtensionName
String
Unique name of the extension to which the version belongs (matching key with the installed extension).

Version
String
Extension version number in "part.part.part.part" format (e.g. 1.0.0.5).

Checksum / HashSum
String
Checksum of the extension binary data to verify identity/integrity during update.

ExtensionData / Storage
ValueStorage
Binary data (body) of the supplied extension or a reference to it.

Activity / InUse
Boolean
Flag indicating that the version is current/connected.

DeletionMark
Boolean
Standard service attribute.

Tabular sections in catalogs of this purpose are usually absent — the extension version is stored as a flat item. If a specific build contains a tabular section (e.g. a list of extension objects or dependencies), it is auxiliary in nature and filled programmatically.

Requires verification (version-specific): the exact list of attributes and the presence/absence of data storage inside the item itself depends on the implementation of the extension supply mechanism in the specific 3.4.5.21 build — to be clarified in Configurator.

3. Forms

For a service catalog of this kind, separate custom forms are usually not created — the platform's auto-generated forms are used:

Form
Purpose

List form (auto)
Viewing the list of registered supplied extension versions (service-level).

Item form (auto)
Viewing the attributes of a specific version.

Selection form (auto)
Selecting an item from program code/service processing.

There are generally no custom managed forms, since the object is not intended for manual maintenance.

4. Key module procedures

No evidence for the object's modules has been provided (the ground truth only contains the "purpose" facet). Below are the typical handlers for this kind of object, which should be expected in the object/manager module and in the service common modules of the extension supply mechanism:

- Object module
- BeforeWrite(Cancel) — validation of the correctness of the service item record (completeness of name/version/checksum).

- FillingProcessing(FillingData, ...) — programmatic filling of attributes when registering a new version.

- Manager module
- ChoiceDataGetProcessing(...), ChoiceDataFindProcessing(...) — service selection handlers.

- Common modules of the extension supply/update mechanism (calls working with this catalog):
- Registering a new version of the supplied extension when updating the configuration.

- Comparing the installed and supplied version by name and checksum, deciding whether to install/update the extension.

- Marking outdated versions.

Specific path:line references cannot be provided — no BSL evidence has been supplied; when customizing, take them from the object/manager modules in Configurator.

5. Posting and movements

The catalog is not posted and does not generate register movements. Objects of the "Catalog" type in 1C are not involved in posting, do not create journal entries, and do not create records in accumulation/information registers as a recorder.

Accordingly, this object:

- does not generate accounting entries under the Kazakhstan chart of accounts (including 1210, 1030, 1330, 3310, 3130, 6010, 7010);

- does not affect the calculation of VAT (16%), IIT, OPC/OPVR/CSHI/SHI/SC/social tax;

- is not related to ESF/SNT electronic documents.

Accounting entries and movements are generated by the configuration's documents (sales, receipt, payment documents, etc.), not by the service catalog of extension versions.

6. Related objects and entry based on

- Entry based on — not provided (service object).

- Related objects: the mechanism for connecting/updating configuration extensions (standard infobase version update subsystem), service registers and extension supply processing. The catalog acts as a storage/registry of versions accessed by the update code.

- In applied (inventory-monetary) accounting the object has no references and is not substituted into documents.

7. Extension points

- Manager/object module — overriding the BeforeWrite, FillingProcessing handlers via a configuration extension (caution: interfering with the service mechanism may disrupt the extension update process).

- Common modules of the extension supply mechanism — if defined procedures/subscriptions exist, it is possible to hook into the version registration logic, but this is not recommended for standard implementations.

- Event subscriptions for catalog record writing — for auditing/logging version registration.

Recommendation: this catalog should not be modified or filled in manually — it is maintained automatically. Customization should be done in external objects, without affecting the service logic of extension supply.

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