--- title: "Document \"СообщениеЭДОК\" — technical description (Accounting for Kazakhstan 3.0.74.2)" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-23 canonical: https://buhgpt.kz/suraqtar/dokument-soobshchenieedok-tehnicheskoe-opisanie-buhgalter-en source: BuhGPT --- # Document "СообщениеЭДОК" — technical description (Accounting for Kazakhstan 3.0.74.2) > **TL;DR:** 1. Identification Parameter Value Metadata type Document (Documents) Object name СообщениеЭДОК Full path Документ.СообщениеЭДОК ( Documents.СообщениеЭДОК ) Synonym “EDM Message for Kazakhstan” Configuration Accounting for Kazakhstan 3.0.74.2 Introduced in release 3.0.73 Interf --- 1. Identification Parameter Value Metadata type Document (Documents) Object name СообщениеЭДОК Full path Документ.СообщениеЭДОК (Documents.СообщениеЭДОК) Synonym “EDM Message for Kazakhstan” Configuration Accounting for Kazakhstan 3.0.74.2 Introduced in release 3.0.73 Interface section EDM / Electronic document exchange Where to find e1cib/list/Документ.СообщениеЭДОК Number String, length 9, numbering non-periodic (continuous) Posting Service document; does not generate accounting entries or register movements Purpose. СообщениеЭДОК is a service document of the electronic document management (EDM) subsystem for interaction with Kazakhstani operators. It records a state-change event of a previously sent or received electronic document: delivery, signing, rejection, status change, as well as actions of recipients and signatories. Essentially it is an exchange log record (audit trail): it does not reflect a business transaction and does not create accounting records, but logs what happened to the electronic document and how the exchange participants responded to it. Separation of roles in the subsystem. The transmitted content itself is stored by the objects ЭлектронныйДокументВходящийЭДОК and ЭлектронныйДокументИсходящийЭДОК, while each change of their state is a separate СообщениеЭДОК. A single electronic document may have several messages over its lifecycle (sent → delivered → signed → completed/rejected); their totality gives the full approval history. Usage mode. The document is created predominantly automatically — by the EDM subsystem when receiving/sending operator service messages and when statuses change. The user (the accountant responsible for EDM) refers to it to analyze the approval chain and to diagnose exchange failures. The document has no amount indicators or currency — it operates only with statuses and participants. (Note on the “country”: VAT 16%, accounts 1210/3130/6010, etc. relate to the primary accounting documents that generate an ЭСФ/СНТ; they do not affect the СообщениеЭДОК itself — it is amountless.) 2. Header attributes and tabular sections 2.1 Header attributes Attribute Purpose Номер Service continuous message number (string, 9 characters, non-periodic). Дата Date of the message registration in the database. Организация EDM subscriber to which the message relates; key filter in the journal. ЭлектронныйДокумент Reference to the incoming/outgoing electronic document whose state the message relates to. The main link for collecting history. СостояниеЭД “Message type” — the state of the electronic document (delivered, signed, rejected, etc.). СтатусДокумента Final status of the exchange document (in progress, completed, error, rejected). ДатаИзмененияСтатуса Moment of the state change; sorting field when building the approval chronology. ВходящийИндекс Transport identifier of the operator’s incoming message; used for reconciliation with the operator’s journal. ИдентификаторДокументаИзмененияСостояния Identifier of the state-change message on the EDM operator’s side; a key for diagnostics. ДополнительнаяИнформация Text explanation/diagnostics (error text, operator comment). 2.2 Tabular section ПолучателиИПодписанты Records the addressees and signatories of the electronic document and the result of the requirements presented to them. Column Purpose ПолучательЭД Recipient subscriber (exchange participant) to which the row relates. РезультатТребованияКПолучателю Result of fulfilling the requirement (sign/approve/review). ДатаВыполнения Date when the recipient fulfilled the requirement. ПользовательПолучателя Specific EDM user on the recipient’s side (if data is available). The conceptual basis of the object is the “EDM world”: EDM subscribers (exchange participants), EDM users, states and statuses of the ED, requirements to participants and the results of their fulfillment. 3. Forms Form Purpose List form (EDM message journal) The main working form. Viewing the message flow, filtering by Организация and the ДатаИзмененияСтатуса interval, grouping/sorting by СтатусДокумента and СостояниеЭД to highlight rejected/erroneous ones. Opened via e1cib/list/Документ.СообщениеЭДОК. Document form (message card) Viewing the attributes of a specific message and the ПолучателиИПодписанты tabular section; reading ДополнительнаяИнформация during diagnostics. Manual entry is practically not used. Selection form Selecting a message from other subsystem objects (for example, from an electronic document card). A separate printable form for the service document is not intended — it is not a primary accounting document. 4. Key module procedures The BSL sources of the handlers are not attached in the evidence, so below are the typical handlers of a document of this kind (service, non-postable, filled programmatically). Specific names/lines should be verified against the release configurator. Object module (typical set): - ОбработкаЗаполнения(ОснованиеЗаполнения, СтандартнаяОбработка) — programmatic filling of attributes (ЭлектронныйДокумент, СостояниеЭД, СтатусДокумента, ДатаИзмененияСтатуса, ВходящийИндекс, ИдентификаторДокументаИзмененияСостояния) when the message is created by the EDM subsystem. - ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты) — control of mandatory attributes: ЭлектронныйДокумент is specified, СостояниеЭД/СтатусДокумента are filled; checking that the recipients in the tabular section correspond to EDM subscribers. - ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения) — service preparation before writing (status normalization, setting ДатаИзмененияСтатуса). - The posting handler (ОбработкаПроведения) for this object is either absent or does not generate movements — the document is non-postable (see section 5). List/document form module (typical set): - ПриСозданииНаСервере — initial filters (by Организация), setting up conditional appearance (highlighting СтатусДокумента = “Rejected”/“Error”). - Filter and sort handlers by ДатаИзмененияСтатуса, СтатусДокумента, СостояниеЭД — for history analysis and bulk diagnostics. Logic on the EDM subsystem side (outside the document’s own module): - Receiving an operator message → creating a СообщениеЭДОК → filling the state/status and the ПолучателиИПодписанты tabular section (setting РезультатТребованияКПолучателю, ДатаВыполнения, ПользовательПолучателя). This logic is implemented by the common modules of the EDM subsystem, not by the document module. 5. Posting and movements СообщениеЭДОК is a service (non-postable) document. By standard logic it: - does not generate accounting entries (there are no accounting register movements; Kazakhstani accounts such as 1210, 1030, 1330, 3310, 3130, 6010, 7010 are not involved here — they relate to the primary documents that generate ЭСФ/СНТ); - does not make movements in tax/amount registers — the object has neither amount nor currency (tenge ₸ does not appear); - records exclusively status/transport information. The role of the data storage is played by the attributes and tabular section themselves, as well as by the objects ЭлектронныйДокументВходящийЭДОК/ЭлектронныйДокументИсходящийЭДОК. The practical effect of “posting” for exchange auditing is achieved not by movements but by the combination ЭлектронныйДокумент + ДатаИзмененияСтатуса + СостояниеЭД/СтатусДокумента, from which the approval history is built. Requires verification (version-specific): whether the “Posting = Allow” flag is set in the metadata of the specific release — in service documents it is often disabled. To be clarified against configurator 3.0.74.2. 6. Related objects and entry on the basis Related objects of the EDM subsystem: - ЭлектронныйДокументВходящийЭДОК — the incoming electronic document; referenced via the ЭлектронныйДокумент attribute. - ЭлектронныйДокументИсходящийЭДОК — the outgoing electronic document. - Catalogs/enumerations of EDM subscribers and users, ED states and statuses, types of requirements to recipients. - External RK exchange entities: ЭСФ (IS ESF) and СНТ — primary electronic documents whose transport events are logged by СообщениеЭДОК. Entry on the basis. Standard manual “entry on the basis” for a service document is usually not provided — messages are generated by the subsystem automatically from operator events. Messages are opened from the card of the corresponding electronic document and from the EDM message journal. Typical access scenarios (from the subsystem documentation): - Automatic registration of a status change (the system creates a message from the operator’s notification). - Receiving a delivery/signing confirmation (filling the ПолучателиИПодписанты tabular section). - Analyzing the approval history: filtering by ЭлектронныйДокумент, sorting by ДатаИзмененияСтатуса. - Tracking the result of the requirement to the recipient (РезультатТребованияКПолучателю, ДатаВыполнения). - Diagnosing an exchange failure (ДополнительнаяИнформация, СтатусДокумента, reconciliation of ВходящийИндекс/ИдентификаторДокументаИзмененияСостояния with the operator’s journal). - Bulk analysis of the journal over a period (filtering by Организация and the date interval, grouping by status/state). 7. Extension points - Configuration extensions (Extensions): overriding the ОбработкаЗаполнения, ОбработкаПроверкиЗаполнения, ПередЗаписью handlers of the object module; adding custom label attributes and columns to the ПолучателиИПодписанты tabular section. - Event subscriptions (Subscription): on the document’s ПередЗаписью/ПриЗаписи — for integration with external EDM monitoring, notifications about rejections/errors. - Forms: enhancing the list form (additional conditional appearance, custom quick filters by СостояниеЭД/СтатусДокумента), adding commands to navigate to the related electronic document. - Common modules of the EDM subsystem: extending the logic of mapping operator states/statuses when connecting a new EDM operator. - Additional reports/data processors: external reports on the message journal (exchange analytics by organizations and periods) without changing the object itself. General recommendation: perform enhancements in an extension without changing the standard object, since in the EDM subsystem the set of states/statuses and transport fields may change from release to release. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_