Verified on release 3.0.74.2 "Accounting for Kazakhstan" (edition 3.0).
You updated the configuration, and on startup it popped up: "Metadata object identifier not found." Or you're setting up an access group profile for a new accountant — and the document permissions "fall off" after an update. Or you're cleaning up objects marked for deletion, and the system complains about a "broken" reference. In all these cases, one service catalog works behind the scenes — "Metadata object identifiers." An ordinary user never opens it. But if you're a database administrator, it's useful to know about it: it's precisely what links the "human" name of an object (Документ.РеализацияТоваровУслуг) with the internal reference relied upon by permissions, exchanges, and scheduled jobs.
Let's be honest right away: this is the technical infrastructure of the platform and the Standard Subsystems Library (SSL), not an accounting document. It does not make postings, does not generate ESF or SNT, does not affect VAT, IIT, MCI, or minimum wage. Tax rates and amounts have nothing to do with it. Therefore, the sections below about postings and printed forms are short and to the point: this object simply doesn't have them, and inventing them would be a mistake.
1. Purpose
The catalog stores unique identifiers (UUID references) of the metadata objects in your configuration: catalogs, documents, registers, reports, data processors, attributes. These references are needed by mechanisms for which the object's "name" is not enough: permission settings (RLS), access group profiles, exchange plans, versioning, additional reports and data processors, cleanup of marked objects. As long as the object's name lives in this catalog as a stable reference, renaming the object in the configuration does not break the settings made by the user.
2. Where to find it
In the standard interface there is no menu item for it — it's a service catalog. You can open it in two ways (administrator rights required):
Main menu (the ≡ icon at the top left) → All functions → Catalogs → Metadata object identifiers. If there is no "All functions" item — enable it: Main menu → Tools → Options → Display the "All functions" command.
1C navigation link. Copy and open it via Main menu → Tools → Navigate by link:
e1cib/list/Справочник.ИдентификаторыОбъектовМетаданных
2a. How to find out your release
Help → About (or the ≡ icon → Help → About). In the window that opens you can see the platform version (for example, 8.3.24) and the configuration release — "Accounting for Kazakhstan, edition 3.0 (3.0.74.2)." Specify exactly this release when you write to support about the catalog's behavior: the set of service attributes may differ slightly from version to version.
3. How to fill it out
The main rule: you do not fill it out manually. Records are created and updated by the configuration itself — during the information base update and by the scheduled job "Updating metadata object identifiers". Manually editing, adding, or deleting records can "tear" permissions and settings away from objects. Therefore, below is not an instruction on "what to enter," but a breakdown of what you see in the card and the list.
| Field / column | What it means | What happens if it's incorrect |
|---|---|---|
| Name | The object's synonym in a readable form (for example, "Sales of goods and services"). Filled in automatically from the metadata synonym. | If it's empty or "strange" — usually a sign that the object has been renamed/deleted and the record is awaiting an update. |
| Full name | The technical key: Документ.РеализацияТоваровУслуг, Справочник.Контрагенты, РегистрНакопления.НДСпоРеализации. It's precisely by this that mechanisms find the object. |
A mismatch with the actual metadata name → mechanisms (permissions, exchange) don't find the object, hence errors during the update. |
| Code | The internal code of the record. Service data, carries no meaning for a person. | No need to touch it. |
| Reference (UUID) | The stable reference itself, which the settings refer to. Not displayed as a field, but it's the "core" of the record. | Delete the record — and all settings that referred to it will "hang." |
| The "no object data" / "deleted" flag | A service mark indicating that the metadata object no longer exists in the current configuration (renamed or deleted by the developer). | Normal after major updates; cleaned up by the same scheduled job. |
None of these fields is filled in by hand as "mandatory" — all of them are managed by the platform. The only meaningful action for an administrator here is to run the update (see section 8) if the mechanisms complain about identifiers.
4. Worked example
An accounting example with amounts and postings for this catalog is impossible — it does not participate in calculations. So let's look at a real administrative scenario, the very reason it's opened at all.
Situation. You updated "Accounting for Kazakhstan" from 3.0.73 to 3.0.74.2. The accountant Petrova had an access group profile configured with a warehouse restriction on the document "Sales of goods and services." After the update, she opens the list of sales — and sees it empty, although the documents for 2026 are in place (sales of a nominal 1,160,000 ₸ with 16% VAT haven't gone anywhere, the problem isn't in the data).
What happened. In the update, the developer reworked the object, and its internal composition changed. The scheduled job "Updating metadata object identifiers" hasn't run yet, and in the catalog the record Документ.РеализацияТоваровУслуг is temporarily marked as "no object data." The RLS permissions referred to this record — and while it's "hanging," the restriction works as "show nothing."
What you do.
- Open the list:
e1cib/list/Справочник.ИдентификаторыОбъектовМетаданных. - Find the row with the full name
Документ.РеализацияТоваровУслуг— it has the service flag "no object data." - Run the scheduled job manually (Master data and administration → Maintenance → Scheduled and background jobs → "Updating metadata object identifiers" → Run now).
- The job reassembles the identifiers, and the record again gets a current reference.
- Go into Petrova's access group profile, make sure the warehouse restriction is in place, and re-save the profile if necessary.
Result: Petrova sees her sales again, and permissions work. No postings or movements are created in the process — only the service link "name ↔ reference" changes.
5. Operation types
The catalog has no "operation types" in the accounting sense. It's more correct to speak of the mechanisms that use it:
- Access permission settings and access group profiles (RLS);
- Exchange plans and data synchronization (stable identification of objects between databases);
- Object versioning (change history);
- Additional reports and data processors (linking to the objects that own commands);
- Deletion of marked objects and referential integrity control;
- Scheduled jobs that refer to metadata objects.
6. What is generated during an update
The catalog is not posted, therefore:
- There are no postings to accounting or tax accounts. It touches neither 1210, nor 1030, nor 3130, nor 6010.
- There are no electronic documents. It does not issue ESF in the ESF IS or SNT and does not affect them.
- There are no movements in accounting registers.
What actually happens when the mechanism runs: records of this very catalog are created, updated, or flagged, and other subsystems (permissions, exchanges) read current references from it. This is an internal data exchange, not an accounting operation.
7. Printed forms
There are no printed forms. This is a service catalog; acts, invoices, waybills, and the like are not printed from it.
8. Common mistakes
"Metadata object identifier not found…" — usually pops up during a database update or when opening permission settings. How to fix: run the scheduled job "Updating metadata object identifiers" manually (Master data and administration → Maintenance → Scheduled and background jobs). If the database is file-based — jobs run only during an active session, so let it finish.
After an update, object lists are empty for users with restricted permissions. How to fix: wait for/run the identifier update, then open and re-save the problematic access group profile.
"Updating of auxiliary data is not completed." How to fix: these are deferred SSL update operations, which also include reassembling the identifiers. Log in with full rights and let the database finish the update (Master data and administration → Update auxiliary data / deferred handlers).
The temptation to delete "extra" records with the "no object data" status. How to fix: do not delete them manually. Such records are a normal trace of renames; the scheduled job cleans them up correctly. Manual deletion breaks the settings that referred to them.
There's no "All functions" item, can't open the catalog. How to fix: Main menu → Tools → Options → enable "Display the 'All functions' command"; administrator rights required.
9. FAQ
Can this catalog be edited manually? Technically yes, practically no. It's a service catalog and is populated automatically. Manual edits "tear" permissions, exchanges, and settings away from objects. Leave it to the configuration.
Where is it filled in from at all? During the information base update and by the scheduled job "Updating metadata object identifiers." This is part of the Standard Subsystems Library.
Does the catalog affect VAT, IIT, postings, or amounts? No. It does not participate in accounting or calculations. The 16% VAT rate, the 30 MCI IIT deduction, the 4,325 ₸ MCI, the 85,000 ₸ minimum wage — none of this has anything to do with it.
Does it generate ESF or SNT? No. Electronic invoices and accompanying waybills are issued by the sales/receipt accounting documents, not by this catalog.
What does a record with the "no object data" status mean? There is no longer a metadata object with such a name in the current configuration — it was renamed or deleted in an update. This is a routine situation; the record will be cleaned up during the identifier update.
Why is a separate reference needed if there's a full object name? The name can change when the configuration is reworked. A stable UUID reference survives a rename, so user settings (permissions, exchanges) don't fall apart.
Why did the document permissions "fall off" after the update? The object identifier was temporarily out of date, and the RLS permissions referred to it. After reassembling the identifiers and re-saving the access group profile, everything is restored.
How to force an update of the catalog? Master data and administration → Maintenance → Scheduled and background jobs → "Updating metadata object identifiers" → Run now. Do it with full rights.
Is it visible to an ordinary accountant, and does it need to be touched? It's not visible to and not needed by an ordinary user. This is the database administrator's domain. In everyday work with sales, receipts, and reporting it does not participate.
Is it safe to clear it when "compacting" the database? There's no need to clear it separately, and it's dangerous. It's small and maintains itself. To optimize the database, use the standard "Deletion of marked objects," not a manual cleanup of this catalog.
10. Related objects
The catalog is not "entered on the basis of" anything, and nothing is created "on its basis" in the accounting sense. But it is linked to:
- Access group profiles and permission settings (RLS) — they use its references;
- Exchange plans and data synchronization — stable identification of objects between databases;
- Additional reports and data processors — linking commands to objects;
- Scheduled jobs (primarily "Updating metadata object identifiers");
- The mechanism for deleting marked objects and versioning.
How to find out your release
Help → About (or the ≡ icon → Help → About): there you'll find the "1C:Enterprise" platform version and the configuration release. Check against your release before applying the instructions — the set of service attributes may change slightly between versions.
This material was prepared for "Accounting for Kazakhstan," edition 3.0, release 3.0.74.2.