1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | IdentifiersOfMetadataObjects |
| Full Name | Catalog.IdentifiersOfMetadataObjects (Catalogs.IdentifiersOfMetadataObjects) |
| Alias | — (not set; displayed by name) |
| Configuration | Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 |
| Origin | Library of standard subsystems (BSP), subsystem "Identifiers of metadata objects" |
| Filling | Automatic (when updating the configuration). Manual creation of elements is not provided |
Purpose. The catalog is a service object of BSP, designed for centralized storage of unique identifiers (internal links/UUID) of all metadata objects of the information base: catalogs, documents, registers, reports, processing, enumerations, and service collections. Through it, the standard functionality subsystems solve tasks that cannot be solved by a regular reference to the metadata type:
- tracking changes in the configuration composition between releases;
- data synchronization in distributed information bases (DIB) and data exchange;
- migration and redirection of links when renaming, moving, or merging metadata objects;
- storing typed "empty links" for programmatically obtaining the object type by its identifier without directly referring to
Metadata.
Accounting users do not work with the catalog: it is not included in the team interface of accounting sections. It is accessed by administrators and support specialists when diagnosing data exchange issues and during updates affecting object renaming.
Where to find in 1C: navigation link e1cib/list/Catalog.IdentifiersOfMetadataObjects; in the interface — section of system/service functions "Standard Subsystems" → "Identifiers of metadata objects" (usually accessible only to the administrator).
Note on the accounting context of the RK. This catalog does not participate in accounting and tax accounting and does not operate with monetary indicators. Relevant values for the configuration in 2026 (VAT rate 16%, MRP 4,325 ₸, MSP 85,000 ₸, basic deduction for PIT 30 MRP/month, RK chart of accounts 1210/1030/1330/3310/3130/6010/7010, ESF/SNT) relate to applied accounting objects, not to this system object.
2. Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| CollectionOrder | xs:decimal (Number) |
Not checked | Numerical order of sorting the element within the collection of metadata objects. Ensures grouping and ordering of similar objects (all catalogs, all documents, etc.). |
| Name | xs:string (String) |
Not checked | System name of the metadata object (e.g., "Organizations", "GoodsAndServicesReceipt"). Used for programmatic access to the object. |
| Alias | xs:string (String) |
Not checked | Alias of the metadata object in the current language. Used in user representation. |
| FullName | xs:string (String) |
Not checked | Full composite name in the format "ObjectType.ObjectName" (e.g., "Catalog.Organizations", "Document.GoodsAndServicesReceipt"). Key field for identifying the object in code. |
| FullAlias | xs:string (String) |
Not checked | Full alias indicating the type in the current language (e.g., "Catalog: Organizations"). Used in lists and logs. |
| NoData | xs:boolean (Boolean) |
Not checked | Indicates that the metadata object does not store data in the database (collections "Catalogs", "Documents", service subsystems). Affects synchronization logic. |
| EmptyLinkValue | Universal link (composite type) | Not checked | Empty link to a metadata object. Allows obtaining a typed link by identifier without referring to the type through metadata. |
| MetadataObjectKey | v8:ValueStorage (ValueStorage) |
Not checked | Service storage of the object key. Allows restoring the connection with the configuration object when renaming/moving. |
| NewLink | CatalogRef.IdentifiersOfMetadataObjects |
Not checked | When migrating data, redirects links to the new catalog element (renaming the object or merging duplicates). |
The field Name (standard attribute of the catalog) is used as a readable representation; Code serves as a technical identifier of the element.
2.2 Table Parts
Table parts are absent.
3. Forms
The catalog uses auto-generated and/or service forms of BSP. There is no applied user interface for the object.
| Form | Purpose |
|---|---|
List Form (ListForm / autoform) |
View the list of identifiers of metadata objects. Used by administrators when diagnosing exchange and updates. Opens via the link e1cib/list/Catalog.IdentifiersOfMetadataObjects. |
Element Form (ElementForm / autoform) |
View the attributes of a specific identifier (Name, FullName, NoData flag, service keys). User editing is not provided. |
Selection Form (SelectionForm / autoform) |
Selecting an element for programmatic/service use from other objects. |
Requires verification in a specific release: the presence of custom (non-auto-generated) forms depends on the BSP delivery embedded in 3.0.74.2. In the typical delivery, autoforms are usually used.
4. Key Procedures of Modules
Evidence with the source code of modules (path:string) is not attached. Below are typical handlers and programmatic interfaces characteristic of this BSP object; actual procedure names match the implementation of the catalog manager and the general-purpose module IdentifiersOfMetadataObjects.
- ManagerModule / general module
IdentifiersOfMetadataObjects— main programmatic interface:- retrieve identifier by metadata object and reverse retrieval of metadata object (or empty link) by identifier;
- create/update catalog elements when updating the configuration (reconciliation of metadata composition with the current content of the catalog);
- handle renaming and merging through the attribute
NewLink.
- FillingHandler (object module) — fills the attributes of the element (
Name,FullName,Alias,FullAlias,NoData,CollectionOrder) with values from metadata during automatic formation. - BeforeWriting / OnWriting (object module) — controls the correctness of service fields and consistency with the current configuration.
- Database Update Handlers — called by the "Database Update" subsystem when transitioning to a new release: initiate the reassembly/update of the catalog so that identifiers correspond to the new metadata composition.
Requires verification: exact method signatures differ between versions of BSP. Refer to the built-in documentation of the corresponding version of the library in 3.0.74.2.
5. Posting and Movements
The catalog is not a document and does not generate movements in registers and does not create accounting entries. It is not linked to the chart of accounts and does not affect accounting/tax accounting.
- Posting is absent.
- Movement registers are absent.
- Entries in RK accounts (1210, 1030, 1330, 3310, 3130, 6010, 7010, etc.) are not generated by this object — this is the responsibility of applied documents (receipt, sale, bank/cash, ESF/SNT).
The only "dynamics" of the object is the service update of catalog records by BSP subsystems during configuration updates and data exchange.
6. Related Objects and Input on Basis
- Input on Basis: not provided (the object is service).
- Consumers of the catalog:
- subsystem "Data Exchange" / DIB — matching objects by identifiers during synchronization;
- subsystem "Update Version of IB" — updating composition when changing releases;
- mechanisms for migration/transfer of data — redirection of links through
NewLink; - service mechanisms that obtain the object type by identifier through
EmptyLinkValue.
- Logically linked with any metadata object of the configuration, as it stores its identifier; it has no direct reference attributes to applied objects.
7. Extension Points
- Configuration Extension: borrowing the manager module / object module to add custom matching logic during atypical exchange. Modifying the composition of attributes is not recommended — this is a service object of BSP.
- Event Subscriptions: technically possible on writing the object, but not used in practice, as filling is performed by BSP platform mechanisms.
- BSP Programmatic Interface: the preferred way to work is to call the standard methods of the module
IdentifiersOfMetadataObjectsinstead of direct reading/writing of elements. - Data Exchange: when developing conversion rules (KD 2/3), identifiers are used as a reliable matching key between databases.
General recommendation: do not manually modify the structure and data of the catalog. Any intervention should go through the standard BSP API, otherwise, synchronization and updates may fail.