Document "Notification of Introduction into Circulation of Electronic Invoice" - Technical Description

1. Identification

Purpose. The document is intended to notify the Information System "Digital Electronic Document Management of Marking" (IS CEDM) about the reintroduction into circulation of marked products in the RK. It is used by participants in the traceability system when returning products to commercial circulation after temporary withdrawal — during returns from customers, reintroduction of rejected batches, relabeling. The document works in conjunction with primary documents of goods movement and ensures bilateral data synchronization with IS CEDM through the mechanism of outgoing notifications.

This is a service exchange document with an external state system: it is not an accounting primary document and does not directly affect accounting/tax records (see section 5).

Where to find in 1C: section "Nomenclature and Warehouse" → "Notification of Reintroduction into Circulation (IS CEDM)". Navigation link: e1cib/list/Document.NotificationOfReintroductionIntoCirculationISCEDM.

2. Attributes of Header and Table Parts

2.1 Header Attributes

Mandatory attributes (without them, processing/recording is blocked with the message "Field … is not filled in"):

In addition to the mandatory ones, the header typically contains service exchange attributes: organization, date/document number, processing status in IS CEDM, document identifier on the traceability system side.

2.2 Table Part of Marking Codes

The main table part stores the list of marking codes being reintroduced into circulation (KIZ/GTIN, series/batch, nomenclature, quantity, and if necessary — price for categories of goods requiring price information).

2.3 Table Part "Typical Errors"

Stores a list of validation errors received from IS CEDM after an attempt to send the document:

The table part is filled in upon receiving a response from IS CEDM and is used to display to the user the reasons for the notification rejection.

3. Forms

The document form implements service scenario commands: filling based on incoming goods, sending notification, updating status, filling prices, bulk loading of codes from a file (see section 4).

4. Key Procedures and Scenarios

There is no BSL export with paths path:string in the attached evidence. Below are typical handlers of this type of object and exchange scenarios recorded in the reference material.

Typical handlers of the object/module form:

• ProcessingConduct — minimal or empty: the document does not generate movements (see section 5).
• ProcessingFilling — filling in attributes when inputting based on the receipt of goods.
• BeforeRecording / ProcessingCheckFilling — control of mandatory fields (ReasonForReintroduction, Supplier, SupplierName, SupplierIdentificationNumber).
• Exchange procedures — formation of the outgoing package, parsing the response from IS CEDM, and recording rows in the table part "Typical Errors".

Work scenarios (from evidence):

3.1 Creating a notification based on the receipt of goods — when returning goods from a customer, reintroducing a rejected batch, or relabeling; attributes are filled from the primary document.

3.2 Sending a notification to IS CEDM — after filling in all mandatory attributes and checking correctness; an outgoing package is formed.

3.3 Updating status from IS CEDM — periodically (on schedule or manually) to synchronize the processing status of the document in the state system.

3.4 Filling prices for IS CEDM — transmitting price information to the traceability system (requirement for certain categories of goods).

3.5 Bulk loading of marking codes from a file — when there is a large volume of codes (more than 50–100), when manual scanning is impractical.

5. Processing and Movements

The document does not generate movements in the registers — the set register_records is empty. This is a service exchange document with the external system IS CEDM, which does not create accounting entries and does not directly affect accounting registers in 1C.

Accordingly, when processing this document:

• RK-plan accounts are not affected — sales (6010 revenue from sales, 7010 cost of goods sold), goods (1330), settlements (1210 receivables from customers, 3310 payables to suppliers), money (1030);
• VAT is not generated (in RK for 2026 the rate is 16 %, account 3130 "VAT payable") — VAT accrual/set-off is performed by primary documents (sales, receipt, return), not by the notification to IS CEDM;
• ESF/SNT are not issued by this document — electronic document management for VAT and traceability is conducted by related objects (ESF in IS ESF, SNT).

Accounting (financial, VAT, PIT, etc.) effects arise exclusively from primary documents; the notification only records the fact of reintroduction into circulation for the state marking system.

6. Related Objects and Input Based On

• Basis for Input — documents of receipt/return of goods: the notification is created "based on" the primary document with auto-filling of the supplier and marking codes (scenario 3.1).
• IS CEDM — external state traceability system: receiver of outgoing notifications and source of statuses/errors (scenarios 3.2, 3.3).
• ESF (IS ESF) and SNT — accompanying electronic documents for VAT and accompanying invoices for goods; maintained by separate configuration objects but relate to one chain of movement of marked products.
• Nomenclature, marking codes (KIZ/GTIN) — subject of the notification, stored in the table part of codes.

7. Extension Points

• Filling Check Processing — adding custom validation rules before sending (checking BIN/IIN format, compliance of the reason for reintroduction and product category).
• Subscription to Events of recording/processing — integration with external processes, logging of exchanges.
• Form Extensions — adding commands for bulk loading of codes, additional filters in the list, visualization of the table part "Typical Errors".
• Module for Exchange with IS CEDM — overriding the formation of the outgoing package and parsing the response when changing the API of the state system (candidate for marking "requires verification" during release updates, as the exchange format is version-specific).