Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).
You open the card of an LLP that has long been purchasing goods from you, and you recall: it has a "sister" — a second LLP with the same founders. Advances sometimes come from it, but you ship to the first one. You keep this in your head, but nowhere in 1C. And when the tax authority sends a request about related parties, or when you're figuring out why one partner has a debt while another has an overpayment, you need the connection between these two partners to be visible right in the program. That's exactly what the "Types of Relations Between Partners" directory is for: it stores the wording of such relations — "parent organization," "founder," "related party," "competitor."
1. Purpose
This is a classifier directory. You don't keep amounts here or make postings. You describe types of relationships between partners so that later, in a partner's card, you can indicate: "this partner is a subsidiary of that one." The relations themselves are stored separately (in the partner's data), and this directory just gives them a name and a "reverse" wording.
2. Where to find it
This is a service directory, so there's often no dedicated command for it in the main menu. Three working paths:
- From the partner's card (the main way). Section CRM and Marketing → Partners (or Sales → Customers) → open the partner → go to their relations ("More → Relations" / navigation panel of the card "Relations") → Create → in the "Relation type" field, click the selection button and create a new item.
- Via navigation link. Main menu (≡ icon in the top left corner) → Tools → Go to link and paste:
e1cib/list/Справочник.ВидыСвязейМеждуПартнерамиThis will open the full list of relation types. - Via "All functions" (if enabled): Main menu → All functions → Directories → Types of Relations Between Partners.
If there's no "Relations" section in the partner's card — enable partner relationship functionality: Master data and administration → CRM and Marketing → Customer Relationship Management.
2a. How to find out your release
Main menu (≡) → Help → About the program. In the window that opens, you'll see the platform version (e.g., 8.3.24.x) and the configuration release — "Trade Management for Kazakhstan, edition 3.4 (3.4.5.21)." Everything written below refers specifically to release 3.4.5.21; in other versions, the field layout may differ.
3. How to fill it in
There are few fields — this is a classifier, not a document. But you need to fill them in carefully, because the wording determines how the relation reads in both directions.
| Field | Required | Purpose and what happens if there's an error |
|---|---|---|
| Name | Yes | Direct wording of the relation, as it reads from the first partner to the second: "Parent organization," "Founder," "Related party." Cannot be saved blank. If written vaguely ("relation1"), later in the partner's card you won't understand who is who to whom. |
| Reverse relation name (reverse name) | Recommended | Wording from the other side. For "Parent organization," the reverse is "Subsidiary organization"; for "Founder" — "Established organization." If not filled in, the program will show the same direct wording in the second card, and the relation will read incorrectly (the partner will appear to be its own "parent organization"). |
| Code | Filled in automatically | Don't touch it: numbering is maintained automatically, needed only for internal reference. |
Procedure:
- Come up with a neutral direct wording — how the relation sounds from the first partner to the second.
- Fill in the reverse wording — how the same relation sounds in the opposite direction. This is the key point: relations are bidirectional.
- Click Save and close.
- Return to the partner's card and, in their relations, select the created type, specifying the second partner.
Symmetric relations (when the wording is the same on both sides) — "Competitor," "Partner," "Related party" — fill in with the same text in both fields.
4. Worked example
You have two clients from the same holding company:
- LLP "Astana Trade" — the parent company;
- LLP "Astana Logistics" — its "subsidiary."
Step 1. Create a relation type.
- Name:
Parent organization - Reverse relation name:
Subsidiary organization
Step 2. In the "Astana Logistics" card, add a relation: type — "Parent organization," partner — "Astana Trade." Now in the "Astana Trade" card, this same relation is automatically read as "Subsidiary organization → Astana Logistics."
What this gives you in practice. Sales within the holding are transactions between related parties, and they are subject to transfer pricing control. By marking the relation, you always see such deals.
The postings themselves are made by the sales document, not this directory. Suppose "Astana Trade" ships goods to "Astana Logistics" worth 1,160,000 ₸ including VAT at a rate of 16%: price excluding VAT is 1,000,000 ₸, VAT is 160,000 ₸. The cost of the goods is 700,000 ₸. The "Sale of Goods and Services" document generates the following under the standard Kazakhstan chart of accounts:
| Dr | Cr | Amount, ₸ | Meaning |
|---|---|---|---|
| 1210 | 6010 | 1,000,000 | Revenue from sale, buyer's debt |
| 1210 | 3130 | 160,000 | VAT 16% payable |
| 7010 | 1330 | 700,000 | Cost of goods written off |
The "Types of Relations Between Partners" directory is not involved in these postings — it only marks that the buyer and seller are related. But it's precisely this mark that tells you the price of 1,000,000 ₸ needs to be justifiable as a market price.
5. Operation types
The directory doesn't have separate "operation types" — it's a classifier. Essentially, you perform three actions with it:
- create a relation type (direct + reverse wording);
- apply it in the partner's card, linking two partners;
- use it for selection and analysis (find all "subsidiaries," all "competitors," all "related parties").
The bidirectionality of the relation is its main "operation": one record reads in both directions with different wordings.
6. What is generated upon posting
The directory is not posted and does not generate accounting entries. When saved, it:
- creates/updates a directory item;
- when you apply it in a partner's card — a record of the relation between partners is created (stored in the partner's data), which is displayed in both cards.
What this object does not do (a frequent question):
- does not create an ESF in the ESF IS and does not generate a SNT — these are done by sale/receipt documents;
- does not affect the calculation of VAT 16%, IIT, MPC, SC and other taxes;
- does not move accounts 1210, 1030, 1330, 3310, 3130, 6010, 7010.
It only supplies your partner database with additional, "human" information about their relationships.
7. Printed forms
The directory has no printed forms of its own — it's a classifier. From the list (navigation link e1cib/list/Справочник.ВидыСвязейМеждуПартнерами), the standard "Print list" is available (button More → Print list), which lets you export the list of relation types to a spreadsheet document or Excel for review and printing. There is no separate unified Kazakhstan form for this object.
8. Common errors
"The 'Name' field is not filled in" You're trying to save a relation type without a name. Fill in the "Name" field — the item won't be saved without it.
The relation reads incorrectly in the second card (partner is "its own parent organization") You didn't fill in the reverse name. Open the relation type and enter the reverse wording ("Subsidiary organization," etc.) — the relation will immediately start reading correctly from the other side.
"Item is in use. Cannot delete" / "References to the object being deleted" when trying to delete a relation type The relation type is already applied in partner cards. This is expected: the directory protects the data. First remove the relations from the partner cards (or mark the type for deletion and run Administration → Maintenance → Delete marked objects), then delete it.
No "Relations" tab/panel in the partner's card CRM functionality is disabled. Enable Master data and administration → CRM and Marketing → Customer Relationship Management — the relations section will appear.
Duplicate relation types ("Parent organization" and "parent org.") You're creating a new type "on the fly" each time without checking the list. Set up a single set of wordings once and choose from the existing ones — this keeps relation-based selections clean.
9. FAQ
1. Does this directory make postings? No. It's a classifier of relationships between partners. Postings (for example, Dr 1210 Cr 6010 and Dr 1210 Cr 3130 for VAT 16%) are generated by sale and receipt documents, not by this directory.
2. How do "Types of Relations Between Partners" differ from partner groups/segments? Groups and segments combine partners into sets. Relation types describe the relationship between two specific partners — who is whose "parent organization," "founder," "competitor."
3. Why is a reverse name needed? The relation is bidirectional. "Parent organization" on one side is "subsidiary organization" on the other. The reverse name sets how the relation reads in the second card.
4. How do I mark related parties for transfer pricing? Create a "Related party" relation type (with the same direct and reverse name) and assign it between the relevant partners. This is a convenient indicator for controlling transactions, but it doesn't perform the tax calculation itself — justifying the market price remains your responsibility.
5. Does the relation type affect the issuance of ESF or SNT? No. ESF (in the ESF IS) and SNT are issued from goods movement documents. The relations directory doesn't affect them.
6. Can I build a report on all "subsidiary" partners? Yes — through filters in partner lists and in partner/relation reports, you select partners by relation type. Clean wordings without duplicates make this much easier.
7. Partner or counterparty — which one is the relation linked to? To the partner (a management entity — a business unit). A counterparty is a legal entity/sole proprietor for documents and ESF. One partner can have several counterparties, and relations are defined at the partner level.
8. I deleted a relation type — what happens to the old relations? As long as the type is in use, it cannot be deleted. If you remove the relations from the cards and delete the type via "Delete marked objects," the marks about these relations will disappear from the partners. This will not affect postings, documents, or taxes.
9. Is it mandatory to maintain this directory at all? No. It doesn't affect accounting, VAT 16%, IIT, or month-end closing. It's a convenience tool: holdings, affiliated persons, and competitors become visible right in the partner's card.
10. Related documents and objects
- "Partners" directory — this is where relations are applied; it's most often from the partner's card that you create a new relation type.
- "Counterparties" directory — the partner's legal entities/sole proprietors; they appear in documents and ESF, but relations are defined at the partner level, not the counterparty level.
- "Sale of Goods and Services" / "Purchase of Goods and Services" documents — these are the ones that generate postings (1210, 6010, 3130 with VAT 16%, 3310, 1330, 7010) and electronic documents (ESF, SNT). The relations directory only "highlights" them with a relationship indicator.
- Partner segments and groups — a parallel classification tool; use together for analytics.
How to find out your release
Main menu (≡) → Help → About the program. There, the version of the "1C:Enterprise" platform and the configuration release are indicated. This guide is compiled for "Trade Management for Kazakhstan," edition 3.4, release 3.4.5.21. If you have a different release — check the field layout: in newer versions it may have changed.
Prepared for release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).