Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).
You are transferring data between two UT databases — for example, from an old database to a new one, or from a copy to a production server. You have exported items, counterparties, and balances to a file and are loading it into the second database. And then a question comes up that decides everything: how will the program understand that "Astana-Snab LLP" from the file is the same counterparty already registered in the receiving database, and not a duplicate? This is exactly what the service processing ВыгрузкаЗагрузкаДанныхПотокЗаписиСопоставляемыхСсылок (ExportImportDataMatchedReferencesRecordStream) handles — stitching together "object from file ↔ object in database" references. You almost never open it manually. But when duplicate catalog entries or "broken" references in documents appear after a transfer, understanding this mechanism becomes critical.
A brief note upfront. This is a technical (service) processing within the "Data Export and Import" subsystem. It does not create accounting entries, does not generate e-invoices/waybills, and does not print documents. Everything about 16% VAT, accounts 1210/3310/6010, and taxes belongs to accounting documents (Sales, Receipt, Invoice), not to this processing. Below is an honest breakdown of what it actually does and how to use it as part of the data transfer mechanism.
1. Purpose
This processing is part of the standard "Data Export and Import" mechanism (exchange via file/directory, ВыгрузкаЗагрузкаДанных / DataExportImport). Its task is to maintain a stream of matched references records: when loading data from a file, it matches source objects with existing objects in the receiver and correctly records the "old reference → new reference" correspondence, so that documents, registers, and attributes point to the correct objects after transfer, without creating duplicates.
2. Where to find it
There is no direct "menu item" for this service processing — it is invoked by the transfer mechanism. But you can open its card/form directly.
Through the working mechanism (the usual user path):
- Section Master Data and Administration → Maintenance → Data Export and Import (or in different builds — Administration → Maintenance → Export and Import Data XML).
- In the wizard that opens, you select what to export/import, and reference matching runs automatically during the load step.
Opening the processing itself directly in 1C:
- Menu Technical Specialist Functions (enabled in "Settings" → "Other" section, "Display Technical Specialist Functions command" flag) → Processing → search by name.
- Or via a navigation link: Tools → "Go to navigation link" and paste:
e1cib/list/Обработка.ВыгрузкаЗагрузкаДанныхПотокЗаписиСопоставляемыхСсылок
Copy the line in full, paste it into the navigation field, and click "Go". The service processing form will open. Note: without administrator rights and without technical specialist mode enabled, this item may be hidden.
2a. How to check your release
Menu "Help" → "About" (or the "i" icon in the top right corner). There you will find:
- platform version (e.g., 8.3.24.xxxx);
- configuration release — "Trade Management for Kazakhstan, edition 3.4 (3.4.5.21)".
This guide was verified on 3.4.5.21. If you have a different release, the location of exchange menu items may differ slightly, but the reference-matching logic is the same.
3. How to "fill it out" — transfer parameters affecting matching
You don't fill out this processing manually, but rather the "Data Export and Import" wizard. Its settings determine how the matched-references record stream operates. Let's review the key parameters and what happens if they're set incorrectly.
| Parameter (wizard step) | Purpose | What happens if set incorrectly |
|---|---|---|
| Mode: Export / Import (required) | Determines the direction. Export writes a file, Import reads and matches it | Choosing "Export" instead of "Import" will overwrite your working file with an empty snapshot |
| Export/import file (required) | Path to the .xml/.zip containing the data snapshot |
Specifying the wrong/old file loads incorrect data; matching will link documents to the wrong objects |
| Data composition (required for export) | Which objects are exported in full and which by reference only | Failing to include a catalog referenced by documents will leave "dangling" references after import |
| Import into existing / clean database | Determines whether to search for matches or create everything from scratch | Choosing "clean" when importing into a working database = duplicates and lost connections |
| Matching rules (by internal identifier / by search attributes: code, name, TIN/BIN) | Determines the criterion by which a source object is considered "the same" in the receiver | A too "loose" rule (by name) will merge different counterparties; a too "strict" one will create duplicates |
| Conflict handling (replace / do not replace existing) | What to do if the object already exists | "Replace" will overwrite up-to-date receiver data with old data from the file |
Requiring deliberate choice: mode, file, matching rules. The rest depends on the situation, but the matching rules are the "heart" of the matched-references record stream.
4. Worked example
Transferring a counterparty and its related sale from database A (copy) to database B (working), where the counterparty is already registered manually.
Initial data:
- In database A: counterparty Astana-Snab LLP, BIN 010203400567, and document "Sale of goods" No. RT-0001 dated 15.09.2026 for the amount of 1,160,000 ₸ (including 16% VAT = 160,000 ₸).
- In database B: this same counterparty is already created manually with the same BIN, but with a different internal identifier (GUID) and code.
Steps:
- In database A: Export, composition — counterparty + document RT-0001, file
perenos.xml. - In database B: Import, mode "into existing database", counterparty matching rule — by BIN (search attribute).
- During import, the matched-references record stream runs: it finds the counterparty with BIN 010203400567 in database B and links the reference from the file with the existing receiver reference.
Matching result:
| Object from file (database A) | Found in database B | Action |
|---|---|---|
| Astana-Snab LLP (GUID-A) | Astana-Snab LLP (GUID-B, BIN matched) | Reference stitched: GUID-A → GUID-B, no duplicate created |
| Sale RT-0001 | not found | New document created, "Counterparty" attribute set = GUID-B |
The processing does not create accounting entries. But so you understand the point of the transfer: the "Sale of goods" document itself, upon being posted in database B, creates accounting entries (example based on the amounts in the scenario):
| Dt | Ct | Amount, ₸ | Description |
|---|---|---|---|
| 1210 | 6010 | 1,000,000 | Revenue from sales (excluding VAT) |
| 1210 | 3130 | 160,000 | 16% VAT payable |
| 7010 | 1330 | (cost) | Write-off of cost of goods |
The key point of the example: if matching had been done by name instead of BIN, and database B had two similar names, the sale would have been linked to the wrong counterparty, and settlements on account 1210 would have been "smeared" across duplicates. Choosing the correct search rule (by BIN/TIN) prevents this.
5. Operation types
Unlike accounting documents, this service processing has no separate "Operation type" attribute. By its role in the mechanism, it performs:
- Recording a new match — the object from the file does not yet exist in the receiver, a new reference is created.
- Stitching with an existing object — the object is found by the search rule, and the "source → receiver" match is recorded.
- Skip/conflict — the object is found, but "do not replace" mode is set; the match is recorded, data is not overwritten.
6. What is generated during processing
- Journal entries (accounting register): none. The service processing does not create accounting movements.
- Electronic documents (e-invoices in the e-Invoice IS, waybills): none. Electronic documents are issued from accounting documents (Invoice, delivery notes), not from the transfer mechanism.
- Printed forms: none (see section 7).
- What is actually generated: a table/stream of "old ↔ new" reference matches, which is used when importing the remaining objects so that their attributes and movements point to the correct receiver references. At the end of import, the wizard displays a report: how many objects were created, how many matched, how many had errors.
7. Printed forms
There are no printed forms. This is a service processing. The only "reporting" artifact is the import log/report in the "Data Export and Import" wizard: it can be saved to a file and used to review what was matched with what.
8. Common errors
"Object not found by reference" / "Object not found" during import. Cause: the file does not include a catalog referenced by the document (for example, the sale was exported but the item catalog was not). Fix: re-export the snapshot, including all dependent catalogs, or configure import "by search attributes" so the reference is stitched to an existing receiver object.
"Duplicate catalog entries found after transfer". Cause: the matching rule was set by internal identifier, while objects in the databases have different GUIDs. Fix: reload with a search rule based on a stable attribute — BIN/TIN for counterparties, SKU/code for items. Merge already-created duplicates via "Find and Merge Duplicates" (Master Data → Tools).
"Object version conflict" / "Object already exists". Cause: "replace" mode is enabled, but the object in the receiver is newer. Fix: select "do not replace existing" so that up-to-date receiver data is not overwritten by the snapshot.
"Insufficient rights" / processing command not visible. Cause: no administrator rights or technical specialist mode is disabled. Fix: enable "Display Technical Specialist Functions command" in personal settings, work under a user with full rights.
"Export file is corrupted / invalid". Cause: the file was not fully downloaded, is truncated, or is an archive of a different format. Fix: re-export the entire snapshot, check that the extension and format version match between databases.
9. FAQ
Is this a document or a processing? It's a service processing of the "Data Export and Import" mechanism. It is not posted and is not stored in document journals.
Does it create Dt/Ct journal entries? No. Accounting entries (1210, 6010, 3130, 7010, etc.) are created by accounting documents after the transfer, not by this processing.
Does it generate e-invoices or waybills? No. E-invoices are issued in the e-Invoice IS from the invoice, waybills from the relevant documents. The transfer mechanism has nothing to do with electronic documents.
Why is it even needed if I never open it? It's the "stitcher" of references during import. Without it, transferred documents would point to non-existent or wrong objects, duplicates would appear, and settlements would be "broken".
Which field is best for matching counterparties? By BIN/TIN — this is a stable unique identifier. Name is unreliable (different spellings will merge), and GUID does not match between independent databases.
Can it be used to transfer only part of the data, e.g., a single catalog? Yes, the data composition is set in the wizard. But be sure to include dependent objects, otherwise you'll get "dangling" references.
Will it overwrite my current data in the working database? Only if "replace existing" mode is selected. For safe addition, choose "do not replace" and always back up the receiving database before importing.
Is this mechanism suitable for regular exchange between databases? No, this is a one-time transfer/migration via file. For ongoing synchronization, use a configured data exchange (exchange plans, synchronization), not manual export/import.
Do 16% VAT rates, MCI, minimum wage, or PIT/pension contribution limits affect it? No. This is a technical data transfer. Tax parameters apply in accounting documents and calculations, not in reference matching.
Where can I see what was matched with what? In the import log in the "Data Export and Import" wizard: it lists created, matched, and erroneous objects.
10. Related documents
- What it operates on: the snapshot file created by the "Data Export and Import" processing (Export mode) from the source database.
- What uses its result: all transferred catalogs (Counterparties, Items, Organizations, Contracts, Warehouses) and documents (Sale of goods, Receipt of goods and services, Payment documents) — their references are stitched during import.
- Related tools: "Find and Merge Duplicates" (Master Data and Administration → Tools) — for eliminating duplicates arising from failed matching; configured Data Synchronization / exchange plans — as a standard alternative for regular exchange.
How to check your release: "Help" → "About" — shows the platform version and configuration release.
Prepared for "Trade Management for Kazakhstan", edition 3.4, release 3.4.5.21. Kazakhstan, 2026: 16% VAT rate, MCI 4,325 ₸, minimum wage 85,000 ₸.