--- title: "Directory \"String Contacts of Interactions\" — Technical Description" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-07 canonical: https://buhgpt.kz/suraqtar/spravochnik-strokovyekontaktyvzaimodeystviy-tehnicheskoe--en source: BuhGPT --- # Directory "String Contacts of Interactions" — Technical Description > **TL;DR:** 1. Identification Parameter Value Object Type Catalog Name StringContactsInteractions Full Name Catalog.StringContactsInteractions Synonym not specified (—) Configuration Accounting for Kazakhstan, edition 3.0 (version 3.0.74.2) Owner Subsystem “Interactions” (Library of Stand --- 1. Identification Parameter Value Object Type Catalog Name StringContactsInteractions Full Name Catalog.StringContactsInteractions Synonym not specified (—) Configuration Accounting for Kazakhstan, edition 3.0 (version 3.0.74.2) Owner Subsystem “Interactions” (Library of Standard Subsystems, BSS) Hierarchy Hierarchy of groups and elements (the catalog supports Parent) Object Nature Service (technical entity of infrastructure) Purpose. The catalog stores contact information in a string (unstructured) format — email addresses, phone numbers, arbitrary strings of recipients — which appears in the documents of the “Interactions” subsystem (emails, phone calls, SMS, meetings, scheduled interactions). The catalog element is needed where the string contact could not or is not required to be matched with a specific counterparty/partner/individual: then the “raw” address of the sender/recipient is saved as a separate element to ensure uniform representation and subsequent mapping with contact catalogs. Working with the catalog in the overwhelming majority of cases is indirect: when registering an interaction, the platform itself finds the existing element by the contact string or creates a new one. Direct manual maintenance of the catalog by the user is atypical. 2. Attributes and Table Parts 2.1 Header Attributes Custom (user-defined) attributes in the metadata are not defined. The catalog relies on standard system fields: Name Type Mandatory Purpose Code String Automatically filled Unique code of the element Name String Yes The actual string contact: e-mail, phone, address, etc. The main informative field of the object Parent CatalogReference.StringContactsInteractions No Hierarchy of groups DeletionMark Boolean System Mark for deletion Predefined Boolean System Indicator of a predefined element (not used) The absence of application attributes is the norm for this object: all significant information fits into Name, and the connections with interaction subjects are stored in external information registers of the subsystem, not in the catalog itself. 2.2 Table Parts Table parts are absent. 2.3 Forms In the metadata, forms are not redefined — auto-generated by the platform: Form Purpose Element Form (auto) View/edit a single string contact (essentially the Name field) List Form (auto) Service list of elements; used in debugging/administration Selection Form (auto) Selection of an element from the code of the “Interactions” subsystem The absence of custom forms confirms the service nature of the object: the end user does not need a separate screen form. 3. Forms — List There are no custom forms. All forms are generated automatically (see p. 2.3). The catalog typically does not have a separate item in the interface (command menu of the section). 4. Key Module Procedures No exported procedures or redefined handlers in evidence are attached. For a catalog of this type in BSS, the following typical mechanisms are characteristic (implemented in the common modules of the “Interactions” subsystem, not in the module of the catalog itself): - Search/create element by contact string. The common module of the “Interactions” subsystem, when recording an interaction document, searches for an element by Name (address) and creates a new one if absent — ensuring the uniqueness of the string contact. - ProcessingFilling (object module, typical handler) — filling Name when programmatically creating an element from the data of an email/call. - BeforeRecording / OnRecording (object module) — normalization of the contact string (case, trimming spaces) before saving, if present. - Registration in the subsystem of contact information — when recording an interaction, the string contact is linked to the subject through the information register of the subsystem (see p. 5). Requires verification on a specific version: the set and signatures of common modules of BSS that service the mapping of string contacts are version-specific and may differ between releases 3.0.7x. 5. Posting and Movements The catalog is not a document and is not posted — it has no properties of “Posting” and registrant movements. Accounting entries (in terms of the typical chart of accounts of the RK: 1210, 1030, 1330, 3310, 3130, 6010, 7010, etc.), as well as movements for VAT/ESF/SNT are not generated by this object — it lies outside the accounting contour and relates to the infrastructure of communications. Indirect participation in movements: - The catalog element acts as a measurement/resource value in the information registers of the “Interactions” subsystem (the connection “interaction subject ↔ contact”), which are filled by interaction documents, not by the catalog itself. - In tax calculations and the formation of electronic documents (ESF in the IS ESF, SNT), the catalog does not participate. Any numerical/tax norms of the RK 2026 (VAT rate 16%, MRP 4,325 ₸, MZP 85,000 ₸, deduction for individual income tax 30 MRP/month and no more than 360 MRP/year, individual income tax 10%/15%, OPE 10%, OPER 3.5%, VOSMS 2%, OSMS 3%, SO 5%, social tax 6%) are not applicable to this object and are provided only as a marker of the current context of the configuration. 6. Related Objects and Input on Basis The catalog is a “leaf” service object. Input on the basis from/to it is not provided. Objects of the “Interactions” subsystem refer to it: Related Object Nature of Connection Documents “Incoming/Outgoing Email” Sender/recipient as a string contact Document “Phone Call” Subscriber not matched with a contact Document “SMS”, “Meeting”, “Scheduled Interaction” Participant in string form Information Registers of the “Interactions” subsystem Store the connection of the string contact with the subject/folder Contact Catalogs (Counterparties, Partners, Individuals, Contact Persons) Target objects for mapping the string contact 7. Extension Points - Contact Mapping. The logic of searching/normalizing the string contact should be correctly extended through redefined common modules of the “Interactions” subsystem BSS, rather than editing the catalog module. - Object Module of the Catalog (BeforeRecording, OnRecording, ProcessingFillingCheck) — point for validation/normalization of Name. - Subscriptions to Events on catalog recording — for integrations with external communication systems. - Configuration Extension — the preferred way of modifications without removing from support; adding attributes/forms should only be done when there is a real need, keeping in mind the service nature of the object. Where to find: navigation link e1cib/list/Catalog.StringContactsInteractions. In the standard interface, a separate menu item is usually absent; opening is done via the link or indirectly from interaction documents. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_