The daily Axapta WTF

[TasmanianDevil]

2009 SP1 5.0.1500.6491 (хотя оно вполне справедливо и для старших/младших версий)

Уже давненько замечал, что есть такая практика в различных обработчиках модульных движений по части использования методов lastAmountCur()/lastAmountMST() от доступного в тех краях объекта LedgerVoucher для наполнения суммовых полей своих родных модульных проводок.

До сих пор отношение к этому далее и конкретнее, чем "чую бесовщину, но обосновать не могу", не шло...

Однако на днях коллеги в "песочнице" попытались разнести накладную по заказу на продажу, в которой было две строки с разными знаками (-/+) в качестве исправления ранее сделанной (изменялась цена продажи одной строки).
Все красиво и хорошо, склад и налоги -/+ прошли как и ожидалось, только вот проводка по клиенту сформировалась на сумму последней строки накладной вместо суммы всех строк.

Исследования показали, что эта "радость" возникает при сложении двух обстоятельств:

1. Накопление разнознаковых частей и разбивка по ним в российской функциональности проводок ГК по клиенту в CustVendVoucher'е при наличии в дебете или кредите позиций с разным знаком (наполняется в SalesFormLetter_Invoice.createCustTrans(), будущие проводки ГК разбиваются далее в CustVendVoucher.postMultipleBalances_RU, вызываемом из post() этого же класса)
2. Использование в инициализации суммы проводки по поставщику/клиенту в CustVendVouchere.initCustVendTrans() вышеозначенных методов, lastAmountCur()/lastAmountMST(), из LedgerVoucher'а

Есть мнение, что вышеозначенные методы небезопасны и их использование за пределами LedgerVoucher'а суть есть зло и рытье ямы самому себе.

P.S. <GEUU> в комментах тамошнего кода, наполнявший разбиение и поклавший на оное в своем же коде - это же наш здешний EVGL, если не ошибаюсь ?