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

1. Identification

Purpose. The document is intended to reflect the operations of mutual settlement (closing) of reciprocal accounts receivable and payable for a single counterparty. It allows for the correct reflection of debt repayment through offsetting without actual cash movement. It is used when the counterparty simultaneously has both accounts receivable and payable that need to be closed without payment. The document is integrated with the tax accounting of the RK (KPN accounting) and supports multi-currency calculations.

Where to find. Section “Analytical Information” → “Closing of Dt/Ct Debt”. Also available through the document journals of the accounting subsystem.

2. Attributes of Header and Table Parts

2.1 Header Attributes

If a mandatory attribute is not filled, 1C does not process the document and issues “Field … is not filled in”.

2.2 Table Part “Debt”

3. Forms

4. Key Module Procedures

According to evidence, the handlers for the form DocumentForm are recorded:

• DebtFillOnServer (server procedure for filling) — automatically fills the table part “Debt” with the balances of mutual settlements by counterparties. Initially checks the settlement accounts: if NOT (DebitSettlementAccount AND CreditSettlementAccount), it issues a message “Incorrect data entered in the settlement account fields with counterparties!”. This means that auto-filling is only possible when both accounts (DebitAccount and CreditAccount) are indeed settlement accounts with counterparties.

• FillByBalances (command/procedure of the form) — initiates filling by balances. Contains a check Object.Posted: if the document is already posted, it issues “Filling is only possible in an unposted document”. Before re-filling, the document must be unposted.

Standard (typical for this type of object) handlers that are also involved here:

• PostingHandler (object module) — generates movements in the “Typical” and “Tax” registers based on the rows of the table part.
• FillingHandler — fills in default attributes (organization, tax accounting type) upon creation.
• OnChange of attributes DebitAccount / CreditAccount in the form — controls the correctness of accounts and, if necessary, clears/rebuilds the table part (scenario 3.3 “changing accounts after filling”).
• FillingCheckHandler — controls mandatory attributes of the header and columns of the table part before recording/posting.

5. Posting and Movements

When posting, the document generates movements in two accounting registers.

5.1 Typical Accounting Register (Main Entries)

For each row of the table part “Debt”:

• Debit: DebitAccount (from the header)
• Credit: CreditAccount (from the header)
• Amount: Debt.Amount

Subaccount:

Currency analytics: Currency ← Debt.CurrencyOfSettlements, currency amount ← Debt.AmountOfSettlements.

Typical entry of mutual settlement (₸):

Dt 3310 (Accounts Payable)  Ct 1210 (Accounts Receivable)  — for the amount of the offset

That is, the accounts payable to the counterparty (3310) is closed by its own accounts receivable (1210). Specific accounts are taken from DebitAccount/CreditAccount in the header — depending on the accounting situation, these may be other settlement accounts.

5.2 Tax Accounting Register (KPN Accounting)

Formed similarly to “Typical”, if AccountKPN = True:

• Debit/Credit, amounts, subaccounts — the same.
• Additionally, TaxAccountingType is taken into account for separating tax accounting of KPN.

The document reflects only the offset of debts and does not generate cash movements, VAT, or income/expenses. VAT (RK rate 2026 — 16%, account 3130), sales (6010), and cost of goods sold (7010) are generated by other documents (sales, receipts, ESF/SNT), and this document merely “collapses” the reciprocal balances of settlements.

5.3 Typical Errors When Posting/Filling

The texts are quoted verbatim from the configuration code (release 3.0.68.1). The formulations and conditions of errors are version-specific; please check upon updating the release.

6. Related Objects and Input Based On

• Counterparties, CounterpartyContracts, Transactions — sources of subaccount and analytics of settlements.
• Accounting Accounts (Typical Chart of Accounts): 1210, 1030, 1330, 3310, 3130, 6010, 7010 — RK accounts used in settlements, from which DebitAccount/CreditAccount are selected.
• Documents that serve as the basis for mutual settlements: sales of goods and services, receipts of goods and services, payments — form the initial balances of accounts receivable/payable (1210/3310), which this document closes.
• Electronic documents of the RK: ESF (ESF IS) and SNT are formed by accompanying documents of sales/receipts; the mutual settlement document does not issue an electronic document.
• Input based on: the typical document is usually entered independently (including auto-filling by balances). There are no special input chains for it in the basic delivery — check the composition of the “Create Based On” commands in the specific release.

7. Extension Points

• Event subscriptions PostingHandler / BeforeRecording of the document — to add custom movements (for example, separate analytics or additional register).
• Configuration extension of the form DocumentForm: overriding DebtFillOnServer for a non-standard algorithm for filling balances (scenario 3.5, manual adjustment).
• Additional attributes/information through the properties mechanism for mutual settlement analytics.
• Manual adjustment of entries (manual adjustment flag of movements) — for non-standard subaccounts not supported by automatic posting processing.
• BSP-handlers (BeforeRecordingExecute, additional reports and processing) — for embedding limit control and post-processing.