Многие технические специалисты и пользователи 1С:Управление торговлей 11 (начиная с версии 11.4 и выше) сталкиваются с крайне неприятной проблемой: форма подбора товаров при открытии в документе «Заказ клиента» начинает «висеть» несколько минут или вовсе приводит к аварийному завершению сеанса. Проанализируем ситуацию: это происходит не во всех случаях, а при строгом соблюдении условий — если дата документа меньше текущей (вчерашняя или ранее) и в документе выбрано индивидуальное соглашение с уточнением цен по ценовым группам.
В этой статье мы подробно разберем, почему типовой механизм ведет себя подобным образом, и какие шаги необходимо предпринять, чтобы восстановить работоспособность системы. Рассмотрим ситуацию со стороны разработчика и системного администратора.
Для начала разберем механику работы формы подбора. Обработка ПодборТоваровВДокументеПродажи использует динамический список для отображения номенклатуры. Когда мы открываем эту форму, система должна не просто показать список товаров, но и рассчитать для каждого из них актуальную цену, остатки и доступность, исходя из условий, заданных в документе.
Основная сложность заключается в использовании индивидуального соглашения. В отличие от типового соглашения, индивидуальное часто содержит уточнения цен по конкретным ценовым группам. Это заставляет систему выполнять сложные соединения таблиц (LEFT JOIN) в запросе динамического списка. Проанализируем, что происходит при изменении даты:
СрезПоследних на конкретный момент времени в прошлом. Это заставляет СУБД просматривать значительно больший объем индексов в регистре сведений ЦеныНоменклатуры.Рассмотрим самое быстрое, хоть и не самое элегантное решение, которое часто предлагают специалисты франчайзи. Если подбор критически завис, а работать нужно «здесь и сейчас», можно применить следующую последовательность действий:
Заказ клиента на текущую (сегодняшнюю).Этот метод помогает избежать простоев, но не решает техническую проблему в корне.
Иногда причина кроется в «замусоривании» настроек пользователя. В 1С настройки динамических списков, колонок и отборов сохраняются в системных таблицах. Если форма подбора когда-то была настроена специфическим образом (например, добавлены сложные отборы по свойствам), это накладывается на проблему с ценами.
Разберем, как сбросить настройки:
Обработка.ПодборТоваровВДокументеПродажи.Форма.Форма и удалим её.Проанализируем влияние прав доступа. Если у пользователя включен механизм RLS (Record Level Security) — например, ограничение по складам, партнерам или номенклатуре — каждый запрос динамического списка «оборачивается» в дополнительные вложенные запросы для проверки прав.
В сочетании с индивидуальным соглашением и поиском цен на прошлую дату, итоговый SQL-запрос может разрастаться до нескольких тысяч строк. Попробуем запустить подбор под пользователем с полными правами. Если под полными правами зависания нет, значит, проблему нужно искать в оптимизации правил RLS или в упрощении структуры групп доступа номенклатуры.
Если вы — программист или администратор БД, нам необходимо заглянуть «под капот». Посмотрим на пример того, как можно диагностировать проблему через консоль запросов или технологический журнал (ТЖ):
DBMSSQL и длительности выполнения более 10-20 секунд.Чаще всего мы увидим Index Scan там, где должен быть Index Seek. Помочь может обновление статистик базы данных. Выполним команду в консоли SQL:
UPDATE STATISTICS [_InfoRg12345] -- имя таблицы регистра цен номенклатуры
WITH FULLSCAN;
Это заставит планировщик SQL-сервера перестроить путь к данным, что часто ускоряет поиск «среза последних» на старые даты. Также стоит проверить размер таблиц базы данных, чтобы исключить аномальный рост регистров. Для оценки количества записей и размеров регистров можно использовать обследование размеров объектов 1С. Это поможет проверить аномальный рост, но не заменяет изучение плана SQL и не обновляет статистику.
Проанализируем настройки самой формы подбора. Часто пользователи включают отображение всех возможных колонок: «Остаток», «В наличии», «Доступно», «Срок поставки». Каждый такой столбец — это отдельный тяжелый расчет.
В форме подбора нажмем кнопку Настройки и попробуем:
Выясним причину на уровне кода конфигурации. Фирма «1С» знает об этой проблеме и периодически выпускает исправления (патчи) для конфигурации УТ 11.5. Проверьте в разделе Обслуживание — Обновление программы — Установленные исправления, нет ли патчей, связанных с ПодборТоваров или ДинамическийСписок.
Если вы самостоятельно дорабатываете систему, обратите внимание на модуль менеджера обработки подбора. Рассмотрим пример кода, который может помочь принудительно ограничить объем данных при поиске цен:
// Пример модификации параметров запроса в динамическом списке
ПараметрыЗапроса = Список.Параметры.УстановитьЗначениеПараметра("ДатаДокумента", ДатаДокумента);
// Если дата слишком старая, можно внедрить упрощенную логику получения цен
Если ДатаДокумента < НачалоДня(ТекущаяДата()) Тогда
// Здесь может быть ваша кастомная логика оптимизации
КонецЕсли;
Зависание формы подбора в УТ 11.5 — это комплексная проблема, возникающая на стыке архитектуры динамических списков и сложности расчета цен по индивидуальным соглашениям в прошлом времени. Чтобы решить её, мы рекомендуем:
Помните, что каждый случай индивидуален, и иногда детальный анализ плана запроса в SQL может подсказать необходимость создания дополнительного индекса в регистре цен, который решит проблему раз и навсегда.