Исправление ошибок стандартного конструктора финансовых отчетов
<b>Описание проблемы</b>
Данные во вторичной валюте в отчетах, созданных на основе конструктора финансовых отчетов, формируются неправильно.
<b>Решение проблемы</b>
Изменены две функции класса LedgerBalanceSheetCol_CurMST
1. в функции initPeriod() теперь всегда используется запрос по проводкам
2. исправлена описка в функции buildQuery()
<u>Описание ошибки</u>
В функции LedgerBalanceSheetCol_CurMST::buildQuery() для каждого столбца в зависимости от значения одного из параметров sumType[3] выполняется
либо запрос qR_BalanceRegular (sumType[] == #SumBalance), который не показывает вторичную валюту
либо запрос qR_LedgerTrans (sumType[] == #SumTransact), который показывает вторичную валюту.
Параметры sumType[3] для каждой колонки отчёта заполняются в функции LedgerBalanceSheetCol_CurMST::initPeriod() и зависят от вложенности периода(ов) журнала проводок в период столбца отчёта.
<u>"Быстрое" решение</u>
Изменена функция LedgerBalanceSheetCol_CurMST::initPeriod().
Всегда используется #SumTransact, т.е. всегда вычисляется сумма по проводкам, а итоги по закрытым периодам игнорируются.
Недостатком решения является (возможно, заметное) замедление генерации отчёта на «очень большом» количестве проводок.
<u>"Правильное" решение</u>
Нужно разобраться в следующих вопросах
1. почему запрос #SumBalance не показывает вторичную валюту
2. формируются ли вообще данные во вторичной валюте при закрытии интервала в журнале проводок и где это происходит
<u>Описка в функции buildQuery</u>
При формировании запроса по дебетовым проводкам (ledgerBalColumns.debCredCriteria==DebCredProposal::Debit)
вместо поля fieldDebitTax ошибочно использовалось поле fieldCreditOpr.
__________________
Evgeny
|