1. Identification
| Parameter | Value |
|---|---|
| Object type | Catalog |
| Name | ВидыСвязейМеждуПартнерами |
| Full name | Справочник.ВидыСвязейМеждуПартнерами (Catalogs.ВидыСвязейМеждуПартнерами) |
| Synonym | "Types of Relationships Between Partners" |
| Configuration | Trade Management for Kazakhstan, edition 3.4.5.21 |
| Purpose | Stores a list of possible types of relationships between the trading company's customers and suppliers: head office, branch, dealer, competitor, subsidiary, etc. Used as a classifier (type) in records describing relationships between partners. |
Nature of the object. This is a simple classifier catalog (an enumerable list of values). It is not an accounting document, is not posted, and does not generate register entries. Its items serve as attribute values when describing relationships between partners (e.g., in the pair "Partner A — relationship type 'Branch' — Partner B").
Where to find it. 1C navigation link:
e1cib/list/Справочник.ВидыСвязейМеждуПартнерами
In the interface, items are typically accessible from the partner card (section Master Data and Administration → Partners) when filling in the relationships block, and the list itself is available via "All Functions" or the navigation link above.
2. Header attributes and tabular sections
The catalog has a minimal classifier structure. The evidence does not include the detailed attribute composition, so below are the standard fields for a catalog of this kind; the classifier has no project-specific tabular sections.
2.1. Standard attributes
| Attribute | Type | Purpose |
|---|---|---|
Код (Code) |
String/Number | Unique item code, auto-numbering |
Наименование (Description) |
String | Name of the relationship type: "Head Office", "Branch", "Dealer", "Competitor", "Subsidiary", etc. |
ПометкаУдаления (Deletion Mark) |
Boolean | Flag indicating the item is marked for deletion |
Предопределённый (Predefined) |
— | Flag indicating a predefined item (if some relationship types are supplied with the standard configuration) |
2.2. Possible classifier header attributes
| Attribute | Type | Purpose |
|---|---|---|
Комментарий / Описание (Comment / Description) |
String | Textual explanation of the relationship type |
ОбратныйВидСвязи (Reverse Relationship Type, if present) |
CatalogRef.ВидыСвязейМеждуПартнерами | Paired (symmetric) relationship type for bidirectional description: "Head Office" ↔ "Branch", "Supplier" ↔ "Customer" |
Needs verification in the specific 3.4.5.21 build: whether an attribute for the reverse/paired relationship type exists is a version-specific detail of the attribute composition.
2.3. Tabular sections
The catalog has no tabular sections — it is a flat classifier.
3. Forms
Standard set of forms for a classifier catalog:
| Form | Purpose |
|---|---|
Item Form (ФормаЭлемента) |
Viewing and editing a single relationship type: description, code, reverse relationship type (if present), comment |
List Form (ФормаСписка) |
Viewing and maintaining the full list of relationship types, search, deletion marking |
Selection Form (ФормаВыбора) |
Selecting a value when filling in the relationship type in a partner card / relationships register |
If no custom forms are defined in the configuration, the platform uses auto-generated forms based on the attribute structure.
4. Key module procedures
The attached evidence contains only the purpose facet (naznachenie); the BSL module code is not included. Therefore, the typical handlers characteristic of a classifier catalog are listed below; specific lines cannot be cited due to the absence of code evidence.
Item form module:
ПриСозданииНаСервере(OnCreateAtServer) — initial form setup, field availability.ОбработкаПроверкиЗаполнения(FillCheckProcessing) — checks that the description is filled in (required), uniqueness check if needed.ПередЗаписьюНаСервере/ПриЗаписиНаСервере(BeforeWriteAtServer / OnWriteAtServer) — internal logic before writing (usually absent for a pure classifier).
List form module:
ПриСозданииНаСервере(OnCreateAtServer) — configuring conditional formatting, filters.
Object module (МодульОбъекта):
ОбработкаЗаполнения(FillingProcessing) — default field population for a new item.ПередЗаписью/ОбработкаПроверкиЗаполнения(BeforeWrite / FillCheckProcessing) — validation; if a paired relationship type exists, synchronization of the reverse reference.
For a classifier catalog, the object and manager modules in the standard configuration are usually empty or contain only standard fill-check logic. There is no key business logic (calculations, movements) here.
5. Posting and register movements
The catalog is not posted and generates no register movements — catalogs in 1C have no posting mechanism. A "Type of relationship between partners" item is an attribute value, not a business transaction.
Accordingly, this object does not create any accounting entries on its own. Therefore, applying Kazakhstani accounts, rates, and norms to the catalog itself is not applicable — it does not participate in tax calculation or accounting.
Configuration context (for reference, to link with the overall logic of Trade Management for Kazakhstan 2026). This classifier indirectly affects partner-related analytics (e.g., distinguishing a head office from a branch in mutual settlements), while the shipment/receipt documents linked to these partners generate movements and entries under the standard Kazakhstani chart of accounts:
| Operation | Dr | Cr |
|---|---|---|
| Sale of goods to a customer | 1210 (short-term customer receivables) | 6010 (sales revenue) |
| VAT accrual on sale, rate 16% | 1210 | 3130 (VAT payable) |
| Write-off of cost of sales | 7010 (cost of sales) | 1330 (goods) |
| Receipt of goods from a supplier | 1330 | 3310 (accounts payable to suppliers) |
| Payment from customer | 1030 (cash in current accounts) | 1210 |
Kazakhstani electronic documents (ESF via the ESF Information System, SNT) are issued from sales/transfer documents, not from this catalog. Numerical norms for Kazakhstan for 2026 (MCI = 4,325 ₸, minimum wage = 85,000 ₸, VAT rate 16%, individual income tax 10%/15%, mandatory pension contributions 10%, employer's mandatory pension contributions 3.5%, mandatory social health insurance contributions (employee) 2%, mandatory social health insurance contributions (employer) 3%, social contributions 5%, social tax 6%, standard individual income tax deduction of 30 MCI/month, up to 360 MCI/year) apply to settlement documents (sales, payroll, taxes) and are not relevant to this classifier.
6. Related objects and "input based on"
Related objects:
Справочник.Партнёры(Catalog.Partners) — the main consumer. The relationship type is used when describing relationships between partners (who is the head office, branch, dealer, or competitor of whom).- The partner relationships mechanism/register (in the standard Trade Management configuration, stores pairs "partner — relationship type — partner"); items of this catalog serve as the value of the "Relationship Type" dimension/attribute.
Input based on. For a classifier catalog, "input based on" and creating items based on other documents are not provided — it is filled in manually by the user and selected in relationship cards/lists.
7. Extension points
- Adding attributes via an extension. A configuration extension can add attributes (e.g., "Priority", "Relationship Group", an "Intra-holding Relationship" flag) without removing the standard configuration from support.
- Form handlers.
ПриСозданииНаСервере(OnCreateAtServer),ОбработкаПроверкиЗаполнения(FillCheckProcessing) of the item form are convenient points for additional validation (preventing duplicate names, auto-filling the reverse relationship type). - Event subscriptions.
ПередЗаписью/ПриЗаписи(BeforeWrite/OnWrite) of the object — for synchronizing paired relationship types or integrating with external master data systems. - Predefined items. If it is necessary to guarantee the presence of basic types ("Head Office", "Branch"), they can be set up as predefined and referenced by name in code.
- Reporting/Data Composition System. The classifier can be used as a dimension in reports on the structure of the partner network (grouping receivables/payables by relationship type), based on accounts 1210/3310.
Needs verification in build 3.4.5.21: the exact composition of predefined items and the presence of a reverse relationship type attribute may differ between releases of the 3.4 line.