fed: Parallel BOM calculation in RollUp 7

[Logger]

Ну если не распараллеливание, то какие другие способы ускорения разноски больших журналов и накладных вы видите ?

Выше вы предполагали что это не нужно или нужно редко. Т.е. ничего не предложили. А если нужно и достаточно часто, то что можно предложить ?

Как вариант, можно вместо одной накладной на 1000 строк обработать 25 по 40 строк и объединить в один документ при печати. (Хотя это просто другой способ распараллеливания)

Другие варианты пока в голову не приходят.

[fed]

Цитата:

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

Ну если не распараллеливание, то какие другие способы ускорения разноски больших журналов и накладных вы видите ?

Выше вы предполагали что это не нужно или нужно редко. Т.е. ничего не предложили. А если нужно и достаточно часто, то что можно предложить ?

Для закупок, я бы пошел таким путем:
1. При разноске накладной по закупке, вместо обновления складских проводок и разноски на складские счета, делается проводка ГК на некий субсчет 15ого счета
2. После разноски накладной, порождается пакетное задание на параллельное обновление складских проводок с разноской в ГК. Код разноски правиться так, чтобы в качестве коррсчета прихода использовался субсчет 15ого счета.
3. Если пакетное задание некорректно завершилось, посылается alert кому надо
4. Надо бы еще подумать на тему усиленной проверки строк накладных в момент 1ого пункта, чтобы снизить вероятность когда накладную мы разнесли, а потом выяснилось что на склад не может оприходовать, потому что, скажем, финансовая аналитика не указана. (которая только на 10ке нужна, а на 15ом - нет).

Для заказов можно аналогичную схему использовать,но только если комплектация используется и к моменту разноски накладных и отборочных, товар уже собран и точно физически присутствует в системе. Просто в случае списания, некоторое отставание в состянии inventSum само по себе критично, а уж если сначала накладную распечатали и отдали, а потом выяснили что такого товара нету - так вообще кранты...

[Logger]

Цитата:

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

Для закупок, я бы пошел таким путем:

Спасибо.
Для заказов мы как раз юзаем комплектацию. Так что хорошо ложится на нашу схему.

[fed]

Цитата:

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

Спасибо.
Для заказов мы как раз юзаем комплектацию. Так что хорошо ложится на нашу схему.

А вы не пробовали профилироваться и смотреть на что время тратиться в основном ? Просто такие тормоза были характерны для времен до изобретения InventSumDelta/InventSumDeltaDim. Может у вас там какие-то доработки не удачные или добавили условие в select, а индекс забыли ?
Даже как-то интересно стало

[Ivanhoe]

Цитата:

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

Ну если не распараллеливание, то какие другие способы ускорения разноски больших журналов и накладных вы видите ?

Большие заказы характерны, например, в ритейле, когда нужно сделать разноску реализации магазина за день. В плане оптимизации разноски можно многое поправить, в т.ч. в коде отключить все неиспользуемые функции. В т.ч. можно рассмотреть вариант SQL-й разноски - есть прецеденты Но все это - тюнинг под конкретный проект, в глобальное решение такое не включат и всегда будет запас под точечную оптимизацию.