В процессе эксплуатации конфигурации 1С:УНФ многие разработчики сталкиваются с проблемой критического замедления работы системы, связанной с регистром сведений ОчередьРасчетаЦен. Когда количество записей в этом регистре достигает десятков тысяч, регламентные задания по пересчету цен начинают «зависать», блокировать таблицы базы данных и приводить к ошибкам при проведении документов поступления. Рассмотрим подробно, почему возникает эта проблема и как ее решить.
Механизм ОчередьРасчетаЦен используется в 1С:УНФ для реализации так называемых «динамических» цен. В архитектуре данной конфигурации цены не рассчитываются «на лету» в момент оформления продажи, а вычисляются заранее и записываются в регистр ЦеныНоменклатуры. При каждом изменении формулы или базовой цены номенклатура попадает в очередь на пересчет. Для расчета наценки и установки цен напрямую от закупочных цен подойдет обработка для расчета наценки и установки цен.
Основная сложность заключается в том, что при массовых изменениях или длительной работе без очистки регистра, накопленные записи создают колоссальную нагрузку на запрос ИзменитьЦенуВТаблицеПоПорогамСрабатывания. Система пытается обработать слишком большие пакеты данных, что приводит к блокировкам и деградации производительности всей информационной базы. Фактическое число записей и размер регистра можно проверить через обследование метаданных базы. Это помогает оценить объём очереди, но не выявляет дубли и не устраняет зависание; на 8.3 работа инструмента не подтверждена.
Разберем основные причины, почему данный механизм перестает справляться с нагрузкой:
В зависимости от текущей ситуации в базе данных, можно рассмотреть три основных способа решения проблемы.
Если нет возможности переписать логику, необходимо регулярно очищать регистр от ненужных данных. Радикальный подход — удаление записей старше определенного периода или дедупликация.
Можно внедрить процедуру, которая оставляет для каждой связки «Номенклатура + Вид цены» только одну, последнюю запись в очереди. Все промежуточные записи, которые были созданы ранее, можно удалять, так как для актуального расчета цен история изменений внутри очереди не требуется.
Если вы хотите сохранить типовой функционал, попробуйте ограничить количество записей, обрабатываемых за один проход регламентного задания. Это позволит избежать длительных блокировок и даст возможность системе выполнять расчет «порциями» в фоновом режиме, не мешая пользователям проводить документы.
В большинстве случаев, когда объем данных велик, самой эффективной мерой является полный отказ от типового механизма в пользу собственной обработки заполнения цен. Создайте обработку, которая будет:
ЦеныНоменклатуры.Такой подход работает значительно быстрее, так как исключает накладные расходы на работу с очередью и сложные запросы к промежуточным регистрам. Приведем пример логики для написания своей процедуры расчета:
// Пример упрощенной логики заполнения цен
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
| ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
|ИЗ
| РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&ТекущаяДата, ) КАК ЦеныНоменклатурыСрезПоследних";
РезультатЗапроса = Запрос.Выполнить();
// Далее цикл по результатам запроса и запись рассчитанных цен
Проблема с ОчередьРасчетаЦен — это известная архитектурная особенность УНФ. Мы выяснили, что при больших объемах данных типовой механизм пересчета не справляется. Для стабилизации работы системы мы рекомендуем:
Работайте с данными осознанно, регулярно оптимизируйте регистры накопления и сведений, и тогда система 1С:УНФ будет радовать вас высокой скоростью работы!