32000 записей в файловой. Записи аж с 2018 года.
Виснет на подтягивании порога расчета цен, ИзменитьЦенуВТаблицеПоПорогамСрабатывания, там какой-то дикий запрос.
Пробую исключить вызов ИзменитьЦенуВТаблицеПоПорогамСрабатывания, т.к. порогов нет, там всего две цены расчетных от закупочной - дилерская и розничная.

Как-то работало, а потом накопилось и сдохло. Сила УНФ.

Можно конечно свой расчет цен намутить, это даже быстрее будет клиенту починить, чем "типовой"  от УНФ ковырять.
Как записи в этот регистр добавляются то? Там номенклатура, характеристика в видах цен.

Беги оттудова ...

Правильно. Надо больше своих костылей и велосипедов

(2) Недавно говорили о невероятной красоте типового кода. Но это наверное не про УНФ, она ж не Селезневская?

(3) кто говорил? я не говорил
и как оценивать код? по твоему плачу?

(3) УНФ писали инопланетяне. это давно известно.
Динамических цен там нет. в принципе.
То что там таковым объявляется - это статические цены, которые насчитываются заранее. Поэтому когда na lzk динамическйо цены определил формулу расчета (условно) - вся номенклатура ставится в очередь расчета цен. Когда это посчитается - одному богу известно. В облаке регулярно случаются затыки и народ жалуется что динамические цены обновляются очень медленно.
.
хорош такой подход или нет - я хз.. я не оценивал.
но вполне себе. если работает норм.
.
а нерасчитанные цены - тоже есть. народ справшивает - и как? - как-как - чистит, и инициировать пересечт заново...
при этом если ты глазками не смотришь - хрен ты увидишь посчиталось оно или нет.
.
могу ошибаться...

(5) так оно при расчете блокирует регистр цен, в итоге поступления не проводятся, видишь ли.
В итоге я сделал расчет порциями, может за ночь и проведется.
Но за эти 2.5 часа реально быстрее было бы обработку обновления цен свою написать по срезу последних. Кто так пишет, пора уже этих рептилоидов распять

Имхо, не отрабатывает рег задание, поэтому очередь и растет

(7) я посмотрел код, там на вход  запроса в ИзменитьЦенуВТаблицеПоПорогамСрабатывания подается таблица значений, причем по ней в регистре сведений делается обор по кортежам (т.е. по измерениям). Все шатко-валко работает до определенного порога. Когда таблица достигла 33.000 записей, эта конструкция умирает.
А записей будет всегда больше, т.к. в очередь попадают зачем-то все записи за периоды. Даже за 2018 цены есть

Как вариант решения проблемы, кстати, можно было бы убрать из регистра цены к расчету, кроме последних, т.е.
если есть запись в очереди для расчета:

Дилерская цена, носки оленьи, 1 марта 2019
Дилерская цена, носки оленьи, 1 апреля 2019

То первую запись удалять нафиг.

Ну и еще в плане оптимизации - удалять записи 2х летней давности. Думаю, предложу клиенту такой вариант.

За ночь обработка пересчитала, но очередь не очистилась, заново заполнилась.
В общем, предложил клиенту не мучаться и напишу ему обработку по заполнению цен, будет ее по расписанию запускать.
Вместо тупой обработки от 1с.