Проблема медленной работы интерфейса подбора товаров в Рабочем месте кассира (РМК) — одна из самых досадных ситуаций для ритейла. Когда при нажатии кнопки подбора система «задумывается» на 1–2 минуты, это парализует работу торговой точки и создает очереди. Особенно часто такая проблема встречается в конфигурации 1С:Управление торговлей 11.4 (а также в КА 2 и ERP), работающей в клиент-серверном варианте через тонкий клиент.
В этой статье мы подробно разберем, почему возникает эта проблема, как она связана с механизмом динамических списков и какие шаги нужно предпринять для ее окончательного решения.
Разберем ситуацию: на большинстве рабочих мест подбор работает быстро, но на одной или нескольких точках начинаются регулярные зависания. Очистка кэша помогает лишь временно. Проанализируем, что происходит «под капотом» 1С в этот момент. Основным механизмом отображения товаров является ДинамическийСписок. Когда пользователь активирует фильтр «Только в наличии на складе», система динамически изменяет SQL-запрос к базе данных.
Выясним основные причины деградации производительности:
LEFT JOIN справочника Номенклатура с виртуальной таблицей остатков регистра ТоварыНаСкладах. Если в базе накоплено много «мусорных» записей (нулевые остатки в разрезе характеристик или серий), SQL-сервер тратит огромное время на расчет итогов./ClearCache лишь временно удаляет локальные индексные файлы. Как только пользователь вновь открывает форму и система пытается построить дерево категорий с учетом остатков, проблема возвращается.Как показывает практика и опыт коллег, в релизах ветки 11.4 существует особенность обработки фильтров. Если стандартная галка «Только в наличии» вызывает зависание, мы можем обойти этот алгоритм через внутренние настройки списка. Рассмотрим по шагам, как это сделать в интерфейсе РМК:
Важный нюанс: Попробуйте снять стандартную галку «Только в наличии на складе» и вместо нее настроить фильтр через расширенный поиск. У многих пользователей именно этот «костыль» позволяет открывать форму за 1 секунду вместо 2 минут, так как 1С по-другому выстраивает приоритеты выполнения условий в SQL-запросе.
Проанализируем ситуацию с правами доступа. Даже если у пользователя «полные права», иногда в системе остаются активными профили с RLS. Рассмотрим, как проверить влияние ограничений на скорость работы. Попробуйте временно назначить проблемному пользователю роль с полным доступом без ограничений. Если скорость подбора мгновенно выросла — проблема в механизме RLS.
Для оптимизации работы RLS в 1С:УТ 11.4 рекомендуется запустить регламентное задание «Заполнение данных для ограничения доступа». Также стоит проверить, не включена ли опция «Ограничивать доступ на уровне записей» в настройках программы, если в ней нет реальной необходимости.
Для диагностики можно использовать следующий программный метод в отладчике, чтобы увидеть, какой именно запрос «тормозит»:
// Включаем замер производительности и смотрим на время выполнения
// метода формы ПриСозданииНаСервере или ПриОткрытии.
// Если проблема в ДинамическомСписке, время будет уходить на получение данных.
ТекстЗапросаСписка = ЭтаФорма.Список.ТекстЗапроса;
Разберем ситуацию, описанную в сообщениях форума. В старых релизах (например, начала 2018 года) алгоритм подбора содержал архитектурные недоработки в части связи с характеристиками товаров. Обновление конфигурации до актуальных релизов ветки 11.4 (или переход на 11.5) часто решает проблему «магическим» образом, так как разработчики 1С оптимизировали запросы в модуле Обработка.ПодборТоваровВДокументыПродажи.
Посмотрим на пример из практики: на релизах ниже 11.4.3.137 наблюдались стабильные затыки. После обновления до актуальной версии и выполнения реструктуризации таблиц проблема исчезла. Это связано с тем, что в новых версиях отбор в списке происходит раньше обработки визуальной галки остатков, что снижает нагрузку на сервер.
Если программные методы не помогают, проанализируем состояние базы данных на уровне сервера. Полнотекстовый поиск (ППС) напрямую влияет на работу формы подбора. Если индекс ППС поврежден или не актуален, инициализация формы может длиться вечно.
Выполним следующие действия:
На стороне SQL-сервера крайне важно выполнить обновление статистик. Рассмотрим, почему это важно: SQL-оптимизатор может строить неверный план запроса для конкретного склада, считая, что данных на нем мало, хотя в реальности таблицы регистра остатков огромны. Выполните команду:
-- Пример команды для MS SQL Server
UPDATE STATISTICS [Имя_Вашей_Базы].[dbo].[_InfoRgXXXX] -- Таблица итогов
WITH FULLSCAN;
Хотя автор темы указал, что чистка кэша сбрасывает настройки РМК, мы можем подойти к вопросу более точечно. Вместо радикального /ClearCache, попробуем удалить только файлы, отвечающие за настройки форм, сохранив при этом общие настройки пользователя. Эти файлы обычно находятся в папке %AppData%\1C\1cv8\.
Однако помните, что постоянная необходимость чистить кэш — это лишь симптом. Настоящая причина обычно кроется либо в «битых» итогах регистров, либо в неоптимальном запросе динамического списка, который мы разобрали выше.
Подведем итог: Для решения проблемы «тормозов» подбора в УТ 11.4 первым делом попробуйте изменить способ фильтрации в настройках динамического списка и обновить конфигурацию. Если это не помогает — копайте в сторону RLS и полнотекстового поиска. Совместное применение этих методов гарантированно ускорит работу кассиров.