--- title: "Access groups for individuals in \"Trade Management for Kazakhstan\" 3.4.5.21: configuring access to personal data" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-23 canonical: https://buhgpt.kz/suraqtar/gruppy-dostupa-fizicheskih-lic-v-upravlenie-torgovley-dly-en source: BuhGPT --- # Access groups for individuals in "Trade Management for Kazakhstan" 3.4.5.21: configuring access to personal data > **TL;DR:** Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4). A manager complains: opened an employee card, and half the fields are hidden — IIN, phone, date of birth are not visible. Or vice versa — a regular salesperson calmly browses the director's data, eve --- Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4). A manager complains: opened an employee card, and half the fields are hidden — IIN, phone, date of birth are not visible. Or vice versa — a regular salesperson calmly browses the director's data, even though they shouldn't see it at all. You go to sort out the permissions and run into an unfamiliar reference — "Access Groups of Individuals". Below is what this is, why it exists, and how to work with it so that everyone sees exactly what they're supposed to. Let's warn you right away: this is not an accounting document. There are no amounts, VAT, postings, or ESF here. This is a service reference for the data access restriction mechanism (RLS). So the sections about Dt/Kt postings and electronic documents below are honestly marked "not applicable" — and we explain what happens instead. 1. Purpose The "Access Groups of Individuals" reference divides all individuals in the database (employees, contact persons, accountable persons) into groups. A user is granted one or more groups in their settings — and they see and edit data only for the individuals that fall into these groups. This way you close off payroll and personal data from unauthorized eyes, staying within the framework of the RK Law "On Personal Data". 2. Where to find it This is a service reference, so it doesn't always open directly as a menu item. Three working ways: - Via permissions: "Master data and administration" → "User and rights settings" → section "Restriction of access to individuals' data" (the checkbox must be enabled). Nearby is the command to open groups and assign individuals. - From an individual's card: open any "Individual" (Payroll/HR → Individuals) — there you'll find the attribute "Access group", from which you can drill into the reference and create a new group. - Directly via 1C navigation link: "Service" (or the platform's main menu) → "Go to navigation link" → paste: e1cib/list/Справочник.ГруппыДоступаФизическихЛиц The last method is the fastest if the menu item is hidden by interface settings. 2a. How to find out your release "Help" → "About the program" (or the ℹ icon in the top right corner). The window shows two versions: the platform (e.g., 8.3.24.x) and the configuration — here it should say "Trade Management for Kazakhstan, edition 3.4 (3.4.5.21)". If your release differs, individual field labels may shift, but the reference logic is the same. 3. How to fill it out The reference is simple — it's not a document but a set of named groups. There are minimal fields, but each affects the result. Field Required Why it matters and what happens if you get it wrong Name Yes The name of the group, which you'll later select in the individual's card and in user settings. Make it descriptive: "Management", "Accounting", "Retail — store on Abay St." It cannot be saved blank. If named vaguely ("Group1"), it's easy to assign the wrong group when setting up permissions and expose someone's salary to the wrong people. Code Auto Assigned automatically, usually not touched. Needed for internal identification and exchange. Parent (if hierarchy is enabled) No Allows grouping into folders (e.g., all retail outlets into a "Stores" folder). The folder itself does not affect access — only the final group does. Once groups are created, work happens in two places: - Individual's card — the "Access group" attribute: you specify which group a particular person belongs to. If not filled in, the individual remains "without a group," and will only be seen by those explicitly allowed the "empty" group or all groups. - User settings — "Master data and administration" → "User and rights settings" → user → "Access groups of individuals": mark which groups this user is allowed. The rule is simple: a user sees an individual only if that individual's group is on the list of groups allowed to the user. 4. Worked example There are no postings here — this is an access reference, not a ledger operation (accounts 1210/3310/6010 and 16% VAT have nothing to do with it). So the "highlight" of this section is a working access delimitation scenario. Let's work through it with specific people. Given. The company has three categories of individuals: - Director Akhmetov A. and chief accountant Sergeyeva I. — sensitive payroll data. - 12 store salespeople. - Warehouse keeper and driver. Task. The HR officer must see everyone. The payroll accountant — also everyone. The senior salesperson should see only their 12 salespeople, but not the director or the accountant. Step 1. Create groups (e1cib/list/Справочник.ГруппыДоступаФизическихЛиц): - "Management and Accounting" - "Retail" - "Warehouse and Logistics" Step 2. Assign individuals — set "Access group" in each person's card: Individual Access group Akhmetov A., Sergeyeva I. Management and Accounting 12 salespeople Retail Warehouse keeper, driver Warehouse and Logistics Step 3. Assign groups to users: User Allowed groups HR officer all three Payroll accountant all three Senior salesperson only "Retail" Result. The senior salesperson opens the list of individuals and sees the 12 salespeople. The cards for Akhmetov and Sergeyeva simply don't appear in their selection, and their amounts and IIN are inaccessible. The HR officer and payroll accountant see everyone. Exactly what was required — without a single posting: the mechanism works at the record-reading level. 5. Operation types The reference doesn't have "operation types" the way a document does. Functionally, a group participates in two modes: - Read restriction — a user without the required group does not see the individual in lists and reports. - Edit restriction — even if visible (if configured that way), the user cannot edit data belonging to another group. The specific set of restrictions is defined not in the group itself, but in access profiles and the "Restriction of access to individuals' data" setting. 6. What is generated upon posting The reference is not posted, therefore: - Dt/Kt postings — are not generated. This is not an accounting operation. - Electronic documents (ESF in the ESF IS, SNT) — are not generated. Access groups do not participate in goods turnover or tax accounting. - Movements in accounting registers — none. What actually happens: the group value is written to the individual's attribute, and the record-level access restriction mechanism (RLS) checks the individual's group against the user's list of groups on every access and decides whether to show the record or not. Internally, the "user ↔ allowed groups" link is stored in an information register of permission settings; there's no need to manually access it — everything is done through user settings. 7. Printed forms The reference has no printed forms of its own — there's no reason to print an access group. A standard list output is available via "More" → "Output list" (to file/print/spreadsheet document) if you need to document the group structure, for example for a personal data protection regulation. 8. Common mistakes "Insufficient rights to view" / individual's card won't open. The user has not been assigned the group this person belongs to. Go to the user's settings → "Access groups of individuals" and add the required group. "Failed to save. An element cannot be its own parent" — occurs when trying to set a group as its own parent in the hierarchy. Remove the self-reference in the "Parent" field. An individual is visible to everyone, even though they shouldn't be. The individual's "Access group" is not filled in. An empty group is often open to everyone who has access "to all without a group" enabled. Assign the individual a specific group. "Object cannot be deleted, referencing objects found" — you're trying to delete a group that still has individuals linked to it. First reassign these individuals to another group (conveniently done via the bulk attribute change processing), then delete. Enabled the restriction — and some employee reports became "empty". This is expected: after enabling "Restriction of access to individuals' data," users only see their own groups. Check that everyone who needs access has been assigned the corresponding groups. 9. FAQ Is this a document? Why are there no amounts or postings? No, this is a service reference for the permissions mechanism. It does not generate postings, does not calculate VAT (16% rate in RK from 2026), and does not generate ESF/SNT — it only distributes individuals into groups for access restriction. How does an individual's access group differ from a user's role/profile? The profile and roles answer the question "what can be done" (operation types, objects). The access group of individuals answers the question "whose personal data can be viewed." These are different levels that work together. Where is the mechanism itself enabled? "Master data and administration" → "User and rights settings" → checkbox "Restriction of access to individuals' data." While it's disabled, groups exist but don't affect anything. Can an individual be in multiple groups? An individual's card specifies one access group. But a user can be allowed several groups at once — that's how the delimitation is built. How can I quickly assign hundreds of individuals to groups? Via "More" → bulk attribute change: select the required individuals and assign a common access group to them in one action. I deleted a group — what happens to the people in it? You cannot delete a group with linked individuals directly (1C won't allow it due to references). First reassign the individuals, then mark the group for deletion and delete it via "Deletion of marked objects." Is an administrator user also restricted by groups? Users with full rights usually see all data regardless of groups. Restrictions apply to regular users who have the corresponding restriction enabled in their profile. Is this necessary if there are only one or two users in the database? Technically, no. The mechanism is valuable where there are several employees with different areas of responsibility and there is sensitive personal/payroll data that can't be shown to everyone. Does the access group affect printed forms and reports? Yes, indirectly: if a user doesn't have access to an individual, that individual won't appear in their reports and lists. The groups themselves have no separate printed form. Where did the "Access group" attribute in the individual's card go? It only appears when "Restriction of access to individuals' data" is enabled. Enable the mechanism — the field will return. 10. Related objects - Individuals (Payroll/HR → Individuals) — each one has "Access group" set here; this is the reference's main "consumer". - Users and their settings ("User and rights settings") — here a user is given a list of allowed groups. - Access group profiles / roles — define what a user can do; individual groups complement them with a restriction by the circle of people. - "Bulk attribute change" processing — convenient for mass-assigning a group to multiple individuals. The reference is not entered "based on" a document, and it does not itself serve as a basis for anything — it's configured once and then simply applied to individuals' cards and user settings. How to find out your release: "Help" → "About the program" — there's a line with the platform version and configuration release. This material was prepared and verified on release 3.4.5.21 of the "Trade Management for Kazakhstan" configuration (edition 3.4). On adjacent releases, command names may differ slightly, but the principle of how access groups of individuals work remains the same. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_