Setting up work with the Honest Sign label on 1C-Bitrix

Setting Up Honest Sign Marking on 1C-Bitrix

Mandatory product marking in the "Honest Sign" system affects online stores on Bitrix selling medicines, tobacco, shoes, clothing, dairy products, and a number of other categories. The technical aspect of the task: receive marking codes from suppliers, store them in the system, and transmit them to GIS MT (Honest Sign IS) upon sale.

Integration via 1C + Bitrix Module

The standard path for most online stores: marked product accounting is maintained in 1C, Bitrix acts as the storefront. Synchronization via the standard exchange module bitrix:catalog.import.1c (CommerceML).

With this approach, marking codes (Data Matrix) are stored in 1C, transmitted to Bitrix with stock levels via XML export. In CommerceML XML, fields for marking codes are not standardized — they are transmitted as additional product requisites:

<ЗначениеРеквизита>
    <Наименование>КодМаркировки</Наименование>
    <Значение>010460406000600021N4N57RSCBUZTJZ</Значение>
</ЗначениеРеквизита>

In Bitrix you configure a catalog property MARKING_CODE and map the requisite in exchange settings.

Direct Integration with Honest Sign API

For online stores working directly with GIS MT without 1C, you need direct integration via markirovka.nalog.ru API. The API uses OAuth2 authorization with EDS (qualified electronic signature).

Main API methods that affect e-commerce:

• POST /api/v3/facade/identifyDocument — verify marking code
• POST /api/v3/facade/send — notify of product withdrawal from circulation on sale

In Bitrix you implement a service class for API work:

namespace Local\MarkingCode;

class ChestnyZnakClient {
    private string $apiUrl = 'https://markirovka.nalog.ru/api/v3';
    private \Bitrix\Main\Web\HttpClient $http;

    public function verifyCode(string $code): array {
        $this->http->setHeader('Authorization', 'Bearer ' . $this->getToken());
        $response = $this->http->post($this->apiUrl . '/facade/identifyDocument', ['code' => $code]);
        return json_decode($response, true);
    }
}

Token is obtained via EDS — requires cryptographic library (CryptoPro CSP) on the server.

Storing Marking Codes in Bitrix

Each product instance has a unique marking code. Storing in element catalog property (b_iblock_element_prop_m*) doesn't work — one product has hundreds of instances with different codes.

Create a separate table via ORM D7:

class MarkingCodeTable extends \Bitrix\Main\Entity\DataManager {
    public static function getTableName() { return 'b_local_marking_code'; }
    public static function getMap() {
        return [
            new \Bitrix\Main\Entity\IntegerField('ID', ['primary' => true, 'autocomplete' => true]),
            new \Bitrix\Main\Entity\IntegerField('PRODUCT_ID'),
            new \Bitrix\Main\Entity\StringField('CODE', ['size' => 200]),
            new \Bitrix\Main\Entity\StringField('STATUS'), // 'active', 'sold', 'returned'
            new \Bitrix\Main\Entity\DatetimeField('CREATED_AT'),
        ];
    }
}

On product sale (event OnSaleOrderPaid) change code status from active to sold and send notification to GIS MT.

Withdrawal from Circulation on Sale

When an order is successfully paid, you must notify the marking system of the product's withdrawal from circulation. This is an asynchronous operation — don't block the checkout process waiting for API response.

Implement via agent or queue: on OnSaleOrderPaid record a task in your own b_local_marking_queue table, agent with 1-minute interval processes the queue and sends requests to GIS MT.