主页
Top.Mail.Ru Yandeks.Metrika
论坛:“基地”;
当前存档:2002.07.25;
下载:[xml.tar.bz2];

向下

IB6舍入 找到类似的分支


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

请求

选择......
((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.



Alexandr   (2002-07-04 10:42) [13]

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



Alexandr   (2002-07-04 10:46) [14]

Да и насчет целочисленных операндов и целочисленного результата
就像那样。

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

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



Johnmen   (2002-07-04 10:56) [15]

> 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


谢谢。
真诚的,伊万诺夫谢尔盖。
Читайте Доки - очень полезно!



Alexandr   (2002-07-04 11:47) [17]

好吧,还是。
Насчет документации это ты верно подметил...



Страницы: 1 整个分支

论坛:“基地”;
当前存档:2002.07.25;
下载:[xml.tar.bz2];

楼上









内存:0.61 MB
时间:0.026 c
14-81412
GydruS
2002-06-20 12:07
2002.07.25
在阴雨天气下,你能和女孩做些什么?


3-81185
奥克塔夫
2002-07-04 19:23
2002.07.25
斑点


14-81434
Chaynik2
2002-06-27 08:36
2002.07.25


14-81426
舅舅佛
2002-06-27 13:18
2002.07.25
我需要一个组件


14-81445
SVET
2002-06-27 15:19
2002.07.25
图标





南非荷兰语 阿尔巴尼亚人 阿拉伯语 亚美尼亚 阿塞拜疆 巴斯克 白俄罗斯 保加利亚语 加泰罗尼亚 简体中文 中国(繁体) 克罗地亚 捷克 丹麦语 荷兰人 英语 爱沙尼亚语 菲律宾人 芬兰 法文
加利亚西语 格鲁吉亚语 德语 希腊语 海地克里奥尔语 希伯来语 印地语 匈牙利 北日耳曼语 印度尼西亚人 爱尔兰语 意大利语 日本性玩偶 韩语 拉脱维亚 立陶宛 马其顿 马来语 马耳他语 挪威语
波斯语 波兰语 葡萄牙语 罗马尼亚 俄语 塞尔维亚 斯洛伐克 斯洛文尼亚 西班牙语 斯瓦希里 瑞典语 泰国人 土耳其 乌克兰 乌尔都语 越南人 威尔士语 意第绪语 孟加拉 波斯尼亚
宿务 世界语 古吉拉特语 豪萨语 苗族 伊博 爪哇 卡纳达语 高棉 老挝 拉丁语 毛利 马拉 蒙古人 尼泊尔 旁遮普 索马里 泰米尔人 泰卢固语 约鲁巴语
祖鲁
英文 Французский Немецкий Итальянский Португальский 俄文 Испанский