Маркировка сильно меняет обычную модель интернет-заказа. Недостаточно знать, что покупатель оплатил две упаковки товара. Перед отправкой нужно понимать, какие именно физические упаковки уйдут клиенту, не использовался ли этот код раньше и готов ли учётный контур принять продажу
В РЕТОН я отделил этот процесс от самого checkout. Покупатель оформляет и оплачивает заказ как обычно, а маркировка появляется позже — на этапе фактической сборки
Почему нельзя просить Data Matrix во время оформления
В момент оплаты конкретная коробка ещё может не быть выбрана. Код Data Matrix относится не к абстрактной позиции каталога, а к конкретной единице товара
Поэтому логика строится так:
заказ → оплата → задача на сборку → сканирование кодов → проверка → реализация → закрывающий чек
Так электронный заказ постепенно связывается с тем, что реально лежит на столе у сотрудника
Сканирование — это не просто поле ввода
Если дать сотруднику большое текстовое поле и сказать «вставьте коды», система быстро накопит проблемы
Нужны как минимум проверки:
- код подходит по формату
- для количества товара собрано нужное количество кодов
- один код не повторяется внутри заказа
- код не был использован в другом уже обработанном заказе
- комплект корректно разложен на фактические единицы, если внутри него несколько маркируемых товаров
Последний пункт особенно важен: кассовая и учётная логика должна видеть реальные единицы товара, а не только красивое коммерческое название комплекта
Сначала фактическая сборка, потом учётная продажа
Одна из важных последовательностей в этом контуре — не создавать закрывающий чек раньше, чем подготовлена реализация в 1С
Система сначала получает проверенные коды сборки, затем формирует и проводит реализацию в учётном контуре. Только после этого можно уверенно завершать кассовую часть продажи
Если поменять порядок, появляется неприятная ситуация: чек уже ушёл, а учётный документ не создан или завис в неопределённом состоянии
Неопределённый ответ опаснее обычной ошибки
Интеграции редко ломаются красиво
Иногда внешний сервис успевает выполнить действие, но соединение обрывается раньше, чем приложение получает подтверждение. Если в этот момент просто нажать «повторить», можно создать второй документ или второй чек
Поэтому для важных операций используется принцип:
сначала проверить, не было ли действие уже выполнено → только потом повторять запись
Такая логика нужна не только для 1С. Она полезна везде, где повторный запрос имеет финансовые или учётные последствия
Что получает сотрудник
В идеальном варианте сотруднику вообще не нужно думать о всей цепочке
Он видит понятный этап сборки, сканирует физические коды и получает результат проверки. Система сама решает, когда можно двигаться дальше, а когда заказ нельзя закрывать
То есть сложность остаётся внутри интеграции, а не перекладывается на человека
Почему я выделяю маркировку в отдельный контур
Можно было встроить весь код прямо в обработчик оплаты. Технически это даже выглядело бы короче
Но тогда платёж, сборка, учёт и касса стали бы одной длинной зависимой цепочкой. Любая ошибка в одном месте начинала бы затрагивать всё остальное
Отдельный контур даёт более понятные состояния:
- заказ создан
- оплата подтверждена
- заказ ждёт кодов
- коды проверены
- реализация подготовлена и проведена
- закрывающий чек завершён
Именно такие границы потом позволяют нормально диагностировать систему, восстанавливать её после сбоев и не гадать, «что вообще уже успело произойти»
Итог
Работа с маркировкой оказалась не задачей «передать Data Matrix в кассу», а отдельным процессом, который связывает электронный заказ с конкретным физическим товаром
Для меня это хороший пример автоматизации, где ценность не в одной API-интеграции. Ценность в том, что сотрудник делает простое физическое действие, а система сама удерживает правильную последовательность между магазином, 1С и фискальным контуром