← На главную

При переходе на разрешительный режим работы с маркированной продукцией пользователи часто сталкиваются с ситуацией, когда через кассу свободно пробиваются товары с истекшим сроком годности или происходит повторное выбытие одного и того же кода маркировки. Кассовое ПО и программные шлюзы не выдают предупреждений и успешно закрывают фискальный чек. Разберем архитектурные особенности взаимодействия связки «1С:Розница», технологического сервиса проверки кодов маркировки (ТС ПИоТ) и локального модуля Честного Знака (ЛМ ЧЗ), выясним причины такого поведения и настроим систему для гарантированной блокировки нарушений.

Архитектура проверки: в чем разница между ТС ПИоТ и ЛМ ЧЗ

Чтобы понять причину сбоя контроля, проанализируем схему взаимодействия компонентов при сканировании кода маркировки на кассовом узле:

1. Онлайн-проверка через ТС ПИоТ: кассовый модуль 1С передает считанный код в службу ТС ПИоТ (обычно доступную по локальному порту, например localhost:51401). ПИоТ выполняет прямой онлайн-запрос к серверам ГИС МТ (ЦРПТ). В структуре онлайн-ответа возвращаются подробные сведения: статус кода, признак выбытия, владелец, а также поля даты производства productionDate и окончания срока годности expireDate. При успешной проверке на кассе формируется признак [М+].
2. Офлайн-проверка через ЛМ ЧЗ (Локальный модуль): если за отведенный интервал времени онлайн-ответ от серверов маркировки не получен (сбой связи, нестабильный интернет, превышение лимита ожидания), ТС ПИоТ выполняет аварийный сброс (fallback) на Локальный модуль.

Главная архитектурная особенность заключается в том, что Локальный модуль (ЛМ ЧЗ) не содержит информации о сроках годности, МРЦ и повторных продажах. ЛМ ЧЗ хранит исключительно базу скомпрометированных и заблокированных по предписаниям надзорных органов кодов. Для него любой код маркировки корректного формата, отсутствующий в черном списке, считается разрешенным к продаже. В чек при этом уходит базовый статус [М] вместо [М+].

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

Анализ логов и диагностика в 1С

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

В первую очередь откроем внутренние регистры учета проверок маркировки в конфигурации 1С. Основным источником данных служит РегистрСведений.ОперацииПроверкиКМ. Проанализируем записи регистра по проблемным чекам:

1. Посмотрим на фактический результат проверки: если вместо статуса успешной онлайн-проверки стоит признак офлайн-валидации или неполной проверки, чек был оформлен без подтверждения от ГИС МТ.
2. Изучим текст ответа в структуре проверки. При успешном онлайн-запросе в нем обязательно присутствуют атрибуты expireDate и productionDate. Если этих полей нет, проверка ушла в ЛМ ЧЗ.
3. Проверим журналы самого сервиса ТС ПИоТ. Нередко в логах наблюдается ситуация, когда ПИоТ успешно получает ответ от сервера ГИС МТ, но из-за превышения установленного внутреннего порога времени параллельно отправляет запрос в ЛМ ЧЗ, возвращая в 1С ответ локального модуля.
4. Зайдем в личный кабинет ТС ПИоТ и оценим статистику: процент чеков, обработанных онлайн, и процент запросов, перенаправленных в локальный модуль.

Регулировка таймаутов и сетевых параметров

Основная причина нежелательного перехода на ЛМ ЧЗ — жесткие тайм-ауты ожидания сетевого ответа. По умолчанию время ожидания может составлять 1500 мс, чего часто недостаточно при кратковременных просадках интернет-канала.

Выполним корректировку параметров:

1. Откроем конфигурационные файлы службы ТС ПИоТ и увеличим время ожидания ответа онлайн-проверки до 3000–5000 мс.
2. В настройках интеграции с ИС МП внутри 1С проверим и актуализируем CDN-площадки. Выполним тестирование скорости отклика до доступных адресов ЦРПТ и выберем площадки с наименьшим пингом.
3. Проверим стабильность физического канала интернет-связи на кассовом узле.

Настройка блокировок в 1С:Розница

Чтобы исключить продажу просроченных позиций и дублей, настроим саму учетную систему:

1. Запрет продажи без статуса [М+]: перейдем в раздел настроек интеграции с ИС МП и параметрах сканирования кодов маркировки установим строгий запрет на добавление позиции в чек и закрытие чека, если код не прошел полноценную онлайн-проверку (статус проверки отличается от [М+]). При такой настройке касса заблокирует чек, если сервис попытается применить ответ от ЛМ ЧЗ.
2. Синхронизация системного времени: сопоставление даты из поля expireDate с текущим моментом времени часто выполняется логикой кассовой программы. Проверим настройки службы времени Windows на кассовом ПК: настроим синхронизацию через NTP и проверим корректность часового пояса. При расхождении системных часов проверка срока годности дает сбой.
3. Локальный контроль повторных продаж: онлайн-сервис ГИС МТ выводит код из оборота с некоторой задержкой (после обработки чека через ОФД), поэтому моментальную повторную продажу серверная часть не блокирует. Защита от повторного считывания должна контролироваться конфигурацией 1С. Убедимся, что в настройках РМК активирован контроль повторного сканирования одного и того же штрихкода в рамках одного чека и проверка статусов кодов по внутренним данным базы.

Обновление и альтернативные варианты РМК

В конфигурациях «1С:Розница 2.3» интерфейс «старого» РМК поддерживается по остаточному принципу, и обработка ответов разрешительного режима в нем может содержать платформенные ошибки:

1. Установка актуальных патчей: через сервис интернет-поддержки установим все вышедшие исправления (патчи) для подсистем БПО и ИС МП. Фирма «1С» регулярно выпускает исправления механизмов парсинга JSON-ответов от ТС ПИоТ.
2. Переход на интерфейс «Новое РМК»: включим использование нового универсального РМК в настройках программы. Новое рабочее место кассира содержит переработанную логику разрешительного режима, корректно обрабатывает структуру вложенных тегов срока годности и жестко блокирует чеки без подтвержденного статуса онлайн-валидации.
3. Включение партионного учета: если требуется исключить влияние сбоев внешних сервисов на контроль годности, включим в 1С серийный учет номенклатуры с контролем сроков годности. В этом случае касса заблокирует просроченный товар на этапе проверки остатков серий, не полагаясь исключительно на внешние запросы к ГИС МТ.