Расчёт цены номенклатуры

[raniel]

Добрый день. Уже который день бьюсь с производительностью функции «Расчёт цены» -> «Цена номенклатуры»(AX2009). У меня есть номенклатура спецификация которой в свою очередь состоит из 5000 спецификаций. Полный расчёт её проходит за 30часов!!! Облазил весь код. В принципе особо что там и не соптимизируешь. Весь расчёт выполняется в одной транзакции(что уже не есть гуд). В ней строится дерево ну и потом бежит с самого низа веточек рассчитывается и сумма поднимается вверх. Понятно что объём большой, но это же ведь ERP… и уж если на то пошло, я так думаю, в России есть не мало производств где и посложнее номенклатуры обсчитыватся. Кстати посмотрел как этот функционал реализован в 12-шке… один в один без изменений.
Кто нить сталкивался с подобной проблемой?

[EVGL]

Цитата:

Сообщение от raniel

Добрый день. Уже который день бьюсь с производительностью функции «Расчёт цены» -> «Цена номенклатуры»(AX2009). У меня есть номенклатура спецификация которой в свою очередь состоит из 5000 спецификаций. Полный расчёт её проходит за 30часов!!! Облазил весь код. В принципе особо что там и не соптимизируешь. Весь расчёт выполняется в одной транзакции(что уже не есть гуд). В ней строится дерево ну и потом бежит с самого низа веточек рассчитывается и сумма поднимается вверх. Понятно что объём большой, но это же ведь ERP… и уж если на то пошло, я так думаю, в России есть не мало производств где и посложнее номенклатуры обсчитыватся. Кстати посмотрел как этот функционал реализован в 12-шке… один в один без изменений.
Кто нить сталкивался с подобной проблемой?

Сталкивался, в машиностроении. Остается только итеративный расчет, где начинаем с нижних узлов (InventTable.BOMLevel), а на верхних насильственно прерываем расчет на первом уровне спецификации (по типу BOMCalcGroup.StopExplosion). Для этого используется метод расчета SingleLevel.

[fed]

В поздних сервис-паках к 2009ой приделали параллельный рассчет спецификаций. То есть - если запускаешь на пакетном сервере полный рассчет всех спецификаций в одноуровневом режиме, то у тебя система рожает n-хелперов (где помнится - по 4 хелпера на каждый сервер, обслуживающий пакетную группу). Хелперы внутри каждого уровня вложенности BOM работают в параллель. После того как просчитаны цены уровня n+1, начинается расчет цен уровня n.
Из всего этого можно сделать параллельный пересчет цены для конкретной спецификации. Надо просто сделать свой клон этого класса, который в табличку заданий для рассчета (BOMCalcItemTask/BOMCalcItemInventoryDimensionTask) пишет только те номенклатуры и аналитики, которые входят в данную спецификацию. (Ну то есть - классическое развертывание спецификации).
Кроме того, надо будет дописывать какой-то механизм автоматической активации цены, чтобы цены, рассчитанные на уровне n+1 немедленно активировались, чтобы рассчет на уровне n прочитал уже их, а не предыдущие значения. (Хотя в режиме стандартной себестоимости, автоматическая активация весьма чревата). На моем проекте это было сделано до меня, но дописка там не очень сложная. У нас на контрольных примерах время рассчета сложной спеки упала с 10-12 часов до 20-30 минут... Это конечно сильно зависит от размера ваших спек и режима их обсчета (может у вас там фантомов много, например), но в целом на 2-3 раза увеличения производительности можно надеятся даже в тяжелых случаях.
P.S. Есть альтернативный подход: Вместо автоматической активации свежепосчитанной цены, можно просто подломать сам рассчет, чтобы при включении определенной галочки, он бы сначала искал цену в pending prices (InventItemPriceSim) и только если там ничего нету - искал бы в обычных местах.

[raniel]

Цитата:

Сообщение от fed

В поздних сервис-паках к 2009ой приделали параллельный рассчет спецификаций. То есть - если запускаешь на пакетном сервере полный рассчет всех спецификаций в одноуровневом режиме, то у тебя система рожает n-хелперов (где помнится - по 4 хелпера на каждый сервер, обслуживающий пакетную группу). Хелперы внутри каждого уровня вложенности BOM работают в параллель. После того как просчитаны цены уровня n+1, начинается расчет цен уровня n.
Из всего этого можно сделать параллельный пересчет цены для конкретной спецификации. Надо просто сделать свой клон этого класса, который в табличку заданий для рассчета (BOMCalcItemTask/BOMCalcItemInventoryDimensionTask) пишет только те номенклатуры и аналитики, которые входят в данную спецификацию. (Ну то есть - классическое развертывание спецификации).
Кроме того, надо будет дописывать какой-то механизм автоматической активации цены, чтобы цены, рассчитанные на уровне n+1 немедленно активировались, чтобы рассчет на уровне n прочитал уже их, а не предыдущие значения. (Хотя в режиме стандартной себестоимости, автоматическая активация весьма чревата). На моем проекте это было сделано до меня, но дописка там не очень сложная. У нас на контрольных примерах время рассчета сложной спеки упала с 10-12 часов до 20-30 минут... Это конечно сильно зависит от размера ваших спек и режима их обсчета (может у вас там фантомов много, например), но в целом на 2-3 раза увеличения производительности можно надеятся даже в тяжелых случаях.
P.S. Есть альтернативный подход: Вместо автоматической активации свежепосчитанной цены, можно просто подломать сам рассчет, чтобы при включении определенной галочки, он бы сначала искал цену в pending prices (InventItemPriceSim) и только если там ничего нету - искал бы в обычных местах.

Добрый день. Я тут приболел потому не мог подробно расмотреть Ваш ответ. Сейчас вот начинаю разбираться и у меня стали возникать вопросы.
Первое, насчёт хелперов (помощников). Как я могу их увидеть? К примеру в Сводном планирование на форме запуска расчёта есть закладка "Помощники по планированию", задав их там я очень здорово могу ускорить расчёт. Тут же этого нет.

[raniel]

Цитата:

Сообщение от fed

В поздних сервис-паках к 2009ой приделали параллельный рассчет спецификаций. То есть - если запускаешь на пакетном сервере полный рассчет всех спецификаций в одноуровневом режиме, то у тебя система рожает n-хелперов (где помнится - по 4 хелпера на каждый сервер, обслуживающий пакетную группу). Хелперы внутри каждого уровня вложенности BOM работают в параллель. После того как просчитаны цены уровня n+1, начинается расчет цен уровня n.
Из всего этого можно сделать параллельный пересчет цены для конкретной спецификации. Надо просто сделать свой клон этого класса, который в табличку заданий для рассчета (BOMCalcItemTask/BOMCalcItemInventoryDimensionTask) пишет только те номенклатуры и аналитики, которые входят в данную спецификацию. (Ну то есть - классическое развертывание спецификации).
Кроме того, надо будет дописывать какой-то механизм автоматической активации цены, чтобы цены, рассчитанные на уровне n+1 немедленно активировались, чтобы рассчет на уровне n прочитал уже их, а не предыдущие значения. (Хотя в режиме стандартной себестоимости, автоматическая активация весьма чревата). На моем проекте это было сделано до меня, но дописка там не очень сложная. У нас на контрольных примерах время рассчета сложной спеки упала с 10-12 часов до 20-30 минут... Это конечно сильно зависит от размера ваших спек и режима их обсчета (может у вас там фантомов много, например), но в целом на 2-3 раза увеличения производительности можно надеятся даже в тяжелых случаях.
P.S. Есть альтернативный подход: Вместо автоматической активации свежепосчитанной цены, можно просто подломать сам рассчет, чтобы при включении определенной галочки, он бы сначала искал цену в pending prices (InventItemPriceSim) и только если там ничего нету - искал бы в обычных местах.

Помотрел это механизм внимательнее. Когда мы из формы "Настройка версии калькуляции издержек" запускаем расчёт по новой строке, то в процессе расчёта формируются списки узлов (BOMCalcItemTask/BOMCalcItemInventoryDimensionTask) для расчёта цен спецификации в классе BOMCalcJob_All. И как я понял, каждая спецификация рассчитывается один раз. Это хорошо.
В этом же механизме можно запустить не по всем расчёт, а задать конкретную номенклатуру...это фактический тоже самое, что вы предлагаете сделать. Проверив как работает это механизм, особого прироста в производительности я не заметил.

[fed]

Цитата:

Сообщение от raniel

Помотрел это механизм внимательнее. Когда мы из формы "Настройка версии калькуляции издержек" запускаем расчёт по новой строке, то в процессе расчёта формируются списки узлов (BOMCalcItemTask/BOMCalcItemInventoryDimensionTask) для расчёта цен спецификации в классе BOMCalcJob_All. И как я понял, каждая спецификация рассчитывается один раз. Это хорошо.
В этом же механизме можно запустить не по всем расчёт, а задать конкретную номенклатуру...это фактический тоже самое, что вы предлагаете сделать. Проверив как работает это механизм, особого прироста в производительности я не заметил.

Насколько я помню, если указываешь конкретную номенклатуру, то и пересчет идет данной конкретной номенклатуры, а не всех ее подкомпонентов. А поскольку одна номенклатура рассчитывается в одном батче, то никакого выигрыша из за параллелизма - нету

[raniel]

Сделал всё как Вы описали. Разницы совершенно ни какой нет. Один плюс у данного метода что за это время он рассчитывает цены всех входящих в нашу номенклатуру спецификаций.

[fed]

Цитата:

Сообщение от raniel

Сделал всё как Вы описали. Разницы совершенно ни какой нет. Один плюс у данного метода что за это время он рассчитывает цены всех входящих в нашу номенклатуру спецификаций.

А сколько у тебя хелперов работает на пересчете ? И какое среднее число номенклатур по уровням вложенности ? Ну то есть - если у тебя вложенность 8 и каждый BOM состоит из 2 номенклатур, то на нижнем уровне будет 256 номенклатур для пересчета, на 7 уровне - 128 и тп. При этом реальный выигрыш будет вероятно только для 2-3 последних уровней и всего процентов на 30-40 для каждого. В то же время, если у тебя, скажем, вложенность 8 и среднее число компонент - 5, то на нижнем уровне будет порядка 350000 номенклатур и выигрыш будет уже прямопропорционален числу хелперов...

[raniel]

Цитата:

Сообщение от fed

А сколько у тебя хелперов работает на пересчете ? И какое среднее число номенклатур по уровням вложенности ? Ну то есть - если у тебя вложенность 8 и каждый BOM состоит из 2 номенклатур, то на нижнем уровне будет 256 номенклатур для пересчета, на 7 уровне - 128 и тп. При этом реальный выигрыш будет вероятно только для 2-3 последних уровней и всего процентов на 30-40 для каждого. В то же время, если у тебя, скажем, вложенность 8 и среднее число компонент - 5, то на нижнем уровне будет порядка 350000 номенклатур и выигрыш будет уже прямопропорционален числу хелперов...

Хм... где я их могу увидеть?

[fed]

Цитата:

Сообщение от raniel

Хм... где я их могу увидеть?

Для подсчета колчества хелперов, достаточно посмотреть сколько дополнительных заданий появилось в пакетной задаче после запуска.
Для того чтобы оценить объем пересчитываемой номенклатуры - достаточно посмотреть BomCALCItemTask сгруппированный по уровням (поле Level или BOMLevel) где-нибудь после того как начали работать задания, пересчитывающие нижний уровень вложености

[raniel]

Цитата:

Сообщение от fed

А сколько у тебя хелперов работает на пересчете ? И какое среднее число номенклатур по уровням вложенности ? Ну то есть - если у тебя вложенность 8 и каждый BOM состоит из 2 номенклатур, то на нижнем уровне будет 256 номенклатур для пересчета, на 7 уровне - 128 и тп. При этом реальный выигрыш будет вероятно только для 2-3 последних уровней и всего процентов на 30-40 для каждого. В то же время, если у тебя, скажем, вложенность 8 и среднее число компонент - 5, то на нижнем уровне будет порядка 350000 номенклатур и выигрыш будет уже прямопропорционален числу хелперов...

Цитата:

Сообщение от fed

Для подсчета колчества хелперов, достаточно посмотреть сколько дополнительных заданий появилось в пакетной задаче после запуска.
Для того чтобы оценить объем пересчитываемой номенклатуры - достаточно посмотреть BomCALCItemTask сгруппированный по уровням (поле Level или BOMLevel) где-нибудь после того как начали работать задания, пересчитывающие нижний уровень вложенности

Добрый день. Вот я вернулся и вчера продолжил разбираться с этой задачей. Как я понял, чтоб увидеть на сколько процессов(подпакетов) разбивается пакет нужно открыть форму Основное->Пакетное задание там нажать кнопку Просмотр задач. У меня в настройках пакетного сервера стоит возможность разбитья на 20 потоков...По кол-ву процессоров на сервере. В принципе это всё и происходит, Но ускорения расчёта я не замечаю.
Как я реализовал тот механизм который Вы мне посоветовали.
В Классе BomCalcJob_All есть метод prepareTasksForSelectedItems. Там идёт создания списка всех спецификаций которые нужно сформировать. Там я сделал анализ, что если мы накладываем фильтр по спецификации/номенклатуре, то формируем список только того что в неё входит(Кстати Вы были правы, что если указать номенклатуру без доработки то считается только она и не разбивается на составляющее). В принципе всё работает, но скорость таже . Что я пропустил? Ещё раз повторюсь что это всё делаю я на 2009-ке