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 fieldsSubject,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/ProcessingPostingfor 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.