1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | TypesOfLettersExchangeWithBanks |
| Full Name | Catalog.TypesOfLettersExchangeWithBanks (Catalogs.TypesOfLettersExchangeWithBanks) |
| Alias | — (not specified) |
| Configuration | Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 |
| Accounting Currency | Tenge (₸) |
Purpose. The catalog classifies and stores a list of types of electronic letters and documents that the organization exchanges with banks through electronic document management (EDM) mechanisms. It is used for configuring and identifying various types of correspondence with banking institutions during automated data exchange.
The object is service: it is accessed by system administrators and accountants working with banking operations, primarily at the initial setup stage of exchange channels or when adding new types of documents. In everyday work, the catalog is called by internal exchange mechanisms to determine the type of transmitted/received document.
Where to find in 1C: section “Electronic Interaction” → “Types of Letters Exchange with Banks”.
Navigation link: e1cib/list/Catalog.TypesOfLettersExchangeWithBanks
2. Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| Direction | EnumRef.DirectionsED |
Optional (DontCheck) | Defines the direction of document flow — incoming or outgoing letter. Allows classifying types of letters by the direction of data transmission between the organization and the bank |
| Template | String (xs:string) |
Optional (DontCheck) | Stores the template/sample of the letter or document for this type. Can be used for automatic generation of exchange documents with the bank according to the specified sample |
| Invalid | Boolean (xs:boolean) |
Optional (DontCheck) | Flag indicating that the type of letter is no longer used in exchanges with banks. Allows excluding outdated document types from active use without physically deleting them from the catalog |
In addition to the listed attributes, the element has standard fields of the platform catalog: Code, Name, DeletionMark, Predefined, Reference.
2.2 Table Parts
Table parts are absent. The catalog has a flat structure — data is stored only at the header level of the element.
3. Forms
The catalog contains three forms:
| Form | Purpose |
|---|---|
| ListForm | List of catalog elements (≈29 UI elements). The main form for viewing all types of letters exchanged with banks, searching and filtering by attributes (including by the “Invalid” flag) |
| ElementForm | Form for editing a single element (≈11 UI elements). The key form for the user when creating or modifying a letter type: filling in the direction, template, and relevance flag |
| SelectForm | Form for selecting an element (≈23 UI elements). Used when selecting a letter type in other system objects (documents and bank exchange processes) |
4. Key Module Procedures
No application BSL code (object module / form modules) is attached in evidence. For a catalog of this type, a minimal set of service handlers is typical; specific presence is determined by the configuration version.
Standard handlers for a catalog of this type:
- Object Module —
ProcessingFilling,BeforeSaving,OnCopy. Usually not overridden or contain default attribute filling (for example, settingDirectionwhen creating a new element). - Element Form Module —
OnCreateOnServer(setting availability/visibility of fields, including blocking editing when the “Invalid” flag is set),OnChangeInvalid(visual formatting of outdated elements). - List Form Module —
OnCreateOnServerwith setting conditional formatting of rows (strikethrough/shading of invalid types) and filtering configuration. - Manager Module — if available, contains functions for obtaining the letter type by direction/code for exchange mechanisms.
“Requires verification” (version-specific): the exact composition of handlers
ElementForm/ListFormand the presence of the manager module in release 3.0.74.2 — to be clarified by the configurator of the specific delivery.
5. Posting and Movements
The catalog is a non-postable metadata object. It does not generate postings to accounting accounts and does not create movements in accumulation/summary registers. Its role is regulatory and reference (classifier of letter types).
Indirectly, the values of the catalog participate in documents and processes of exchange with the bank, which already generate accounting movements. However, the letter type itself does not generate postings; typical postings for monetary and settlement operations in the RK, where these documents are involved, use accounts from the unified chart of accounts of Kazakhstan, for example:
| Operation | Dr | Cr |
|---|---|---|
| Receipt of money into the current account from the buyer | 1030 (money in current accounts) | 1210 (short-term receivables from buyers) |
| Payment to the supplier from the current account | 3310 (payables to suppliers) | 1030 |
| Sale of goods to the buyer | 1210 | 6010 (income from sales) / 3130 (VAT payable) |
| Cost of goods sold | 7010 (cost of sales) | 1330 (goods) |
Reference values of current rates and amounts in the RK for 2026, used by related documents (for context, not for movements of this catalog): VAT 16%; MRP 4,325 ₸; MSP 85,000 ₸; basic tax deduction for individual income tax 30 MRP/month (not more than 360 MRP/year); individual income tax 10% up to 8,500 MRP annual income and 15% above; OPE 10% (ceiling base 50 MSP), OPEA 3.5%, VOSMS 2%, OSMS 3%, SO 5%, social tax 6%. Electronic documents of the RK: ESF (IS ESF), CNT.
6. Related Objects and Input on Basis
Enumeration.DirectionsED— source of values for the “Direction” attribute (incoming/outgoing).- Documents and processes of exchange with the bank (Client-bank / DirectBank) — consumers of the catalog: use the letter type to identify transmitted and received messages within the “Electronic Interaction” subsystem.
- Registers and EDM settings — use catalog elements as a classifier when routing messages.
Input on Basis. For a service classifier catalog, the “Input on Basis” mechanism is not standardly provided; the element is used as a value of an attribute in other objects, not as a basis for creating documents.
7. Extension Points
- Configuration Extension: adding custom attributes (for example, bank format code, encryption flag) and columns in
ListForm/SelectFormwithout removing from support. - Form Handlers: overriding
OnCreateOnServerof the element form to control field availability and conditional formatting of outdated types. - Event Subscriptions (
BeforeSaving/OnSaving): control uniqueness of letter type by direction, auto-filling the template. - Additional attributes and information (property subsystem) — for storing unregulated characteristics of the letter type without changing metadata.
- Programmatic API of the object manager — adding functions to retrieve the letter type by direction/code for use in custom exchange mechanisms.