Directory "String Contacts of Interactions" — Technical Description

1. Identification

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:

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:

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:

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.