Document "Settlement Document with Counterparty" - Technical Description (Accounting for Kazakhstan 3.0)

1. Identification of the object

Purpose. The document is intended for manual accounting of settlements with counterparties — both receivables and payables. It is used by accountants and finance specialists when the operation is not covered by standard documents for receipt/sale: adjustment of debts, entry of initial balances for mutual settlements, accounting for other (non-standard) settlements. The structure is simple — counterparty, contract, amount, currency; there are no complex tabular parts.

2. Attributes of the header and tabular parts

2.1 Attributes of the header

Mandatory minimum for evidence: Organization. If the field is not filled — when recording/conducting, 1C will issue an error “Field … is not filled” and will not conduct the document. The completeness of the set of other mandatory fields is checked in ProcessingCheckFilling of the specific assembly — this is version-specific.

2.2 Tabular parts

According to evidence, the document “does not have a complex tabular structure” — this is a header-level operation (counterparty/contract/amount/currency). Tabular parts (if available in the specific assembly) are used as a breakdown of settlements by underlying documents; in the basic version, the document does not operate with them.

3. Forms

4. Key procedures of modules

In the provided modules (evidence) the procedure ProcessingConducting is absent, and the metadata contains register_records: []. Therefore, below are the typical handlers of this type of object; specific bodies of procedures — by assembly.

Object module:

• ProcessingCheckFilling(Refusal, CheckedAttributes) — control of mandatory attributes (at least Organization); formation of error messages.
• BeforeRecording(Refusal, RecordingMode, ConductingMode) — pre-recording logic (recalculation of amounts, setting service values).
• ProcessingFilling(FillingData, FillingText, StandardProcessing) — filling during input based on/copying.
• ProcessingConducting(...) — not found in evidence. See section 5 on how movements are formed.

Form module (DocumentForm):

• OnCreationOnServer — initial setup of the form, setting default values (organization, currency = tenge).
• OrganizationOnChange, CounterpartyContractOnChange, CurrencyOnChange — recalculation of dependent fields (exchange rate, currency of settlements).

Scenarios covered by forms (according to evidence): creating a new document, editing an existing one, copying, selection by filters (SelectForm), bulk modification of documents.

5. Conducting and movements

According to the metadata (register_records: []), the document does not have its own ProcessingConducting. This means one of two options:

1. The document only stores data (without direct formation of movements), and
2. Movements are formed by an external mechanism of the BK 3.0 configuration — a typical mechanism for manual/standard operations and a subsystem for reflection in regulated accounting.

The standard scheme for reflecting settlements with counterparties according to the typical chart of accounts of the RK (accounting register, analytics: Counterparty, Contract):

VAT calculation: VAT amount = amount without VAT × 16 % (or allocation of 16/116 from the amount with VAT). All amounts — in tenge (₸); in the case of a currency contract, conversion is done at the exchange rate on the date of the document.

Requires verification (version-specific): whether the specific assembly 3.0.74.2 generates movements directly from the document or through a related operation/standard reflection mechanism. The set of movement registers is determined by the implementation of the assembly, as it is empty in evidence.

6. Related objects and input based on

• Directories: Organizations, Counterparties, CounterpartyContracts, Currencies, StructuralDepartments, Users.
• Registers: accounting register (typical chart of accounts of the RK), registers of mutual settlements with counterparties.
• Electronic documents of the RK: the results of settlements participate in chains reflected in ESF (electronic invoice, IS ESF) and SNT (accompanying invoice for goods) — the manual document of settlements usually does not directly generate ESF/SNT, but affects the state of mutual settlements used when issuing them.
• Input based on / copying: copying is supported for recurring operations (monthly settlements) and filling in attributes from the underlying document through ProcessingFilling.

7. Extension points

• Configuration extensions: overriding/adding ProcessingConducting, ProcessingCheckFilling, BeforeRecording in the object module; adding header attributes without removing support.
• Forms: adding elements and handlers in DocumentForm/ListForm through form extension.
• Event subscriptions: BeforeRecording/OnRecording/ProcessingConducting for external logic of movement formation or integration with ESF/SNT.
• BSM mechanisms: bulk modification of attributes (scenario 3.5), versioning of objects, additional attributes/information.
• Reflection in accounting: in the absence of its own ProcessingConducting, custom logic for postings should be correctly placed in the general reflection module/standard operation, rather than hard-coded in the document.