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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.11.2018, 17:10   #14  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (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).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Разноска накладной клиента 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, время: 02:23.