Задача
В связи с изменениями требований законодательства товары клиента стали подпадать под обязательную маркировку. Перед нами стояла задача организовать корректную передачу кодов маркировки от склада в интернет-магазин на 1С-Битрикс, а затем — в онлайн-кассу для формирования чеков с маркированными товарами. При этом маркировка товара становится известна не в момент оформления и оплаты заказа, а только после его сборки на складе. Это стало одним из ключевых технических ограничений проекта.
Основные сложности
В процессе реализации потребовалось решить сразу несколько задач:
- подобрать онлайн-кассу, которая поддерживает работу с маркированными товарами и модуль ТС ПиОТ;
- получать коды маркировки автоматически через API склада;
- передавать полученные коды в отгрузку 1С-Битрикс;
- обеспечить передачу маркировки в чек полного расчёта;
- учесть специфику интернет-магазина, где код маркировки становится известен только после комплектации заказа.
Этап 1. Получение кодов маркировки со склада
На стороне склада уже использовался API, через который интернет-магазин получал информацию о статусах заказов.
По мере сборки заказа склад дополняет ответ API информацией о фактически собранных товарах и их кодах маркировки.
Для нашей задачи было необходимо:
- Определить момент, когда заказ переходит в статус «На контроле»;
- Получить из ответа API список маркированных товаров;
- Сопоставить товары из API с товарами в заказе 1С-Битрикс;
- Получить соответствующие коды маркировки;
- Автоматически записать их в отгрузку заказа.
Особенность формата данных
Пример ответа от API склада:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<m:GetOrderStatusesResponse xmlns:m="http://www.sample-package.org">
<m:return xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="m:StatusOrderList">
<m:Status>
<m:Number>ACAD-250</m:Number>
<m:Period>2026</m:Period>
<m:ExtNumber>*штрихкод*</m:ExtNumber>
<m:Status>На контроле</m:Status>
<m:Volume>0.000168</m:Volume>
<m:Weight>0.14</m:Weight>
<m:Places>1</m:Places>
<m:PlacesBarcode>010306510</m:PlacesBarcode>
<m:HonestMarkLines>
<m:HonestMarkLine>
<m:ItemID>9118024</m:ItemID>
<m:Mark>0103145079118038215CNEVJ</m:Mark> <!-- Не используется -->
<m:KIZ>MDEwMzE0NTA3OTExODAzODIxNUNORVZKHTkxRUUxMh05MllRTjBncFFDL1lxRDBFeWMrTk5EZ2dIQnlZYWFFVnViZ2JJRnlQRE1nMkE9</m:KIZ> <!-- Код маркировки в формате Base64 -->
</m:HonestMarkLine>
</m:HonestMarkLines>
<m:ShippedLines>
<m:ShippedLine>
<m:ItemID>9118024</m:ItemID>
<m:LotNumber>26160154</m:LotNumber>
<m:Exp>2030-04-01</m:Exp>
<m:Qty>1</m:Qty>
</m:ShippedLine>
</m:ShippedLines>
</m:Status>
</m:return>
<m:Error xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:nil="true"/>
</m:GetOrderStatusesResponse>
</soap:Body>
</soap:Envelope>
Код маркировки передаётся в поле «KIZ» в формате Base64. Поле «Mark», также присутствующее в ответе, в рамках данной интеграции не используется.
Перед сохранением данных в 1С-Битрикс система выполняет следующий алгоритм:
- Получает код из API.
- Декодирует строку из Base64.
- Сопоставляет декодированный код с товаром в заказе.
- Автоматически записывает маркировку в отгрузку.
В результате, после перехода заказа в статус сборки, маркировка появляется в отгрузке 1С-Битрикс автоматически, без ручного ввода или сканирования оператором.
Этап 2. Передача маркировки в онлайн-кассу
Изначально на сайте использовалась связка:
Платежный модуль PayKeeper → фискализация через PayKeeper.
Предполагался следующий сценарий:
Оплата заказа → чек предоплаты → сборка заказа → получение кодов маркировки → добавление маркировки в отгрузку → получение заказа покупателем в ПВЗ → чек полного расчёта с маркировкой.
Ключевая проблема заключалась в том, что код маркировки становится известен только после сборки заказа.
Проблема с PayKeeper
В процессе интеграции мы столкнулись с тем, что передать маркировку в чек полного расчёта через используемый модуль PayKeeper не удалось.
Были протестированы различные варианты:
- использование складского учёта;
- передача маркировки вручную;
- анализ данных заказа;
- проверка логов и параметров формирования чеков.
Для решения проблемы мы обратились в техническую поддержку PayKeeper и предоставили необходимые логи, доступы и данные тестовых заказов.
Однако в течение месяца получить техническое решение проблемы не удалось.
Реверс-инжинирнг модуля
Чтобы точно определить причину проблемы, мы самостоятельно провели анализ модуля интеграции PayKeeper.
В результате выяснилось, что используемая логика работы передачи маркировки в модуле была привязана к моменту формирования первого чека.
Для нашего сценария это принципиально не подходило, так как в момент оплаты маркировки ещё нет, поскольку товар физически ещё не собран на складе.
Следовательно, передать код маркировки на этом этапе невозможно.
Временное решение
На время выяснения ситуации была реализована дополнительная логика:
- заказ собирается;
- маркировка автоматически записывается в отгрузку;
- система фиксирует необходимость формирования чека полного расчёта;
- бухгалтер получает уведомление о необходимости сформировать чек с маркировкой вручную.
Это позволило не останавливать работу магазина, но не решало задачу полностью, поскольку требовало ручного участия сотрудника.
Переход на цифровую кассу Эвотор
После анализа ограничений PayKeeper было принято решение отказаться от его фискализации и перейти на цифровую кассу Эвотор.
Одним из важных требований к новой кассе была поддержка ТС ПиОТ, поскольку товары клиента относятся к косметической продукции и должны дополнительно проверяться с помощью модуля.
После подключения и настройки интеграции были проведены тестовые операции.
На первых тестовых чеках обнаружилась ошибка — чеки не формировались корректно.
Мы передали логи в техническую поддержку Эвотор.
Специалисты оперативно определили причину: в запрос передавались цены с количеством знаков после запятой больше допустимого.
После корректировки округления цен на стороне сайта проблема была устранена.
Корректный чек с маркировкой:
Товар выведен из оборота в Честном знаке:
Результат
После настройки передачи маркировки в онлайн-кассу мы провели комплексное тестирование не только формирования чеков, но и дальнейшего движения маркированного товара.
В рамках тестирования проверили:
- формирование чека предоплаты;
- передачу кода маркировки в чек полного расчёта;
- проверку маркировки через систему «Честный знак»;
- выбытие товара из оборота после продажи;
- формления возврата маркированного товара;
- формирование возвратного чека;
- возвращения товара в оборот после оформления возврата.
Таким образом, была проверена не только передача маркировки в чек, но и полный цикл движения маркированного товара: от продажи и выбытия из оборота до возврата и повторного ввода в оборот.
Теперь чеки пробиваются по сценарию, который полностью соответствует 54-ФЗ и 488-ФЗ:
Оплата → Чек предоплаты → Сборка заказа → Получение маркировки через API склада → Декодирование и запись маркировки в отгрузку 1С-Битрикс → передача маркировки в Эвотор → Автоматическая проверка в ТС ПиОТ → Чек полного расчёта → Передача данных в ОФД → Выбытие товара из оборота в системе Честный знак.
