Reference "DeleteAdditionalInformationStorage" (Accounting for Kazakhstan 3.0)

1. Identification

Purpose. The catalog is a deprecated technical object, as indicated by the prefix Delete in the name and the note “(Do not use)” in the synonym. Previously, it served as a storage for additional information and files linked to the main accounting objects — counterparties, individuals, and organizations. Data of different categories were classified by enumerating types, and the file itself was stored in a property of type ValueStorage directly in the database.

In the current versions of “1C:Accounting for Kazakhstan 3.0”, this functionality has been fully transferred to the subsystem of attached files (BSP). The catalog is preserved solely to ensure readability and portability of previously accumulated data. It must not be used in new development, modifications, or daily operations.

Where to find in 1C

• Interface: section “Universal Mechanisms” → “(Do not use) Additional Information Storage”.
• Navigation link: e1cib/list/Catalog.DeleteAdditionalInformationStorage

The object is hidden from the ordinary user. Accessing it is advisable only when analyzing historical data or controlling the correctness of completed conversion.

2. Header Attributes and Table Parts

2.1 Header Attributes

All attributes are marked as optional (DontCheck) — this is typical for a service object that was filled programmatically, not through a form with validation.

2.2 Table Parts

Table parts are absent. The catalog has a flat structure: only header attributes.

2.3 Standard Attributes

Standard attributes of the catalog are used: Code, Name, Reference, DeletionMark, Predefined. Hierarchy and owner are not applied — the catalog is linear, not hierarchical, and not subordinate.

3. Forms

No custom forms are defined in the metadata. Given the status “(Do not use)”, interface forms were either removed when the object was decommissioned or were never created for the end user.

When opened via the navigation link, the platform generates auto-forms:

• List Form (auto) — view of the list of elements; used for controlling historical data and conversion results.
• Element Form (auto) — view of a single record: data type, file name, owner object, reference to the attached file.
• Selection Form (auto) — theoretically available, but practically not utilized, as composite type fields in new objects no longer reference this catalog.

Work with the catalog was mainly done programmatically (in migration/conversion code) or through universal forms in debug mode.

4. Key Module Procedures

Evidence with module texts (BSL) for this object is not attached. Below are typical handlers characteristic of a service catalog of this type. Specific lines of code in your release should be viewed in the configurator.

Object Module (CatalogObject)

• FillProcessing(FillingData, ...) — usually empty or absent: the object was filled by conversion.
• BeforeWriting(Refusal) / OnWriting(Refusal) — service objects usually do not contain business logic; if present — blocking manual creation of new elements.
• FillCheckProcessing(Refusal, CheckedAttributes) — due to the DontCheck flag, filling check is not actually performed for all attributes.

Manager Module (CatalogManager)

• May contain service functions for reading data from the Storage attribute (GetFile, ReadBinaryData) for conversion needs.

Migration Handlers (most significant logic). The main logic related to this object is found not in the catalog modules, but in the update handlers of the IB (BSP subsystem “IB Version Update”, procedures like FillData... / TransferAttachedFiles...). They:

1. read binary data from the Storage attribute;
2. create elements of modern catalogs of attached files (CounterpartiesAttachedFiles, OrganizationsAttachedFiles, NomenclatureAttachedFiles);
3. write a reverse reference in the AttachedFile attribute to match the old and new records.

Requires verification (version-specific): the exact composition and names of the update handler procedures depend on the release of the BSP platform and the specific version of the configuration.

5. Posting and Movements

The catalog is not a document and is not posted. It does not generate movements in accumulation registers, information registers, or accounting entries.

Accordingly, the object does not affect accounting and tax records and does not participate in calculations. For context: in “Accounting for Kazakhstan 3.0”, economic operations are reflected by documents according to the standard chart of accounts of the RK — for example, sales generate entries Dr 1210 Cr 6010 (revenue from sales), Dr 7010 Cr 1330 (write-off of the cost of goods), Dr 1210 Cr 3130 (VAT payable at the rate of 16%, effective in 2026); receipt of money — Dr 1030 Cr 1210; settlements with suppliers — Dr 1330 Cr 3310. Electronic documents (ESF in the ESF IS, SCT) are generated by relevant documents of the configuration. The catalog in question is not involved in any of these operations — it only stores files and service links.

6. Related Objects and Input Based On

Input based on for this catalog is not provided either as a source or as a receiver.

Related Objects:

The logical direction of connections is one-way migration: old data from Storage → new attached files, with a reverse reference being recorded.

7. Extension Points

Given the status of the object, expanding its functionality is not recommended. Acceptable scenarios are limited to servicing historical data:

• Configuration Extension (without decommissioning). It is possible to add handlers to the manager/object module for one-time audit tasks: unloading remaining files from the Storage attribute, checking the completeness of AttachedFile, searching for “orphaned” records without a match in the new catalogs.
• Programmatic Access. Reading data via a request to Catalog.DeleteAdditionalInformationStorage for controlling the completeness of conversion; extracting a file via Storage.Get().
• Quality Control of Migration. Report/processing comparing the number of non-empty Storage and filled AttachedFile.
• What should NOT be done: creating new elements, referencing this catalog from new objects, adding attributes and forms. For new work with files, use the attached files subsystem.

Requires verification (version-specific): the presence of a planned procedure for the physical deletion of the object in future releases of the configuration — before developing any extension, ensure that the data has already been fully migrated and the catalog can be cleared.