Document "Bank Exchange Settings" (Accounting for Kazakhstan 3.0.74.2)

1. Identification

What it essentially is. The object is not a business transaction, but a connection settings card. One record describes one pair Organization–Bank and is used when sending payment orders, receiving statements, and exchanging registers. The system accesses the record from both interactive processes (sending payments, loading statements) and scheduled tasks for automatic exchange.

Requires verification (version-dependent): in a number of releases of the 3.0 line, the storage object for these settings is implemented as a directory, in others — as a document. In the evidence, the structure is described as "header attributes," therefore below the object is considered as a document; when modifying, clarify the metadata of the specific delivery 3.0.74.2.

Where to find in 1C: section "Electronic Interaction" → "Bank Exchange Settings" (or "Bank and Cash" → "Exchange with Banks" → "Bank Exchange Settings"). Navigation link: e1cib/list/Document.BankExchangeSettings

2. Attributes and Table Parts

2.1 Header Attributes

2.2 Table Parts

In the attached evidence, table parts are not recorded. For an object of this type, the following are characteristic (if available — clarify according to the delivery metadata):

• Certificates / Signatures — list of electronic signature certificates and the order of signing outgoing documents (signing route);
• BankAccounts — accounts of the organization in this bank participating in the exchange;
• AdditionalParameters — pairs "Key–Value" for specific settings of a particular bank format.

If multiple accounts/signers are used for a specific pair Organization–Bank, this data is stored in such table parts or in related bank account settings.

3. Forms

The specific list of forms in the BSL evidence is not attached — the composition is indicated according to the typical implementation of the bank exchange object in BK 3.0.

4. Key Procedures of Modules

BSL code in the evidence is not attached, so below are the typical handlers of this type of object (object module / form module):

Object Module:

• FillProcessing() — filling in default attributes when created from the wizard or based on the bank (transferring BankName, BankBranchNumber from the Bank directory, setting FormatVersion).
• CheckFillProcessing() — control of mandatory filling: when UsesCryptography = True — presence of a certificate; when ServerAddress is filled — correctness of URL; non-empty Organization and Bank.
• BeforeSaving() — synchronization of dependent fields (for example, copying bank data), normalization of resource addresses.

Form Module:

• OnCreateOnServer() — managing the visibility of attribute groups depending on BankProgram (for Sberbank Online, cryptography fields are shown, for asynchronous — REST resources).
• BankProgramOnChange() — restructuring the availability of attributes under the selected type of exchange.
• UsesCryptographyOnChange() — enabling/disabling certificate fields.
• CheckConnection() (command) — test call to the bank server using the entered attributes.

5. Posting and Movements

The object is not a business document and does not generate accounting entries and movements in accounting registers. It is a configuration record; when saved, it only stores connection parameters (and, if available, registers them in the service information registers of the bank exchange subsystem — for example, the register of correspondence of bank accounts to exchange settings and electronic document statuses).

Accounting movements arise in related bank documents that use this setting for sending/loading. According to the typical chart of accounts of the RK:

Settlements with the budget (payment of taxes and contributions), initiated by payment orders through the same exchange, use liability accounts: PIT, OPE (10%, base cap 50 MCI = 50 × 85,000 ₸), OPEI (3.5%), VOSMS (2%), OSMS (3%), SO (5%), social tax (6%); amounts are formed in payroll/tax documents, and the write-off is reflected by the entry Dr 3120/3210/3220… — Cr 1030. All amounts are in tenge (₸). The object "BankExchangeSettings" does not participate in these entries — it only provides the channel for transmitting payment documents to the bank.

6. Related Objects and Input Based On

Uses (references):

• Directory.Organizations — owner of the settings;
• Bank directory and Directory.BankAccountsOfOrganizations — accounts participating in the exchange;
• Enumeration.BankPrograms — type of exchange system;
• Directory.AdditionalReportsAndProcesses — external processing of custom format;
• electronic signature/cryptography subsystem — signature and encryption certificates.

Used (consumers of the settings):

• Document.PaymentOrder — sending outgoing payment orders to the bank;
• Document.DebitFromCurrentAccount / Document.ReceiptToCurrentAccount — generated when loading bank statements through this setting;
• processes/scheduled tasks for automatic payment export and statement loading;
• registers of statuses and queues of electronic documents exchanged with the bank.

Input Based On. The setting is usually created through the exchange setup wizard (wizard), not by input based on. Pre-filling of attributes from the selected bank/organization is possible. Conversely — based on the ready setting, an exchange session is initiated (sending payments, receiving statements), but these are commands, not documents "based on."

Bank exchange relates to the bank-client channel and does not intersect with the contour of electronic invoices (ESF in the ESF IS) and STS — these are independent mechanisms of electronic interaction.

7. Extension Points

• External exchange processing — attributes AdditionalProcessing and ExternalModuleName allow connecting a custom exchange algorithm for a non-standard bank without changing the configuration.
• Configuration Extension: adding connection attributes for new banks, additional format flags; subscribing to events BeforeSaving/CheckFillProcessing for custom attribute checks.
• Enumeration BankPrograms — adding new types of exchange (with support from the corresponding processing code).
• Scheduled tasks for automatic statement retrieval/payment sending — redefining schedules and conditions (AutomaticStatementRetrievalAvailable).
• Additional parameters (table part "Key–Value," if available) — extension without changing the metadata structure.
• Cryptography subsystem — substituting the electronic signature provider and signing rules to comply with the requirements of the NUС RK.