Разноска накладной по большой закупке

[trud]

А приход это что? т.е. для закупки есть подтверждение, разноска отборочной накладной, разноска инвойса. Если убрать все косяки локализации то подтверждение и отборочная накладная в 5 минут уложатся(на каждую операцию). инвойс уложится если отключить(или как-то переписать) корреспонденцию. В целом не так уж и плохо.

[Ivanhoe]

Цитата:

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

А приход это что? т.е. для закупки есть подтверждение, разноска отборочной накладной, разноска инвойса. Если убрать все косяки локализации то подтверждение и отборочная накладная в 5 минут уложатся(на каждую операцию). инвойс уложится если отключить(или как-то переписать) корреспонденцию. В целом не так уж и плохо.

Для сравнения логично использовать сравнимое - обработка накладной со складом, проводками ГК и поставщиком. Я так спрашивал. Не претендую на супер исследование, но интуитивно больше 10 минут - это зло. И мне обидно, что в любим продукте именно такое зло и поселилось

[trud]

Цитата:

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

Вы можете попробовать закомментить код в SubledgerJournalizer.recordSubledgerJournalAcctEntriesDist кроме вызова события.

В общем реализация этого совета привела к сокращению времени разноски закупки в 1500 строк с 1часа10минут до 20 минут, что в целом просто замечательно. спасибо

Цитата:

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

Спросил про системы двух основных конкурентов. Для среднего предприятия в 100-200 пользователей с нормальным складом в системе и нормальным железом, приход на 1000 строк не должен обрабатываться больше 5 минут, иначе это уже повод для разбирательств.

Проверил для 1000 строк по закупкам(по 3 основным этапам - Подтверждение, Packing slip, Invoice)
Результаты следующие:
Из коробки с включенной корреспонденцией за разумное время работает только Подтверждение Packing slip срубается на подсчете итогов для каждой строки без кеширования, Invoice на запросе описанном выше

После "обработки напильником" результаты следующие:
PO Confirm ~ 2 минуты
PO Packing slip ~ 5 минут
PO Invoice ~ 10 минут
При отключении корреспонденции(галка в параметрах гк)
PO Packing slip ~ 4 минуты
PO Invoice ~ 5 минут

Какие в целом выводы - международная версия АХ в целом в тренде и укладывается в 5 минут конкурентов
Особого контроля(и по видимому бюджета на оптимизацию) со стороны MS за командой локализации нет, что конечно печально

[Logger]

Интересно, что движок переписан, а баг повторился.
Т.е. это типичный баг.

Неплохо бы было добавить в тесты проверку на скорость разноски или хотя бы на нелинейные зависимости времени разноски от числа строк. Это несложно.

[fed]

А во времена v2.1 и самого первого релиза 2.50 время корреспондирования складского журнала росло пропорционально четвертой степени от числа строк.

[Logger]

Цитата:

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

А во времена v2.1 и самого первого релиза 2.50 время корреспондирования складского журнала росло пропорционально четвертой степени от числа строк.

Воот !
Застарелая проблема.
Значит надо контролировать.

[trud]

Цитата:

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

Неплохо бы было добавить в тесты проверку на скорость разноски или хотя бы на нелинейные зависимости времени разноски от числа строк. Это несложно.

Кстати даже тестов то и не нужно, достаточно просто выполнить просмотр кода. Вот еще четкий пример(из 10.0, но есть в 2012)

метод PurchFormletterParmDataInvoice canCreateParmLine как следует из названия вызывается для каждой строки. при этом в нем идет цикл по всем строкам(4 раза !!!). т.е. для 1000 строк получаем 4 миллиона вычислений кол-ва. Правда произойдет это если будет нечего разносить, т.е. все уже в предварительной накладной
Вызывается только в RU компаний