--- title: "Catalog “Individual Access Groups” (Catalogs.ГруппыДоступаФизическихЛиц) — Technical Description" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-10-14 canonical: https://buhgpt.kz/suraqtar/spravochnik-gruppy-dostupa-fizicheskih-lic-catalogs-grupp-en source: BuhGPT --- # Catalog “Individual Access Groups” (Catalogs.ГруппыДоступаФизическихЛиц) — Technical Description > **TL;DR:** 1. Identification Parameter Value Object type Catalog Name ГруппыДоступаФизическихЛиц Full path Справочник.ГруппыДоступаФизическихЛиц / Catalogs.ГруппыДоступаФизическихЛиц Synonym Individual Access Groups Configuration and release “Accounting for Kazakhstan,” edition 3.0, rele --- 1. Identification ParameterValue Object typeCatalog NameГруппыДоступаФизическихЛиц Full pathСправочник.ГруппыДоступаФизическихЛиц / Catalogs.ГруппыДоступаФизическихЛиц SynonymIndividual Access Groups Configuration and release“Accounting for Kazakhstan,” edition 3.0, release 3.0.74.2. If another release in the 3.0.74.x series is used, the actual composition of the object is determined by the metadata of the installed build. Current release of the related configuration“Payroll and HR Management for Kazakhstan” 3.1.37.x. SubsystemAccess management service mechanism HierarchyThe presence and type of hierarchy are defined by the catalog properties in the metadata of the installed configuration. OwnerThe presence of an owner is determined by the object properties in the metadata. Where to find it in 1CAccess to the catalog depends on the command interface and user permissions. The service object may not appear in user sections. Navigation linke1cib/list/Справочник.ГруппыДоступаФизическихЛиц Purpose. “Individual Access Groups” is a service catalog used to classify individuals within the access control mechanism. A catalog item contains a group description rather than individual records or business transaction details. Catalog values may be used when creating access rules for data related to individuals. A user obtains access not directly from an item in this catalog, but through the application of roles, profiles, access groups, and record-level restrictions provided by the installed configuration. Important. The catalog does not calculate taxes or payroll. The applicable indicators in the Republic of Kazakhstan for 2026—VAT 16 %, MCI 4 325 ₸, MMW 85 000 ₸, and the basic PIT deduction of 30 MCI—are not attributes of this object and do not affect the recording of its items. 2. Header attributes and tabular sections The exact set of attributes is established by the metadata of the specific release. For technical analysis, the standard catalog fields are considered first, followed by attributes added by the application solution or an extension. AttributeTypePurpose CodeStandard catalog attributeItem identifier. Its format and numbering method are defined by metadata properties. DescriptionStandard catalog attributeUser-defined name of the access group, such as “Branch Employees” or “Contact Persons.” ParentStandard hierarchical catalog attributeReference to a parent item or group. The field is present when hierarchy is enabled. DeletionMarkBooleanIndicates that the item is marked for deletion. The mark itself does not mean that the record has been physically deleted. PredefinedStandard indicatorIndicates that the item is associated with predefined configuration data. RefСправочникСсылка.ГруппыДоступаФизическихЛицA unique reference to the catalog item used in attributes and registers. Tabular sections. The presence of tabular sections is determined by the metadata of the installed build. The relationship between an individual and an access group may be stored in an application object attribute or in a service register, so it cannot automatically be regarded as a tabular section of this catalog. Additional attributes and information appear only when the corresponding mechanism is connected to the object or when the configuration is customized. Their composition should be read from the metadata and infobase settings rather than inferred from the catalog name. 3. Forms The set of forms depends on the metadata. If the developer has not assigned a custom form for a particular action, the platform may generate a standard representation of the object. Therefore, the names below describe typical purposes but do not guarantee the presence of identically named forms in every build. FormPurpose List formViewing items available to the user, searching, filtering, creating, and opening a group when the appropriate permissions are available. Item formCreating or editing an item, including its description and application attributes. Group formUsed with a hierarchy of groups and items if such a form is provided by the metadata. Selection formSelecting a reference to an access group when completing another object’s attribute or configuring access rules. The visibility of the command for opening the catalog and the availability of actions in the form depend on user roles, functional options, and the command interface. The absence of a command from a section does not mean that the object is absent from the metadata. 4. Key module procedures The module source code and metadata export are not attached to the article, so it would be incorrect to list specific export procedures as guaranteed to exist. During a technical examination of the object, the object module, manager module, form modules, event subscriptions, and common modules of the access mechanism are analyzed. Object module - Fill processing. May set initial values when an item is created if such a handler is implemented in the configuration. - Fill check. May validate required attributes and data consistency before writing. - Before write and on write. May perform application checks, register changes, or update related service data. Manager module - May provide a programmatic interface for searching, selecting, or retrieving service values from the catalog. - The absence of a manager module or application code within it is acceptable: the main logic may reside in common modules. Form modules - Control the display of attributes, form commands, client-side checks, and server calls. - Should not be regarded as the sole source of access rules: actual data restrictions are enforced by roles and record-level access conditions. To find dependencies, it is useful to perform a global search for the strings “ГруппыДоступаФизическихЛиц” and “СправочникСсылка.ГруппыДоступаФизическихЛиц,” as well as review attribute types, common module parameters, queries, and event subscriptions. 5. Posting and register movements A catalog is not a document, so it cannot be posted. Writing a catalog item does not create accounting entries or generate the register movements typical of postable documents. When an item is written, related service data may change if this is explicitly implemented by handlers, subscriptions, or the access management mechanism. Such changes result from application code rather than catalog posting. The object’s role in the accounting system is indirect: a reference to a group may be used to determine the data available to a user. After a group or its relationships are changed, record-filtering results may change in accordance with the configuration algorithms and permission settings. Accounting transactions, calculation of VAT at the 16 % rate, and preparation of E-invoices and accompanying waybills for goods are performed by the documents and subsystems intended for these purposes. This catalog does not determine account correspondence and does not create entries in the accounts of the standard chart of accounts of the Republic of Kazakhstan, including accounts 1210 “Short-term trade receivables,” 3130 “Value-added tax,” and 3310 “Short-term trade payables.” It also does not determine the tax amount, turnover date, or electronic document status. 6. Related objects and creation based on another object - Individuals catalog. The relationship with an access group is implemented in the manner defined by the metadata: through an attribute, information register, or another service object. - Access groups and profiles. Define the aggregate user permissions and may be involved in configuring available values. - Roles. Define permitted actions on objects and may contain record-level access restrictions. - Service registers. May store prepared sets of values, relationships, and parameters used by the access mechanism. - Common modules. May calculate available values, update service data, and apply access control rules. Creation based on another object. For a service classifier, the creation-based-on scenario is not mandatory. If the corresponding commands are not defined in the metadata, items are created directly from the list form, programmatically, or supplied as predefined data. To establish the actual relationship, open the attribute properties of related objects and find the type СправочникСсылка.ГруппыДоступаФизическихЛиц. The dimensions and resources of information registers, query texts, and procedure parameters should also be analyzed. 7. Extension points - Configuration extension. Suitable for adding an attribute, command, form, or handler without directly modifying the main configuration. - Event subscriptions. Allow additional processing to be performed when an object is written, provided that the event and handler are supported by the platform and configuration. - Common modules. Used for centralized application logic when the customization should not depend on a specific form. - Additional attributes and information. Used for custom classification if the object is connected to this mechanism. - Record-level access restrictions. Are changed together with the entire access model because an error in a condition may hide required data or expose excessive data. When customizing the catalog, its purpose as a service classifier should be preserved, and personal, calculation, or tax data should not be transferred into it without a separate, justified storage model. New attributes should have a clear purpose, and write handlers should account for bulk data exchange and background operations. After changing the access mechanism, functional testing should be performed at least under an administrator account and under a user account with restricted permissions. Testing should cover reading the list, selecting a value, writing an item, working with related objects, and updating service access sets. Questions and answers Can the catalog be opened using the navigation link? Yes, if the object is present in the configuration and the user has view permission. The link e1cib/list/Справочник.ГруппыДоступаФизическихЛиц is used. If the user lacks permission, the platform will not provide access to the data. Why is the catalog not displayed in the application sections? A service object may be excluded from the command interface. Its presence is determined through the Designer or available metadata viewing tools, rather than solely from the user menu. Do the items store individuals’ personal data? The catalog is intended to store access groups. Individual records are located in the object intended for them. If an extension has added other attributes here, their composition is visible in the metadata of the installed infobase. Do documents need to be reposted after a group is changed? No, the catalog does not participate in document posting. However, changing access relationships may affect which records a user sees after service data is updated or a new session is started. Do VAT 16 %, MCI 4 325 ₸, MMW 85 000 ₸, and the 30 MCI deduction affect this catalog? No. These indicators apply to the relevant tax and calculation operations, while the catalog groups values for access management and does not perform such calculations. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_