1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | ContactPersonRoles |
| Full Name | Catalog.ContactPersonRoles (Catalogs.ContactPersonRoles) |
| Synonym | Contact person roles |
| Configuration | Accounting for Kazakhstan, edition 3.0 (3.0.74.2) |
| Hierarchy | Not used (flat list) |
| Owner | No (independent catalog) |
| Purpose | Classifier of functional roles of contact persons of counterparties |
Purpose. The catalog is intended for classifying contact persons of counterparties by their functional roles — "Director", "Chief Accountant", "Sales Manager", "Contact Person for Notifications", etc. The values of the catalog are used when filling in information about individuals representing partner organizations to structure data in the counterparty cards. The catalog is auxiliary (regulatory-reference): it is mainly referred to during the initial setup of the system and periodically updated as needed. Users include accountants, sales and procurement managers.
Where to find in 1C: section "Main Activity" → "Contact Person Roles". Navigation link: e1cib/list/Catalog.ContactPersonRoles
2. Attributes and Tabular Parts
2.1 Header Attributes
The catalog has a standard structure without additional user-defined attributes (in metadata "attributes": []). Only standard attributes of the catalog are used.
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| Code | String | No | Unique code of the element for identification |
| Name | String | Yes | Name of the contact person role (e.g., "Director", "Chief Accountant") |
2.2 Tabular Parts
None ("tabular_sections": []).
Since the catalog has no additional attributes and tabular parts, it serves exclusively as an enumerative classifier of string values — a "flat" list of roles.
3. Forms
The catalog contains three forms:
| Form | UI Elements | Purpose |
|---|---|---|
| ListForm | 32 | Main list form for viewing all roles; includes a command for group modification of selected items |
| ElementForm | 10 | Form for editing a single role; contains fields "Name" and "Code" |
| SelectForm | 26 | Form for selecting a role when filling in contact persons of a counterparty |
Key forms for the user: ListForm and ElementForm — for maintaining the catalog; SelectForm — when working with contact persons in counterparty cards.
4. Key Module Procedures
The attached evidence does not present the program code (BSL) of the modules, and the composition of attributes is minimal. For a catalog of this type, a blank or trivial object module is characteristic; all logic is reduced to the standard mechanisms of the platform. Below are typical handlers applicable to this type of object.
Object Module (CatalogObject.ContactPersonRoles):
FillProcessing(FillData, StandardProcessing)— filling a new element based on input data.BeforeWriting(Refusal)— control of correctness before writing (e.g., check for empty name).OnCopying(CopyingObject)— adjustment of fields when copying an element.
Element Form Module (ElementForm):
OnServerCreation(Refusal, StandardProcessing)— initial setup of the form, visibility/accessibility of fields.OnOpening(Refusal)— additional setup of the form upon opening.
List Form Module (ListForm):
OnServerCreation(Refusal, StandardProcessing)— setup of the dynamic list, filters, and conditional formatting.- Handler for the command of group modification of selected elements (standard processing "Group Modification of Attributes").
Specific procedures for processing, calculations, or exchanges are absent for this catalog — it is a regulatory-reference object without applied movement logic.
5. Processing and Movements
The catalog is not a document, does not perform processing, and does not generate movements in registers. It has no tabular parts, sum attributes, accounting accounts, or connections with accounting/accumulation registers. Accordingly:
- This object does not generate entries according to the RK chart of accounts.
- It does not participate in tax and contribution calculations, in the formation of electronic invoices (ESF)/SNT, and in accounting entries.
The catalog serves only as a value-sign (role) in the contact person cards of counterparties. For the context of the "Accounting for Kazakhstan" configuration, we remind the reference benchmarks of the RK for 2026, to which this classifier has no relation, but which are applied in related accounting mechanisms:
- VAT — 16 %; VAT payable is accounted for on account 3130.
- MPR = 4,325 ₸, MZP = 85,000 ₸.
- Basic deduction for PIT — 30 MPR per month (no more than 360 MPR per year).
- PIT — 10 % up to 8,500 MPR of annual income and 15 % above; OPE 10 % (ceiling base — 50 MZP), OPEP 3.5 %, VOSMS 2 %, OSMS 3 %, CO 5 %, social tax 6 %.
- Typical accounts of the RK: 1210 (Accounts Receivable from Customers), 1030 (Cash in Current Accounts), 1330 (Goods), 3310 (Accounts Payable to Suppliers), 3130 (VAT Payable), 6010 (Revenue from Sales), 7010 (Cost of Sales).
These values are provided for completeness of the configuration picture and do not involve the catalog "ContactPersonRoles".
6. Related Objects and Input Based On
- Catalog "Counterparties" and its subordinate catalog "ContactPersons" — the main consumer: in the contact person card, the role is selected from this catalog via
SelectForm. - Subsystem for Working with Counterparties — the catalog is included as an auxiliary classifier.
- Input based on: not provided and not required (the catalog is filled manually from the list).
- Role values are used as a selection attribute when outputting lists of contact persons and in printed forms where representatives of the counterparty are listed.
7. Extension Points
- Configuration Extension: adding custom attributes (e.g., "Notification Priority", "Role Type", "Default Flag") through object borrowing; adding form attributes and handlers
OnServerCreation. - Additional Attributes and Information (BSP): connecting the properties mechanism to extend attributes without changing metadata.
- Group Modification of Attributes: standard command in the list form for mass adjustment.
- BSP Event Handlers (
BeforeWriting,OnWriting) for controlling the uniqueness of names or integration with external systems. - Data Exchange: inclusion in exchange/synchronization rules when exporting contact data of counterparties.
Requires verification (version-specific): the exact composition of UI commands
ListFormand the presence of connected BSP mechanisms may differ between sub-releases of branch 3.0.74 — please clarify for the specific delivery 3.0.74.2.
