AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.11.2018, 16:26   #1  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Разноска накладной по большой закупке
Столкнулся со странностями при разноске накладной по закупке где больше 1000 строк(функциональность локализации)
Система во время процесса создает около миллиона записей в SUBLEDGERJOURNALACCOUNTENTRYDISTRIBUTION,
(место в коде не знаю, проверял путем запуска следующего скрипта во время разноски, отличие было более чем в миллион
X++:
select count(*) from SUBLEDGERJOURNALACCOUNTENTRYDISTRIBUTION
select count(*) from SUBLEDGERJOURNALACCOUNTENTRYDISTRIBUTION(nolock)
потом при запуске блока корреспонденции эти записи удаляются
Нажмите на изображение для увеличения
Название: Subledger.jpg
Просмотров: 334
Размер:	121.4 Кб
ID:	12123
и далее разноска идет уже в нормальном режиме.
Проблема что притормаживает
Вопрос - откуда вообще возникло такое странное архитектурное решение(создать миллион записей, а потом его удалить) и можно ли как-то с этим бороться
Версия AX2012R3 CU12
Старый 06.11.2018, 16:35   #2  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
расчет налогов?
Старый 06.11.2018, 16:44   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Миллион это 1000^2
Возможно там вместо перебора в памяти скинули в табличку все возможные комбинации...
Старый 06.11.2018, 16:50   #4  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Logger Посмотреть сообщение
Миллион это 1000^2
Возможно там вместо перебора в памяти скинули в табличку все возможные комбинации...
да, очень похоже на то. а потом при отладке блока корреспонденции решили не заморачиваться и просто их удалить
Нажмите на изображение для увеличения
Название: i_tak_soydet_1_20062221-1024x670.jpg
Просмотров: 488
Размер:	66.9 Кб
ID:	12124
Старый 06.11.2018, 19:38   #5  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Это моё.

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

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

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

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

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

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

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

Если вы хотите более надежно решить проблему, лучше зарегистрировать ошибку по официальным каналам.
За это сообщение автора поблагодарили: trud (5), Logger (3).
Старый 06.11.2018, 20:48   #6  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Максим, так миллион записей для 1000 строк это баг или by design ?
Старый 06.11.2018, 20:53   #7  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Мне непонятно, откуда взялся этот миллион. В таблице хранится связь проводок сабледжера и распределений.
Старый 06.11.2018, 22:24   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
А если хранится 1000 проводок сабледжера. И 1000 записей распределений. И не повезло получить связь каждого с каждым. Вот и получается по порядку величины N*N
Либо миллион сразу в распределении вылез. Если каждый с каждым то это N*N. На маленьких N незаметно. Но уже после 100 начинается веселье.
Старый 06.11.2018, 23:17   #9  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Я себе плохо представляю как сильно быть каждый с каждым при таких количествах. Вы берете миру исходного документа, распределяете ее по каким-то аналитикам, сгенерированные сабледжерные проводки должны связаться с соответствующим распределением. Если не распределяете то, насколько я помню, автоматически генерируется одно распределение на строку исходного документа (про подстроки - накладные расходы и налоги - не помню уже).
Старый 07.11.2018, 01:10   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от belugin Посмотреть сообщение
либо вытирать то, что сделал SubledgerJournalizer и вместо него писать свое.
Тут еще проблема что не учли как работает SQL Server и Optimistic concurrency control, т.е. если при паралельных update все это нормально разрешается, то при delete сессии просто блокируются
Цитата:
Сообщение от belugin Посмотреть сообщение
Если вы хотите более надежно решить проблему, лучше зарегистрировать ошибку по официальным каналам.
так а это признают ошибкой? поддержка насколько я знаю не решает проблемы производительности, это платная услуга
Я думаю это даже не стандартной демо базе повторится, берете большую закупку и разносите ее в компании RU и не RU, отличия будут огромные

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

Нажмите на изображение для увеличения
Название: PurchMarkup.jpg
Просмотров: 305
Размер:	149.2 Кб
ID:	12127
За это сообщение автора поблагодарили: Logger (10), AvrDen (1).
Старый 07.11.2018, 09:33   #11  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
так а это признают ошибкой?
Я не могу сказать это наверняка - до меня доходят ошибки по моей теперешней области ответственности связанные с быстродействием. Но обычно они формулируются не так, что "это медленнее чем международная функциональность" а так, что быстродействие неприемлемо так как при таких-то условиях время такое-то, а требуется такое-то.
Старый 07.11.2018, 10:01   #12  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Попробую. Так а какие были ожидания когда вы разрабатывали этот класс - SubledgerJouralizerBondExtension?
для примера закупка 500 с включенной галкой Корреспондеция в параметрах разносится 8 минут, с выключенной около 3. т.е. корреспонденция дает практически 3 кратное увеличение времени разноски накладной. С 2012 я не работал, но в прошлых версиях это вроде были просто парные поля в проводках которые надо заполнять
Т.е. действительно ли сложность алгоритма корреспонденции такова, что его реализация превышает все остальные действия при разноске инвойса? если ли какие документы описывающие на словах что там происходит(для древних версий вроде бы был подобный документ)
Старый 07.11.2018, 12:38   #13  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Грустно.

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

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

По идее, можно ведь было создать простейший тест "Накладная по заказу / закупке из 1000 строк должна разноситься не более чем за X секунд / минут / часов / суток". И если он не выполняется то считать что ошибка. Время обработки это такой же критичной параметр как и корректность работы функционала.
Старый 07.11.2018, 17:10   #14  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Так а какие были ожидания когда вы разрабатывали этот класс
Я точно не помню. Обычно когда происходит аптейк какого-то нового способа выполнить тот же сценарий ставят цель, чтоб не хуже чем раньше. Это, правда, осложняется тем, что мы обычно работаем с ранними версиями международного кода, которые сами могут быть недооптимизированы.

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

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

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

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

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

X++:
someClassField = someValue;

if (conditionThatDoesNotMetHere)
{
  the only usage of someClassField ;
}
И тормозило на строчке someClassField = someValue;; если ее закомментировать, то работает быстро.

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

Детерминисткий сбор мусора X++ начинал считать количество циклов (чтобы выяснить когда они закончатся и можно освободить объект прям сразу) и на это уходило большое количество времени.
За это сообщение автора поблагодарили: Logger (3).
Старый 09.11.2018, 09:36   #15  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
цель, чтоб не хуже чем раньше.
отлично понимаю, что ты только транслируешь подход руководства.
я говорил это и руководству, и сейчас хочу повторить:
это самоубийственный подход.

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

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

Цитата:
Сообщение от belugin Посмотреть сообщение
которые сами могут быть недооптимизированы.


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

Цитата:
Сообщение от belugin Посмотреть сообщение
В LedgerVoucher данные поступают уже суммированные и их надо разбить обратно...
Нет, конечно.

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

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

Долгое время я считал, что об этом параметре не знают только "пресловутые" локализаторы. Но сабледжер показал, что о нем не знают и буржуины.
Миниатюры
Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 293
Размер:	78.4 Кб
ID:	12128  
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: George Nordic (10), AvrDen (1).
Старый 09.11.2018, 14:08   #16  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Дискуссия о новом типе add-on перенесена в профильный раздел.
Старый 09.11.2018, 20:04   #17  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
такой подход допустим только если твой продукт монополист и только на краткое время. прежде всего потому что, такой подход подразумевает, что "раньше" в продукте не было никаких недостатков.
Я говорил про аптейк существующего функционала на новую версию. Есть отдельные активности по оптимизации того, что есть, обычно это происходит по результатам обратной связи от рынка (зарегистрированные баги или телеметрия, там где она есть).

Цитата:
Нет, конечно.
Если я правильно помню.

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

X++:
protected CustVoucher initCustVoucher(LedgerTransTxt _ledgerTransTxt)
    {
        return CustVoucher::newCustVoucherSales(_ledgerTransTxt, custInvoiceJour, salesParmTable, salesTable);
    }
В сабледжерах наоборот, AccountingRules для каждой строки генерируют пары проводок, которые потом суммируются

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

...

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

Но разговор вообще не об этом а о см. выше.
За это сообщение автора поблагодарили: Logger (3).
Старый 19.11.2018, 12:36   #18  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от belugin Посмотреть сообщение
В Subledger есть уже готовые пары, которые потом суммируются, но в международном суммировании они суммируются все отдельно по счетам/аналитикам а при включенной корреспонденции они должны суммироваться с сохранением парности.
Посмотрел немного код, вообще все очень странно выглядит.
Нажмите на изображение для увеличения
Название: SubledgerBond.jpg
Просмотров: 328
Размер:	194.5 Кб
ID:	12143
Т.е. идет insert_recordset который вставляет записи(их кол-во равно сумме строк в закупке в квадрате, т.е. для 30 строк будет 900, для 1000 - миллион), далее сразу же после этого insert_recordset идет delete_from который я привел в первом посте. Между ними нет ни одной строчки кода, сразу после insert вызывается event handler на этот insert в котором все удаляется.
Почему перед исходным insert просто не добавили проверку - если включена корреспонденция, не делать его? Тем более код в рамках локализации все равно менялся (какая то проверка на #isoRu). Т.е. это кто-то что-то пропустил, или было осознанное действие?
Старый 19.11.2018, 13:29   #19  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Первый мой ответ содержит описание чего и почему
За это сообщение автора поблагодарили: trud (2).
Старый 19.11.2018, 14:09   #20  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
То ли тут, то ли в соседней теме спрашивали про скорость у конкурентов. Спросил про системы двух основных конкурентов. Для среднего предприятия в 100-200 пользователей с нормальным складом в системе и нормальным железом, приход на 1000 строк не должен обрабатываться больше 5 минут, иначе это уже повод для разбирательств.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: trud (1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Разноска накладной клиента DAX 2012 Romashka DAX: Функционал 5 26.11.2015 15:59
сторнирование накладной по закупке с накладными расходами bes DAX: Функционал 9 13.02.2015 17:29
Разноска накладной по закупке sparur DAX: Программирование 47 18.01.2008 12:36
Производство.Разноска отгрузочной накладной в главную книгу. AlexeyBP DAX: Функционал 1 10.04.2007 12:01
разноска счета на оплату после разноски накладной OlegKocherga DAX: Функционал 14 12.03.2004 17:48
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 03:01.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.