Avoid labeling issues with 1C-Bitrix – full setup and integration

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 introduc

Our competencies:

Frequently Asked Questions

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

  1. Analysis — study catalog structure, load, current cash register, and 1C exchange.
  2. Design — choose storage architecture, design reservation and withdrawal.
  3. Implementation — write storage code, handlers for cart and cash register, code import.
  4. Testing — test all scenarios: reservation, cancellation, returns, multi-threaded sales.
  5. Deployment — deploy to production server, set up monitoring.
  6. 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.