1. Identification
| Parameter | Value |
|---|---|
| Object type | Data Processor (DataProcessors) |
| Name | ВыгрузкаЗагрузкаДанныхМенеджерОбработчиковВыгрузкиДанных |
| Full path | DataProcessors.ВыгрузкаЗагрузкаДанныхМенеджерОбработчиковВыгрузкиДанных |
| Synonym | not set (the object name is used in the interface) |
| Configuration | Trade Management for Kazakhstan, 3.4.5.21 |
| Where to find | Section "Service technology" → "Data export import export handlers manager". Navigation link: e1cib/list/Обработка.ВыгрузкаЗагрузкаДанныхМенеджерОбработчиковВыгрузкиДанных |
Purpose. A service (technological) data processor of the "Data Export and Import" subsystem (ВыгрузкаЗагрузкаДанныхПереопределяемый / SSL "Data export import"). It acts as a manager (registry) of handlers involved in exporting infobase data to a unified archive (XML serialization) and subsequently importing it into another infobase or cloud service. The data processor is not intended for interactive user input and is not related to operational or regulated accounting: it does not reflect business transactions, does not generate journal entries, and does not work with the chart of accounts, VAT, IIT, or other tax mechanisms of Kazakhstan. Its task is to sequentially invoke custom (overridable) and standard handlers at the stages before export, during export, after export, and at the symmetric stages of import of objects.
The data processor is used as an infrastructure component when:
- transferring data between infobases (for example, when switching to a new release or between nodes);
- exporting/importing data within the service model (1cFresh / service technology);
- migrating a configuration and its data.
Important: this object relates to platform/SSL mechanics, not to the subject area of Kazakhstan trade and accounting. Therefore the "numeric" specifics of Kazakhstan 2026 (VAT 16%, MCI 4,325 ₸, minimum wage 85,000 ₸, IIT deduction of 30 MCI, chart of accounts 1210/1030/1330/3310/3130/6010/7010, ESF/CNT) do not apply directly to the data processor itself — it passes "through" the mechanism as ordinary object data and ends up in target registers and documents, not in this service data processor.
2. Header attributes and tabular sections
This type of data processor is program-controlled; its state is formed in memory during the export/import session. It does not contain permanent header attributes and application-level tabular sections (nothing is stored in the database). The working data is represented by internal structures and collections formed in the object module:
| Conditional field / collection | Purpose |
|---|---|
| List of registered handlers | Registry of handler modules subscribed to export/import events, indicating the types of metadata objects they apply to |
| Correspondence "Metadata object → handlers" | Quick access to the set of handlers for a specific object type during stream processing |
| Stage flags | Marking of the process stage (BeforeExport, OnExport, AfterExport, BeforeImport, OnImport, AfterImport) at which the handler is invoked |
| Export container/stream | Reference to the container object into which data is serialized, and the current operation's parameters |
Tabular sections are usually not described for this object in the configurator, or are technical in nature — they have no application value for an implementer.
3. Forms
The data processor is not expected to have or use its own interactive forms (list, object, selection) in standard user scenarios: the object is invoked programmatically from the data export/import mechanism. If a form is present in a specific release, it is diagnostic/service in nature (viewing the composition of handlers) and is not part of the standard user interface. Opening it via the navigation link e1cib/list/... provides technical access for an administrator/developer.
4. Key module procedures
The attached evidence contains only the "purpose" facet — the source code (BSL) of the module is not provided in the materials. Therefore, the typical handlers and methods characteristic of the SSL/"Data Export and Import" subsystem's export handler manager are listed below. Specific signatures and lines should be verified against the object module in the target release 3.4.5.21.
| Method (typical) | Purpose |
|---|---|
ПриРегистрацииОбработчиков(Обработчики) |
Populating the handler table: mapping the metadata object type, version, stage (Export/Import), and procedure name |
ПередВыгрузкойОбъекта(...) / ПриВыгрузкеОбъекта(...) / ПослеВыгрузкиОбъекта(...) |
Invoking custom handlers at the corresponding stages of serializing an object into the container |
ПередЗагрузкойОбъекта(...) / ПриЗагрузкеОбъекта(...) / ПослеЗагрузкиОбъекта(...) |
Symmetric stages of deserializing and writing an object at the receiver; this is where reference mapping, replacement/skipping of objects is performed |
ПередВыгрузкойТипа(...) / ПередЗагрузкойТипа(...) |
Group handlers at the type level (all objects of a given kind) for optimization and service preparation |
ВыполнитьОбработчики(...) (internal dispatching) |
Iterating over registered handlers for the current object/stage and invoking them, passing the container and parameters |
The logic is typical: the manager collects a registry of handlers (including from the overridable module ВыгрузкаЗагрузкаДанныхПереопределяемый), and then, when stream-processing a selection of objects, invokes the necessary handlers strictly at their own stage, ensuring correct export and subsequent import with restoration of links.
5. Posting and movements
The data processor is not posted and does not generate movements in registers, nor does it create accounting entries. This is fundamental: the object belongs to the data exchange infrastructure, not to accounting.
- The object itself does not move accumulation/information/accounting registers.
- The Kazakhstan chart of accounts (1210 "Short-term receivables from customers", 1030 "Cash in current accounts", 1330 "Inventory", 3310 "Payables to suppliers", 3130 "VAT payable", 6010 "Revenue from sales", 7010 "Cost of sales"), as well as the calculation of 16% VAT, IIT, mandatory pension contributions/employer pension contributions/compulsory social health insurance/social health insurance/social contributions/social tax — are implemented by application documents and configuration registers, not by this data processor.
- During export/import, the data of the listed documents and registers is transferred as serialization objects; the resulting movements and balances are formed by the application logic at the receiving base during standard reposting/data restoration.
6. Related objects and input based on
Input based on is not provided for this service data processor. The links are programmatic in nature:
ВыгрузкаЗагрузкаДанныхПереопределяемый— the common overridable module from which the manager obtains custom handler registration.- The "Data Export and Import" mechanism (SSL) — container data processors, export/import process managers, XML serializers.
- Configuration metadata objects — all catalogs, documents, registers, etc., whose data passes through the handlers (including sales/receipt documents involved in ESF and CNT, VAT and mutual settlement registers).
- Service technology (1cFresh) — scenarios for exporting/importing a subscriber's data area.
7. Extension points
- Registering custom handlers in
ВыгрузкаЗагрузкаДанныхПереопределяемый.ПриРегистрацииОбработчиков— the standard way to intervene in the export/import of specific object types (for example, clearing technical fields, recalculating references, filtering confidential data before export). - Configuration extensions: borrowing the object module/overridable module to add or override handlers without removing the base configuration from support.
- Stage handlers BeforeExport/AfterImport — points for migration adjustments when changing release (including bringing data into line with Kazakhstan 2026 norms: reconfiguring VAT rates, mandatory pension contribution limits based on 50 minimum wages, and the 30 MCI IIT deduction is performed by application objects, but can be initiated from import handlers during migration).
Requires verification in the specific release 3.4.5.21: the exact composition of the object module's methods, the presence/purpose of the service form, and the versions of serialized structures — these details are version-specific and should be clarified against the configurator.