Для логистической компании изменение законодательства о маркировке товаров стало настоящим вызовом. Ситуация была напряженной: времени на адаптацию – всего несколько месяцев, а штрафы – до 1 млн рублей за каждое нарушение.
Мы решили задачу комплексно: связали водителей, 1С, облачную кассу и ОФД в единую систему. Теперь бизнес не только соблюдает закон и не боится проверок, но и серьезно экономит время на рутинных операциях.
Кто к нам пришел и с чем
К нам обратилась компания, которая занимается доставкой питьевой воды. Ситуация на старте напоминала классические «нулевые», несмотря на наличие 1С.
Как это работало раньше:
- Утро. Перед сменой логисты формировали путевые листы в 1С, печатали стопку бумаг и выдавали водителям. С этими распечатками экипажи уезжали на маршрут.
- День. У клиента водитель принимал оплату – наличкой или картой через обычный банковский терминал. Данные вносил ручкой в бумажку. Если оплата шла по карте, приходилось вручную вбивать сумму и статус на терминале. Естественно, человеческий фактор работал безотказно: ошибки случались регулярно.
- Вечер. Водитель с мешком денег и пачкой мятых бумаг возвращался в офис. Там стояла стационарная касса, и только в этот момент пробивались чеки.
Главная проблема: Фискализация происходила задним числом. По новым правилам это недопустимо. Чек должен быть выбит в момент передачи товара.
Итог такого подхода: Руководство работало вслепую. Было непонятно, какие заказы реально закрыты прямо сейчас, сколько денег собрано и сколько воды осталось в кузове. Отчеты появлялись только постфактум и часто не бились с реальностью.
Так продолжаться не могло. Заказчик выкатил список требований, который выглядел вполне логично:
- Упростить жизнь водителю. Хватит заполнять бумажки на коленке.
- Синхронизация с 1С в реальном времени. Чтобы логист видел статус заказа сразу, а не через 10 часов.
- Фискализация по закону. Электронный чек клиенту прямо на месте.
- Прозрачная аналитика. Кто сколько собрал, сколько сдал и где сейчас товар.
Вроде бы обычная задача по автоматизации. Но был один нюанс, который превращал проект в гонку на выживание: Нужна полная интеграция с системой «Честный ЗНАК».
Очень короткая справка: Это государственная система тотального контроля за товарами. Работает просто: на каждой единице товара (в нашем случае – на бутылке воды) есть уникальный DataMatrix код. Его нужно сканировать на всех этапах: от производства до передачи покупателю. Каждая операция летит в единую базу через операторов фискальных данных (ОФД). Цель благая – убрать контрафакт и серый рынок.
В чем была проблема? У заказчика эта система не была встроена в процессы доставки. Коды не проверялись в момент отгрузки клиенту – сверка шла постфактум в 1С. Это порождало огромный риск: водитель мог отдать клиенту бутылку с кодом А, а по документам провести бутылку с кодом Б (или вообще с нечитаемым кодом). Для налоговой это нарушение. А правила игры ужесточались с каждым днем, и перспектива получить штраф (или конфискацию товара) становилась пугающе реальной.
Получается, нужно было не просто решить задачу, но и успеть сделать это вовремя, а неудача обошлась бы очень дорого. Мы конечно согласились.
Какое решение мы предложили
Мы поняли, что бороться с бумажками можно только одним способом – сжечь их (фигурально) и дать водителю в руки нормальный инструмент. Мы разработали мобильное приложение, которое превращает терминал сбора данных (мы использовали неубиваемый ТСД Атол Smart.Slim Plus на Android 10) в полноценное рабочее место.
Как выглядит процесс теперь:
1. Загрузка. Водитель открывает приложение и видит список заказов, который прилетел напрямую из 1С. Никаких распечаток.
2. Скан. На адресе он не просто отдает воду, а сканирует маркировку на каждой бутыли камерой терминала.
3. Момент истины (Проверка). В эту же секунду код летит в базу «Честного ЗНАКА».
Сценарий «Провал»: Если код левый, просроченный или не в обороте – приложение выдает ошибку и блокирует продажу. Это та самая «защита от дурака», которая спасает компанию от штрафа в миллион. Водитель физически не может продать «неправильный» товар.
Сценарий «Успех»: Если все ок, открывается экран оплаты.
4. Деньги. Клиент платит как ему удобно (наличка, карта, СБП).
5. Финал. Чек формируется автоматически и улетает на email покупателя. Налоговая довольна, клиент доволен, водитель не мучается с писаниной.
Техническая начинка: Чтобы это все летало и не тупило в полях, мы взяли проверенную связку: Flutter на фронте (красиво, быстро и удобно для Android) и PHP (Laravel) на бэкенде (надежно как швейцарские часы).
С чего мы начали
Прежде чем приступить к разработке, мы проработали архитектуру будущего решения.
Сервер транзакций
Ключевым элементом стала прослойка между «полем» и офисом. Вот что делает этот сервер:
- Работает буфером. Передает данные из приложения в 1С и обратно.
- Маршрутизирует. Собирает данные от внешних сервисов («Честный ЗНАК», SoftPOS) и передает их в 1С. Учет в офисе всегда синхронизирован с реальностью.
- Хранит ходы. Каждая транзакция записывается с флагом «дошло до 1С / не дошло». Ничего не теряется при сбоях.
- Управляет очередью. Если 1С «приуныла» или недоступна, сервер ставит данные в очередь и пробует отправить их снова, пока не добьется успеха.
Сервер авторизации
Чтобы снять нагрузку с мобильного приложения и навести порядок в доступах, выделили отдельный сервер:
- Синхронизация. Подтягивает учетки водителей и права из 1С.
- Сессии. Позволяет оставаться в системе заданное время. Водителю не нужно логиниться заново посреди рейса, даже если связь моргнула.
- Фильтр. Любой запрос из приложения сначала проходит проверку здесь, и только потом допускается к телу (к транзакциям или 1С).
💡 Пользовательский опыт: При входе нужно ввести access-code для SoftPOS – это часть пользовательского пути, но доступ к приложению все равно выдает наш сервер авторизации. Безопасность превыше всего.
Для интеграции с учетной системой мы задействовали шину 1С (ESB). Зачем усложнять? Все просто: у заказчика в 1С уже было столько кастомных настроек и «костылей», что любое прямое вмешательство грозило обрушить всю бухгалтерию.
Зачем нам шина:
- Безопасный контур. Даже если на стороне мобильного приложения случится армагеддон, основная 1С останется в домике. Шина берет удар на себя, снижая риск случайных повреждений критичных данных.
- Трудности перевода. Она работает как переводчик: берет данные от сервера, конвертирует их из одного формата (например, XML в JSON) и только потом передает.
- Задел на будущее. Захотим подключить аналитику или новую CRM? Допиливать придется только взаимодействие на уровне шины, а не переписывать все модули.
💡 Безопасность: Для серверов транзакций и авторизации мы развернули изолированную виртуальную машину (Ubuntu Server 24.04 LTS) в Yandex Cloud. Доступ к шине 1С настроен так, что постучаться в нее может только эта конкретная ВМ. Никакие внешние сервисы или случайные приложения туда не пролезут.
Фичи нашего приложения
Архитектура – это скелет. А теперь про мышцы. Вот как мы решили две самые «больные» задачи проекта на практике.
1. Как переварить «тяжелую» 1С
Первая проблема всплыла сразу: база 1С у заказчика была огромной. При попытке выгрузить данные API плевалось десятками тысяч строк. Если бы мы отдали этот поток напрямую в приложение на терминал, он бы просто «сгорел».
Как мы это разрулили:
- Кэширование. Данные подгружаются частями. Это снимает нагрузку, и мобильный клиент летает, а не ползает.
- Синхронизация. Поручения на завтра подгружаются заранее ночью. Это страховка: даже если утром 1С «отвалится» или в офисе пропадет интернет, водитель все равно увидит свой маршрут и поедет работать.
- Мозги на сервере. Всю тяжелую математику и обработку данных мы оставили на сервере. Терминал – это просто экран с кнопками. Благодаря этому интерфейс не виснет, а бизнес уверен: все статусы улетят в базу корректно.
Итог: Риск потерять заказ из-за сбоя сети сведен к нулю.
2. Тройной удар: Касса, Эквайринг и «Честный ЗНАК»
Самая сложная часть – момент продажи. Тут нужно было связать сканер, проверку государством и прием денег так, чтобы водитель не запутался. Мы выбрали схему с SoftPOS (использовали 2can Tap2Go αPOS) и настроили бесшовный переход.
Перед самой оплатой водитель сканирует коды DataMatrix. Для каждой марки выполняется запрос в «Честный знак» в разрешительном режиме. Если код некорректный, выбыл из оборота или повторный – система не даст провести продажу. Только «чистые» коды формируют состав чека и сумму к оплате. Это важно: так мы исключили риск, что товар с «битой» маркировкой уйдет клиенту и создаст проблемы при фискализации.
После успешной проверки открывается SoftPOS с готовой суммой.
Когда клиент платит, SoftPOS возвращает управляющее событие в приложение. Мы фиксируем оплату, отправляем данные в 1С и в облачную кассу через ОФД. Касса передает фискальные данные и сведения о маркировке в ФНС и «Честный ЗНАК», а событие сохраняется в 1С.
💡 Технический момент: Реализовали возможность выгрузки логов сканирования и проверки маркировки.
💡 Пользовательский опыт: Водитель видит только понятные статусы (зеленый – можно, красный – нельзя, с пояснением) и не вводит сумму вручную. Это снижает ошибки и ускоряет работу.
А что если интернета нет?
Мы прекрасно понимали, что у водителей не всегда есть стабильная связь (подвалы, промзоны, трасса). Поэтому реализовали оффлайн-очередь: если в момент оплаты или передачи данных в 1С и облачную кассу интернет пропадает, данные не теряются. Чек и события оплаты ставятся в очередь на устройстве и автоматически улетают на сервер, как только соединение восстанавливается.
Важный нюанс: Раньше для работы с маркировкой обязательно нужно было быть онлайн – система не давала добро без проверки. Уже после старта работ у «Честного ЗНАКА» вышло обновление, которое позволяет делать это даже без интернета (с локальной базой). Мы уже зафиксировали этот запрос заказчика на поддержку офлайн-проверок и планируем реализовать ее в следующих итерациях.
Финал и выводы
Движение товаров теперь полностью соответствует требованиям законодательства. Сервис прошел проверку боем и успешно используется в работе.
Что в итоге:
- Водители: Получили удобный инструмент. Поручения, сканирование марок, пробитие чеков – все в одном приложении, а не в трех разных девайсах и блокноте.
- Компания: Получила прозрачность. Доступ к информации по заказам, статусам, деньгам и остаткам товаров обновляется в реальном времени. Руководитель видит картину здесь и сейчас.
- Мы: Получили классный, сложный кейс в портфолио.
Что дальше? Проект живет и развивается. На следующих этапах планируем внедрить:
- Полноценную карту с отображением всех экипажей.
- Модуль заработной платы для водителей.
- Приложение для клиентов.
Привет, я Алексей Сорокин, и мы в Softlex разрабатываем веб-сервисы и мобильные приложения, а еще помогаем стартапам принимать взвешенные бизнес-решения 🤝
👉 Свяжитесь с нами в Telegram или оставьте заявку на сайте – и получите партнера, который берет на себя сложное, чтобы у вас оставалось время на важное.
И подписывайся на наш телеграм канал 😉