Document "ПисьмоОбменСБанками" (Letter with bank) — Accounting for Kazakhstan 3.0

1. Object identification

Purpose. The document is intended for registering and processing electronic correspondence between the organization and the bank within the electronic interaction system (technology 1С:DirectBank). Through it messages, notifications, requests and responses are sent and received: free-form letters, currency control documents, accompanying correspondence for payment orders. The document is used daily by accounting and treasury users when sending and receiving electronic documents. The list displays incoming and outgoing letters with the ability to filter by organizations, banks and letter types.

The document implements precisely correspondence (exchange of letters), not monetary transactions. Financial movements on the settlement account (account 1030 “Cash in current bank accounts”) are generated by payment documents (payment order, payment warrant), not by a letter.

2. Header attributes and tabular sections

Below are the field purposes according to the standard 1С:DirectBank electronic exchange document model. The specific set of attributes should be verified in the configurator of the particular release.

2.1. Header attributes

2.2. Tabular sections

The exact list of attributes and tabular sections is version-specific — verify against the object metadata in your release.

3. Forms

4. Key module procedures

The following code locations are confirmed by evidence (release 3.0.68.1, message texts — verbatim from the configuration):

Standard handlers (by object type — non-posting exchange document)

• ОбработкаЗаполнения (object module) — filling attributes when entering on the basis of (payment order, incoming letter).
• ОбработкаПроверкиЗаполнения — checking mandatory fields (organization, bank, exchange setting) before writing.
• ПередЗаписью / ПриЗаписи (object module) — recording the exchange status, updating message identifiers.
• Client form handlers: ПриСозданииНаСервере, ПриОткрытии — initialization of visibility and availability of elements depending on the direction and status of the letter.
• DirectBank integration procedures: sending a message, synchronizing statuses and loading incoming letters (scenario 3.5), verifying electronic signatures (scenario 3.6), exporting data for technical support (scenario 3.7) — implemented in the common modules of the bank exchange subsystem.

5. Posting and movements

The document is non-posting. The object metadata lacks a register_records section (register movements), and the modules have no ОбработкаПроведения procedure. As a result:

• The document does not generate accounting entries and does not create records in accumulation/information registers as part of its own posting.
• It records the fact and content of correspondence with the bank, not a business transaction.

Accordingly, the letter does not affect such accounts of the standard RK chart of accounts as:

Cash and settlement transactions (movements on 1030, mutual settlements on 1210/3310, revenue recognition 6010, cost of sales 7010, VAT on account 3130 “VAT payable” at the rate of 16%) are reflected by dedicated documents (payment orders/warrants, sales, receipts), as well as by electronic documents ESF (IS ESF) and SNT. The letter to the bank merely accompanies these transactions with correspondence.

If an audit of movements is required, they should be sought in the related financial documents, not in the letter.

6. Related objects and entry on the basis of

Main work scenarios

Related objects

• Bank exchange settings (1С:DirectBank) — a mandatory source of connection parameters; without an active setting, creating/sending a letter is blocked.
• Catalogs “Organizations”, “Banks”, “Bank accounts” — header attributes.
• Payment order — the basis document for the letter (scenario 3.4, ДокументОснование).
• ПисьмоОбменСБанками (itself) — the “letter → response” chain via ПисьмоОснование (scenario 3.3).
• Electronic signature key certificates — used in the “Подписи” form for signing and verification.

Entry on the basis of

• From a payment order → “Letter to bank” (scenario 3.4): organization, bank and exchange setting attributes are carried over from the basis document.
• From an incoming letter → response letter (scenario 3.3): ПисьмоОснование is filled, subject/addressee are inherited.

7. Extension points

• Configuration extensions (form modules): intercepting ЗаполнитьСпискиОрганизацийИБанков, ОформитьШапкуФормы, ОткрытьСертификат via &Вместо/&После for custom filtering of exchange settings or additional validation.
• Object module: extending ОбработкаЗаполнения (rules for entry on the basis of), ОбработкаПроверкиЗаполнения (additional mandatory fields), ПриЗаписи (integration hooks, exchange logging).
• Event subscriptions (document ПередЗаписью/ПриЗаписи) — for external auditing of correspondence without interfering with the object module.
• Additional attributes and information (properties mechanism) — for marking letters without changing the metadata.
• Common modules of the exchange subsystem — points for modifying the synchronization logic (scenario 3.5) and electronic signature verification (scenario 3.6).

Since the document is non-posting, adding your own movements (registers) via an extension is possible but atypical: use dedicated posting documents to reflect financial transactions, and keep the letter as a means of correspondence.

Typical errors (verbatim from code, release 3.0.68.1)

If you see such a message, check the condition in the third column. The message texts and procedure names require verification when moving to a different release — they are version-specific.