Processing "UploadDownloadDataUserSettingsLoadingManager" (UT for Kazakhstan 3.4)

1. Identification

Purpose in essence. This data processor is one of the specialized handlers of the BSP "Data Export and Import" subsystem (ExportImportData). This subsystem exports infobase data into a transferable set of files (XML/ZIP) and imports them into another database — typical scenarios: migrating a database to the service model (1C:Fresh / "cloud"), splitting off a data area, migration and merging of databases. This manager is responsible for correctly transferring user settings stored not in metadata objects, but in the platform's standard settings storages:

• ХранилищеСистемныхНастроек (System Settings Storage);
• ХранилищеОбщихНастроек (Common Settings Storage);
• ХранилищеПользовательскихНастроекДинамическихСписков (Dynamic List User Settings Storage);
• ХранилищеПользовательскихНастроекОтчетов (Report User Settings Storage), ХранилищеВариантовОтчетов (Report Variants Storage);
• ХранилищеФормДанных (Data Form Storage).

When loading, settings need to be re-linked to the users of the target database and references to objects (catalogs, documents), whose unique identifiers are remapped during the transfer, need to be re-mapped. This is exactly what the data processor does.

Important: this is a technical (service) object of the transfer infrastructure, not an accounting document. It does not participate in operational/regulated accounting, and does not generate postings or register movements (see Section 5).

Where to find it in Configurator / debugging: the object is visible only in Configurator (the "Data Processors" branch). To open the service list in the application mode (for debugging, with full rights):

e1cib/list/Обработка.ВыгрузкаЗагрузкаДанныхМенеджерЗагрузкиНастроекПользователей

By default, the data processor is not shown to the user and is absent from the command interface of any sections — it is called programmatically by the export/import engine.

2. Header attributes and tabular sections

Service handlers of the "Data Export and Import" subsystem are typically characterized by the absence of attributes and tabular sections: all logic is encapsulated in the object module, and data is passed through procedure parameters (export/import container, serializer stream, reference mapping tables). The table below reflects the typical structure of objects of this kind.

Working data the data processor operates with at the loading stage:

• reference mapping table (old GUID → new reference) — provided by the export/import manager;
• user mapping between source and destination (by infobase name / user ID);
• serialized setting value and its key (settings object, object key, settings key, presentation).

3. Forms

The data processor has no forms. This is expected for a service manager of the BSP subsystem: it is not intended for interactive use, and no selection/list form is used. Control of the transfer process is carried out from the forms of the "Data Export and Import" subsystem itself and from service administration data processors (e.g., the service migration assistant), and this data processor connects to them programmatically as a handler.

4. Key module procedures

No BSL text evidence is attached for this object (the source contains only the "purpose" facet). Below is the typical contract of a settings load handler of the BSP "Data Export and Import" subsystem; specific names/signatures may differ within the release (this is version-specific and requires verification against the object module of 3.4.5.21).

The object module of such a manager typically implements part of the export/import handler interface:

• ПриРегистрацииОбработчиковЗагрузки(ТаблицаОбработчиков) (OnRegisterLoadHandlers) — registers the data processor as a load handler for the corresponding "artificial" settings data types (settings storages). Specifies for which objects to call the ПередЗагрузкойТипа / ПриЗагрузкеОбъекта / ПослеЗагрузкиТипа methods.
• ПередЗагрузкойТипа(МенеджерВыгрузкиЗагрузки, ...) (BeforeLoadingType) — preparation before loading a block of settings: buffer initialization, reading the user and reference mapping.
• ПриЗагрузкеОбъекта(...) / loading a settings item — the main step: deserializes the setting, remaps references to objects within it using the mapping table, determines the owner user of the setting in the destination, and calls ХранилищаНастроек.<...>.Сохранить(...) (SettingsStorages.<...>.Save(...)) with the correct user key. Settings for which the owner user cannot be found in the destination are skipped or transferred to common settings.
• ПослеЗагрузкиТипа(...) / ПослеЗагрузкиДанных(...) (AfterLoadingType / AfterLoadingData) — final actions: clearing buffers, recording statistics of transferred settings, processing deferred references.

During export, the paired manager (or the same object in export mode) implements ПередВыгрузкойТипа / ПриВыгрузкеОбъекта, iterating over the settings storage records, serializing the setting value and saving alongside it the object key, settings key, presentation, and owner user ID.

Common server mechanisms accessed by the data processor: the ВыгрузкаЗагрузкаДанных subsystem manager (container, serializer, reference mapping table), as well as standard platform objects ХранилищаНастроек. (SettingsStorages.) and ПользователиИнформационнойБазы (InfoBaseUsers).

5. Posting and movements

The data processor is not posted and does not generate register movements — it has no "posting" concept at all, as it is not a document. Accordingly:

• no postings for regulated accounting are generated;
• no movements in accumulation/information/accounting registers are created.

Therefore, the RK standard chart of accounts (e.g., 1210 — short-term accounts receivable from customers, 1030 — cash in current accounts, 1330 — inventory, 3310 — accounts payable to suppliers, 3130 — VAT payable, 6010 — sales revenue, 7010 — cost of sales), rates and limits for 2026 (VAT 16%, MCI 4,325 ₸, minimum wage 85,000 ₸, standard IIT deduction 30 MCI/month and no more than 360 MCI/year, IIT 10%/15% with an 8,500 MCI threshold, mandatory pension contributions (OPV) 10% capped at 50 minimum wages of base, employer's OPVR 3.5%, VOSMS 2%, OSMS 3%, social contributions (SO) 5%, social tax 6%) do not directly relate to this object.

The role of the data processor in the context of this data is indirect: when a database is transferred using the "Data Export and Import" subsystem, it ensures the preservation of user settings — dynamic list filters, report variants and settings (including for VAT/ESF/SNT, mutual settlements, inventory movement), desktop and form settings. Accounting data itself (documents, registers, RK account postings) is transferred by other handlers of the same subsystem. The accounting content itself remains unchanged.

6. Related objects and input based on

Input based on does not apply to the data processor (it is neither a document nor a catalog).

Interacting objects:

• "Data Export and Import" subsystem (ВыгрузкаЗагрузкаДанных, BSP) — the calling party; provides the container, serializer, and reference mapping.
• Platform settings storages — source and destination for data: ХранилищеСистемныхНастроек, ХранилищеОбщихНастроек, ХранилищеПользовательскихНастроекДинамическихСписков, ХранилищеПользовательскихНастроекОтчетов, ХранилищеВариантовОтчетов, ХранилищеФормДанных.
• Users — Catalog.Users and ПользователиИнформационнойБазы (InfoBaseUsers, "Users" subsystem): transferred settings are linked to these.
• Related service transfer data processors (service migration/back-migration scenarios, data area export), which launch the process this manager is a part of.

7. Extension points

• Configuration extension. BSP service handlers can be modified via the extension mechanism, adding/overriding object module procedures (&Instead, &Before, &After). Caution: the subsystem is updated by the vendor, and if the handler interface changes, the extension may "break" — track the BSP/Trade Management version.
• Subsystem common modules. The standard logic for including objects in the transfer is configured via the overridable modules of the "Data Export and Import" subsystem (registration of export/import handlers) — the preferred, vendor-supported way to influence the composition and order of the transfer.
• Additional handlers. Custom rules for remapping references in settings can be plugged in by registering your own handler alongside the standard one, without modifying the data processor itself.
• Not recommended to remove the object from support and edit it directly: this will complicate updates; use extensions and BSP overridable points instead.

Version-specific (requires verification against release 3.4.5.21): the exact names and signatures of module methods, the composition of processed settings storages, and whether the export manager resides in this same object vs. a paired data processor.