Tested on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).
You transferred the database — deployed a copy in the cloud, split one organization into two, merged two databases into one, or updated via export/import. The data is in place, the documents are there. Then the next morning managers write: "my filters in the orders list are gone", "favorites disappeared", "the sales report opens empty, all settings are reset", "columns in the form are back to default". You go looking for where these settings are stored and why they didn't move over. The answer is this processing. It's not responsible for goods and money, but for users' personal settings: filters, favorites, history, form design, and report variants.
Right away, to save time: this is a service (internal) object of the "Data Export and Import" mechanism. It's not opened to "post a document". It has no postings, no ESF or SNT, no printed forms in the accounting sense. It is called automatically when the transfer mechanism loads a batch of user settings into the target database and decides: transfer, merge, or skip. Below is what this means in practice and how to manage it.
1. Purpose
The processing is a manager that, when loading data from an export file, transfers user settings to the recipient database: saved filters and groupings in lists, favorites, form design, custom report variants, and other personal parameters. It matches source and recipient users and distributes settings by owner, rather than dumping them together.
2. Where to find it
There's no direct "Open this processing" button in the interface — it's a service object. You can reach it in two ways.
Via the standard transfer mechanism:
- Master Data and Administration → Maintenance → Data Export and Import (or "Administration → Data Export/Import" depending on rights). This is where you launch export to file and import from file — the processing works inside the import.
Open the object itself in 1C (for administrator/developer):
- Menu "Tools" → "All Functions" → "Processing" — in the list of service processings.
- Or via a navigation link. Copy it, then in 1C: main menu → "Tools" → "Go to navigation link" and paste:
e1cib/list/Обработка.ВыгрузкаЗагрузкаДанныхМенеджерЗагрузкиНастроекПользователей
Administrative rights are required: the object is not, and should not be, available to a regular manager.
2a. How to find your release
Main menu → "Help" → "About". In the window that opens:
- platform version (e.g., 8.3.24.xxxx) — top line;
- configuration release — "Trade Management for Kazakhstan, edition 3.4 (3.4.5.21)".
Check both numbers: the export/import mechanism is sensitive to whether the source and recipient versions match.
3. How to fill it in (what you specify when working with the mechanism)
There's no separate "document form" with attributes here — you manage the import parameters. The key ones:
| Parameter | Why | What happens with an incorrect value |
|---|---|---|
| Export file (required) | Source of data and settings. The .zip/.xml obtained during export |
If you specify the wrong file or one from a different release, import either won't start or will transfer garbage settings |
| Import user settings (flag, must be set consciously) | Allows transferring personal settings. If unchecked — data goes in, settings don't | Uncheck it by mistake — people lose filters and favorites; check it when merging databases — you may overwrite settings in the recipient |
| User matching rule | By which attribute to link the source user to the recipient user (by name/login/IB identifier) | A matching error — settings land on the wrong user or are lost |
| Conflict action | What to do if the recipient user already has settings: replace, merge, skip | "Replace" without a backup — irreversibly overwrites current settings |
| Settings only, no data | Transfer settings without touching documents (a common scenario for "catching up" settings after the main transfer) | Forget it — you reload documents again and get duplicates |
Ironclad rule: before importing, make a backup of the recipient database (Master Data and Administration → Maintenance → Backup). There is no standard button to undo a settings import.
4. Worked example
The "AlmatyStyle" salon is migrating a Trade Management for Kazakhstan database from a local installation to the cloud. There's one organization, VAT 16%, it works with ESF and SNT, and uses the standard KZ chart of accounts (1210, 1030, 1330, 3310, 3130, 6010, 7010). There are three users in the database.
- In the old database: Data Export and Import → Export to File → obtained
ut_kz_backup.zip. - In the cloud, they set up a clean database of the same release 3.4.5.21 and made a backup of the recipient.
- Import from File → specified
ut_kz_backup.zip, left the "Import user settings" flag checked, matching rule — by username, conflict action — "Merge". - The mechanism loads the data, reaches the settings batch — our manager kicks in. It sees three source users and finds three matching ones in the recipient:
| User | What the manager transferred |
|---|---|
| Administrator | Form settings, "Gross Profit" report, favorites |
| Salesperson Aigul | "My Orders" filter, saved sales report variant |
| Warehouse keeper Yerzhan | "Items in Warehouses" list settings, opening history |
Result: the documents (sales with 16% VAT, cost of sales on account 7010, revenue on 6010) migrated via their own mechanism, while personal settings landed with each user — Aigul immediately sees her "My Orders" filter, the sales report opens in her variant.
Why there are no Dr/Cr postings here. This processing transfers interface settings, not business transactions. Postings (Dr 1210 Cr 6010 — revenue, Dr 3130 Cr … — VAT 16%, Dr 7010 Cr 1330 — cost of sales) are generated by the sales documents themselves during their transfer and posting, not by the settings manager. Confusing these two layers is the main mistake when analyzing this object.
5. Operation types
The manager handles several settings transfer scenarios:
- Full import — settings travel together with the data during a standard database export/import.
- Settings-only import — data has already been transferred, only settings are caught up (the "settings only" flag).
- Matching and distribution — linking settings to recipient users according to the selected rule.
- Merge/replace/skip — conflict resolution when a user already has settings.
- Skipping settings — data is loaded, personal settings are ignored (a clean interface start).
6. What is generated during import
- Records in the platform's settings storages: form data settings, general settings, favorites, history, custom report variants.
- Update of the "setting ↔ user" link in the recipient database.
- A service log of the import — which settings were transferred, to whom, and what was skipped.
What is not generated: accounting postings, register movements (cost of sales, mutual settlements, VAT), electronic documents ESF (ESF IS) and SNT. All of these are created by primary documents, not by the settings manager. If you need to issue an ESF or SNT after a transfer — work with sales/purchase documents, not with this processing.
7. Printed forms
The service processing has no printed forms of its own — there's nothing to print. The only "output document" is the service import log (messages about successfully transferred and skipped settings), which can be saved to a file for a transfer history record.
8. Common errors
"Configuration version mismatch: the export file was created in a different version." The source and recipient are on different releases. Update both databases to the same release (here, 3.4.5.21) and repeat the export/import.
"User <Name> not found in the infobase." There's no matching user in the recipient. Create the users in advance (Master Data and Administration → User and Rights Settings → Users) or change the matching rule, then re-import the settings.
"User settings not imported" / everything is "back to default" after the transfer. The "Import user settings" flag was unchecked. Repeat the import from the same file in "settings only" mode with the flag checked.
"Data import is not possible: there are unfinished background jobs in the database." Wait for scheduled jobs to finish or stop them, close other users' sessions, and run the import in exclusive mode.
Current settings in the working database were overwritten. The conflict action was set to "Replace". Restore the recipient database from the backup (you made one, right?) and repeat with "Merge" mode.
9. FAQ
Q: Does this processing generate postings or ESF? A: No. It only transfers users' personal settings. Postings (Dr 1210 Cr 6010, etc.) and electronic ESF/SNT documents are generated by sales and purchase documents, not by it.
Q: I'm an accountant — do I need to open it manually? A: Usually not. This is a service object of the "Data Export and Import" mechanism. It's called automatically during import from file. An administrator accesses it manually.
Q: After the database transfer, my filters and favorites are gone. What do I do? A: The settings weren't imported. Repeat the import from the export file with the "Import user settings" flag checked, matching users by name.
Q: Can I transfer only settings without touching documents? A: Yes. In the import, select "settings only" mode — documents and balances will remain untouched, only personal interface parameters will be caught up.
Q: What happens if a user in the new database already has their own settings? A: It depends on the conflict action: "Replace" will overwrite, "Merge" will add to, "Skip" will leave as is. "Merge" is generally the safer default.
Q: Is it mandatory to make a backup before importing? A: Yes. There's no standard button to undo a settings import. A recipient backup is the only way to roll back.
Q: The source and recipient are on different releases — will it work? A: No, the mechanism requires matching releases. Bring both databases to the same release (e.g., 3.4.5.21) and repeat.
Q: Does this processing affect the VAT rate, MCI, or tax calculation? A: Not at all. Rates (VAT 16%, MCI 4,325 ₸, minimum wage 85,000 ₸, 30 MCI deduction for IIT) are stored in accounting registers and settings. The settings manager doesn't change them — it's about the user interface.
Q: Where can I see exactly what was transferred? A: In the service import log — it lists the transferred and skipped settings for each user.
Q: Why isn't the object available to a regular manager? A: That's by design. Transferring settings is an administrative operation; opening service processings requires the appropriate rights.
10. Related objects
- What it's based on: a file created by the "Export Data to File" processing (the "Data Export and Import" subsystem).
- What it's paired with: the "Import Data from File" mechanism, the "Users" catalog (for matching), and the platform's settings storages.
- What helps after the transfer: "User and Rights Settings" — to fine-tune rights; personal report and form settings — each user can manually adjust them as needed.
- Not to be confused with: "Universal XML Data Exchange" and "Data Synchronization" — these are about regular document exchange, not a one-time interface settings transfer.
How to find your release
"Help" → "About" — shows the platform version (8.3.24.xxxx) and configuration release. This guide is tested on "Trade Management for Kazakhstan", edition 3.4, release 3.4.5.21. The set of import parameters may differ on other releases.
Prepared for Trade Management for Kazakhstan 3.4.5.21 (ed. 3.4).