Document "AvisoMiscellaneous" ("Aviso for Other Transactions") - Technical Description (BK 3.0.74.2)

1. Identification

Purpose. The document is intended to reflect inter-budget transfers, asset transfers, and other operations between structural divisions within one organization. It allows for simultaneous operation in accounting (BU) and tax (NU) accounting, forming bilateral entries “sender → recipient” across an arbitrary set of accounts. It is used when standard documents for turnover (sales, transfers, receipts) are not suitable: one-time accounting adjustments, transferring balances between divisions, executing orders from higher authorities. Working with the document requires knowledge of the chart of accounts and sub-accounts — amounts and accounts are entered manually by the user in the table part or filled in based on balances.

All monetary amounts are in tenge (₸). Relevant for the RK in 2026: VAT rate 16%, MRP 4,325 ₸, MSP 85,000 ₸ (the rates are not “hardcoded” in the document — they are applied in related objects, for example, when entering an electronic invoice (ESF)).

2. Attributes of the Header and Table Parts

2.1 Header Attributes

The attributes of the sender/recipient at the division level are set in the rows of the table part through the sub-accounts of the accounts; the visibility of the recipient's columns is switched on the form (see p. 3 and scenario 3.5).

2.2 Table Part “DataBukh”

The main table part, where the operation “from the sender's account to the recipient's account” is described line by line in BU and NU.

Control of filling. The listed mandatory columns are checked during processing. If at least one of them is not filled, the platform will not process the document and will issue an error of the type “Field … is not filled”.

3. Forms

The specificity of the document form is the mechanism for switching the visibility of recipient attributes (scenario 3.5): when reflecting a simple operation, the columns of the recipient side can be hidden to simplify input and shown again if necessary.

4. Key Procedures of Modules

From the attached evidence for the object:

• GenerateEntry (ManagerModule, manager module) — the central method of processing. It generates bilateral entries for each line of the table part: for BU — Dr RecipientAccountBU – Cr SenderAccountBU with the corresponding sub-accounts, amount, quantity, and currency data of the line; for NU — Dr RecipientAccountNU – Cr SenderAccountNU with the accounting type and NU sub-accounts. NU entries are created only when the NU accounts are filled and ReflectInNU = True (the flag is determined automatically based on the selected account).

Standard handlers for documents of this type (if there is no explicit evidence — standard implementation of BK 3.0):

• ProcessingConducting (object module) — iterates through the rows “DataBukh” and calls the generation of movements/entries through the manager logic.
• ProcessingFillingCheck (object module) — control of mandatory header attributes (Organization) and mandatory columns of lines (BU/NU accounts, NU accounting types).
• OnCreateOnServer / OnOpen (form module) — initial setup of the form, setting the visibility of recipient columns.
• Form commands for switching the visibility of recipient attributes (scenario 3.5) and handlers for filling the table part based on the balances of BU accounts (scenario 3.2).

5. Processing and Movements

When processing, the document generates movements in two registers of accounting:

• AccountingRegister.Standard — accounting (BU);
• AccountingRegister.Tax — tax accounting (NU).

BU Entry (for each line):

Dr RecipientAccountBU (recipient's sub-account) — Cr SenderAccountBU (sender's sub-account)
Amount         = <Line Amount>
Quantity       = <Line Quantity> (if the account is quantitative)
Currency       = <Line Currency>
CurrencyAmount  = <Line CurrencyAmount>

NU Entry (for each line, when ReflectInNU = True and NU accounts are filled):

Dr RecipientAccountNU (NU recipient's sub-account) — Cr SenderAccountNU (NU sender's sub-account)
Amount    = <Line Amount>
AccountingType = <NUAccountingTypeRecipient / NUAccountingTypeSender>

Feature: specific accounts for entries are not fixed by the algorithm — they are taken from the lines of the table part. The user determines the correspondence, making the document universal. Examples of correspondences according to the standard chart of accounts of the RK:

• transfer of goods between divisions: Dr 1330 – Cr 1330 (different sub-accounts “Warehouses”/“Divisions”);
• transfer of cash balances: Dr 1030 – Cr 1030;
• adjustment of calculations: Dr 1210 – Cr 1210, Dr 3310 – Cr 3310.

Since the operation is performed within one organization, it typically does not involve income/expense accounts (6010, 7010) and tax accounts (3130 VAT) — the document does not calculate VAT and does not generate tax liabilities.

6. Related Objects and Input Based on

• Chart of accounts: Economic (BU) and Tax — the source of accounts and the structure of sub-accounts for lines.
• Sub-account directories: Nomenclature, Warehouses, Divisions, Counterparties, Cost Items, etc. — depending on the selected accounts.
• Accounting registers “Standard” and “Tax” — receivers of movements.
• Accounting reports (OSV, Account Card, Account Analysis) — reflect the results of processing the avizo.

The document is used in specific one-time situations; standard commands “Input based on” from it/to it are not provided in the standard delivery. Filling is done manually (scenario 3.1) or based on the balances of the sender's BU accounts (scenario 3.2). Electronic documents (ESF in IS ESF, SNT) are not related to internal avizo — they are generated from sales/movement documents with movements between counterparties.

7. Extension Points

• Manager module, GenerateEntry — if necessary, change the rules of correspondence or add account checks using method extension (subscriptions/overriding in the configuration extension).
• ProcessingConducting / ProcessingFillingCheck — adding custom row controls and additional movements to information/accumulation registers.
• Document and list forms — adding form attributes, commands, changing the logic of visibility of recipient columns through form extension.
• Additional attributes and information (the “Properties” mechanism) — extension without changing the configuration.
• Event subscriptions of the document (BeforeWriting, OnWriting) — integration with external accounting/exchange.

Requires verification in a specific version: the exact composition of sub-accounts for NU accounts and the rule for auto-determining the flag ReflectInNU may differ between releases of the 3.0.74.x line.