Data Export/Import Processing "VygruzkaZagruzkaDannykhPotokomZapisiDannykhInformatsionnoyBazy" in UT for Kazakhstan 3.4: what it is and how to work with it

Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).

You've been contacted by 1C support or a partner: "Export the entire database and send the archive" — either you're moving from local 1C to the cloud (1cfresh / 1C:Fresh), or, conversely, deploying a copy of the working database on your own server. You open the list of processing objects, search for something with the word "Data export import" and stumble upon the long name DataExportImportInfobaseDataWriteStream. You open it — but there are no fields, no "Export" button. The question arises: is this what's needed or not? Let's sort it out honestly.

Important right away. This is a service (internal) processing object from the Standard Subsystems Library (SSL), not an accounting document. It has no fields for manual entry, no journal entries, no e-invoices/e-waybills, and no printed forms. It's the "engine" inside the mechanism for a full infobase data transfer, not something an accountant runs manually. Below is what it does, how database transfer actually works, and why it can't have "familiar" sections.

1. Purpose

The processing object belongs to the "Data Export and Import" subsystem (full infobase data transfer). Its task is to be the infobase data write stream: sequentially packing database objects (catalogs, documents, registers) into an export container file. It operates under the control of the export manager, is called programmatically, and delivers its result not to a person but to the transfer mechanism.

2. Where to find it

There's no need to search for this processing object in the interface and nothing to "run" it for. But you can open its form to make sure "this is it":

• Via a 1C navigation link. Menu "Tools and settings" (▾ icon in the top right corner) → "Functions for a technical specialist" → navigation link field (or the "Go to navigation link" option) → paste:

  e1cib/list/Обработка.ВыгрузкаЗагрузкаДанныхПотокЗаписиДанныхИнформационнойБазы

• Via the list of all processing objects: "Functions for a technical specialist" → "All functions" → "Processing objects" section → find the object by name in the list.

The "All functions" / "Functions for a technical specialist" item appears only if it's enabled: "Tools and settings" → "Settings" → "Parameters" → the "Display the 'All functions' command" checkbox.

The actual user entry point into the transfer mechanism is different:

• "Master data and administration" section → "Administration" → "Maintenance" → "Data export and import" (in the cloud version 1cfresh — via the service's personal account: "My applications → … → Export to file / Import from file").

2a. How to find your release

Menu "Tools and settings" (▾) → "About the program" (in some versions — "Help" → "About the program"). The window that opens will show:

• the platform version 1C:Enterprise (e.g., 8.3.24.xxxx);
• the configuration release — "Trade Management for Kazakhstan, edition 3.4 (3.4.5.21)".

Check against this exact line: the location of menu items in the transfer subsystem changes slightly from release to release.

3. How to "fill it in"

There's nothing to fill in for the processing object itself — it has no fields on its form. What gets filled in are the parameters of the entire transfer mechanism in the "Data export and import" form. Let's look at the key ones — why each is needed and what happens if it's wrong.

Main rule: a user has no, and shouldn't have any, direct "manual" call to this particular processing object. It runs automatically when you click "Export to file" in the transfer form.

4. Worked example

A typical "example with amounts and journal entries" isn't possible here — the processing object doesn't move money or calculate taxes. So let's look at a real migration scenario where this processing object runs internally.

Situation. A company on local Trade Management for Kazakhstan 3.4.5.21 is migrating to the 1cfresh cloud. Database size — 40 GB, 900,000 documents.

Steps:

1. Everyone logs out of the database, exclusive mode is enabled.
2. "Master data and administration → Maintenance → Data export and import → Export to file", path D:\Migration\ut_kz.zip.
3. The export manager iterates over the objects and passes them to the infobase data write stream (this is our processing object). The stream sequentially serializes objects into the container: the "Counterparties" catalog, "Sales of goods and services" documents, mutual settlement registers, etc.
4. The output is a ut_kz.zip file of ~6 GB.
5. In the cloud: "Import from file" → specify ut_kz.zip → the mechanism checks release compatibility and deploys the data.

What to check "in numbers" after the transfer (control checks, not accounting entries produced by the processing object): compare the totals in key sections in the new database — for example, the balance on account 1210 (short-term accounts receivable from customers), inventory balances on account 1330, revenue turnover on account 6010. If the same balance sheet before and after the transfer matches down to the tenge (₸) — the transfer is correct. The processing object itself doesn't generate any Dr/Cr entries: all journal entries, 16% VAT, e-invoices, individual income tax/pension contributions/social contribution calculations, etc. are simply transferred as is along with the documents.

5. Operation types

This processing object doesn't have "operation types" as such (like a document does). Within the transfer mechanism, it participates in exactly one action — writing (serializing) infobase data into an export container. The paired role (reading from the container during import) is performed by a separate read-stream object. In summary, functionally:

• Export — writing database data to a file (this is where our "write stream" works).
• Import — reading a file and writing to the target database (the "read stream" works here).

6. What is generated during operation

• Dr/Cr journal entries — not generated. The processing object doesn't create business transactions.
• Electronic documents (e-invoices in the e-invoice IS, e-waybills) — not generated. It doesn't issue them; previously created e-invoices/e-waybills are transferred as data within the documents.
• Register movements — not generated. On the contrary, it reads existing register movements in order to pack them into the file.
• What's actually created: an export container file (.zip/.xml) on disk and service records in the event log about the progress of the export/import.

7. Printed forms

There are no printed forms. This is a service processing object with no interface documents, nothing to print. The only "reporting" artifact is the export file itself and the entries in the event log ("Functions for a technical specialist" → "Event log"), which show how the operation ended.

8. Common errors

• "The operation cannot be performed because other users are working with the infobase" — exclusive mode is not enabled. End all sessions (including background jobs) and try again.
• "File write error" / "Not enough disk space" — not enough space in the export folder or no permissions. Choose a drive with plenty of free space (the file may be much smaller than the database, but you need peak space available) and a folder with write access.
• "The configuration version in the export file does not match the configuration version of the infobase" — you're importing a file into a database of a different release/edition. Bring the releases to the same version (3.4.5.21) and repeat the import.
• "Data can only be imported into an empty infobase" (or an overwrite warning) — you're trying to import a container into a working database with data. Deploy only into a clean/test database, otherwise you'll lose the current data.
• The processing object "does nothing" when its form is opened — this is not an error. It has no interactive form to run; use the "Data export and import" form instead.

9. FAQ

See the Q&A block below — it's presented separately.

10. Related objects

• "Data Export and Import" subsystem (Master data and administration → Maintenance) — the user "shell" from which the process is launched; this processing object runs inside it.
• Infobase data read stream object — the paired processing object responsible for importing the container into the database.
• Data export manager — manages the queue of objects and calls the write stream.
• "Testing and repair" / export to .dt (Designer or "Functions for a technical specialist") — an alternative, lower-level way to transfer the entire database; chosen when transfer via the SSL subsystem isn't available.

This is NOT an accounting object: it isn't entered "based on" documents, and nothing is created based on it. It serves the transfer of the entire database as a whole.

How to find your release

"Tools and settings" (▾) → "About the program" (or "Help" → "About the program") — this shows the 1C:Enterprise platform version and the configuration release.

Material prepared for "Trade Management for Kazakhstan", edition 3.4, release 3.4.5.21. When switching to a new release, check the location of menu items in the "Data export and import" subsystem.