Document "СообщениеЭДОК" — technical description (Accounting for Kazakhstan 3.0.74.2)

1. Identification

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

2.2 Tabular section ПолучателиИПодписанты

Records the addressees and signatories of the electronic document and the result of the requirements presented to them.

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

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.