1. Identification
| Property | Value |
|---|---|
| Object type | Catalog |
| Name | ГруппыДоступаПартнеров |
| Full name | Справочник.ГруппыДоступаПартнеров (Catalogs.ГруппыДоступаПартнеров) |
| Synonym | "Partner Access Groups" |
| Configuration | Trade Management for Kazakhstan, edition 3.4 (version 3.4.5.21) |
| Where to find | Section "Service subsystems" → "Partner access groups". Navigation link: e1cib/list/Справочник.ГруппыДоступаПартнеров |
| Purpose | Classifier for configuring record-level data access restrictions (RLS) for partners. Catalog values are assigned to partners and used in access restriction templates of the "Access Management" subsystem to differentiate partner visibility between users/user groups. |
The object belongs to the service (technological) part of the configuration: it does not participate in operational or regulated accounting, does not generate financial indicators, and is not directly related to tax calculation. The Kazakhstani parameters below (VAT rate 16%, MCI 4,325 ₸, minimum wage 85,000 ₸, RK chart of accounts) relate to the configuration's accounting objects and do not affect this catalog — they are not applicable here.
2. Header attributes and tabular sections
Standard attributes
| Attribute | Type | Purpose |
|---|---|---|
Код (Code) |
String/Number | Unique item code. Generated automatically. |
Наименование (Description) |
String (usually 150) | Name of the partner access group — the main content attribute (see evidence: "Name of the partner access group"). Displayed in selection lists and RLS settings. |
Ссылка (Reference), ПометкаУдаления (Deletion mark), Предопределённый (Predefined) |
service | Standard platform fields. |
Header attributes
The catalog is maximally "flat": as an access classifier element, it generally does not contain additional application attributes beyond the description. In the standard delivery, the following may be present:
| Attribute | Type | Purpose |
|---|---|---|
ДополнительныеРеквизиты / ДополнительныеСведения (Additional attributes / Additional information) |
TS/IR | Properties subsystem of the SSL — arbitrary user-defined group characteristics (if the mechanism is enabled for this catalog). |
Tabular sections
The object has no application tabular sections of its own. Catalog values are "linked" to partners not through their own tabular section, but through the partner's attribute referencing this access group.
Requires verification for the specific version: the presence of hierarchy (
Иерархический) and the exact set of additional attributes may differ between 3.4.x builds.
3. Forms
| Form | Purpose |
|---|---|
ФормаСписка (List form, or auto-generated) |
Viewing and maintaining the list of partner access groups; called via navigation link e1cib/list/Справочник.ГруппыДоступаПартнеров. |
ФормаЭлемента (Item form, or auto-generated) |
Creating/editing an individual group: entering the name, deletion mark. |
ФормаВыбора (Selection form, auto-generated) |
Selecting an access group when filling in the partner attribute and in user access group/profile settings. |
As a rule, dedicated forms are not created in the configuration for service classifiers of this kind — the platform uses automatically generated list, item, and selection forms.
4. Key module procedures
The attached evidence does not contain the source code (BSL) of the modules, so the typical handlers characteristic of an SSL/TM classifier catalog are listed below:
- Object module —
ОбработкаЗаполнения(FillingProcessing),ПередЗаписью(BeforeWrite),ПриУстановкеНовогоНомера(OnSetNewNumber): standard attribute filling on creation and control before writing. - Manager module — procedures integrated into SSL mechanisms: connection to the "Properties" subsystem (
ПолучитьПараметрыПравки, etc.), participation in data exchange. - List/item form module —
ПриСозданииНаСервере(OnCreateAtServer): configuring conditional formatting, connecting additional attributes viaУправлениеСвойствами(PropertyManagement). - Registration in access rights — the object is used in RLS templates of the "Access Management" subsystem (
УправлениеДоступомПереопределяемыйmodules, restrictions of the "By values"/"By value sets" type).
Requires verification for the specific version: exact procedure names and the presence of overridable handlers — per the configurator of build 3.4.5.21.
5. Posting and movements
The catalog is not a document: it is not posted, does not generate movements in accumulation/information registers, and does not create accounting entries. Accordingly, it does not perform movements on any of the RK chart of accounts.
For comparison — accounting entries in the configuration are generated by goods movement and settlement documents using the standard RK chart of accounts: 1210 (short-term customer receivables), 1030 (cash in current accounts), 1330 (inventory), 3310 (accounts payable to suppliers), 3130 (VAT payable, 16% rate), 6010 (sales revenue), 7010 (cost of sales), accompanied by ESF (ESF IS) and SNT. This does not apply to the "PartnerAccessGroups" catalog — its "result" is manifested exclusively in the record-level access restriction mechanism (RLS), not in accounting registers.
6. Related objects and input based on
- "Partners" catalog — the main consumer: the partner attribute referencing the access group determines the partner's membership in the group for RLS purposes.
- "Access Management" subsystem (SSL) — access group profiles, user groups: catalog values are set as allowed access values for users.
- Information register with access settings — stores the correspondence "user/user group ↔ allowed partner access groups".
Input based on another document is not provided for this object (the object is not a source and is not generated based on other objects in the application sense).
7. Extension points
- Configuration extensions — adding attributes (e.g., responsible person, description, archive flag) and overriding forms without removal from support.
- "Properties" subsystem — adding additional attributes and information via user mode.
- RLS mechanism — configuring/refining access restriction templates in the "Access Management" subsystem to extend partner differentiation logic.
- Event subscriptions / object module handlers — control of correct name filling and group uniqueness upon writing.
- Data exchange — including the object in exchange plans for a distributed information base.