Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).
You are migrating a database to the cloud (1cfresh / BusinessStart service) or moving from an old database to a new one. You exported data from one infobase and import it into another — and end up with either duplicate currencies and accounts, or a "object reference not found" error. The reason is the same: predefined elements and references in two databases have different internal identifiers. This is exactly what the processing "DataExportImportLinkMappingManager" handles — it ensures that the "KZT" currency, account 1210, or an organization from the old database "attach" to their counterparts in the new database, instead of being created anew.
The main point right away: this is a service (technical) processing, not a document. It does not make accounting entries, does not generate an ESF or SNT, and does not print primary documents. Its task is technical — correctly link references when transferring data between databases. That's why there is no section below with Dr/Cr for 16% VAT — they physically don't exist here. But there is everything you actually need for the transfer to go through without duplicates and errors.
1. Purpose
The processing provides mapping of references and predefined data when exporting an infobase to a file and subsequently importing it into another database. It ensures that after the transfer, references to organizations, warehouses, accounting accounts, currencies, and other objects point to the correct elements, and predefined elements are not duplicated.
2. Where to find it
The processing is called automatically from the data transfer mechanism, but it can also be opened directly.
- Via the menu:
Master Data and Administration→Maintenance→Export Data/Import Data(in the cloud version — theAdministrationsection →Data Export and Import). The mapping manager itself opens at the import step, when the program cannot unambiguously find a reference. - Direct call (navigation link): copy the line below, in 1C click
Tools→Go to navigation link(orFile→Open→ address bar), paste it, and click "Go":
e1cib/list/Обработка.ВыгрузкаЗагрузкаДанныхМенеджерСопоставленияСсылок
This will open the object directly, without going through the entire export wizard.
2a. How to check your release
Help ("?" icon in the top right corner) → About the program. In the window that opens:
- Platform — "1C:Enterprise" version (e.g., 8.3.24).
- Configuration — "Trade Management for Kazakhstan", release (you should have 3.4.5.21 or comparable).
If the release is different, the names of menu items and columns may change slightly — go by meaning, not literal match.
3. How to fill it in
"Filling in" here does not mean entering amounts, but working with the mapping table. The procedure is as follows.
- Select the export file (REQUIRED). At the import step, specify the
.zipor.xmlfile obtained during export. Choose the wrong file — and you'll import someone else's data or get a structure error. - Check the table of unmapped references. The program shows objects for which it could not find a match in the receiver. Columns:
- Source object — what was in the old database (e.g., currency "Tenge", organization "Romashka LLP"). Cannot be changed, it's a fact from the file.
- Receiver object — what to substitute in the new database. This is a key field. Leave it blank and the object will be created anew (a second "Tenge" or a second warehouse will appear). Specify it incorrectly and transactions will end up attached to the wrong object, and reports will "drift".
- Action — "Map", "Create new", "Skip". An error here means either duplicates or data loss.
- Map predefined elements (REQUIRED for charts of accounts and characteristics). Accounting accounts (1210, 1030, 1330, 3310, 6010, 7010, etc.), contact information types, statuses — these are predefined data. They need to be linked by name/code, not created anew. Otherwise the standard accounting entries of the configuration will stop finding the right account.
- Resolve ambiguities. If there are two candidates in the receiver (two counterparties with the same BIN/IIN), select the correct one manually — autoselection will not work here.
- Save the mapping rules. If the transfer is multi-stage, export the configured mapping to a file — so you won't have to mark everything up again on repeated import.
- Start the import. Only after there are no "red" (unmapped required) rows left in the table.
Practice tip: first map the "foundation" — organizations, currencies, accounts, warehouses, units of measurement. All other references depend on them. Sort these out, and most of the rest will map automatically by their attributes.
4. Worked example
You are migrating the database of "Astana Trade" LLP from an old server to the cloud. Both databases have a tenge currency and an inventory accounting account, but the internal identifiers are different.
Source data in the export file:
| Source object | Type | What's wrong with it |
|---|---|---|
| Currency "KZT (Tenge)" | Catalog.Currencies | The receiver already has "Tenge" with a different ID |
| Account "1330 Goods" | ChartOfAccounts | Predefined, exists in the receiver |
| Organization "Astana Trade LLP" | Catalog.Organizations | Already manually created in the receiver in advance |
| Counterparty "Snabsbyt LLP" (BIN 070…) | Catalog.Counterparties | Duplicated: two candidates |
How to mark up the table:
| Source object | Action | Receiver object |
|---|---|---|
| Currency "KZT (Tenge)" | Map | Tenge (existing) |
| Account "1330 Goods" | Map | 1330 (predefined) |
| Astana Trade LLP | Map | Astana Trade LLP (created) |
| Snabsbyt LLP | Map (manually) | Snabsbyt LLP with BIN 070… |
Result after import: sales documents that referenced income account 6010, cost of sales 7010, and VAT payable 3130 (at 16% rate) ended up on exactly the same accounts in the new database. No duplicates of the currency or counterparty appeared. Turnovers matched to the last cent.
What would have happened with an error: if you had left the "Receiver object" field blank for the currency, a second "Tenge" would have appeared in the database, some documents would reference it, and the account balances for 1210/3310 would not match. That's why required blank rows cannot be left unfilled.
The processing itself does not create accounting entries — it merely transfers already existing transactions to the correct references.
5. Operation types
The processing serves three scenarios of the "Data Export and Import" mechanism:
- Data export — preparing references and predefined data for transfer, recording their identifiers.
- Data import — searching for matches in the receiver database and mapping references.
- Manual mapping — resolving unmapped and ambiguous references, choosing an action (map / create / skip).
6. What is generated during processing
The processing does not create accounting entries, ESF, SNT, or movements in accounting registers — this is a technical, not an operational, transaction. During its operation:
- a reference correspondence table source → receiver is populated;
- objects with correctly linked references are transferred to the receiver database;
- predefined elements (accounts, statuses) are linked by name rather than duplicated;
- if needed, a saved mapping file is generated for reuse;
- unmapped and skipped objects are recorded in the service log.
7. Printed forms
The service processing has no printed forms — it is not a primary document. Only an import log (protocol) is available on screen: a list of mapped, created, and skipped objects, and warnings. It can be saved to a text file using the log save button.
8. Common errors
- "Failed to map the reference to object <…>. The object will be created anew." — you did not specify a receiver. Go back to the table, in the "Receiver object" column select an existing element, action — "Map".
- "Several objects matching the mapping condition were found." — a duplicated counterparty/item. Resolve it manually: open the row and select the required element by BIN/IIN or code.
- "The export file structure does not match the receiver configuration." — the export was made from a different configuration or an incompatible release. Update the receiver database to a compatible release and repeat the export.
- "Integrity violation: parent reference not found." — you mapped a child object before the parent. First map groups/owners, then subordinate elements.
- Currency/warehouse duplicates appeared after import. — some rows were left with the "Create new" action. Undo the import (or delete duplicates), remark the table, and repeat.
9. FAQ
Q: Does this processing make 16% VAT entries? A: No. This is a service data transfer processing. Entries and ESF are generated by documents (sales, receipts). It only links their references when the database is migrated.
Q: What is the difference between "Map" and "Create new"? A: "Map" links an object from the file to one already existing in the receiver. "Create new" adds a new element. For currencies, accounts, and organizations you almost always need "Map".
Q: What happens if you leave the receiver blank? A: The object will be created anew. This is how duplicates are born: a second "Tenge", a second warehouse. Some documents will go to the duplicate, and turnovers will diverge.
Q: Do accounts 1210, 1330, 3310 need to be mapped manually? A: Yes, accounting accounts are predefined data, they are linked by code/name. Otherwise standard mechanisms won't find the account, and document posting will start throwing errors.
Q: Can the processing be opened without the export wizard?
A: Yes, via Tools → Go to navigation link and the link e1cib/list/Обработка.ВыгрузкаЗагрузкаДанныхМенеджерСопоставленияСсылок.
Q: Can a saved mapping be applied again? A: Yes. Export the configured rules to a file — on the next import of the same source, load them and don't remark the table again.
Q: Why does it say "several objects match the condition"? A: There are duplicates in the receiver (e.g., two counterparties with the same BIN). Select the correct one manually — autoselection is deliberately disabled in ambiguous situations.
Q: The account balances don't match after import. Is this processing's fault? A: Most often yes, if unmapped references remained: transactions ended up attached to new duplicates. Check the import log — it lists the objects created anew.
Q: Is this processing suitable for exchange between Trade Management for Kazakhstan and an accounting configuration? A: It is designed for transferring data of an area/database within one configuration (including to the cloud). For regular exchange between different configurations, exchange plans and synchronization are used, not this service processing.
Q: Does the processing decide on its own what to map? A: It automatically selects unambiguous matches by attributes, but leaves disputed and predefined items to you. Check the table before starting the import.
10. Related documents
- What it operates on: the export file (
.zip/.xml) created by the data export processing from the source database. - What it uses: the
Data Export and Importmechanism (Master Data and Administration→Maintenance), exchange plans, and data synchronization rules. - What "inherits" the result: all transferred documents — receipts, sales, payments — start referencing correctly mapped organizations, accounts (1210, 1030, 1330, 3310, 3130, 6010, 7010), currencies, and warehouses.
How to check your release
Help → About the program: it shows the "1C:Enterprise" platform version and the configuration release.
The instructions are current for release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4). When updating, check against "Help" → "About the program".
