Курсовая разница

[kornix]

Всем привет!

Коллеги, появилась удивительная проблема: при расчете курсовой разницы периодической операцией из ГК по определенному счету вылетает ошибка:
"Ошибка в суммы в валюте 'RUR'. Необходимо округлить до '0,00'." и "Сумма в -22 293 038 037,63 -22 293 038 037,63, кот. проведена по счету 'У66.22', слишком мала.
". В итоге транзакция откатывается и пользователю не удается рассчитать курсовую разницу.
Насколько я понял, проблема в округлении чисел, разрядность которых превосходит тип real (16 знаков). По стеку ошибка вылетает на следующем методе:

static boolean checkRoundOff(LedgerAccount _accountNum,
AmountMST _amountMST)
{
if (_amountMST != Currency::amount(_amountMST))
{
error(strFmt("@SYS27168",CompanyInfo::find().currencyCode,
Currency::roundOffAmount(CompanyInfo::find().currencyCode)));
return checkFailed(strFmt("@SYS18429",
_amountMST,
Currency::amount(_amountMST),
_accountNum));
}
return true;
}

Основная валюта компании рубли, в настройках ГК округление настроено как 0.00

[fed]

Когда-то уже видел такое. Возникает при следующих ситуациях:
1. У вас когда-то давно было настроено более мелкое округление сумм (скажем до долей копейки). Эти суммы попали в существующие проводки (ledgerTrans/vendTrans/custTrans etc).
2. Теперь процедура рассчета курсовой бежит по старым ledgerTrans, подсчитывает суммы округленные до долей копейки и рассчитывает курсовые из этих сумм. В итоге - пытается провести проводку на сумму с округлением до долей копейки. Система же проверяет - не пытаемся ли мы провести сумму не округленную до текущих настроек округления, и как следствие - грязно ругается.

Общего и гарантировано правильного выхода из ситуации (за исключением перезапуска системы) нет. Частично решить ситуацию можно двумя способами:
1. Пробежаться по старым проводкам и округлить суммы до нынешних значений. НО: Из за округлений в разную сторону может поехать баланс. Так что это не выход на мой взгляд.
2. Подправить рассчет курсовых таким образом, чтобы он насильственно округлял проводимую сумму до копеек. Тоже на самом деле вариант - не подарок. Скажем - курсовые по каким-то конкретным сочетаниям аналитик может округлится до ноля копеек. В итоге - если мы после расчета курсовой попробуем, например, посчитать рублевое и валютное сальдо по счету (не в разрезе аналитик, а вообще по счету), то у нас может получится так что курсовые недопровелись и валютное сальдо после пересчета в рубли не равно рублевому.

Так что универсального решения нету. Точнее говоря - универсальное решение есть, но это рестарт системы :-(

[ZVV]

Цитата:

Сообщение от kornix

.........
Основная валюта компании рубли, в настройках ГК округление настроено как 0.00

А если поставить 1.00 или 0.01?

[kornix]

Спасибо за ответ! Как раз начал переделывать метод расчета курсовой разницы, наверно этот вариант единственный, обеспечит работу пользователя, но потом придется как-то сводить сальдо.. Спасибо, fed!

[kornix]

Этот вариант интересный, но он породит слишком большую ошибку расхождения сальдо

[gaenar]

Поправьте джобиком суммы в LedgerTrans, мы на то же нарывались, проджобили - эти проблемы ушли, новых не вылезло. если хотите кину даже сам джобик (пишите в личку, форум смотрю крайне редко)

[Владимир Максимов]

Вообще-то, еще одна причина может быть в кастомизированном коде. Т.е. где-то, как-то, создаются суммы бух.проводок вообще без округления. Ведь в случае, если округление настроено как 0.00 метод Currency::amount() выполняет округление до копейки.

Другими словами, причина в том, что полученная сумма amountMST имеет дробную часть более, чем 2 знака после запятой. А вот как этот "хвост" появился, как следствие штатного функционала (раньше было округление до 0,001) или как следствие ошибок кастомизации, и надо выяснить. После этого уже искать пути решения.

Найти как раз не сложно. Просто поискать бух.проводки (LedgerTrans) у которых суммы имеют более 2 знаков после запятой. Далее смотреть как эти проводки были созданы.