Каждый владелец розничного магазина и системный администратор знает, что скорость работы кассы — это критически важный фактор. Задержка на кассовом узле даже на 15–20 секунд способна мгновенно выстроить очередь, вызвать недовольство покупателей и снизить лояльность к торговой точке. Но что делать, если после очередного обновления программы или включения обязательной маркировки касса начинает «зависать» на несколько минут при пробитии обычного чека?
В этой статье мы подробно проанализируем распространенную и крайне неприятную проблему, с которой столкнулись пользователи конфигурации 1С:Розница (в частности, релиза 2.3.4.33 на платформе 8.3.15.1869). Выясним, почему при активации опции интеграции с МОТП (Мониторинг оборота табачной продукции) и Честным Знаком пробитие чеков превращается в мучительное ожидание, сопровождающееся лавинообразным ростом дисковой активности, и как по шагам устранить эти «тормоза».
Давайте детально рассмотрим поведение системы в момент возникновения проблемы. При включенной опции Вести учет табачной продукции (раздел администрирования интеграции с ИС МП / МОТП) кассир сканирует маркированный товар, принимает оплату и подтверждает пробитие чека. В этот момент программа буквально замирает. Процесс фискализации может занимать от 30 секунд до 5 минут даже для чека с одной позицией.
Если мы обратимся к монитору ресурсов операционной системы или технологическому журналу 1С, то увидим лавинообразный рост дискового обмена с базой данных. База совершает сотни тысяч мелких операций чтения и записи. Стоит нам отключить флаг учета табачной продукции — и былая скорость возвращается: чеки снова пробиваются мгновенно, а дисковая нагрузка падает до нуля. Очевидно, что проблема кроется в неоптимальных алгоритмах обработки маркировки внутри самой конфигурации.
Разработчики фирмы 1С признали наличие этой проблемы и зарегистрировали несколько критических ошибок, связанных с производительностью механизмов интеграции с ИС МП в РМК (Рабочем месте кассира).
1. Ошибка EF_00_00300787 («РМК: Долгое пробитие чека ККМ»)
Эта ошибка напрямую связана с логикой работы общего модуля РозничныеПродажиСервер. При проведении чека с маркированной продукцией система инициирует сложный каскад проверок кодов маркировки в базе данных и пытается сопоставить их со статусами ИС МП. Из-за архитектурных недочетов в коде проверки выполнялись циклически для каждой позиции, создавая избыточную нагрузку на СУБД или файловую базу данных. В результате время записи движений документа ЧекККМ возрастало в геометрической прогрессии.
2. Ошибка EF_00_00302072 («Долго открывается документ ЧекККМ»)
Данная ошибка часто сопутствует первой и проявляется при попытке открыть уже пробитый чек или оформить возврат. Программа «зависает» на 30–40 секунд. Причина здесь чисто техническая и кроется в классическом неоптимальном SQL-запросе в механизме фискальных операций.
Проанализируем структуру проблемного запроса. В исходном коде конфигурации условие связи таблиц выглядело следующим образом:
ВЫБРАТЬ
ФискальныеОперации.Ссылка КАК Ссылка
ИЗ
РегистрСведений.ФискальныеОперации КАК ФискальныеОперации
ГДЕ
ФискальныеОперации.ДокументОснование.Ссылка = &Ссылка
Использование конструкции ДокументОснование.Ссылка при обращении к реквизиту ссылки через точку является грубейшей ошибкой оптимизации в 1С. Поскольку реквизит ДокументОснование имеет составной тип данных, такое обращение заставляет СУБД выполнять неявное левое соединение (LEFT JOIN) со всеми таблицами документов, входящих в этот тип. Это полностью блокирует использование индексов СУБД и приводит к сканированию всей таблицы (Table Scan), вызывая колоссальную нагрузку на жесткий диск кассового ПК.
Для исправления этой ситуации разработчики оптимизировали запрос, убрав лишнее разыменование ссылки:
ВЫБРАТЬ
ФискальныеОперации.Ссылка КАК Ссылка
ИЗ
РегистрСведений.ФискальныеОперации КАК ФискальныеОперации
ГДЕ
ФискальныеОперации.ДокументОснование = &Ссылка
После этой простой замены СУБД начинает использовать прямой индекс по измерению ДокументОснование, и поиск фискальной операции выполняется мгновенно за миллисекунды.
Рассмотрим подробнее, какие практические шаги необходимо предпринять системному администратору или программисту 1С для ликвидации этой проблемы.
Если у вас установлена версия 1С:Розница 2.3.4.33 и вы пока не планируете глобальное обновление конфигурации, наиболее быстрым решением будет установка готовых патчей от разработчиков 1С. Вам понадобятся исправления под номерами EF_00_00300787 и EF_00_00302072.
Для их автоматической установки перейдите в раздел Администрирование -> Обслуживание -> Обновление программы -> Установленные исправления (патчи) и загрузите их из Интернета или установите вручную, предварительно скачав файлы исправлений с портала техподдержки 1С.
Установка патчей — это эффективная, но временная мера. Кардинальным решением является обновление конфигурации «1С:Розница» до более актуальных релизов. Все указанные ошибки интеграции с МОТП были полностью устранены в релизах начиная с 2.3.5.28, а также в последующих версиях ветки 2.3.6 и Розница 3.0. Рекомендуется запланировать обновление во внерабочее время.
При включении табачного учета активируется фоновая активность по обмену данными. Проанализируем расписание регламентного задания Очередь операций с ИС МП. Если оно запускается слишком часто (например, каждые 10-20 секунд), это может блокировать таблицы СУБД прямо в момент транзакции на кассе. Настройте запуск этого задания на нерабочее время или увеличьте интервал опроса до приемлемых 15-30 минут.
Медленная запись движений чека часто усугубляется задержками на уровне физического оборудования. Вместе с обновлением конфигурации обязательно обновите встроенную Библиотеку подключаемого оборудования (БПО) и установите самые свежие сертифицированные драйверы для ваших ККТ (АТОЛ, Штрих-М и др.). Это существенно снизит время задержки при передаче команды печати на фискальный регистратор.
Если ваша касса работает в файловом режиме (особенно при работе по локальной сети), накладные расходы на блокировку файлов базы данных при проверке маркировки возрастают лавинообразно. Для исключения подобных проблем рассмотрите переход на клиент-серверный вариант работы с использованием СУБД (PostgreSQL, MS SQL) либо, как минимум, перенесите файловую базу на быстрый локальный SSD-накопитель серверного класса на кассовом ПК.
Применение данных рекомендаций позволит вам полностью избавиться от задержек при пробитии чеков с маркировкой, разгрузит дисковую подсистему ваших кассовых компьютеров и обеспечит быструю, комфортную работу кассиров без очередей.