Ситуация
Заказчик — региональная сеть, которая продает автотовары в розницу: шины, покрышки, моторные масла и техжидкости. У компании несколько своих магазинов, интернет-магазин, площадки Яндекса и Озона и небольшой опт.
Шины и покрышки подлежат обязательной маркировке в «Честном знаке». У каждой единицы товара свой код, и при продаже его нужно отсканировать и вывести из оборота. Без этого товар нельзя ни продать в магазине, ни отгрузить на маркетплейс.
Раньше заказчик вел учет в «1С:Управление торговлей» (УТ) редакции 10.3. Работа с маркировкой в этой редакции не предусмотрена: она вышла до того, как появился «Честный знак». Требования закона компания закрывала собственными доработками — их дописывали по мере того, как под маркировку попадали новые товарные группы.
Доработки уже не успевали за требованиями. Часть действий сотрудникам приходилось выполнять вручную, и работа с маркетплейсами упиралась в те же ограничения. С апреля 2024 года фирма «1С» перестала выпускать обновления для редакции 10.3, и каждое новое требование законодательства компания разрабатывала за свой счет.
Заказчик перешёл на УТ 11.5, где поддержка маркировки типовая и приходит с обновлениями. Интеграцию с «Честным знаком» вынесли в отдельный этап и занялись ею, когда компания начала работать в новой базе.
Настройку начали с шин и покрышек — и тогда впервые стало видно, что типовой отбор документов здесь не работает. Дело в том, как в компании устроена розничная продажа.
Покупатель оплачивает товар, кассир пробивает чек на аванс, склад выдает товар, и только потом пробивается второй чек на зачет оплаты. Схема с двумя чеками сложилась исторически, и при переходе на УТ 11.5 заказчик ее сохранил.
Между этими двумя чеками маркированный товар нужно отсканировать на ТСД, чтобы коды попали в документ реализации. Задание на сканирование склад получает автоматически, по шаблону выгрузки. Шаблон умеет отбирать документы по статусу, дате, складу, варианту оформления продажи, но проверить, пробит ли по документу аванс, он не умеет.
В результате на терминал уходил весь поток документов по складу: оплаченные продажи вперемешку с только что созданными и висящими в статусе предоплаты. Понять по документу, расплатился ли покупатель, было нельзя. Поэтому статус оплаты уточняли у кассиров — звонили, писали в почту, подходили лично. Часть работы взял на себя системный администратор: какое-то время он вычищал лишние документы из очереди вручную.
Задача
Заказчик попросил настроить отбор так, чтобы на ТСД уходили только продажи маркированного товара с уже пробитым авансовым чеком. Задание на сканирование должно приходить на склад в течение минуты после оплаты. Для покупателя все должно выглядеть как в обычном магазине: оплатил и забрал товар, без ожидания у кассы.
Решение
К началу работ у нас уже были схемы всего торгового процесса заказчика, отрисованные при переходе на новую редакцию. По ним разбирались, по какому признаку система может отличить оплаченную продажу от неоплаченной.
Нашли признак оплаты. Первым делом посмотрели на статус документа реализации — того самого, который уходит на терминал. Статус у него есть, и шаблон выгрузки умеет по нему фильтровать. Но статус меняют руками, и к факту оплаты он отношения не имеет.
Тогда вернулись к схеме. Чек на аванс создается на основании документа реализации — значит у каждого из них есть событие, по которому видно, что оплата прошла. Признаком готовности решили сделать появление авансового чека. Он попадает в базу только тогда, когда деньги уже приняты. Оставалось научить систему узнавать об этом автоматически и без участия кассира.
Закрыли признак от ручной правки. В документ добавили служебный реквизит impro_ПлатежСделан. На форму он не выводится: кассир и бухгалтер его не видят и не могут изменить. Это осознанное ограничение — будь признак на форме обычной галочкой, оставался бы шанс проставить его раньше времени, и на склад ушел бы неоплаченный документ. Заодно из этого решения выросло следующее. Раз пользователи к реквизиту не допущены, заполнять его должна сама система.
Настроили регламентное задание. Оно запускается раз в минуту, находит реализации, по которым уже пробит авансовый чек, и проставляет им признак. Минуты достаточно, чтобы покупатель не замечал паузы между оплатой и выдачей товара.
Дописали условие в шаблон выгрузки. К типовым условиям автовыгрузки DataMobile — статус, дата, склад, вариант оформления продажи — добавили еще одно: impro_ПлатежСделан = Да. Эта строка отсекает все лишнее, и на терминал попадают только те продажи, по которым покупатель уже расплатился.
Непредвиденные трудности
Осенью 2025 года, когда работы уже шли, под обязательную маркировку попала новая товарная группа. Моторные масла и техжидкости тоже стали маркируемыми, а остатки на складах нужно было промаркировать до конца октября — иначе продавать их было уже нельзя.
В проект закладывали только шины и покрышки, а тут добавились масла. Времени оставалось совсем мало. Позиции номенклатуры перевели на новый вид, запросили в «Честном знаке» коды маркировки на остатки и ввели товары в оборот. Отдельно проверили, что новая группа проходит через тот же процесс продажи — от задания на ТСД до закрывающего чека.
Перечень маркируемых товаров расширяется каждый год, и подключать новые группы приходится всем участникам оборота — от производителя до розницы. Мы настраиваем «Честный знак» в 1С под сложившиеся процессы компании, включая работу с торговым оборудованием.
Результат
Раньше на терминал склада падали десятки документов подряд, оплаченные вперемешку с неоплаченными, и кладовщик не мог понять, по каким из них выдавать товар. Теперь он получает задание на сканирование только по тем продажам, где покупатель уже расплатился, а системный администратор не занимается ручной чисткой очереди.
От оплаты до выдачи товара проходит 5–10 минут. Покупатель забирает все сразу, как в обычном магазине, и не ждет, пока склад и касса разберутся между собой.
Длительность. Две недели, включая срочное подключение масел и техжидкостей.
Команда. С нашей стороны работали 2 специалиста: аналитик и разработчик. Со стороны заказчика проект вели системный администратор и бухгалтер, в работе участвовали кассиры и работники склада.
