How to avoid labeling issues with 1C-Bitrix
An online clothing store with 50,000 items. Each order requires checking the labeling code. Without automation, managers spend hours, and every tenth code has already been sold — returns, fines up to 300,000 rubles. Since mandatory labeling was introduced, most product groups fall under the Chestny Znak system. Without automation, you risk not only revenue but also reputation. Our engineers configure product labeling on 1C-Bitrix so that codes are reserved when added to the cart, transmitted in the cash receipt per 54-FZ, and correctly withdrawn from circulation. Labeling errors are one of the main reasons for fines during inspections, with the average fine reaching 300,000 rubles. Automation eliminates the human factor and guarantees compliance with the law. We work turnkey with a guaranteed result.
What difficulties arise when integrating with Chestny Znak?
Main issues include:
- Incorrect storage of codes. If codes are stored in a regular infoblock property, with large volumes (10,000+ codes) retrieval slows down, and transactional integrity is not guaranteed. This leads to duplicates and sale of already withdrawn codes.
- Errors when transferring to the receipt. The labeling code must be transmitted in tag 1163 (DataMatrix). Not all cash register modules support this out of the box — customization is needed.
- Lack of reservation. Without a reservation mechanism, a single code can be sold twice, risking refusal of fiscalization and a fine.
- Incorrect withdrawal. After sale, the code must be withdrawn from circulation in GIS MT. If not done — data discrepancies and inventory blocking.
How to store labeling codes in Bitrix?
We use two approaches — choice depends on volumes. Compare them:
| Criteria | Infoblock property | Separate table |
|---|---|---|
| Retrieval speed | Slower with >10,000 codes | Fast with indices |
| Implementation complexity | Simple (add property) | Requires creating table and handlers |
| Space usage | In infoblock property table | Separate table |
| Transaction support | No | Yes (InnoDB) |
| Suitable for | Up to 10,000 codes | Any volume |
For most projects with an annual turnover of 20,000+ codes, we recommend a separate table. It works 10 times faster for large volumes. Here is how to create it:
CREATE TABLE b_marking_codes ( ID INT AUTO_INCREMENT PRIMARY KEY, PRODUCT_ID INT NOT NULL, CODE VARCHAR(255) NOT NULL UNIQUE, STATUS ENUM('available', 'reserved', 'sold', 'returned') DEFAULT 'available', ORDER_ID INT NULL, DATE_SOLD DATETIME NULL, INDEX idx_product_status (PRODUCT_ID, STATUS), INDEX idx_code (CODE) ); Example of code reservation when adding to cart
Reservation is performed on the event `OnSaleBasketBeforeSaved`. We use `SELECT ... FOR UPDATE` locking to avoid race conditions. After successful locking, the status changes to 'reserved', and the code is linked to the order ID. If the code is already reserved, the next free one is selected.How to transfer the labeling code to the cash receipt per 54-FZ?
According to 54-FZ, the labeling code must be transmitted in the cash receipt. We customize the cash register module handler so that the code is pulled from the basket item properties. Example for ATOL Online:
AddEventHandler('sale', 'OnCashboxBuildCheck', function($checkData) { foreach ($checkData['ITEMS'] as &$item) { $basketItemId = $item['BASKET_ID'] ?? null; if ($basketItemId) { $res = \Bitrix\Sale\Internals\BasketPropertiesTable::getList([ 'filter' => ['BASKET_ID' => $basketItemId, 'CODE' => 'MARKING_CODE'], 'select' => ['VALUE'] ]); if ($prop = $res->fetch()) { $item['MARKING_CODE'] = $prop['VALUE']; } } } return $checkData; }); Similarly, we handle code reservation on add to cart (event OnSaleBasketBeforeSaved) and write-off after payment (OnSalePaymentEntitySaved).
How we solve these tasks: a case study from our practice
Recently, we configured labeling for a client — an online clothing store with 50,000 products and 300,000 codes per year. Initially, codes were stored in an infoblock property — retrieval took up to 2 seconds, and reservation conflicts were common. We moved data to a separate table, added a SELECT ... FOR UPDATE locking mechanism, and reworked basket handlers. Result: order processing speed reduced by 40%, and sales without codes errors dropped to zero. The client saved more than 500,000 rubles per year from prevented fines and returns.
Work process
- Analysis — study catalog structure, load, current cash register, and 1C exchange.
- Design — choose storage architecture, design reservation and withdrawal.
- Implementation — write storage code, handlers for cart and cash register, code import.
- Testing — test all scenarios: reservation, cancellation, returns, multi-threaded sales.
- Deployment — deploy to production server, set up monitoring.
- Training — hand over documentation, train managers and accountants.
Timeframes and what is included
Estimated timeframes: basic setup (up to 10,000 codes) — 5-7 working days, comprehensive (from 100,000 codes) — up to 3 weeks.
| Stage | Duration |
|---|---|
| Implement code storage (property or table) | 1-2 days |
| Reservation and write-off handlers | 2-3 days |
| Customize cash register module to transmit code in receipt | 1-2 days |
| Set up import of codes from supplier files | 1 day |
| Integration with 1C (if needed) | 2-5 days |
| Documentation and employee training | 1 day |
| Warranty support for 3 months | included |
Our engineers hold 1C-Bitrix certifications and have 10+ years of experience in development. We have completed more than 50 labeling integration projects. Contact us — we will assess your project for free. For a consultation and audit of your catalog, leave a request — we will analyze the structure and offer the optimal solution.
Typical labeling setup mistakes
- Storing codes in common properties without indices — leads to slowdowns as catalog grows.
- No reservation before payment — risk of selling one code twice.
- Incorrect filling of tag 1163 — cash register refuses to fiscalize the receipt.
- Ignoring returns — if the code is not returned to circulation, inventory diverges from GIS MT.
We guarantee that after our setup, all these issues will be resolved. Get a free engineer consultation.

