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

[Ivanhoe]

Т.е. все-таки модификации есть

[AvrDen]

Цитата:

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

Т.е. все-таки модификации есть

Ну да - это модификация, но модификация, которая никак не влияет на расчет суммы затрат, это "просто удобство для пользователей" и которое стабильно работало в предыдущих версиях.
Непонятно почему сейчас происходят такие "фокусы"

[S.Kuskov]

Согласен с AvrDen, это не серьёзно. Явный баг
Интересно было бы создать тестовый проектик (тестовые таблички + тестовая форма), на котором бы воспроизводился описанный глюк и погонять такой проект на разных приложениях и СУБД. AvrDen, может сворганите такой на скорую руку?

[Ivanhoe]

Баг неприятный. Но если в стандарте его нет, то намного быстрее можно было бы найти проблему - модификацию.

Вопрос автору: у вас версия системы указана для чего? Приложение или и все bin-файлы?

Попробовал сделать модификацию с новым ДС по InnerJoin (вывел ItemName на форму) - ошибка не повторилась. Приложение 5.0.1500.2116, bin-файлы 5.0.1500.3761.

[AvrDen]

Провел эксперимент - взял рабочее приложение и создал новую БД, залил туда тестовые данные. Ошибка не повторилась... Т.е. дело не в модификациях...

[AvrDen]

Цитата:

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

Вопрос автору: у вас версия системы указана для чего? Приложение или и все bin-файлы?

у меня и приложение и bin-файлы 5.0.1500.2116

[AvrDen]

Цитата:

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

Интересно было бы создать тестовый проектик

Попробуйте запустить следующий job(recId только свой подставьте ) и посмотреть в Журнале трассировки операторов SQL план запроса

static void Job17(Args _args)
{
    InventJournalTrans  inventJournaltrans;
    InventDim           inventDim;
    InventTable         inventTable;
    InventItemBarcode   inventItemBarcode;
    ;
    ttsbegin;
    select forupdate inventJournaltrans
        where inventJournaltrans.RecId == 5637149414
        join inventDim
        where inventDim.inventDimId == inventJournaltrans.InventDimId
        join inventTable
        where inventTable.ItemId == inventJournaltrans.ItemId;

        inventJournaltrans.CostAmount = 8933.72;
        inventJournaltrans.update();
    ttscommit;
}

У меня получился следующий план запроса:

UPDATE INVENTJOURNALTRANS SET COSTAMOUNT=8.93372E3,RECVERSION=702523288 WHERE (((DATAAREAID=N'mhv') AND (RECID=5637149414)) AND (RECVERSION=902287041))

Как видно CostAmount представлен в экспоненциальном виде и SQL воспринимает его как 8933.719999999999

Удалив из job таблицу Inventtable

static void Job17(Args _args)
{
    InventJournalTrans  inventJournaltrans;
    InventDim           inventDim;
    InventTable         inventTable;
    InventItemBarcode   inventItemBarcode;
    ;
    ttsbegin;
    select forupdate inventJournaltrans
        where inventJournaltrans.RecId == 5637149414
        join inventDim
        where inventDim.inventDimId == inventJournaltrans.InventDimId;

        inventJournaltrans.CostAmount = 8933.72;
        inventJournaltrans.update();
    ttscommit;
}

получим план запроса

UPDATE INVENTJOURNALTRANS SET COSTAMOUNT=?,RECVERSION=? WHERE (((DATAAREAID=?) AND (RECID=?)) AND (RECVERSION=?))

[AvrDen]

Обратились с этой проблемой на форум SQL
http://www.sql.ru/forum/actualthread.aspx?tid=830538

В связи с этим вопрос: как можно поменять размерность полей в AX?

[gl00mie]

По-моему, размерность полей в AX ни при чем, поскольку потеря точности может возникать при разной размерности на разных числовых константах. Проблема, если верить описанию на sql.ru, в том, что ядро отправляет запрос, указывая значение для поля типа numeric в экспоненциальной форме, соответствующей типам float и real, вместо использования формата констант, принятых для типа numeric/decimal (см. константы TSQL). Из-за этого возникает приведение типа, в ходе которого теряется точность. Это все, конечно, отчасти связано с особенностями Ms SQL, тем не менее, используй ядро "родную" форму представления констант, проблем бы не возникало. К слову, вот простой пример, иллюстрирующий "странности" в приведении типов в Ms SQL (проверено на Ms SQL Server 2008, v10.0.4000.0):

PHP код:

declare @test numeric(28,12)
select @test = 8.93372E3
print @test
select @test = 8933.72
print @test 


на выходе получаем:

8933.719999999999
8933.720000000000

Я бы в такой ситуации посоветовал внимательно изучить список вышедших исправлений и при отсутствии чего-то схожего зарегистрировать ошибку в службе поддержки. Думаю, исправить в ядре формат строкового представления числовых констант, отправляемых на СУБД, не составит особого труда, и скоро выйдет соответствующий hotfix.

[axalex]

Цитата:

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

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

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

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

//исправление ошибки округления в складском журнале
static void InventJournalCostAmountRound(Args _args)
{
    InventJournalTrans  inventjournalTrans;
    InventJournalId     inventJournalId = "/*НОМЕР ЖУРНАЛА*/";
    ;

    ttsbegin;
    while select forupdate inventjournalTrans
        where inventjournalTrans.JournalId == inventJournalId
    {
        inventjournalTrans.CostAmount = Currency::amount(inventjournalTrans.CostAmount);
        inventjournalTrans.doUpdate();
    }
    ttscommit;
    info("Округление успешно");
}