Processing "UploadDownloadDataInformationBaseDataLoadManager

1. Identification

Purpose. A service (technical) data processor of the infobase data export/import mechanism in the SSL's neutral XML format. It is responsible for the import part of the process: reading a previously created export archive (a *.zip file containing Data.xml, DumpInfo.xml, nested files), parsing the structure of the exported data, checking metadata and configuration version compatibility, restoring reference integrity, and writing objects to the target.

The data processor is an internal "manager" (coordinator) of the import process and, as a rule, is not opened directly by the user as a standalone tool — it is called from the subsystem's common modules and from the export/import wizard. The typical user scenario for this data processor is transferring data between databases with an identical configuration: moving a working database to another server/DBMS, deploying a copy, migration, or restoring from a technological export. This is not data exchange (not DIB, not CD 2/3) — the format is intended for a "snapshot" of the entire database or a selected data set without conversion rules.

Important: the data processor does not perform accounting operations and does not depend on Kazakhstan tax parameters (VAT rate 16%, MCI 4,325 ₸, MW 85,000 ₸, etc.). These values are stored in application objects (constants, information registers, calculation type plans) and are transferred by the data processor "as is," without recalculation. See section 5.

2. Attributes and tabular sections

The data processor is built on the SSL service model: it has no permanent set of application attributes and tabular sections — process parameters are passed through the import parameter structure and form/data attributes. The logically used data composition (per the standard subsystem architecture):

There are no tabular sections in the usual user sense; the set of transferred objects is formed dynamically based on the archive's contents.

3. Forms

The data processor typically has no user forms of its own, or only service forms. User interaction in the "Data export and import" subsystem is implemented via the forms of related data processors:

If the object has no standalone forms, all actions are initiated programmatically from the subsystem's common modules (see section 4).

4. Key module procedures

No application BSL evidence for this object is attached (only the purpose facet is present in the source). Below is the typical composition of the programming interface of the SSL subsystem's data import manager; specific names and signatures should be verified against the object module of version 3.4.5.21.

Object module / manager module:

• ЗагрузитьДанные(ПараметрыЗагрузки) — main procedure: accepts a parameter structure (file, directory, modes), orchestrates the full import cycle.
• ПрочитатьОписаниеВыгрузки(...) / reading DumpInfo.xml — retrieves export metadata: source configuration, versions, format, list of types.
• ПроверитьСовместимость(...) — compares the source and target configuration/version; on mismatch, generates diagnostics and either aborts the import or issues a warning. (Requires verification: the strictness of version control depends on the SSL release.)
• ЗагрузитьКонстанты(...), ЗагрузитьОбъекты(...), ЗагрузитьНаборыЗаписей(...) — staged writing of target data by metadata kind.
• ВосстановитьСсылки(...) / deferred writing — handling reference integrity, resolving references not yet imported.
• УстановитьРежимЗагрузкиДанных(True/False) — enables/disables the system flag ОбменДанными.Загрузка so that filling checks and posting logic do not trigger on write.

Standard handlers of this object type: ОбработкаПолученияФормы, as well as server-side wrapper procedures called from the common modules ВыгрузкаЗагрузкаДанных / ВыгрузкаЗагрузкаДанныхСлужебный.

5. Posting and register movements

The data processor is not a document and does not generate accounting entries or register movements in the application sense. Register writes occur only as a side effect of the data transfer: the data processor restores the target register record sets exactly as they were in the source.

A key point for implementers: during import, the mode ОбменДанными.Загрузка = True is set, therefore:

• application posting, filling, and validation handlers do not run — data is written "as is";
• application amounts, rates, and reference values are not recalculated.

Therefore all Kazakhstan accounting parameters are transferred unchanged:

• the 16% VAT rate (the value in the corresponding rate registers/catalogs) is preserved as in the source;
• the values MCI = 4,325 ₸, MW = 85,000 ₸, the basic personal income tax deduction of 30 MCI/month (up to 360 MCI/year), PIT thresholds (10% up to 8,500 MCI of annual income, 15% above), rates OPV 10% (base cap of 50 MW), OPVR 3.5%, VOSMS 2%, OSMS 3%, SO 5%, social tax 6% — are carried over from the source's constants/information registers/calculation type plans;
• entries under the standard Kazakhstan chart of accounts (1210 — short-term customer receivables, 1030 — cash in current accounts, 1330 — goods, 3310 — payables to suppliers, 3130 — VAT payable, 6010 — sales revenue, 7010 — cost of sales) are transferred along with the source documents' movements.

Electronic documents (ESF for the ESF IS, waybills/SNT) and their related registers are also transferred as data; the data processor does not re-send or re-register them with government systems.

Practical conclusion: the correctness of accounting amounts after import is determined by the correctness of the source, not by the data processor's logic. If recalculation is required (for example, documents need to be re-posted after the transfer) — this is a separate operation, outside this data processor.

6. Related objects and entry on basis

• The paired export data processor of the "Data export and import" subsystem — creates the archive that this manager imports.
• Common modules ВыгрузкаЗагрузкаДанных, ВыгрузкаЗагрузкаДанныхСлужебный, ВыгрузкаЗагрузкаДанныхПереопределяемый — the subsystem's programming interface and customization points.
• SSL export XDTO/XML format (Data.xml, DumpInfo.xml) — the structure of the exchanged data.
• All application configuration objects (documents, catalogs, registers, constants, chart of accounts/calculation types) — are transferable data.

Entry on basis is not applicable: the object is a service object and does not create document instances.

7. Extension points

• Overridable modules ВыгрузкаЗагрузкаДанныхПереопределяемый — control the composition of exported/imported data, exclude specific metadata types, add handlers before/after object import.
• Programmatic handlers (ПередЗагрузкойДанных, ПослеЗагрузкиДанных, ПередЗагрузкойОбъекта, ПослеЗагрузкиОбъекта and similar) — intervention in the writing process to adjust/filter data.
• Configuration extension — acceptable for enhancing logic without losing support status; borrow the manager's procedures carefully, since the object belongs to the SSL and is updated along with it.
• Limitation: application business logic (recalculation of Kazakhstan taxes, regeneration of ESF/SNT) should not be placed in this data processor — it would violate the format's neutrality and the ОбменДанными.Загрузка mode. Move such logic to separate scheduled operations launched after the import.