Document "OutgoingElectronicLetter" - Technical Description (Accounting for Kazakhstan 3.0.74.2)

1. Identification

Purpose. The document is used for creating, editing, and sending electronic mails directly from 1C. It is an element of the subsystem for managing interactions with counterparties, partners, and internal users. The document is integrated with email accounts, supports the creation of mails based on other interactions (meetings, phone calls, incoming mails), works with attachments and templates, manages sending statuses, and stores the history of correspondence. It is used by employees of sales, procurement, accounting departments, and managers for formal communication. Access to the mail is restricted by the rights of the responsible person, author, and account owner through the RLS (Row-Level Security) mechanism.

Important: this is a communication document, not an accounting document. It does not participate in tax and accounting records, does not operate with VAT amounts (in the RK from 2026 — 16%), MRP (4,325 ₸), or account plan invoices. The mail can only contain as an attachment accounting and electronic documents (for example, printed invoice form, electronic invoice (ESF), tax invoice), but does not itself generate movements and amounts.

2. Attributes of Header and Table Parts

2.1 Header Attributes

2.2 Table Parts

Attachments (files) are stored not in the table part, but in a separate directory of attached files OutgoingElectronicMailAttachedFiles, linked to the owner document. Attached mails (scenario 3.7) are stored as attached files in .eml format.

Requires verification in a specific release: in different versions of BSP, the set of columns in the table part “Recipients” and the presence of separate TPs for CC/BCC may differ — in 3.0.7x recipients are usually separated by the RecipientGroup field within one TP.

3. Forms

Additionally, common forms of the “Interactions” subsystem are used: form for clarifying recipient contacts (scenario 3.6), form for working with message templates (scenario 3.4), form for selecting the email account.

4. Key Module Procedures

From evidence, the following handlers are extracted (the message texts are quoted verbatim from the code, release 3.0.68.1; in 3.0.74.2 the logic is preserved):

Standard handlers of this type of object (general logic, not from evidence):

• OnFillProcessing — filling during input based on (substituting the recipient from the counterparty, subject, subject of correspondence).
• BeforeWrite / OnWrite — fixing the sending status, updating the register of interaction subjects, recalculating size.
• Form handlers OnCreateOnServer, OnOpen — initializing the default email account, preparing the list of recipients and attachments.

Supported scenarios (from evidence): creating a mail from scratch (3.1), replying to an incoming (3.2), forwarding (3.3), creating from a template (3.4), delayed sending (3.5), clarifying recipient contacts (3.6), adding attachments and nested mails (3.7).

5. Posting and Movements

The document is not posted and does not generate movements — in the metadata register_records = []. It does not create records in accounting registers, accumulations, and information on the accounting circuit.

Hence:

• The document does not create postings according to the RK chart of accounts (accounts 1210 “Short-term receivables from customers”, 1030 “Cash in current accounts”, 1330 “Goods”, 3310 “Payables to suppliers”, 3130 “VAT payable”, 6010 “Revenue from sales”, 7010 “Cost of sales”, etc. are not involved here).
• Amounts, rates, and taxes (VAT 16%, PIT, social tax, health insurance, etc.) are not calculated by the document.
• All “movement” of the document is the fact of sending a mail message through the SMTP server of the account and the service binding to the subject of interaction (through the information register InteractionFolderSubjects / InteractionStates of the “Interactions” subsystem).

If the mail is used to send accounting or electronic documents to the counterparty (invoice, electronic invoice (ESF) via the ESF IS, tax invoice), then the formation of these documents and their postings/export is the responsibility of the relevant accounting objects (sales, ESF, tax invoice), not the mail. The mail only carries them as attachments.

6. Related Objects and Input Based On

Input based on the outgoing mail — usually the mail itself is the result of input based on, not the source. Typical sources (creating a mail “Reply”/“Forward”/“Write”):

Related objects:

• Reference.EmailAccounts — from whose name and through which SMTP it is sent.
• Reference.OutgoingElectronicMailAttachedFiles — attachments.
• Registers of the “Interactions” subsystem: subjects, states, folders, delayed for sending.
• Document.IncomingElectronicMail — the second half of the correspondence chain (linked by MessageIdentifier / subject).

7. Extension Points

• Configuration extension (without removal from support): adding attributes/columns to the document and form, overriding form handlers DocumentForm (SendExecute, SendForwardExecute), adding custom commands (for example, “Attach ESF”, “Attach tax invoice”).
• BSP programming interfaces: modules Interactions, WorkWithMailMessages, WorkWithMailMessagesClient — overridable procedures for forming and sending mails.
• “Properties” mechanism (TP AdditionalAttributes) — extending the composition of mail characteristics without changing metadata.
• Message templates (Reference.MessageTemplates) — typification of mail texts (offer invoice, debt notification) for implementation tasks.
• Attached files — integration with external storage (volumes, S3) through the file management subsystem.
• Exchange rules / business processes — launching mail sending from business processes and tasks.

Requires verification in a specific release 3.0.74.2: the exact composition of export procedures of modules Interactions* is version-dependent — before overriding, check with the current syntax assistant of the configuration.