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

[trud]

Столкнулся со странностями при разноске накладной по закупке где больше 1000 строк(функциональность локализации)
Система во время процесса создает около миллиона записей в SUBLEDGERJOURNALACCOUNTENTRYDISTRIBUTION,
(место в коде не знаю, проверял путем запуска следующего скрипта во время разноски, отличие было более чем в миллион

select count(*) from SUBLEDGERJOURNALACCOUNTENTRYDISTRIBUTION
select count(*) from SUBLEDGERJOURNALACCOUNTENTRYDISTRIBUTION(nolock)

потом при запуске блока корреспонденции эти записи удаляются

и далее разноска идет уже в нормальном режиме.
Проблема что притормаживает
Вопрос - откуда вообще возникло такое странное архитектурное решение(создать миллион записей, а потом его удалить) и можно ли как-то с этим бороться
Версия AX2012R3 CU12

[ice]

расчет налогов?

[Logger]

Миллион это 1000^2
Возможно там вместо перебора в памяти скинули в табличку все возможные комбинации...

[trud]

Цитата:

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

Миллион это 1000^2
Возможно там вместо перебора в памяти скинули в табличку все возможные комбинации...

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

[belugin]

Это моё.

SubledgerJouralizerBondExtension написан так, чтобы быть расширением для SubledgerJournalizer.

SubledgerJouralizer в данной фазе обрабатывает distributions и генерирует по ним subledger согласно AccountingRules. Для этого он сначала вставляет во временные таблички

SubledgerJouralizerBondExtension не может дополнить уже готовый сабледжер. Так что ему приходится действовать двумя путями: либо говорить SubledgerJouralizer не делать этого (см использование SysEventOverride ) либо вытирать то, что сделал SubledgerJournalizer и вместо него писать свое.

Второе было первым по порядку интерфейсом согласованным между командами занимающимися общими финансами и российскими, поэтому, вероятно, оно тут осталось.

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

Если я все помню точно И ничего существенного тут не изменилось, то все будет работать так же без этого кода.

НО учтите, что к этой точке привязано еще расширение _CN - так что вам, возможно, надо будет проанализировать и его.

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

[Logger]

Максим, так миллион записей для 1000 строк это баг или by design ?

[belugin]

Мне непонятно, откуда взялся этот миллион. В таблице хранится связь проводок сабледжера и распределений.

[Logger]

А если хранится 1000 проводок сабледжера. И 1000 записей распределений. И не повезло получить связь каждого с каждым. Вот и получается по порядку величины N*N
Либо миллион сразу в распределении вылез. Если каждый с каждым то это N*N. На маленьких N незаметно. Но уже после 100 начинается веселье.

[belugin]

Я себе плохо представляю как сильно быть каждый с каждым при таких количествах. Вы берете миру исходного документа, распределяете ее по каким-то аналитикам, сгенерированные сабледжерные проводки должны связаться с соответствующим распределением. Если не распределяете то, насколько я помню, автоматически генерируется одно распределение на строку исходного документа (про подстроки - накладные расходы и налоги - не помню уже).

[trud]

Цитата:

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

либо вытирать то, что сделал SubledgerJournalizer и вместо него писать свое.

Тут еще проблема что не учли как работает SQL Server и Optimistic concurrency control, т.е. если при паралельных update все это нормально разрешается, то при delete сессии просто блокируются

Цитата:

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

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

так а это признают ошибкой? поддержка насколько я знаю не решает проблемы производительности, это платная услуга
Я думаю это даже не стандартной демо базе повторится, берете большую закупку и разносите ее в компании RU и не RU, отличия будут огромные

Причем ксати это не единственный момент, более простой случай при разноске отборочной накладной - т.е. в какой то момент запускается метод подсчета накладных расходов по строке (при том что накладных расходов в моем примере вообще не было).
Перед этим он решает посчитать итоги по закупке(а чтобы это сделать надо опять же пройтись во всем строкам закупки), Получается для 1000 строк надо сделать миллион проходов
В 2012 лечится довольно просто - надо в класс подчета итогов purchTotalMarkup передать стандартный параметр - кешировать результат.
В D365 думаю будет веселее, код там остался

[belugin]

Цитата:

так а это признают ошибкой?

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

[trud]

Попробую. Так а какие были ожидания когда вы разрабатывали этот класс - SubledgerJouralizerBondExtension?
для примера закупка 500 с включенной галкой Корреспондеция в параметрах разносится 8 минут, с выключенной около 3. т.е. корреспонденция дает практически 3 кратное увеличение времени разноски накладной. С 2012 я не работал, но в прошлых версиях это вроде были просто парные поля в проводках которые надо заполнять
Т.е. действительно ли сложность алгоритма корреспонденции такова, что его реализация превышает все остальные действия при разноске инвойса? если ли какие документы описывающие на словах что там происходит(для древних версий вроде бы был подобный документ)

[Logger]

Грустно.

Еще же в ax3-2009 подобные проблемы были.
Оптимизация класса Tax

В 2012-й движок полностью поменялся, а те же грабли остались

По идее, можно ведь было создать простейший тест "Накладная по заказу / закупке из 1000 строк должна разноситься не более чем за X секунд / минут / часов / суток". И если он не выполняется то считать что ошибка. Время обработки это такой же критичной параметр как и корректность работы функционала.

[belugin]

Цитата:

Так а какие были ожидания когда вы разрабатывали этот класс

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

Цитата:

Т.е. действительно ли сложность алгоритма корреспонденции такова, что его реализация превышает все остальные действия при разноске инвойса?

Я без исследования не могу сказать. Интересно, что с тех пор ко мне никто не подходил по вопросу быстродействия данного кода, правда, это уже вне моей зоны ответственности.

Там разные сложности. В LedgerVoucher данные поступают уже суммированные и их надо разбить обратно на пары проводок (с учетом ошибок округления и прочего). Например, при разноске накладной, отдельно вычисляется изменение задолженности клиента и отдельно корресподнирующие проводки, а потом для них вызывается bondVref2Log или типа того.

В Subledger есть уже готовые пары, которые потом суммируются, но в международном суммировании они суммируются все отдельно по счетам/аналитикам а при включенной корреспонденции они должны суммироваться с сохранением парности.

Зато надо записать все связи, чтобы от конечной проводки можно было отследить какая ее часть вызвана каким распределением.

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

someClassField = someValue;

if (conditionThatDoesNotMetHere)
{
  the only usage of someClassField ;
}

И тормозило на строчке someClassField = someValue;; если ее закомментировать, то работает быстро.

причина в том, что параметр это, кажется, был LedgerVoucher и все месте приводило к образованию циклической ссылки на которую было навешано по объекту на проводку да еще и какие-то объекты корреспонденции.

Детерминисткий сбор мусора X++ начинал считать количество циклов (чтобы выяснить когда они закончатся и можно освободить объект прям сразу) и на это уходило большое количество времени.

[mazzy]

Цитата:

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

цель, чтоб не хуже чем раньше.

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

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

потребители используют совсем другой критерий - чтоб не хуже чем у конкурентов в данной ценовой категории.

Цитата:

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

которые сами могут быть недооптимизированы.

...причем внутри команды мс все все понимают.

Цитата:

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

В LedgerVoucher данные поступают уже суммированные и их надо разбить обратно...

Нет, конечно.

Издревле в аксапте, как и в конкорде у леджера есть параметр Detail Level.
вручную его можно изменить только в журналах.
во всех остальных документах этот параметр в коде устанавливается в Суммировать.
но в коде же его можно поменять на Детально. и, вуаля, аксапта не будет выполнять суммирование.

Параметр появился очень давно, еще когда была специальная платная лицензия на количество записей в базе. Ну и еще не было SQL.

Долгое время я считал, что об этом параметре не знают только "пресловутые" локализаторы. Но сабледжер показал, что о нем не знают и буржуины.

[fed]

Дискуссия о новом типе add-on перенесена в профильный раздел.

[belugin]

Цитата:

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

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

Я говорил про аптейк существующего функционала на новую версию. Есть отдельные активности по оптимизации того, что есть, обычно это происходит по результатам обратной связи от рынка (зарегистрированные баги или телеметрия, там где она есть).

Цитата:

Нет, конечно.

Если я правильно помню.

в SalesInvoiceJournalPostBase.endLedgerVoucher есть bondVref2Log
потому, что единственная проводка по custVoucher разносится в postCustVend через custVendVoucher, куда попадает сумма из инвойса со всеми накладными расходами налогами и прочим. Чтобы скорреспонировать эту сумму с проводками по строкам и нужен vref2log.

protected CustVoucher initCustVoucher(LedgerTransTxt _ledgerTransTxt)
    {
        return CustVoucher::newCustVoucherSales(_ledgerTransTxt, custInvoiceJour, salesParmTable, salesTable);
    }

В сабледжерах наоборот, AccountingRules для каждой строки генерируют пары проводок, которые потом суммируются

Цитата:

Издревле в аксапте, как и в конкорде у леджера есть параметр Detail Level.
вручную его можно изменить только в журналах.
локализаторы.

...

Но сабледжер показал, что о нем не знают и буржуины.

В сабледжер тоже есть этот параметр - насколько я помню AccountingRule.parmSummarize позволяет его задать из кода.

Но разговор вообще не об этом а о см. выше.

[trud]

Цитата:

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

В Subledger есть уже готовые пары, которые потом суммируются, но в международном суммировании они суммируются все отдельно по счетам/аналитикам а при включенной корреспонденции они должны суммироваться с сохранением парности.

Посмотрел немного код, вообще все очень странно выглядит.

Т.е. идет insert_recordset который вставляет записи(их кол-во равно сумме строк в закупке в квадрате, т.е. для 30 строк будет 900, для 1000 - миллион), далее сразу же после этого insert_recordset идет delete_from который я привел в первом посте. Между ними нет ни одной строчки кода, сразу после insert вызывается event handler на этот insert в котором все удаляется.
Почему перед исходным insert просто не добавили проверку - если включена корреспонденция, не делать его? Тем более код в рамках локализации все равно менялся (какая то проверка на #isoRu). Т.е. это кто-то что-то пропустил, или было осознанное действие?

[belugin]

Первый мой ответ содержит описание чего и почему

[Ivanhoe]

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