Неправильное округление величины

[AvrDen]

Добрый день!
Периодически при разноске складских журналов возникает ошибка "Неправильное округление величины".
Ошибка возникает в InventJournalTrans/checkAmount

    if (this.CostAmount != Currency::amount(this.CostAmount))
        ok = checkFailed("@SYS2602");

В строке журнала поле CostAmount стоит сумма 8933,72
При этом в отладчике в поле CostAmount непонятно почему заносится очень странное значение(например 8933,719999999999), т.е. система не округлила сумму. При этом, если изменить в строке журнала сумму на 8933,73, то ошибка не возникает.

Не подскажите в чем может быть проблема

Dynamics AX 2009 5.0.1500.2116

[Ivanhoe]

Строка в журнале создается программным способом - читай модификацией?

[AvrDen]

Нет, все создается руками.

[Ivanhoe]

А на основной валюте компании у вас поставлено округление? Например, 0,01.

[AvrDen]

Да, на валютах, везде стоит округление 0,01.

[glibs]

А в каком месте отладчик пишет в поле неокругленную сумму? И какую операцию вы вводите?

[gl00mie]

Чтобы не гадать, откуда берутся неокругленные суммы, можно на InventJournalTrans.insert() и update() повесить проверку поля CostAmount и, если что, выводить стек вызовов (как вариант - писать куда-нить детализированную информацию). Так, по-моему, будет проще, чем пытаться отловить ситуацию, не имея никаких зацепок. К тому же, очень сомнительно, что неокругленная сумма вводится руками - округление на формах работает вполне надежно и таких вольностей не допускает (либо это будет первый известный случай).

[glibs]

Там в Cost price можно вводить до 12 знаков после запятой или даже больше (что из внешнего вида формы совсем не очевидно, и мне кажется что раньше могло быть не так). Cost amount в форме должно округляться до двух знаков. Но если кто-то что-то программировал в этом месте, то мог забыть округлить.

[AvrDen]

Цитата:

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

Чтобы не гадать, откуда берутся неокругленные суммы, можно на InventJournalTrans.insert() и update() повесить проверку поля CostAmount и, если что, выводить стек вызовов (как вариант - писать куда-нить детализированную информацию). Так, по-моему, будет проще, чем пытаться отловить ситуацию, не имея никаких зацепок. К тому же, очень сомнительно, что неокругленная сумма вводится руками - округление на формах работает вполне надежно и таких вольностей не допускает (либо это будет первый известный случай).

Да я так и сделал в первую очередь, на insert() и update() InventJournalTrans вставил округление CostPrice и CostAmount перед вызовом super()

    this.CostPrice = Currency::amount(this.CostPrice);

    this.CostAmount = Currency::amount(this.CostAmount);
    super();

[AvrDen]

Цитата:

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

А в каком месте отладчик пишет в поле неокругленную сумму? И какую операцию вы вводите?

Ошибка возникает при проверке суммы строк журнала InventJournalTrans/checkAmount.
Возникает при проверке журнала Инвентаризации и Проводки. И возникает именно на сумме 8933,72(при вводе суммы 8933,73 все проходит без ошибок). Еще один ньюанс - данная ошибка возникла только в AX5.0 в 4.0 ее не было.

[S.Kuskov]

Цитата:

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

Да я так и сделал в первую очередь, на insert() и update() InventJournalTrans вставил округление CostPrice и CostAmount перед вызовом super()

Суть не в том что бы за минуту написать заглушку, а в том чтобы вычислить природу происхождения неокруглённых значений.

Я бы на вашем месте последовал бы совету gl00mie

Цитата:

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

Чтобы не гадать, откуда берутся неокругленные суммы, можно на InventJournalTrans.insert() и update() повесить проверку поля CostAmount и, если что, выводить стек вызовов (как вариант - писать куда-нить детализированную информацию).

[Ivanhoe]

Вы случайно не списываете номенклатуру? Может, у вас начальные данные были некорректно загружены и складская себестоимость имеет такую размерность (кучка знаков после запятой)?

[AvrDen]

Цитата:

Сообщение от S.Kuskov

Суть не в том что бы за минуту написать заглушку, а в том чтобы вычислить природу происхождения неокруглённых значений.

Я бы на вашем месте последовал бы совету gl00mie

Так в том то и дело, что с этой заглушкой все равно возникает ошибка

[AvrDen]

Цитата:

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

Вы случайно не списываете номенклатуру? Может, у вас начальные данные были некорректно загружены и складская себестоимость имеет такую размерность (кучка знаков после запятой)?

Ошибка возникает и при списании и при оприходовании товара, независимо от номенклатуры и соответственно от себестоимости

[glibs]

Вам известно как создавалась строка журнала?

Если вручную в этом же журнале ввести точно такую же строку журнала - проверка выдаст ошибку во введенной вручную строке?

[AvrDen]

Цитата:

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

Если вручную в этом же журнале ввести точно такую же строку журнала - проверка выдаст ошибку во введенной вручную строке?

Да, при ручном вводе ошибка повторяется

[S.Kuskov]

Если вы говорите, что перед сохранинием записи (перед super в insert/update) вы значения округляете, то значит портятся эти значения уже позже и причём в обход update при помощи doUpdate. Запускаете ли вы какие-нибудь дополнительные обработки перед разноской журнала, или возможно у вас есть какие-то модификации самой процедуры разноски?

Цитата:

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

Да, при ручном вводе ошибка повторяется

Т.е.на форме вводим 8933.72, а в таблицу попадает 8933,719999999999 ? Или сразу после ввода до попытки разнести журнал в таблице ещё правильное значение, а хвост появляется позже? Непонятно в какой именно момент у суммы в таблице появляется хвост.

[AvrDen]

Цитата:

Сообщение от S.Kuskov

Т.е.на форме вводим 8933.72, а в таблицу попадает 8933,719999999999 ?

Да, именно так...

После долгих экспериментов, удалось установить что неправильное значение присваиваеться в super() inventJournalTrans.update(). Я сделал выборку строки журнала ДО super, и ПОСЛЕ. До в CostAmount было значение 8933.72, после 8933,719999999999

[S.Kuskov]

Цитата:

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

Да, именно так...

Ужас то какой. И что, стабильно воспроизводится? А на тестовом приложении также?

[AvrDen]

Сейчас обнаружил еще одну странную вещь: у нас на форме InventJournalCount есть небольшая модификация к InventJournalTrans присоединена таблица Inventtable для отображания доп. параметров номенклатуры в строках журнала(больше можификаций нет, никакие методы не перекрыты). Так вот при JoinMode:: Active запись обновляется нормально и проверка проходит тоже, а при InnerJoin возникает эта ошибка.
Смотрели профайлер SQL и при JoinMode:: Active обновление проходит с помощью команды
exec sp_execute 94,8933.720000000000,8933.720000000000,1150887998,N'mhv',N'000256_070',1.000000000000,2095401284,
а при JoinMode::InnerJoin
UPDATE INVENTJOURNALTRANS SET COSTPRICE=4.46686E3,COSTAMOUNT=8.93372E3,RECVERSION=290773656 WHERE (((DATAAREAID=N'mhv') AND (RECID=5693788077)) AND (RECVERSION=140598760))

т.е. при InnerJoin COSTAMOUNT представляется в экспоненциальном виде.
В АХ 3.0/4.0 такой проблемы не было...