---
title: "Contact Persons — Technical Description of the Object (Accounting for Kazakhstan 3.0.74.2)"
country: KZ
lang: en
author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti)
date: 2026-09-07
canonical: https://buhgpt.kz/suraqtar/kontaktnyelica-tehnicheskoe-opisanie-obekta-buhgalteriya--en
source: BuhGPT
---

# Contact Persons — Technical Description of the Object (Accounting for Kazakhstan 3.0.74.2)

> **TL;DR:** Important discrepancy regarding the object type. The object is declared in the task as Document.ContactPersons , while the navigation link is given as e1cib/list/Document.ContactPersons . However, the entire structure of the object in evidence and metadata ( object_type_ru , o

---

Important discrepancy regarding the object type. The object is declared in the task as Document.ContactPersons, while the navigation link is given as e1cib/list/Document.ContactPersons. However, the entire structure of the object in evidence and metadata (object_type_ru, owner field ObjectOwner, form ElementForm, versioning mechanism, absence of movements) clearly indicates that it is actually a Directory — Directory.ContactPersons. In standard configurations of 1C for the RK and RF, "Contact Persons" are always implemented as a subordinate directory, not a document. Below, the object is described as a directory; the correct navigation link is e1cib/list/Directory.ContactPersons. The declared type "Document" should be considered a mistake in the setup.

1. Identification

Parameter
Value

Full name
Directory.ContactPersons (incorrectly stated in the task as Document.ContactPersons)

Metadata type
Directory (subordinate)

Name
ContactPersons

Synonym
Contact persons

Owner
Counterparties, Users (composite owner)

Configuration
Accounting for Kazakhstan, ed. 3.0.74.2

Versioning
Supported (history of object changes)

Where to find
Section "Main Activity" → "Contact Persons". Also opened from the counterparty card and user settings. Navigation link: e1cib/list/Directory.ContactPersons

Purpose. Stores information about individuals — representatives of counterparties (managers, accountants, procurement specialists, contract managers) and personal contacts of system users. Allows for maintaining full name, position, role, date of birth, and an arbitrary set of additional information (phones, email, messengers). Used for identifying representatives when working with counterparties and for personalization (birthday greetings).

2. Attributes and Table Parts

2.1 Header Attributes (Element Card)

Name
Type
Mandatory
Purpose

Last Name
String
No (DontCheck)
Last name for identification and search

First Name
String
No (DontCheck)
First name of the contact person

Patronymic
String
No (DontCheck)
Patronymic (if applicable)

DateOfBirth
Date
No (DontCheck)
Date of birth — personalization, greetings

Role
Directory ContactPersonRoles
No (DontCheck)
Functional role (manager, accountant, etc.)

Position
String
No (DontCheck)
Position in the organization

Description
String
No (DontCheck)
Other information about the contact person

ObjectOwner
Directory: Counterparties, Users
Yes (ShowError)
Owner of the contact. The necessity is dynamic — depends on ContactPersonType

ContactPersonType
Enumeration ContactPersonTypes
Yes (ShowError)
Type of contact: counterparty contact or personal contact of the user. Determines validation logic

UserOfPersonalContact
Directory Users
No (DontCheck)
User-owner of the personal contact. Automatically filled for personal contacts

In addition to the listed attributes, the directory has standard Code and Name. The name is usually generated automatically from the full name.

2.2 Table Part "AdditionalAttributes"

Stores extended, user-defined properties of the contact (phone numbers, email, messengers, and other attributes), specified through the "Additional Attributes and Information" mechanism.

Name
Type
Purpose

Property
Characteristic plan type AdditionalAttributesAndInformation
Definition of an additional attribute (which property is stored)

Value
Composite type
Value of the attribute (string, number, date, etc.)

TextString
String
Text representation of the value for storage and display

3. Forms

The directory contains three forms:

- ElementForm — the main form for editing a contact person. Contains 11 input fields: ContactPersonType, Code, ObjectOwner, LastName, FirstName, Patronymic, Name, Position, Role, DateOfBirth, Description. The form usually includes a block of contact information and a table of additional attributes.

- ListForm — viewing and filtering the list of contact persons (standard list form of the directory). Requires verification against a specific release — the exact name of the second form in evidence is not provided.

- SelectionForm — selection of a contact person in the fields of other objects. Requires verification — the exact name of the third form in evidence is not provided.

The exact composition of the second and third forms in evidence is not detailed; standard forms for subordinate directories of lists and selections are provided.

4. Key Module Procedures

BSL code in evidence is not attached, therefore below are standard handlers for a subordinate directory of this purpose (real names and content are specified according to the module of the object of a specific release).

- FillProcessing (object module) — filling in attributes upon entry based on / by default: substitution of ObjectOwner from context, setting ContactPersonType, auto-filling UserOfPersonalContact for personal contacts.

- CheckFillProcessing — implementation of dynamic necessity: for the type "counterparty contact," checks the filling of ObjectOwner (counterparty), for "personal contact" — binding to the user. Here, the list of checked attributes is also formed.

- BeforeSaving / OnSaving — synchronization of Name from full name, maintaining consistency of ObjectOwner and ContactPersonType, recording the version of the object (versioning).

- OnCopying — clearing/reinstalling attributes that should not be copied.

- Form procedures (OnCreatingOnServer, ContactPersonTypeOnChange, handlers for contact information and the table of additional attributes) — managing visibility and accessibility of fields depending on the type of contact.

5. Posting and Movements

The object does not generate movements. ContactPersons is a directory, not a document: it has no posting mode, does not create records in accumulation/information registers, and does not generate accounting entries.

Accordingly, this object does not apply to the chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010), nor to the rates and limits of taxes in Kazakhstan 2026 (VAT 16%, MRP 4,325 ₸, MSP 85,000 ₸, basic deduction for PIT 30 MRP/month and no more than 360 MRP/year, PIT 10%/15% with a threshold of 8,500 MRP, OPV 10% with a base ceiling of 50 MSP, OPVR 3.5%, VOSMS 2%, OSMS 3%, CO 5%, social tax 6%), nor to electronic documents (ESF, CNT). These norms are used in calculation and accounting documents of the configuration (sales, receipts, payroll, tax reporting), but not in the directory of contact persons.

Contact persons participate in accounting only as reference data: they are substituted in contracts, powers of attorney, printed forms, and exchanges, where they act as representatives of the counterparty.

6. Related Objects and Input Based On

Owners / referring objects:

- Directory.Counterparties — main owner of counterparty contacts;

- Directory.Users — owner of personal contacts (attribute UserOfPersonalContact);

- Directory.ContactPersonRoles — source of values for the Role attribute;

- CharacteristicPlan.AdditionalAttributesAndInformation — definitions of additional attributes;

- mechanism of contact information (phones, email, addresses) — standard subsystem that stores contact data linked to the element.

Input based on. As a directory, contact persons are usually neither a source nor a receiver of classic "input based on." Creating a new contact is more often initiated from the counterparty card (the "Create" button in the list of the counterparty's contact persons) with automatic substitution of the owner and type.

7. Extension Points

- Configuration extension — adding attributes/forms without removing from support; overriding procedures CheckFillProcessing, OnSaving through &Instead/&After.

- Additional attributes and information — standard way to add user attributes (through the table part AdditionalAttributes) without changing the configuration.

- Event subscriptions — to OnSaving/BeforeSaving of the object for integrations (CRM, exchange, contact synchronization).

- Additional processing/reports (BSP) — binding to the directory of fill commands, printing, exporting.

- Element / list form — modification through extension to add fields of contact information, buttons, and visibility logic by ContactPersonType.

---
_BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_