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,FillingProcessinghandlers 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.