Checked on release 3.0.74.2 "Accounting for Kazakhstan" (version 3.0).
The accountant calls you in a panic: "I can only see my documents, but the sales for LLP 'Almaty' have disappeared; they were there yesterday." You haven't changed her permissions. You open her profile — everything is in order, the organization restriction is set correctly. Yet the documents are still "invisible." You dig deeper and come across a service directory that the average user doesn't even suspect exists — "Access Keys". This is where the platform stores the "prints" of who is allowed to see which records. If these prints are outdated or not filled in (a common case after loading the database from a copy or an update), the user honestly loses access to the data, even though the permission settings are fine.
First and foremost: this is a technical directory for the record-level security (RLS) access restriction mechanism. You do not fill it in manually and should not. It has no entries, it does not generate electronic invoices (ESF) or tax reports, and it has no accounting printed forms. The administrator and the chief accountant who assigns permissions need to know about it — to understand why documents "disappear" and how to fix it.
1. Purpose
The "Access Keys" directory stores unique sets of values (organization, counterparty, warehouse, document type, etc.) based on which the platform quickly decides whether to show a specific user a given record or hide it. This is the core of the RLS (Row Level Security) mechanism from the Library of Standard Subsystems. It is filled and updated automatically by background tasks; a person only diagnoses it and, in case of failure, initiates a recalculation.
2. Where to Find
You cannot open the directory from a regular menu — it is a service directory and is intentionally hidden. Here are three ways to access it:
Main Menu (☰) → "All Functions" → "Directories" → "Access Keys". If the "All Functions" item is not present, enable it: "Service" → "Settings" → check the box "Show 'All Functions' command".
1C Navigation Link. Main Menu (☰) → "Service" → "Active Link" (or "Go to Link") → paste:
e1cib/list/Справочник.КлючиДоступа- Settings for the rights mechanism itself — from where the keys recalculation is initiated: "Administration" → "User and Rights Settings" → "Access Groups" / "Access Group Profiles".
2a. How to Know Your Release
Main Menu (☰) → "Help" → "About the Program". In the opened window: at the top — the version of the platform "1C:Enterprise" (for example, 8.3.24.x), below — the line "Accounting for Kazakhstan, version 3.0 (3.0.74.2)". This is the release of the configuration. All paths in this guide are given for 3.0.74.2; in neighboring releases, the command names are almost identical.
3. How to "Fill" (correctly — how to maintain)
When you open an element of the directory, you will see a set of service fields. You must not fill them in manually — any manual change will be overwritten by the platform during the next recalculation, and until then, the user may gain incorrect access. Understanding the fields is only useful for diagnostics.
| Field | What it is and why | What will happen if you "correct" it manually |
|---|---|---|
| Code | Internal number of the key. Technical. | No point in changing it; it is not considered as a setting during recalculation. |
| Hash | Checksum of the access value set. It allows the mechanism to instantly find the required key without comparing values one by one. | It will diverge from the actual set of values — the key will be "lost," and access will become unpredictable. |
| Table Part with Values | The actual set: a combination of organization, counterparty, document type, etc., to which permission is tied. | Change = false permission or denial; it can only be corrected by a full recalculation. |
What you really need to do instead of manual filling is to initiate the update of keys. The procedure:
- "Administration" → "User and Rights Settings". Ensure that the checkbox "Restrict Access at the Record Level" (RLS) is checked. Without it, the keys do not work at all.
- Check the settings in "Access Group Profiles" and "Access Groups": the user must have correct restriction values (for example, "Organizations: LLP 'Almaty'"). Keys are calculated based on these settings.
- Initiate the recalculation. In the typical configuration, this is done by the scheduled task "Filling Data for Access Restriction" (in some releases — "Updating Access Keys"). To find and run it manually: "Administration" → "Maintenance" → "Scheduled and Background Tasks" → find the task with this name → "Run Now". (The exact name of the scheduled task is the only item that should be checked in your release: the wording has changed between versions of the BSP.)
- Wait for the background task to complete (in large databases — minutes, occasionally longer) and ask the user to log in again.
There is one mandatory condition: RLS must be enabled, and the rights in the profile must be set correctly. The system will handle everything else itself.
4. Analyzed Example
Situation. The LLP keeps records for two organizations: "LLP Almaty" and "LLP Astana". Accountant Saule should only see "LLP Almaty". Yesterday, the accountant processed a sale: goods for 1,000,000 ₸ excluding VAT, VAT 16% = 160,000 ₸, total payable 1,160,000 ₸. The entries for this sale (to understand which record the key is tied to):
| Debit | Credit | Amount, ₸ | Description |
|---|---|---|---|
| 1210 | 6010 | 1,000,000 | Revenue from sales to the customer |
| 1210 | 3130 | 160,000 | VAT payable (16%) |
| 7010 | 1330 | 700,000 | Cost of goods sold |
The sales document itself and its entries have no relation to the "Access Keys" directory — they are different subsystems. However, the document has the attribute "Organization = LLP Almaty". The RLS mechanism creates an access key with the set of values {Organization = LLP Almaty} and the hash of this set. Saule has the same hash in her personal keys — which means the document is visible to her, and she will immediately notice that the amount in her act (1,160,000 ₸) matches the processed amount.
What went wrong in the initial situation. The database was restored from a copy the day before, and the scheduled task for recalculating keys was disabled. The key {Organization = LLP Almaty} was not created for the document. There is no hash — nothing to match — the document "disappeared" from Saule's list, even though the entries for 1,160,000 ₸ are in place, and the chief accountant sees them in full rights.
Treatment. Administration → Scheduled Tasks → "Filling Data for Access Restriction" → "Run Now". In a minute, the key is restored, Saule logs in again — the sale is visible again.
5. Types of Operations
The service directory has no "types of operations" in the accounting sense. Functionally, it participates in three modes of operation of the mechanism:
- Object Keys — which sets of values correspond to each data record (document, directory item).
- User Keys — which sets of values are allowed for a specific user/access group.
- Recalculation (actualization) — background adjustment of the first two to match the current rights settings.
6. What is Formed During Operation
To be clear: this directory does not create accounting movements. No entries, no electronic invoices (ESF) in the ESF information system, no tax reports, no movements in VAT registers, mutual settlements, or tax registers. This is fundamental — do not look for tax consequences here.
What really happens "under the hood" during recalculation:
- elements of the "Access Keys" directory are filled/updated (unique sets of values and their hashes);
- related service information registers of the RLS mechanism are updated — object keys and user keys;
- only records with permitted hashes begin to appear in the data lists for each user.
7. Printed Forms
The directory has no accounting printed forms. For control and diagnostics, use:
- the list of the directory itself (
e1cib/list/Справочник.КлючиДоступа) — can be printed using the standard command "More → Print List"; - the report "Access Rights" / "User Rights Report" (Administration → User and Rights Settings) — shows what is actually permitted to the user.
8. Frequent Errors and Messages 1C
"Access rights violation!" — the user is trying to open a record for which they do not have the appropriate key. Check the settings of their access group; if the settings are correct — initiate the recalculation of keys.
"Insufficient rights to view" / documents have disappeared from the list. A classic sign of unfilled or outdated keys after loading from a copy, updating the configuration, or bulk data loading. Treatment — scheduled task "Filling Data for Access Restriction" → "Run Now".
"Filling data for access restriction is in progress..." and it is taking a long time. In a large database, the first full recalculation is noticeable. Do not interrupt: let the background task complete, monitor it in the list of background tasks.
After enabling the checkbox "Restrict Access at the Record Level," everyone started seeing less data. This is normal: until the first recalculation, the keys are not yet built. Wait for the background filling to complete.
Manual editing of the directory element did not change anything (or broke access). As expected — edits are overwritten by recalculation. Do not edit keys manually, change permission settings and recalculate.
9. FAQ
(see the separate Q&A block below)
10. Related Objects
The "Access Keys" directory is not introduced "based on" and does not generate anything as a document. It serves the access restriction mechanism and is related to:
- "Access Group Profiles" and "Access Groups" (Administration → User and Rights Settings) — the source of settings based on which keys are calculated;
- "Users" — to whom rights are assigned;
- service information registers of the RLS mechanism (object keys, user keys, value keys);
- scheduled task for recalculating access keys.
All application objects (sales, receipts, payment orders) are "clients" of this mechanism: keys are built based on their attributes (organization, counterparty, etc.), but the documents themselves are not tied to the directory by settings.
How to Know Your Release
Main Menu (☰) → "Help" → "About the Program": the line "Accounting for Kazakhstan, version 3.0" and the release number. This guide was written and checked for release 3.0.74.2 of the "1C:Enterprise 8.3" platform. In other releases, command names may differ by a word or two.
Prepared for "Accounting for Kazakhstan," version 3.0, release 3.0.74.2.