1. Identification of the Object
| Parameter | Value |
|---|---|
| Object Type | Document (Documents) |
| Name | NotificationOfImportFromEAEUISCEDM |
| Full Name | Documents.NotificationOfImportFromEAEUISCEDM |
| Synonym | Notification of the import of marked products (EAEU) (IS CEDM) |
| Configuration | Accounting for Kazakhstan, edition 3.0 (3.0.74.2) |
| Country | Republic of Kazakhstan |
Purpose. The document registers and transmits information about the import of marked products from the Eurasian Economic Union (EAEU) to the information system CEDM (Digital Unified Document Flow of Marking) of Kazakhstan. It is used by importers and customs declarants when processing cross-border shipments of marked goods. The document is informative in nature and does not generate accounting entries, but is critical for the legal introduction of goods into circulation in the territory of the RK.
The document operates in two directions:
- Outgoing notifications — created by the organization and sent to CEDM;
- Incoming notifications — received from counterparties through the system; the organization acts as the recipient and confirms or rejects the fact of receipt.
Where to find in 1C
- Interface: section “Service 1C: Marking (IS CEDM)” → “Notification of the import of marked products (EAEU) (IS CEDM)”.
- Navigation link:
e1cib/list/Document.NotificationOfImportFromEAEUISCEDM
2. Attributes of the Header and Table Parts
2.1 Mandatory Attributes of the Header
| Attribute | Purpose |
|---|---|
Supplier |
Link to the counterparty-sender (seller from the EAEU country) |
SupplierName |
Text name of the supplier in the format for exchange with CEDM |
SupplierIdentificationNumber |
Identifier of the supplier (analogous to BIN/TIN of the sending country) |
Recipient |
Link to the organization/counterparty-recipient of the goods |
RecipientName |
Text name of the recipient for the exchange package |
RecipientIdentificationNumber |
BIN/IIN of the recipient in the RK |
All listed fields are mandatory. If a field is not filled, 1C will not process the document and will issue an error of the type “Field … is not filled”.
In addition to the mandatory fields, the header typically contains service attributes for integration with CEDM: notification number and date, document status in the marking system (draft / sent / confirmed / rejected / discrepancy), exchange package identifier, direction (outgoing/incoming), link to the underlying document.
2.2 Table Parts
Goods (marking codes). The rows of the goods part contain the nomenclature, quantity, unit of measurement, and marking codes (KIZ/GTIN) transmitted to CEDM. It is filled in manually, when entering based on receipt or by bulk upload (see scenarios 3.1 and 3.6).
Typical Errors. Technical log of errors returned by the CEDM system when sending/processing the document.
| Name | Type | Purpose |
|---|---|---|
Text |
xs:string | Description of the error received from CEDM |
Field |
xs:string | Name of the field to which the error relates |
3. Forms
| Form | Purpose |
|---|---|
| Document Form (DocumentForm) | Main form for input and editing: filling in supplier/recipient, goods part, sending to CEDM, viewing status and error log |
| List Form (ListForm) | List of notifications filtered by direction, status, counterparty; entry point via navigation link |
| Selection Form | Selecting a document when specifying it as the basis in related objects |
Additionally, the document form usually contains commands for interaction with CEDM: “Send”, “Update Status”, “Confirm”, “Reject”, “Create Discrepancy Notification”, “Upload Marking Codes”.
4. Key Procedures of Modules
Evidence with BSL code (path:string) is not attached, therefore below are typical handlers of the marking document of this type. Specific names of procedures are specified according to the object module version 3.0.74.2.
Object Module
ProcessingFilling— filling in attributes when entering based on the receipt of goods (transferring supplier, recipient, goods part, and marking codes).ProcessingCheckFilling— control of mandatory attributes (Supplier, Recipient, and their identifiers). If not filled, adds an error and interrupts the recording/processing.BeforeRecording— service pre-processing (setting direction, draft status by default).
Form Module
OnCreateOnServer— setting the visibility of CEDM commands depending on direction and current status.SendToCEDM(command) — forming an exchange package and calling the CEDM IS service; the result is parsed into the table part “Typical Errors”.UpdateStatus(command) — synchronizing the document state with the state system (scenario 3.4).Confirm/Reject(commands) — processing incoming notification (scenario 3.3).UploadMarkingCodes(command) — importing codes from a file or from TSD into the goods part (scenario 3.6).
5. Processing and Movements
The document does not generate movements in accounting registers. Movement registers in the object's metadata are absent. This is a reference (informative) document of the marking system: it does not affect accounting balances and does not create entries.
Accordingly, for this document the accounts of the standard chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010) are not used and taxes are not calculated. Accounting consequences of import (receiving goods on account 1330, liability to the supplier 3310, VAT on import 3130 at the rate of 16%, etc.) are reflected in separate accounting documents (Receipt of Goods and Services, Import Declaration, declarations for indirect taxes), while the CEDM notification only ensures the legalization of marking codes.
Numerical norms of the RK for 2026 (for reference in related accounting documents, not in this notification): VAT rate 16%, MRP = 4,325 ₸, MZP = 85,000 ₸. They are not applied here.
6. Related Objects and Input on the Basis
Main working scenarios (from evidence):
| No. | Scenario | When Applied |
|---|---|---|
| 3.1 | Creating an outgoing notification of import based on receipt | Import of marked products from the EAEU based on an already registered receipt of goods in 1C |
| 3.2 | Sending notification to CEDM | After filling in all mandatory data — transmission to the state system |
| 3.3 | Confirmation/Rejecting incoming notification | The organization is the recipient of the goods; it is required to confirm or reject the fact of receipt |
| 3.4 | Updating status from CEDM | Synchronizing the current state of the document with the state system |
| 3.5 | Creating a discrepancy notification | When receiving, a discrepancy with the incoming notification is found (quantity, marking codes) |
| 3.6 | Loading marking codes from a file or TSD | Bulk loading of codes (scanning in the warehouse, importing from an external system) |
Input on the Basis. The underlying document is the receipt of goods and services (scenario 3.1). Based on the notification itself, a discrepancy notification can be formed (scenario 3.5).
Adjacent Integration Objects. Electronic documents of the RK: ESF (IS ESF) and SNT — accompany the same goods supply and are related to it through the counterparty and nomenclature, but are formed as independent documents.
7. Points of Extension
- Configuration Extension — adding attributes/commands to the document form without removing from support; overriding handlers
OnCreateOnServer,ProcessingCheckFilling. - Event Subscriptions — on
BeforeRecording/OnRecordingfor additional control of marking codes or logging exchanges with CEDM. - Additional Processing (BSP) — assigned commands for filling/exporting, integration with external systems for loading codes.
- Exchange Rules — expanding the composition of the exchange package with IS CEDM when changing formats of the state system.
- Table Part “Typical Errors” — used as a diagnostic point: processing responses from CEDM for automatic resending.
Requires verification in a specific build 3.0.74.2: exact names of module procedures, complete composition of service attributes of the header, and format of the exchange package with CEDM — these elements are version-specific and are specified according to the metadata of the release.