При переходе на новые релизы конфигурации «1С:Розница» (начиная с версии 2.3.1.40 и выше) многие пользователи и технические специалисты сталкиваются с крайне неприятной проблемой: при пробитии чека, содержащего алкогольную продукцию, касса «зависает» на 30–60 секунд. Обычные (немаркированные) товары при этом пробиваются мгновенно, а сетевой пинг до УТМ (Универсального транспортного модуля ЕГАИС) составляет менее 1 миллисекунды. Переустановка драйверов ККТ, обновление самого УТМ и стандартное тестирование базы данных результатов не дают.
В этой статье мы подробно разберем, почему возникает данная задержка, где именно в коде конфигурации находится «узкое горлышко» и какими способами можно вернуть высокую скорость обслуживания покупателей на кассовой зоне.
Для того чтобы понять природу зависания, нам необходимо воспользоваться встроенным инструментом отладки. Проанализируем ситуацию и выполним замер производительности в момент пробития чека на кассовом узле.
Замер показывает, что практически все время задержки (до 90% экранного времени ожидания) уходит на выполнение одной-единственной процедуры: ПроверитьАкцизныеМаркиПередЗаписьюЧека в общем модуле ПродажиСервер. Запрос внутри этой процедуры пытается убедиться, что сканируемая акцизная марка не продавалась в магазине ранее.
Давайте разберем, почему этот механизм начинает тормозить именно после обновления на версию 2.3:
РегистрСведений.АкцизныеМаркиЕГАИС (работает быстро за счет индексов) и по табличным частям АкцизныеМарки всех исторических документов Документ.ЧекККМ.Ниже мы подробно рассмотрим несколько практических вариантов решения этой технической проблемы — от оперативного вмешательства в код до системной оптимизации базы данных.
Если у вас нет времени на глубокую реструктуризацию базы данных, наиболее быстрым решением является возврат к старому, облегченному алгоритму проверки акцизных марок, который использовался в версии 2.2. Этот метод успешно применил автор темы на форуме.
Для этого мы создадим расширение конфигурации и переопределим поведение процедуры ПроверитьАкцизныеМаркиПередЗаписьюЧека. Вместо выполнения тяжелого запроса по архивным чекам ККМ за несколько лет, мы можем либо полностью отключить эту избыточную проверку внутри 1С (переложив контроль дублей на сам УТМ ЕГАИС, который в любом случае проверяет марки онлайн на серверах ФСРАР), либо ограничить поиск.
Рассмотрим пример кода в расширении, который полностью отключает тяжелую локальную проверку перед записью чека, доверяя контроль системе ЕГАИС:
&Вместо("ПроверитьАкцизныеМаркиПередЗаписьюЧека")
Процедура Расш_ПроверитьАкцизныеМаркиПередЗаписьюЧека(ДокументОбъект, Отказ)
// Мы сознательно обходим стандартный тяжелый запрос по табличным частям архивных ЧекККМ.
// Контроль уникальности марок будет выполняться на стороне УТМ ЕГАИС при отправке чека.
Возврат;
КонецПроцедуры
Важно: При использовании этого метода обязательно убедитесь, что ваш УТМ работает стабильно и база ЕГАИС оперативно отклоняет дубликаты марок при попытке повторной продажи.
Более правильным с точки зрения бизнес-логики решением будет доработка поискового запроса в процедуре проверки. Вместо полного отключения контроля мы можем ограничить период поиска документов ЧекККМ. Например, искать повторные продажи марки только в чеках за последние 3-5 дней или в рамках текущей кассовой смены.
Давайте разберем, как изменить запрос через расширение конфигурации с использованием аннотации &Вместо. Нам нужно перехватить исходный текст запроса и добавить туда параметр ограничения даты:
&Вместо("ПроверитьАкцизныеМаркиПередЗаписьюЧека")
Процедура Расш_ПроверитьАкцизныеМаркиПередЗаписьюЧека(ДокументОбъект, Отказ)
// Если документ не содержит маркируемой алкогольной продукции, проверку не выполняем
Если Не ПродажиСервер.ЕстьМаркируемаяПродукцияВДокументе(ДокументОбъект) Тогда
Возврат;
КонецЕсли;
// Задаем разумную глубину проверки истории продаж, например, 5 дней
ГлубинаПроверки = ТекущаяДата() - (5 * 86400);
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ
| ЧекМарки.АкцизнаяМарка КАК АкцизнаяМарка
|ИЗ
| Документ.ЧекККМ.АкцизныеМарки КАК ЧекМарки
|ГДЕ
| ЧекМарки.Ссылка.Дата >= &ГлубинаПроверки
| И ЧекМарки.АкцизнаяМарка В(&СписокМарокДокумента)
| И ЧекМарки.Ссылка <> &ТекущийДокумент";
// Наполняем запрос параметрами и анализируем результат...
// При нахождении дублей устанавливаем параметр Отказ = Истина;
КонецПроцедуры
Этот компромиссный вариант полностью убирает задержку при пробитии, так как СУБД больше не сканирует миллионы старых записей, ограничиваясь только оперативным периодом текущей недели.
Если вы хотите решить проблему радикально и без изменения программного кода конфигурации, то лучшим путем будет обслуживание самой информационной базы данных. Торможение происходит из-за огромного объема накопленных документов ЧекККМ.
Выполним очистку базы по следующему алгоритму:
РегистрСведений.АкцизныеМаркиЕГАИС. Это гарантирует, что система «запомнит» старые продажи даже после удаления самих документов.После удаления миллионов неиспользуемых строк из табличных частей документов ЧекККМ файловая СУБД снова начнет выполнять поисковые запросы за доли секунды, и задержка при печати чеков пропадет.
Помимо оптимизации программного кода, проанализируем настройки торгового оборудования и архитектуру базы данных:
Применив один из предложенных нами методов, вы гарантированно решите проблему с долгой печатью чеков и обеспечите быструю и комфортную работу кассиров на рабочем месте.