PurchTableWorkflow и немножко архитектуры + неочевидного

[axm2017]

Смотрю метод submit

public void  submit()
    {
        WorkflowSubmitDialog            workflowSubmitDialog;

        if (purchTable != null)
        {
            // Tax is needed to be calculated first or else the Accounting Distribution allocation factor will not be calculated correctly.
            if (Ledger::isLedgerBudgetControlEnabled())
            {
                PurchTotals::newPurchTable(purchTable).calc();
            }
                
            if (this.canSubmit(purchTable))
            {
                workflowSubmitDialog = WorkflowSubmitDialog::construct(args.caller().getActiveWorkflowConfiguration());

                if (this.submitDialog(workflowSubmitDialog))
                {
                    purchTable.submitToWorkflow(workFlowTypeStr(PurchTableTemplate), workflowSubmitDialog.parmWorkflowComment(), false);
                }
            }
        }
    }

Заинтересовал кусочек

 // Tax is needed to be calculated first or else the Accounting Distribution allocation factor will not be calculated correctly.
if (Ledger::isLedgerBudgetControlEnabled())
            {
                PurchTotals::newPurchTable(purchTable).calc();
            }

Получается предварительный расчет по заказу как то меняет данные да так что от этого зависит остальное?

Можно ли как то этого избежать или вынести куда то если цель сократить время до появления диалога

this.submitDialog

Вдруг кто глубоко рылся в данном коде или умеет в спеца по perfomance?

[Pandasama]

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

[EVGL]

Для контроля бюджета в закупках перед отправкой в workflow со времен AX2012 идет расстановка счетов ГК и расчет Accounting distribution. Самое позднее, когда это случается - это формирование Confirmation.

Чтобы ускорить, надо сделать так, чтобы Ledger::isLedgerBudgetControlEnabled() возвращал false?

[axm2017]

Заметил что повторные запуски
PurchTotals::newPurchTable(purchTable).calc(); существенно ускоряются так как видимо в работе класса предположительно используется кэширование.
Первый запуск традиционно идет небыстро.

Можно ли как то запустить класс в стороне и потом как то расшарить кэш и на пользователя?

[DarkSpirit22]

Там не совсем кэш. В 2012 в модуле поставщиков реализовали кэширование в постоянной таблице TaxUncommitted. Если для связи HeaderTableId + HeaderRecId( напр. для PurchTable или VendInvoiceInfoTable) есть уже посчитанные налоги, то Tax (TaxPurch) возьмет от туда, иначе пойдет считать. Подробнее можете почитать здесь.

[axm2017]

решил в общем попытаться уже традиционно для себя через runAsync
runAsync и его использование

Пример для любознательных чтобы не копаться как передать параметры из таска обратно в основной поток

validationTask.Wait();
AsyncTaskResult asyncTaskResult = AsyncTaskResult::getAsyncTaskResult(validationTask);

boolean valid;
container messageContainer;

[valid, messageContainer] = asyncTaskResult.getResult();
infolog.import(messageContainer);