Округление в IB6

← →
IvanovSergey (2002-07-03 13:32) [0]

Запрос

select ...
((ROW_COUNT*ROW_PRICE)-((ROW_COUNT*ROW_PRICE)/(100+ROW_NDS)*ROW_NDS))/ROW_COUNT AS PRICE_WO_NDS,
(ROW_COUNT*ROW_PRICE)-((ROW_COUNT*ROW_PRICE)/(100+ROW_NDS)*ROW_NDS) AS SUM_WO_NDS,
(ROW_COUNT*ROW_PRICE)/(100+ROW_NDS)*ROW_NDS AS SUM_NDS,
(ROW_COUNT*ROW_PRICE) AS SUM_TOTAL,

PRICE_WO_NDS при расчете не округляется а отбрасывется дробная часть.

Как побороть?

← →
Johnmen © (2002-07-03 13:40) [1]

А как это было определено ?

← →
IvanovSergey (2002-07-03 14:15) [2]

2 Johnmen:

C аналогичным расчетом в старой программе не совпало.
Я стал проверять с реальными числами
((20*9,16)-((20*9,16)/(100+20)*20))/20 AS PRICE_WO_NDS
(183,20-(183,20/120*20))/20 AS PRICE_WO_NDS
(183,20-( 1,52*20))/20 AS PRICE_WO_NDS если отбросить дробную часть
(183,20-( 1,53*20))/20 AS PRICE_WO_NDS если округлить дробную часть

← →
Val © (2002-07-03 14:24) [3]

как вы смотрите результаты запроса?

← →
IvanovSergey (2002-07-03 14:29) [4]

2 Val:
ibConsole, а эксперименты с цифрами уже в excel, а что?

← →
IvanovSergey (2002-07-03 14:34) [5]

2 Val:
ibConsole, а эксперименты с цифрами уже в excel, а что?

← →
Val © (2002-07-03 14:36) [6]

, а что?
было подозрение на округление уже приложением.
как у вас объявлены типы?

← →
IvanovSergey (2002-07-03 19:01) [7]

в таблице

"ROW_COUNT" INTEGER NOT NULL,
"ROW_PRICE" NUMERIC(9, 2) NOT NULL,

С уважением Иванов Сергей

← →
kaif © (2002-07-03 20:40) [8]

По вашему, если цена без НДС будет округляться правильно, это избавит от остальных проблем? На знаю, какой идиот придумал все эти НДС, но я Вам вот, что скажу. Если не отталкиваться от цены без НДС изначально, то ни при каких условиях навозможно получить правильный счет-фактуру если не заложить все цены кратными 6. Одним словом, задача расчета цены без НДС на основе цены (или суммы) с НДС обречена на провал, если не использовать плавающий тип (FLOAT или DOUBLE PRECISION) и не выводить 4 знака после запятой. Типа цена 123.1234 рубля. Пускай потом в налоговой радуются на свое изобретение...

← →
Alexandr © (2002-07-04 06:36) [9]

нет.
Просто менеджерам объясняют, что если они хотят работать с ценой с НДС, то эта цена будет приблизительной.
Т.е. программа сразу из этой цены получаент цену без НДС, округляет до копеек, а потом опять получает цену с НДС и это будет уже правильная цена с НДС, о чем менеджера и предупреждают.

Все остальные варианты( типа 4 знаков в копейках, изменения формы СФ зарубятся ГНИ, да еще и штраф выпишут)

← →
Johnmen © (2002-07-04 09:53) [10]

1.
NUMERIC(9, 2) - на самом деле integer (см.доки)
2.
>kaif © (03.07.02 20:40)
>Alexandr © (04.07.02 06:36)

Оба правы, оба подхода правомочны, я исповедую с несколькими вариациями Alexandr © (04.07.02 06:36)

← →
IvanovSergey (2002-07-04 10:30) [11]

Про все эти приколы с кратностью я знаю, все размышления на эту тему свелись к следующему принципу: расчеты программы должны совпадать с расчетами на калькуляторе иначе ни какие доводы про машинную арифметику не работают. Потому как "я не знаю как у вас оно там щитает, а вот у _меня_ правильно".
Был, кстати такой случай с четырьмя знаками после запятой, уперлась тетка в райпо - так я ей в екселе счет рисовал.

Так numeric использовать нельзя, что ли? А что использовать?
Ну и все равно это не правильно. Если (9.2) то почему он его обрабатывает как (9.0)?

← →
Johnmen © (2002-07-04 10:38) [12]

>IvanovSergey

Я думаю твоя проблема из-зи того, что происходит неявное приведение типов в запросе : т.к. все переменные выражения целочисленны, то и результат предполагается integer.

Попробуй привести результат к float с пом.CAST.

2Johnmen: У меня бухгалтер отверг начисто все подходы в том числе и с 4 знаками после запятой. Однозначно сославшись на налоговую инспекцию и требования наших клиентов.
А тот вариант, который я тут написал вот уже давно очень работает и нареканий не было совершенно.

Да и насчет целочисленных операндов и целочисленного результата
именно так.

В доке на этот счет написано было...
Да еще и от диалекта зависит

Вообщем после долгих мучений с Numeric, хранением денег и прочим.
Я пришел к выводу что достаточно иметь Integer и double чтобы спать спокойно, а все эти нумерики забыть как дурной сон.

>Alexandr © (04.07.02 10:46)
>достаточно иметь Integer и double чтобы спать спокойно

Полностью согласен. Хотя можно иметь и Integer и Numeric(15,2)

← →
IvanovSergey (2002-07-04 11:45) [16]

Все получилось. Кажется...

седующая запись возвращает требуемый результат:
(ROW_COUNT*cast(ROW_PRICE as FLOAT))/(100+ROW_NDS)*ROW_NDS AS SUM_NDS

Спасибо.
С уважением Иванов Сергей.
Читайте Доки - очень полезно!

ну еще бы.
Насчет документации это ты верно подметил...

Округление в IB6 Найти похожие ветки