Marking at the POS: code does not scan or fails verification

The cashier scans the Data Matrix on the packaging — and nothing happens, or the POS responds "item failed verification" and refuses to print the receipt. For a marked item, there is an entire chain of checks between the scanner and the receipt, and understanding which link is broken saves the cashier and technician the most time.

1. Marking Code Verification Chain at the POS#

1. The scanner reads the Data Matrix and transmits the string to the POS software — if the scanner is not configured for GS1 DataMatrix, the code will not reach the POS at all (see scanner setup).
2. POS software / inventory management parses the code string (GTIN, serial number, crypto-tail) and searches for a matching item in the catalog.
3. Local FN-M check — the fiscal storage device mathematically verifies the code's crypto-tail without an internet connection: confirming that the code is not counterfeit.
4. Online request to OSU/GIS MT (under permissive mode for the product group) — the POS queries the "Chestny ZNAK" tracking operator whether this specific instance can be sold right now.
5. Receipt response — the verification result is written to the receipt as a tag containing MC verification details (marked as M+ on success or M− on failure) along with verdict codes; the POS either processes the item or blocks the sale.

A break in the chain most often occurs at steps 1–2 ("nothing happens") or steps 4–5 ("verification failed") — these are two different scenarios, which we will examine separately.

2. "Nothing Happens When Scanning": Troubleshooting Tree#

Code is Not Linked to an Item in the Inventory System#

A common reason for "silence": the POS received the code but cannot understand which catalog item it belongs to — for example, the GTIN in the code differs from the GTIN specified in the item card (different packaging, different supplier for the same item). In this case, the POS software either remains silent or asks to select the item manually. The solution is to update the GTIN in the item card to match the actual packaging, or add an alternative GTIN if supported by your inventory system.

3. "Item Failed Verification": Verdicts and What the Cashier Should Do#

General rule for the cashier: a negative verdict is a reason to stop and figure it out, rather than looking for a way to "ring it up at all costs". The fine for selling an unmarked or uncirculated item for the organization is significantly higher than the lost sale of a single item.

4. Permit Mode#

Permit mode is a mandatory online verification of a code prior to sale: the POS does not simply check the crypto tail locally, but requests authorization for a specific real-time sale from the inventory management operator (item-by-item accounting operator) or directly from GIS MT. The state is introducing it in stages by product group — check the up-to-date list at честныйзнак.рф to see which categories are already required to operate in permit mode and which are not yet, as it expands periodically.

Offline exception. If a response from GIS MT is not received within the designated request timeout (for example, internet is available, but the connection is slow or the marking server is overloaded), the POS is not required to block the sale permanently — it allows the sale with a local tag, and the code itself is sent for post-processing and verification after the fact once the connection stabilizes. This distinguishes "no response on time" from "received a negative response" — in the second case, the item cannot be sold.

Local "Chestny ZNAK" module. For locations where internet connectivity is inherently unstable (remote trade, mobile sales, periodic connection drops), a local verification module is provided — it stores and updates part of the code data locally and can confirm verification without querying the cloud every time. Deploying it makes sense where offline periods occur regularly rather than as isolated incidents.

5. Internet Connection Down: Can You Sell Marked Goods#

It is important to distinguish between two different states here:

• Marking code verification is impossible (no connection to GIS MT/OSU), but the POS operates normally as a CRE — the fiscal document is generated, saved in the FN, and sent to the OFD once the connection is restored (standard CRE offline mode, 30-day limit — see details in the article about OFD). For goods outside the permit mode, where only local FN-M verification is required, sales usually continue as normal.
• The POS terminal itself is offline (powered off, frozen, no connection to the cash register network) — this is no longer about marking, but about the functionality of the CRE itself; if payments occur completely without a POS terminal, correction receipts will be required; see correction receipt for marked goods.

Summary: A lost internet connection by itself does not prohibit selling marked goods — it is prohibited either by an explicit negative verification verdict or by a non-working POS terminal.

6. Return of Marked Goods#

The return of marked goods is processed with a "return of receipt" receipt specifying the marking code — this is precisely what returns the code to circulation and makes its subsequent sale possible again. Without the code in the return receipt, the item physically rests on the shelf, but in the marking system it is listed as sold — it cannot be sold a second time until the status is corrected (for a detailed analysis of erroneous return receipts and corrections, see the article on correction receipts for marked goods).

Special cases:

• Code lost (packaging thrown away, label torn off) — look for the code in the inventory system by remaining stock of the same batch/SKU or request it from the supplier via the waybill; issuing a return "without a code at all" is not allowed, as the status in circulation will not be restored.
• Code unreadable (scuffed, smudged) — restore it manually from the waybill or product card if the inventory system allows manual code entry instead of scanning; if it is impossible to restore, proceed via an official act and a request to "Chestny ZNAK" support, similar to the case of a lost code during correction.

7. Example#

A clothing store sells an item from a regulated product group. The cashier scans the Data Matrix — the POS initiates an online check and within a couple of seconds receives the status "code already sold". The cashier does not issue the receipt and instead checks the inventory: it turns out that the same instance was already sold the day before, while an item identical in appearance but physically different remained on the shelf with a damaged label — its code was unreadable and had been mistakenly duplicated manually from an adjacent item. After verifying with the invoice, the cashier scans the correct code on the product itself, the check passes successfully, and the receipt is issued as normal.

8. How to do this in Cenaly#

• The marking attribute is enabled in the item card in the catalog — after this, Cenaly POS requires scanning a Data Matrix upon sale and prevents creating a receipt without scanning.
• Scanning and transferring the code to the receipt go through Cenaly Hardware Bridge — the "Hardware" section shows the status of the connected POS and the latest code verification result.
• Returning marked items in Cenaly also prompts for code scanning — the status in "Chestny ZNAK" is restored automatically, without manual correction receipts under normal operation (corrections are only needed if an error has already occurred — see the relevant article).
• Scanner setup for Data Matrix and common scanner failures are covered in a separate article, "Barcode Scanner".

9. Frequently Asked Questions#

Marking code verification takes too long, and the line is stuck — is this normal? A few seconds is standard practice for an online request. If delays are consistently large, check the location's internet connection and the load on the item verification system; persistent slow responses are a reason to consider a local offline verification module.

Can a product be sold if the POS displays "code not found", but the customer insists the product is genuine? No, not based on the customer's assurance alone. Postpone the sale, log the situation, and resolve it through the supplier or Chestny ZNAK support — a "not found" verdict indicates either a supplier-side entry-into-circulation error or a sign of counterfeit.

How does error code 94 on SHTRIH-M POS terminals differ from the verdicts in §3 of this article? Code 94 is a technical command sequence error in FFD 1.2 (the item was added to the bill before the marking code verification was completed), whereas the verdicts in §3 are the results of the code verification itself after the sequence operated normally. For details on code 94, see the article on SHTRIH-M errors.

Is the mandatory verification mode already active for my product category? The list of product categories and transition deadlines are published in stages — check the current status for your category on chestnyznak.ru, and do not rely on memory or outdated instructions.

Related articles: barcode scanner · correction receipt for marked goods · SHTRIH-M POS errors · receipts are not sending to OFD

This material is for informational purposes only and does not replace consultation with a marking or OFD specialist. Primary sources: guidelines from the Chestny ZNAK marking system (chestnyznak.ru), FFD 1.2 documentation from the FNS, 54-FZ.