Document "Notification of Discrepancy in SMP TK" - Technical Description (Accounting for Kazakhstan 3.0.74.2)

1. Identification of the Object

Purpose. The document is intended for registering and synchronizing discrepancies between the data of the sender and recipient of goods invoices in the Information System for Monitoring the Movement of Goods in Kazakhstan (ISM MG). It is used by organizations when discrepancies in quantity, labeling, or other parameters of goods are identified during the acceptance-transfer of labeled products. The document can be created manually (outgoing notification) or automatically uploaded from ISM MG upon receiving an incoming notification from the counterparty.

The document is informational: it does not create entries or movements in the registers, but serves as a tool for reconciling discrepancies with the state labeling system. Actual adjustments to accounting data are made by a separate corrective Acceptance-Transfer Act created based on the notification.

Where to find in 1C:

• Section “1C Service: Labeling (ISM MG)” → “Notification of Discrepancies (ISM MG)”.
• Access to lists is divided into teams “Notifications of Discrepancies (incoming)” and “Notifications of Discrepancies (outgoing)”.
• Navigation link: e1cib/list/Document.NotificationOfDiscrepancyInESF

2. Header Attributes and Table Parts

2.1. Header Attributes

If any of the mandatory attributes are not filled in, the platform will not allow saving/conducting the document and will issue an error of the type “Field … is not filled in”.

In addition to mandatory attributes, the header typically contains service attributes for integration with ISM MG: number and date of the original document (SNT/invoice), direction of the notification (incoming/outgoing), processing status in ISM MG, notification identifier in the state system.

2.2. Table Part “Labels”

Rows of labeled products for which the result of the reconciliation is recorded.

Typically, this table part also includes: labeling code (GTIN/KIZ/aggregated code), nomenclature, quantity according to the sender and recipient data, comment on the discrepancy.

2.3. Table Part “Typical Errors”

Serves to register validation errors and synchronization with ISM MG.

3. Forms

No separate BSL module of forms in evidence is attached; below is the typical composition of forms for this type of object.

4. Key Module Procedures

No separate BSL modules with the indication path:string in evidence are attached. Below are the typical handlers for the document-integration with the state labeling system, corresponding to the described scenarios.

• ProcessingConducting — absent. According to metadata.register_records, the list of movement registers is empty: the document does not generate accounting entries and movements in the registers.
• ProcessingFilling / Fill — filling in attributes when entering based on the original document-invoice (SNT, Acceptance-Transfer Act).
• BeforeSaving / OnSaving — control of filling in mandatory attributes (Supplier, SupplierIdentificationNumber, Recipient, RecipientIdentificationNumber) and reconciliation statuses in the table part “Labels”.
• IntegrationHandlers with ISM MG — formation/sending of outgoing notification, reception and parsing of incoming notification, updating status, registering validation errors in the table part “Typical Errors”.
• CreateCorrectionAct — command to create a corrective Acceptance-Transfer Act based on agreed discrepancies.
• Command for uploading labeling codes — mass upload of codes from a file into the table part “Labels”.

Typical Work Scenarios

1. Creating an outgoing notification of discrepancy — when accepting goods, the organization identified discrepancies with the data of ISM MG (shortage, excess, incorrect labeling) and issues a notification to the sender.
2. Receiving and processing an incoming notification — the counterparty sent a notification via ISM MG, the document is automatically uploaded into the database.
3. Creating a corrective act based on the notification — after reconciling discrepancies, a corrective Acceptance-Transfer Act is issued (command CreateCorrectionAct).
4. Uploading labeling codes from a file — when dealing with a large volume of products, codes are uploaded in bulk instead of manual entry.
5. Synchronization and status check — updating the status of the document after its processing in ISM MG.

5. Conducting and Movements

The document does not generate movements in any register of accounting or tax records — the handler ProcessingConducting is absent, and the list of movement registers is empty. For this reason, no entries are created by this document.

Actual changes to accounting data resulting from agreed discrepancies are reflected by a separate corrective Acceptance-Transfer Act (created by the command CreateCorrectionAct). This act generates accounting movements according to the typical chart of accounts of the RK. Approximate adjustment entries on the recipient's side (for reference):

On the sender's side, when adjusting sales, accounts 1210 “Short-term receivables from customers”, 6010 “Revenue from sales”, 7010 “Cost of sales” and 3130 “VAT payable” (at a rate of 16%) are involved. Specific entries depend on the type of corrective act, not on the notification itself.

6. Related Objects and Input Based On

• Original Documents — SNT (accompanying invoice for goods) and Acceptance-Transfer Act, during the acceptance of which discrepancies were identified. The notification is typically entered based on these documents.
• Electronic Documents of the RK — integration with IS ESF (ESF) and ISM MG; the notification is synchronized with ISM MG by KIZ/GTIN.
• Input Based On (created from the notification) — corrective Acceptance-Transfer Act by the command CreateCorrectionAct.
• Counterparties and Contracts — Supplier and Recipient refer to the directory “Counterparties” identified by BIN/IIN.
• Nomenclature and Labeling Codes — rows of the table part “Labels” are linked to nomenclature and the storage of labeling codes.

7. Extension Points

• Event Subscriptions (BeforeSaving, OnSaving) — additional control of the compliance of reconciliation statuses before creating a corrective act.
• Configuration Extension — adding attributes/columns to the table part “Labels” without removing from support; overriding form handlers.
• Exchange Rules / Integration — connection points to ISM MG and IS ESF (processing incoming/outgoing notifications, parsing errors into the table part “Typical Errors”).
• Additional BSP Processes — designated processes for mass uploading of labeling codes from external files.
• Form Commands — extending the command CreateCorrectionAct for atypical schemes of reconciling discrepancies.

Version-specific: the exact composition of service attributes for integration and the names of module procedures may differ between releases of the 3.0.7x line — when refining, refer to the document module of the specific installed version.