В последнее время пользователи конфигурации 1С:Розница 2.3.21.29 и смежных релизов столкнулись с критической проблемой: при сканировании маркированного товара рабочее место кассира (РМК) «наглухо» зависает. Ситуация осложняется, если на предприятии настроено несколько касс ККМ в РМК для Розницы 2.3, что требует особой стабильности соединений. На экране отображается статус «Идет проверка в ОИСМ», и система перестает реагировать на любые действия, кроме принудительного завершения процесса через диспетчер задач Windows. Эта ситуация особенно актуальна в связи с введением обязательного разрешительного режима на кассах.
Проанализируем причины возникновения этой ошибки и разберем по шагам методы ее устранения, опираясь на практический опыт технических специалистов.
Разберем ситуацию: современная «Розница» использует два параллельных пути проверки кода маркировки. Первый путь — это запросы самой 1С к CDN-площадкам «Честного знака» через установленный токен доступа. Второй путь — это проверка средствами самой контрольно-кассовой техники (ККТ) через ОИСМ (Общероссийская информационная система маркировки) в соответствии с ФФД 1.2.
Зависание происходит в тот момент, когда 1С ожидает ответа от драйвера ККТ, а драйвер, в свою очередь, ожидает ответа от серверов ИСМ — для решения проблемы подойдёт система удаленной печати чеков для устранения зависаний ККТ. Если канал связи нестабилен или настройки портов в кассе конфликтуют с настройками в программе, возникает бесконечный цикл ожидания. Посмотрим, как это исправить программными методами.
Для владельцев кассовых аппаратов АТОЛ одним из самых эффективных решений является смена способа передачи данных в ОФД и ИСМ. Рассмотрим этот процесс подробнее:
EoU (Ethernet-over-USB), это может быть причиной блокировки потока данных.EoT (Ethernet-over-Transport). Этот протокол работает внутри основного канала обмена с кассой и значительно стабильнее обрабатывает запросы к ОИСМ в фоновом режиме.Разберем, как минимизировать время ожидания, чтобы программа не «висела» бесконечно. Если проверка в ОИСМ занимает слишком много времени, мы можем ограничить период ожидания:
В настройках интеграции с ИС МП (раздел Администрирование — Маркировка) проверим параметры Разрешительного режима — для этого подойдёт обработка для работы онлайн-касс с маркировкой и разрешительным режимом. Проанализируем настройки CDN-площадок. Рекомендуется нажать кнопку Обновить площадки, так как старые адреса могут быть недоступны. Также важно убедиться, что автоматическое обновление токенов Честного Знака в 1С настроено корректно, иначе просроченный токен приведет к ошибкам аутентификации и подвисанию интерфейса.
Если закон позволяет (например, в случае технических сбоев на стороне ЦРПТ), можно временно настроить работу так, чтобы при отсутствии ответа в течение 3–5 секунд система предлагала добавить товар в чек без онлайн-проверки. Это исключит «мертвое» зависание интерфейса. Для этой задачи есть модуль подключения касс для маркировки без обновления 1С.
Для касс производства «Штрих-М» ситуация часто требует обновления драйверов. Проанализируем технические требования:
1cv8.exe и фискальным регистратором.Часто зависания сопровождаются сопутствующими ошибками при обмене данными с другими конфигурациями (например, УТ 11). Выясним причину ошибки ПКО НДС 5%, упомянутой в обсуждении. Ирония судьбы, или С новой ставкой! заключается в том, что в правилах обмена Enterprise Data версии 2.3.21.x могут отсутствовать новые налоговые ставки, актуальные с 2025 года.
В самой «Рознице» логика сопоставления выглядит так:
// Пример логики сопоставления ставок в правилах обмена (условно)
Если ЗначениеЗаполнено(СтавкаНДС) И СтавкаНДС = Перечисления.СтавкиНДС.НДС5 Тогда
// Необходимо убедиться, что в приемнике (УТ 11) создана аналогичная ставка
// и обновлена версия метаданных обмена
Результат = "НДС5";
КонецЕсли;
На текущий момент решением является ручная корректировка сопоставления в узлах обмена или ожидание патча, который добавит поддержку ставок 5% и 7% в транспортные сообщения XML.
Рассмотрим дополнительные технические аспекты, которые влияют на скорость проверки марок:
123 (NTP) для автоматической синхронизации. Разница даже в несколько минут может привести к тому, что токен проверки будет считаться невалидным.Local и Roaming в профиле пользователя).Резюмируем: Основной способ борьбы с зависанием «Розницы» при проверке марок — это переход на современные протоколы передачи данных (EoT для АТОЛ, RNDIS для Штрих-М) и жесткое указание параметров серверов ИСМ в настройках 1С. Совместное использование этих методов позволит вашему РМК работать стабильно даже в условиях повышенной нагрузки на систему маркировки.