RUKKENZH
Задать вопрос AI
SectionsОбъекты конфигурации 1С
Contact Persons — Technical Description of the Object (Accounting for Kazakhstan 3.0.74.2)
Язык статьи:🇷🇺 RU🇰🇿 KK🇬🇧 EN🇨🇳 ZH
Версия статьи:📘 Для бухгалтера⚙️ Для тех-специалиста

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

Applies to: 1С:Бухгалтерия для Казахстана, release 3.0.74.2 · by 1C-Sapa Group, 1C partner
СТ
Сапа Т.И. — Эксперт по 1С и бухгалтерскому учёту, преподаватель-практик

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 DirectoryDirectory.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.

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.

Частые вопросы

Is this a document or a reference?
In fact, this is a subordinate reference of the Reference.ContactPersons. In the task, the type "Document" and the link e1cib/list/Document.ContactPersons are indicated incorrectly: the structure of the object (owner, element form, versioning, absence of movements) corresponds to a reference. The correct link is e1cib/list/Reference.ContactPersons.
What transactions and movements does the object generate?
None. The reference does not generate transactions and does not create records in registers and accounting entries. Therefore, the accounts of the RK plan (1210, 1030, 3310, etc.) and the tax norms of Kazakhstan 2026 are not applicable to it — they are used in accounting documents, not in the contact reference.
Why is the attribute OwnerObject not always mandatory?
The obligation is dynamic and depends on the attribute ContactPersonType. For a counterparty contact, the owner must be the counterparty; for a personal contact, it must be the user. The logic is implemented in the handler FillingCheckProcessing.
How many forms does the object have and what are they?
Three forms. The ElementForm is precisely described (11 input fields). The other two are standard for a subordinate reference: the list form and the selection form; their exact names in the evidence are not provided and require verification according to the release.
How to store contact phones and email?
Through the tabular part AdditionalAttributes (properties from the plan of types of characteristics AdditionalAttributesAndInformation) and through the standard subsystem of contact information. This is the standard way to extend without removing the configuration from support.

Read also

Источники

Была ли статья полезна?
💼 Нужна помощь с 1С или учётом? Слава КВЦ — многолетняя практика в 1С в Казахстане. Изучите разложенный НК РК 2026 или спросите в чате BuhGPT — ответит за секунды.