Document "Internal Transfer Act in ISCEDM" - Technical Description (Accounting for Kazakhstan 3.0.74.2)

1. Identification

Purpose. The document formalizes acts of internal transfer of marked goods between warehouses/storage locations of one organization (or distributor) with the registration of the operation in the Information System of the Electronic Document Management Center (IS CEDM) of the Republic of Kazakhstan. It generates an electronic XML package for IS CEDM, allows loading marking codes from TSD/mobile applications, conducts reconciliation of actual codes with the underlying document, and tracks the status of the document in the electronic system.

It is used by warehouse specialists and employees responsible for marking when moving goods with marking codes (KIZ/DataMatrix) between structural divisions.

Important: this is a document of electronic document management for marking, and not an accounting document for goods movement. Financial and warehouse entries during internal transfer are made by a separate accounting document (see section 6). This act only records the movement of marking codes in IS CEDM.

Where to find in 1C: section "Nomenclature and Warehouse" → "Internal Transfer Act (IS CEDM)". Navigation link: e1cib/list/Document.InternalTransferActISCEDM

2. Attributes of Header and Table Parts

2.1 Mandatory Attributes of Header

If any of the listed fields are not filled, the platform will not allow saving/sending the document and will issue an error like "Field ... is not filled." Filling is controlled on the client (form handlers) and/or when attempting to send to IS CEDM.

2.2 Typical Attributes of Header (by Object Type)

In addition to mandatory attributes, documents of this class typically contain: Number, Date, Organization, DocumentBasis (reference to transfer/sale), attributes of EDO status (state in IS CEDM, package identifier, date of sending/confirmation), as well as service attributes for exchange.

2.3 Table Part "Goods" (Marking Codes)

The main table part stores the list of transferred units with marking codes. It is filled from the underlying document, manually or by loading from TSD. The typical composition of a row: nomenclature, characteristic/packaging, marking code (GTIN + serial, DataMatrix/KIZ), quantity, unit, reconciliation flag with the basis.

2.4 Service Table Part "Errors"

Stores the results of validation and exchange with IS CEDM.

3. Forms

The exact composition of forms is determined by the configuration; for documents of this class, the following are typical:

4. Key Module Procedures

The attached evidence does not contain specific references path:string to BSL procedures, so below are typical handlers for documents of this type (object module and form), implementing the described scenarios.

Object Module:

• FillProcessing(FillData, …) — filling the header and table part of codes when inputting based on the transfer/sale document (scenario 3.1) and when copying (3.6).
• FillCheckProcessing(Refusal, CheckedAttributes) — control of mandatory attributes (SupplierName/IdentificationNumber, RecipientName/IdentificationNumber, OperationType); if not filled — refusal and filling the "Errors" table part.
• ConductProcessing — not available. The document does not perform accounting conduct and does not generate movements in registers (see section 5).

Form Module:

• Handlers for sending the XML package to IS CEDM (scenario 3.2): generating the electronic act, signing, sending, receiving a response, and updating the status.
• Handlers for loading marking codes from TSD/mobile application and filling the table part (3.3).
• Handlers for reconciling scanned codes with the underlying document and highlighting discrepancies (3.4).
• Handlers for confirming/rejecting the act by the recipient and reflecting the new status (3.5).
• Filling and navigation in the "Errors" table part (navigation to the field by the attribute Field).

5. Conducting and Movements

The document does not perform accounting conduct. In the JSON description and BSL modules, there are no references to accounting registers or accumulation registers, and the handler ConductProcessing is absent.

The main task of the document is to generate an electronic XML package for IS CEDM and exchange statuses. The registration of the movement of marking codes (registration/deregistration of KIZ) is performed by overridable modules of the marking subsystem, not by the entries of the document itself.

As a result:

• according to the accounting register (typical chart of accounts of the RK), this act of movements does not create;
• warehouse balances and cost during actual internal transfer are reflected by the accompanying accounting document (for example, "Goods Transfer"), which for marked goods keeps records in account 1330 "Goods" (transfer between warehouses is analytics by subaccount "Warehouses" within account 1330, without changing the turnover of income/costs);
• income/expense accounts and VAT during internal transfer are not involved (there is no sale): accounts 6010 "Income from Sales", 7010 "Cost of Sales", 3130 "VAT Payable" are not applied here.

For reference, the specifics of RK 2026 (applied in related accounting and tax documents, but not in this act): VAT rate 16%; MRP 4,325 ₸, MZP 85,000 ₸; basic deduction for PIT 30 MRP/month (no more than 360 MRP per year); PIT 10% up to 8,500 MRP of annual income and 15% above; OPE 10% (ceiling base 50 MZP), OPR 3.5%, VOSMS 2%, OSMS 3%, SO 5%, social tax 6%. Currency — tenge (₸).

6. Related Objects and Input Based On

• Underlying Documents: "Goods Transfer", "Sale of Goods and Services" and similar — data sources for filling parties and the table part of marking codes (scenario 3.1).
• Electronic Documents of the RK: ESF (IS ESF) and SNT — accompanying mechanisms of electronic document management in Kazakhstan; the act of IS CEDM works in conjunction with the marking subsystem of ISMPTK.
• TSD / Mobile Applications: source of marking codes for loading into the table part (scenario 3.3).
• Copying an existing act — quick input of a new document based on a similar set of goods (scenario 3.6).

7. Extension Points

• Overridable Marking Modules — the main point of customization: registration/deregistration of marking code movements, rules for generating the XML package for IS CEDM, processing responses and statuses.
• Form Handlers (FillProcessing, handlers for sending/reconciling/loading from TSD) — for additional checks, auto-filling, and integration with scanning equipment.
• Table Part "Errors" — standard mechanism for outputting validation results; extended by adding custom checks in FillCheckProcessing.
• Configuration Extensions and event subscriptions — for adding attributes/logics without removing from support.

Requires verification (version-specific): the exact list of header attributes beyond the mandatory ones, the composition of forms, and specific names of overridable exchange procedures in release 3.0.74.2 — clarified by the metadata of the specific delivery, as the XML formats of IS CEDM are updated along with releases.