ТС ПИоТ выходит на передний план для всех компаний, которые продают маркированный товар через кассу. Пока схема держится на старых настройках, кажется, что вопрос можно отложить. Но как только продажи начинают идти через разрешительный режим, быстро выясняется: важен не отдельный флажок в 1С, а вся цепочка целиком — релиз конфигурации, ККТ, драйверы, формат фискальных данных, канал связи с ГИС МТ и сценарий отказа.
В новых материалах 1С по обновлениям прямо указано, что после завершения действия розничного токена запросы в ГИС МТ будут выполняться с использованием сертифицированного ПО ТС ПИоТ. Поэтому проект внедрения стоит воспринимать не как косметическую настройку, а как часть подготовки кассового и учетного контура к продаже маркированной продукции без остановок на кассе.
Продажа маркированного товара в рознице требует корректно настроенного разрешительного режима.
Что такое ТС ПИоТ и кому он нужен
В практическом смысле ТС ПИоТ — это сертифицированный программный контур, через который кассовое ПО и 1С выполняют проверку маркированного товара при продаже. Для бизнеса это не отдельная “коробка”, а часть рабочей схемы розничной продажи: касса считывает код, 1С и торговое оборудование отправляют запрос, система получает ответ и уже после этого продажа либо проходит, либо блокируется.
Это важно тем компаниям, которые:
- продают маркированные товарные группы в рознице;
- работают через 1С:РМК, 1С:Розницу, УНФ или смежный 1С-контур с кассовым оборудованием;
- не хотят останавливать продажу на кассе из-за неподготовленных драйверов, ККТ или настроек проверки;
- должны заранее подготовиться к переходу на работу через ТС ПИоТ после завершения переходного периода по розничным токенам.
Именно поэтому внедрение ТС ПИоТ лучше вести как мини-проект: с проверкой версий, оборудования, прав доступа, каналов связи и тестового сценария продажи, а не как локальную правку “на одной кассе”.
Как работает разрешительный режим на кассе
Официальная логика режима достаточно простая, но в реальной работе ломается именно на стыках систем.
- Кассир сканирует код маркировки при продаже.
- Касса и учетный контур отправляют запрос на проверку.
- Если код проходит проверку, продажа разрешается; если нет, касса должна корректно отработать отказ.
- Если онлайн-проверка недоступна, бизнес должен понимать, как работает резервный офлайн-сценарий и где он контролируется.
Для проекта это означает одну важную вещь: проверять нужно не “видит ли касса код”, а проходит ли весь сквозной маршрут от сканирования до чека и записи в журнал проверки. Именно здесь чаще всего и проявляются реальные ошибки внедрения.
Перед запуском ТС ПИоТ стоит собрать единый чек-лист, а не разрозненные заметки по кассе, 1С и маркировке.
Что нужно проверить до старта проекта
1. Версию 1С и поддержку режима в конфигурации
Первый вопрос не в том, “есть ли маркировка”, а в том, поддерживает ли ваш текущий релиз именно тот сценарий разрешительного режима, который нужен бизнесу сейчас. В материалах 1С это вынесено отдельно: по разным конфигурациям и релизам поддержка расширяется постепенно, а часть настроек появляется только в новых версиях.
Если база давно не обновлялась, начинать надо не с кассы, а с аудита текущего релиза и плана обновления. Иначе дальше выстраивается схема вокруг конфигурации, которая не готова к нужной логике проверки.
2. ККТ, ФФД и драйверы
На кассовом контуре слабое место почти всегда одно и то же: старая модель работы с ККТ или неактуальный драйвер. В официальном чек-листе 1С отдельно указано, что ККТ с форматом фискальных данных 1.0.5 не поддерживает разрешительный режим, потому что в этом формате отсутствует тег 1260.
Практически это означает, что перед стартом проекта нужно:
- проверить модель кассы и ее совместимость с ТС ПИоТ;
- убедиться, что используется корректный формат фискальных данных;
- обновить драйверы ККТ;
- проверить, не завязана ли работа на старую схему, которая уже не подойдет после переходного периода.
3. Категории товаров, даты и настройки сканирования
Разрешительный режим вводится поэтапно, а значит ошибка может быть не в оборудовании, а в неверной логике по товарной группе. Если в 1С некорректно заданы даты начала режима, исключения или параметры сканирования кодов, касса начнет вести себя не так, как ожидает бизнес.
Здесь нужно проверить:
- какие маркированные категории реально продаются в компании;
- для каких из них уже действует нужный режим проверки;
- верно ли настроены даты, исключения и параметры сканирования;
- включены ли опции продаж маркированной продукции на рабочих местах кассира.
4. Связь, офлайн-проверку и пробный чек
Даже если онлайн-сценарий выглядит настроенным, проект нельзя считать готовым без пробной продажи и проверки журналов. В официальных материалах 1С есть отдельные блоки про журнал проверки кодов маркировки и настройки, которые сокращают задержку ответа на кассе. Это не “дополнительные детали”, а способ заранее увидеть, где будет ломаться реальная продажа.
Минимальный рабочий набор перед запуском:
- проверить канал связи и время ответа;
- понять, где и как будет использоваться офлайн-проверка;
- провести тестовую продажу на реальной кассе;
- открыть журнал проверок и убедиться, что результаты фиксируются предсказуемо.
Окно подключения ТС ПИоТ в 1С лучше проверять вместе с кассовым контуром, а не отдельно от него.
Где бизнес чаще всего ошибается
Типовые ошибки почти всегда повторяются от проекта к проекту.
Считают, что достаточно просто обновить 1С
Обновление конфигурации — только часть задачи. Если не проверены ККТ, драйверы, формат фискальных данных и реальный маршрут проверки на кассе, сам по себе релиз проблему не решает.
Настраивают одну кассу, а не весь сценарий продажи
Демонстрация “на стенде” часто проходит успешно, а на реальной точке начинаются зависания, нестабильный ответ или несогласованность между настройками рабочих мест. Поэтому тест должен воспроизводить настоящий маршрут продажи, а не только открытие формы настройки.
Игнорируют офлайн-сценарий
Когда в магазине нестабилен интернет или есть особенности канала связи, отсутствие понятного офлайн-плана быстро превращается в блокировку продаж. Это особенно опасно в распределенной рознице и на точках, где нет сильного локального ИТ-ресурса.
Не проверяют журнал и не фиксируют результат пилота
Если команда не смотрит, как именно проходят проверки кодов и какие ответы возвращаются по тестовым продажам, она узнает о проблемах только в момент живого чека. Для кассового контура это поздно.
Как внедрять без сбоев
Рабочий подход к ТС ПИоТ обычно выглядит так:
- Зафиксировать, какие товарные группы и какие кассы реально участвуют в проекте.
- Проверить текущие релизы 1С, ККТ, драйверы и формат фискальных данных.
- Настроить подключение ТС ПИоТ, параметры сканирования и рабочие места кассира.
- Провести пилот на ограниченном наборе точек или касс.
- Проверить журнал, время ответа, отказные сценарии и поведение персонала на кассе.
- Только после этого масштабировать настройку на всю сеть или все торговые точки.
Такой сценарий позволяет снизить риск “тихих” ошибок, которые обычно проявляются уже в торговом зале: продажа не проходит, кассир не понимает причину отказа, а ИТ разбирается с проблемой уже под давлением очереди.
Вывод
Внедрение ТС ПИоТ — это не про отдельный параметр в 1С, а про готовность всей цепочки продажи маркированного товара. Если конфигурация, касса, драйверы и сценарий проверки настроены несогласованно, бизнес получает не контроль, а новый источник сбоев на кассе.
Правильный подход другой: заранее проверить релизы, ФФД, оборудование, настройки категорий, журнал и пробный чек, а затем запускать режим поэтапно. Тогда разрешительный режим становится управляемой частью розничного процесса, а не аварийной точкой в момент продажи.
По теме статьи
Подготовить 1С и кассы к ТС ПИоТ без сбоев
Если нужно подготовить 1С, кассовый контур и маркировку к работе через ТС ПИоТ и разрешительный режим, поможем провести аудит, настроить подключение и безопасно запустить проект на действующих точках.