--- title: "Document \"Phone Call\" (Documents.PhoneCall) — 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/dokument-telefonnyy-zvonok-documents-telefonnyyzvonok-buh-en source: BuhGPT --- # Document "Phone Call" (Documents.PhoneCall) — Accounting for Kazakhstan 3.0.74.2 > **TL;DR:** 1. Identification of the Object Parameter Value Object Type Document (Documents) Name PhoneCall Full Name Document.PhoneCall Synonym “Phone Call” Synonym from Task — (in the configuration, “Phone Call” is used) Configuration Accounting for Kazakhstan, edition 3.0 (version 3.0. --- 1. Identification of the Object Parameter Value Object Type Document (Documents) Name PhoneCall Full Name Document.PhoneCall Synonym “Phone Call” Synonym from Task — (in the configuration, “Phone Call” is used) Configuration Accounting for Kazakhstan, edition 3.0 (version 3.0.74.2) Subsystem CRM / Interactions (in the interface — “Standard Subsystems” → “Phone Call”) Navigation Link e1cib/list/Document.PhoneCall Purpose. The document is intended for registering and managing information about phone interactions with clients, partners, and other counterparties within the CRM subsystem. It is used by sales department employees, support services, and other specialists working with the client base. The document records both incoming and outgoing calls, allows linking the call to a contact, setting the topic and importance of the conversation, and assigning a responsible person. It is part of the overall interaction system alongside “Meeting,” “Email,” and “Planned Interaction.” Important: “Phone Call” is a CRM document for accounting communications, not an accounting document. It does not generate accounting entries and movements in accumulation/summary registers (see section 5). Therefore, VAT rates, PIT, account plan of the RK, etc., do not apply directly to it — they only appear in related financial documents that may be entered based on the call. 2. Header Attributes and Table Parts The document implements a general interaction mechanism, so the main set of attributes is inherited from the typical structure of “Interactions.” 2.1. Mandatory Header Attributes Without filling them out, the document cannot be saved/posted — 1C will issue “Field … is not filled in.” Attribute Type (typical) Purpose Subject String Brief subject of the conversation, displayed in lists and interaction logs Description String (multiline) Expanded text/result of the conversation, manager's notes Incoming Boolean Direction of the call: True — incoming, False — outgoing SubscriberRepresentation String Text representation of the interlocutor (full name/name), as shown in the list SubscriberContactInfo String Contact information of the subscriber (phone number) through which the communication was made 2.2. Other Header Attributes (Typical for Interactions) Attribute Type Purpose Date Date Date and time of the call recording Number String Document number Responsible ReferenceLink.Users Employee responsible for the interaction (used in group change, p. 3.4 of scenarios) Importance Enumeration (Low/Normal/High) Priority of the interaction Basis DocumentLink / arbitrary link Basis object (deal, order, planned interaction) Comment String Service comment 2.3. Table Parts The document does not have separate subject-specific table parts. The list of participants/contacts in the interaction is maintained through the typical mechanism “Subject and Participants of Interaction” (information registers of the “Interactions” subsystem), not through the table part of the document itself. 3. Forms Form Purpose DocumentForm Main form for entering and viewing the call: subject, direction (incoming/outgoing), subscriber, description of the result, responsible, importance ListForm List of calls; opens via the link e1cib/list/Document.PhoneCall, used for navigation and group changes SelectForm Selecting a call when picking from other objects/interactions journal Additionally, the document participates in the overall interaction journal form (together with “Meeting,” “Email,” “Planned Interaction”), where it displays a unified stream of communications by contact/subject. 4. Key Module Procedures The attached evidence does not contain BSL exports with coordinates path:string, so below are listed typical handlers for this type of object; verify the specific implementation in the configurator. Object Module (ObjectModule): - FillProcessing(FillingData, ...) — filling in attributes when entering based on (for example, from “Planned Interaction,” p. 3.3 of scenarios): transfers the subscriber, subject, responsible. - FillCheckProcessing(Refusal, CheckedAttributes) — control of mandatory fields Subject, Description, Incoming, SubscriberRepresentation, SubscriberContactInfo. - BeforeSaving(...) / OnSaving(...) — updating data in the “Interactions” subsystem (subject, participants, read status). - ProcessingPosting(Refusal, PostingMode) — does not generate movements for this document (see section 5). Form Module (DocumentForm): - OnCreateOnServer — finalizing visibility/accessibility of call direction fields. - Input command handlers based on (“Create Meeting,” “Create Email”) — see section 6. Typical error from evidence: “Invalid object call on the client.” (occurs in ObjectModule) — addressing the server context/method of the object from client code. The texts are taken from release 3.0.68.1; when the message appears, check that the call is made on the server. 5. Posting and Movements The document does not generate accounting entries and does not create movements in registers — in the metadata register_records is empty. This is confirmed by evidence: “The document does not generate entries and movements in registers — it is a CRM document for managing interactions, not an accounting document.” Accordingly: - Accounting registers (typical account plan of the RK — 1210, 1030, 1330, 3310, 3130, 6010, 7010) are not affected by the document. - Tax calculations (VAT 16%, PIT, OPR, SO, social tax, etc.) do not apply to it. - Electronic documents (ESF in IS ESF, SNT) are not issued from the phone call. In fact, “posting” a call merely means recording the fact of the interaction and updating data in the “Interactions” subsystem (status, subject, participants). All financial consequences arise only in related documents (order, sale, invoice), which are entered based on and already generate entries in RK accounts and tax movements. 6. Related Objects and Entry Based On Similar objects of the “Interactions” subsystem: “Meeting,” “Email (incoming/outgoing),” “Planned Interaction,” “SMS.” Entry based on (according to evidence scenarios): Scenario Direction of Entry 3.3 Creating a call based on a planned interaction “Planned Interaction” → “Phone Call” 3.5 Creating a meeting based on a call “Phone Call” → “Meeting” 3.2 Recording an outgoing call with the creation of a contact “Phone Call” → creating a contact/reference item Connection with CRM objects: through the attribute Basis and the “Subject of Interaction” mechanism, the call is linked to a counterparty/partner, contact person, deal, or sales document. From the call (as a result of negotiations), financial documents can then be entered — “Invoice,” “Customer Order,” “Sale of Goods and Services,” which already generate entries and, if necessary, ESF/SNT. Group Operations (scenario 3.4): mass reassignment of the Responsible attribute for selected calls through the “Group Change of Attributes” processing. 7. Extension Points - Attributes. Adding custom fields (for example, “Source of Inquiry,” “Category of Request,” “Duration of Call”) through configuration extension — header attributes of the document. - Object Module Handlers. Subscriptions to events OnSaving/ProcessingPosting for integration with external telephony (CTI), automatic call registration from PBX, task assignment. - Entry Based On. Extending “Create Based On” commands to generate tasks, support inquiries, sales documents. - Forms. Refining DocumentForm (dialing buttons, pop-up card of the caller) through extensions without removing the configuration from support. - Event Subscriptions (BSP). Using “Interactions” BSP mechanisms for integration with email, calendar, reminders. Requires verification (version-specific): the exact composition of form attributes and message texts may differ between releases — evidence on the structure is collected on releases 3.0.68.1, target version — 3.0.74.2. Verify the composition of mandatory fields and handlers in the configurator of the target release. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_