Все Вода

«Все Вода» — это компания специализирующаяся на продаже бутилированной воды, работающая в сегменте B2C и B2B. Основным видом деятельности являются продажа и доставка бутилированной воды. Компания работает как с частными покупателями, так и с корпоративными клиентами

Главной особенностью бизнеса является одновременное ведение онлайн-продаж через интернет-магазин и офлайн-продаж через физические точки. Это накладывает высокие требования к точности управления складскими остатками, обработке заказов и юридической корректности формирования фискальных документов.

С введением обязательной цифровой маркировки товаров через систему «Честный знак» компания столкнулась с необходимостью обеспечить сквозной процесс работы с кодами DataMatrix: от сканирования на складе до отображения в фискальном чеке, включая передачу данных в государственную систему. Нарушение требований маркировки грозило серьезными штрафами и блокировкой операций.

На момент старта проекта у клиента уже была базовая техническая инфраструктура: сайт на CMS 1С-Битрикс, через который оформлялись заказы и принимались онлайн-платежи, учетная система 1С: «Управление торговлей» с установленным типовым модулем обмена с сайтом, онлайн-касса Эвотор 5i, которая использовалась одновременно для интернет-магазина и розничной точки, а также платежный шлюз ЮKassa с модулем фискализации и интеграцией с кассовым оборудованием через API.

Несмотря на наличие всех необходимых инструментов, между ними не было выстроено единой бизнес-логики для работы с маркировкой: в 1С не были настроены процессы продажи и отгрузки с учетом маркированной продукции, сканирование кода DataMatrix не фиксировалось как единая транзакция между системами, а онлайн-касса не получала данные по кодам маркировки, из-за чего чеки печатались без DataMatrix.

Таким образом, существующая инфраструктура формально позволяла принимать заказы и проводить платежи, но не обеспечивала законную корректность работы с маркированной продукцией и не могла гарантировать автоматизацию процессов.

Главная задача проекта заключалась в построении полностью автоматизированной, сквозной системы передачи кодов маркировки от момента оформления заказа до формирования фискального чека и передачи данных в систему «Честный знак».

Основные требования к процессу были следующими:

Для выполнения вышеуказанных требований необходимо было создать сквозной сценарий, охватывающий все стадии: заказ, оплата, формирование чеков, передача в 1С, сканирование кодов на складе, возврат заказа на сайт, смена статуса заказа и финальная передача данных в кассу и «Честный Знак».

Особое внимание уделялось правильной структуре DataMatrix, включающей GTIN, уникальный серийный номер и криптографический хвост, разделенные непечатаемым символом GS. Ошибки на любом этапе могли привести к отказу кассы, нарушению законодательства и потенциальным штрафам.

Первый критический барьер на пути к автоматизации был в том, что типовой модуль обмена между 1С и 1С-Битрикс при передаче заказа с сайта в 1С и обратно пересоздавал товарные строки в документе реализации. В результате сбрасывались важные пользовательские атрибуты: обнулялся флаг «Требуется маркировка», исчезало поле для DataMatrix-кода, а уже введенные и сохраненные в 1С коды не передавались обратно на сайт. По факту информация о маркировке терялась прямо на этапе обмена, из-за чего становилось невозможным корректное формирование фискальных чеков и соблюдение требований законодательства по маркированной продукции.

Это не являлось ошибкой или багом в классическом смысле. Служба поддержки 1С-Битрикс подтвердила, что такое поведение модуля предусмотрено конструкцией и документированно: пересоздание строк документа «сбрасывает» все пользовательские поля, включая код маркировки.

Для устранения проблемы мы выполнили точечную доработку модуля обмена. Основная идея была в том, чтобы отследить момент пересоздания номенклатурных строк в документе реализации и автоматически восстанавливать данные по маркировке: флаг «Требуется маркировка» и поле с DataMatrix-кодом.

Логика работала так: при добавлении новой строки в документ 1С система проверяла, была ли номенклатура ранее помечена как маркированная. Если да, то в новой строке автоматически проставлялся нужный флаг, а значение DataMatrix сохранялось и переносилось без изменений. За счет этого при повторной выгрузке заказа на сайт код не терялся, а информация о маркировке оставалась актуальной.

Эта доработка позволила сохранить целостность данных на уровне 1С и исключить потерю кодов при стандартном обмене. Она стала первым шагом к формированию сквозного процесса передачи кодов маркировки от сайта до кассы.

После внедрения решения коды маркировки начали корректно сохраняться при обработке заказов в 1С, типовой модуль обмена с 1С-Битрикс перестал обнулять поле с DataMatrix, а заказы, возвращенные на сайт, уже содержали корректные коды маркировки.

Однако на этом этапе оставалась нерешенная проблема: формирование фискального чека по интернет-заказам все еще работало некорректно, потому что касса не принимала код маркировки для фискализации. Это потребовало отдельного анализа и решения следующего критического блока.

После того как мы закрыли проблему с потерей кода при обмене между 1С и 1С-Битрикс, следующим критическим этапом стала проверка сквозного процесса на стороне фискальной системы.

При попытке сформировать чек отгрузки для интернет-заказов касса Эвотор отказывалась принимать DataMatrix-код, хотя на предыдущих шагах все выглядело корректно: код успешно сканировался с товара и сохранялся в 1С, при выгрузке заказа на сайт отображался правильно, а ЮKassa принимала данные и включала код в чек. Но при передаче на кассу происходила ошибка валидации, из-за чего чек не формировался, а операция фискализации не завершалась.

Причина оказалась в особенностях хранения кода в 1С. Стандартное поле для маркировки было рассчитано в первую очередь на передачу данных в систему «Честный знак», и при этом часть информации отрезалась: криптографический хвост (AI 93) и разделитель GS (ASCII 29). В итоге код становился неполным и невалидным для кассы.

Чтобы было понятно, почему касса считала код невалидным, нужно коротко пояснить, как устроен DataMatrix по стандарту GS1 и что именно «обрезалось» в 1С.

Российский стандарт GS1 DataMatrix включает три логических блока: GTIN (AI 01) — 14-значный глобальный номер товара, Serial (AI 21) — уникальный серийный номер упаковки, и CryptoTail (AI 93) — криптографическая подпись (4 символа). Эти части разделяются непечатаемым символом GS (ASCII 29).

В нашем случае при стандартной обработке в 1С данные после символа GS (то есть криптографический хвост) отрезались, из-за чего код становился неполным и уже не подходил для фискализации.

Чтобы сохранить целостность DataMatrix и не терять криптографический хвост, мы внедрили параллельную схему хранения. При сканировании кода в штатное поле 1С записывался «обрезанный» вариант, который нужен для передачи данных в систему «Честный знак», а в отдельное пользовательское поле сохранялся полный код, включая криптографический хвост.

Дальше мы доработали модуль обмена между 1С и 1С-Битрикс так, чтобы при выгрузке заказа на сайт использовалось именно это кастомное поле. За счет этого сайт стабильно получал полный, валидный код, а касса могла корректно пройти валидацию и завершить фискализацию.

Дополнительная сложность была в непечатаемом символе GS (ASCII 29): его нельзя напрямую корректно передать в XML/JSON и надежно сохранить в обычном текстовом поле. На практике этот символ «терялся» или искажался на этапе передачи и хранения.

При этом наличие GS критично для валидации кода на кассе. Если разделитель пропадает, DataMatrix формально становится другим (неполным) и касса воспринимает его как невалидный, из-за чего фискализация не завершается.

Чтобы не терять GS, мы сделали замену непечатаемого символа на метасимвол, который система может хранить и передавать без искажений. При сканировании GS автоматически подменялся на печатаемый эквивалент, например на «&», и в таком виде код спокойно проходил через хранение и обмен.

Дальше, при передаче кода на сайт и далее в ЮKassa, работал алгоритм обратной замены: «&» преобразовывался обратно в GS (ASCII 29). Это позволило корректно сериализовать и десериализовать код без потерь, сохраняя его валидность для кассы.

В итоге после внедрения кастомного поля и обработки GS полный DataMatrix сохранялся на всех этапах: в 1С, на сайте, в кассе, в ЮKassa — касса уверенно принимала и передавала код, чек фискализировался корректно, а код отображался в чеке и уходил в систему «Честный знак». Таким образом, получился полностью автоматизированный и законно корректный путь передачи маркировки от сканера до кассы.

После того как мы настроили кастомное поле и добились корректной передачи DataMatrix-кодов на кассу, всплыл еще один критический операционный риск. Он был связан с тем, что смарт-терминал Эвотор 5i одновременно использовался и как онлайн-касса для интернет-магазина, и как касса розничной точки. Формально это выглядело допустимым, тем более что в документации Эвотора заявлен «гибридный режим», но на практике такое совмещение приводило к конфликтам учетных сценариев.

Ситуация выглядела так: при оформлении интернет-заказа и фискализации чека через ЮKassa товар списывался со склада, и параллельно при продаже через интерфейс терминала в розничной точке этот же товар также мог списаться. В результате возникало двойное списание одного и того же SKU, особенно при высокой скорости операций, что приводило к отрицательным остаткам и расхождению с фактическими данными.

Это создавало серьезные риски: нарушение целостности учета и ошибки в отчетности, усложнение контроля остатков между онлайн- и офлайн-каналами, а также повышенный риск претензий и штрафов со стороны ФНС из-за расхождений в учете товаров.

По итогам анализа мы приняли решение разделить функционал кассового оборудования по каналам продаж. Для интернет-магазина выделили отдельный фискальный регистратор, который использовался исключительно для печати чеков по онлайн-заказам. Существующий Эвотор 5i оставили в розничной точке и закрепили только за офлайн-продажами.

Такое разделение убрало конфликт сценариев списания и позволило вести независимый учет по каждому каналу. В итоге удалось исключить ошибки списания и расхождения по остаткам, упростить логистику и инвентаризацию, снизить операционные и юридические риски, а также получить запас по масштабированию: добавлять новые SKU и развивать продажи без риска конфликтов между онлайн- и офлайн-каналами.

После внедрения всех решений мы прогнали полный сквозной сценарий работы с кодом маркировки и проверили, что цепочка от сайта до кассы отрабатывает стабильно и без потерь данных.

Сценарий выглядел так: покупатель оформляет заказ на сайте и оплачивает его онлайн, после чего формируется предоплатный чек (чек №1). Далее заказ выгружается в 1С, оператор сканирует DataMatrix-коды с бутылок, и они фиксируются в кастомном поле. При синхронизации заказ возвращается на сайт уже с полными кодами, а смена статуса на «Отгружен» инициирует формирование второго чека (чек №2) с передачей данных в ЮKassa и далее в кассу. Касса принимает код, формирует фискальный чек и передает его в ОФД и в систему «Честный знак».

По итогам тестирования весь путь — от сканера до фискального чека — стал полностью автоматическим, стабильным и законно корректным.

После внедрения всех технических решений компания «Все Вода» получила полностью автоматизированный процесс работы с маркированной продукцией, который обеспечивает:

Дополнительно решение укрепило внутренние процессы компании. Ускорилась обработка заказов и отгрузка, а остатки на складе стали прозрачными и предсказуемыми даже при параллельной работе онлайн- и офлайн-каналов. Появилась возможность вести аналитику и строить отчеты по каждому каналу продаж отдельно, без риска ошибок и расхождений в данных.

Разработанная архитектура интеграции не привязана к конкретнои версии 1С или типу кассового оборудования. Ее можно адаптировать под разные конфигурации 1С, включая УТ, ERP и «Розницу», под кассы с поддержкои фискального API (например, Штрих-М, АТОЛ и Эвотор), а также под различные платежные шлюзы и сервисы фискализации, включая CloudKassir, PayKeeper и другие.

Такой подход делает систему масштабируемой, гибкой и готовой к внедрению в других бизнесах, где требуется работа с маркированными товарами и фискализация через онлайн-кассу.

Главная мысль этого кейса простая: даже задача, которая выглядит технически «несложной», на практике быстро становится комплексной, если нужно синхронизировать несколько систем с разными ограничениями и стандартами.

Системный анализ, последовательные доработки и внимание к каждому этапу передачи данных позволили собрать стабильную, законно корректную и масштабируемую цепочку. Ее можно использовать как рабочий архитектурный паттерн для похожих проектов.

Рекомендации для компаний с аналогичным контуром: