Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Каким должен быть тип поля в Firebird? [D6, IB6.x, Firebird]

Страницы: 1 2 >
Пубертанец © (2004-02-04 09:10:00)

Чтобы в SQLDataSet и ClientDataSet этот тип поля был Currency. Что не пытался делать - все равно появляется FMtBCD, а хочу Currency.

Пубертанец (2004-02-04 17:59:00) [1]

Спасибо всем за участие

Sandman25 (2004-02-04 17:56:00) [2]

В обществе с ограниченной ответственностью, разрабатывающем ПО. У вас в registru тоже бывал как-то, там у меня сокурсник работал.

Currency в основном служит для отображения со знаком денежной валюты. В остальном он почти неотличим от Float. Так что никакое умножение/деление не избавит от погрешностей округления.

Пубертанец (2004-02-04 17:45:00) [3]

Sandman25 - *б твою, так ты, землячок, оказывается. Если бы про 1 бан не написал, так бы и жил в неведении. А где робишь?

Так что, в клиенте, насколько я понял, придется все время умножать на 100, проводить необходимые операции, а потом обратно делить на 100? И все-таки, свойство currency=true у поля приведет ли к точным расчетам или оно только для визуального отображения?

Sandman25 (2004-02-04 17:03:00) [4]

[25] Johnmen © (04.02.04 16:58)

Мы стали записывать в БД сумму с точностью до 5 знаков.
То есть из моего примера:
14.67633+25.68633+36.70734=77.07
Причем 5 взято не от балды, а рассчитано: количество имеет 3 знака, а цена - 2 знака. Проблема остается только для случая скидок - скидка должна браться от общей суммы покупки, а мы вынуждены делать скидку прямо в цене. Но тут уже ничего не поделаешь. Все равно нельзя прямо в чеке печатать цену с 5 знаками.

Johnmen (2004-02-04 16:58:00) [5]
>Sandman25 © (04.02.04 16:52)

Виноват, не в [10], а в [18] :)

>Нет разницы, что DEC(16,5), что Integer.
&
>Мы недавно перешли с DEC(18,2) на DEC(18,5)....

Значит, есть.....

Sandman25 (2004-02-04 16:52:00) [6]

То, что в [10], ничем не отличается от sum(round(price*amount,2)).
Нет разницы, что DEC(16,5), что Integer.

Johnmen (2004-02-04 16:43:00) [7]

>Sandman25 © (04.02.04 16:37)

Тогда сделай 18,10 :)
И всё-таки [18]

Sandman25 (2004-02-04 16:37:00) [8]

[20] Dedushka_Mazai © (04.02.04 16:27)

Приходные накладные к делу не относятся. Например, этот вид колбасы был получен по трем разным накладным (за разные даты или от разных поставщиков).

[21] Johnmen © (04.02.04 16:31)

После перехода проблемы составляют 1-2 баня в день. До перехода нам высказывали претензии, что многие клиенты наших клиентов начинали ругаться, что их пытаются обмануть, и соответственно переставали быть клиентами наших клиентов.
Конкретно этот пример выдумал, но подобные ситуации возникали постоянно.

ЗЫ. Некоторые клиенты действительно торгуют в том числе и колбасой :)

Johnmen (2004-02-04 16:31:00) [9]

>Sandman25 © (04.02.04 16:21)
>Но ведь это проблему не решило.

Зачем тогда переходили ? :)

А твой пример суммирования [11] из реальности (относительно цифирей) ? Есть подозрение, что ты его выдумал...:)

Dedushka_Mazai (2004-02-04 16:27:00) [10]

2Sandman:
ну так в расходной и будет одна позиция

Кол-во Цена Сумма
--------------------------
7кг 11.01р 77.07р

а как у тебя тогда приходная будет выглядеть?

Кол-во Цена Сумма
--------------------------
1.333кг 11.01р 14.68р
2.333кг 11.01р 25.69р
3.334кг 11.01р 36.71р
-------
77.08р ?

или у тебя в приходной в поле "сумма" надцать знаков после запятой?

ЗЫ: упарился набирать

Sandman25 (2004-02-04 16:21:00) [11]

[18] Johnmen © (04.02.04 16:19)

Но ведь это проблему не решило. И в принципе не могло. Пока СУБД не научатся работать с бесконечными десятичными дробями :)

Johnmen (2004-02-04 16:19:00) [12]

>Sandman25 © (04.02.04 16:15)

Смотрю Sandman25 © (04.02.04 15:50)
и думаю, что связаны. С реализацией типов в разных СУБД.
:)

Sandman25 (2004-02-04 16:15:00) [13]

[15] Johnmen © (04.02.04 16:13)

И вообще, эти проблемы (твои), похоже не относятся к семейке IB :)

Они вообще с БД не связаны, это проблемы философского характера :)

Sandman25 (2004-02-04 16:14:00) [14]

[14] Dedushka_Mazai © (04.02.04 16:10)

Клиенту наплевать, что тремя партиями. Он взял один кусок весом ровно 7 кг, почему он должен переплачивать? В выходной накладной 1 позиция. Это "внутри" (в товарном движении) она делится на 3.

Johnmen (2004-02-04 16:13:00) [15]

>Sandman25 © (04.02.04 16:04)

Тогда второй вариант из [10]
И вообще, эти проблемы (твои), похоже не относятся к семейке IB :)

>Dedushka_Mazai © (04.02.04 16:05)

Смотря что округлять, и чего хотим добиться...

Dedushka_Mazai (2004-02-04 16:10:00) [16]

2Sandman:
раз колбаса идёт тремя партиями, значит и сумму надо для каждой позиции из накладной вычислять отдельно. поэтому, правильно будет 77.09, а не 77.07

Sandman25 (2004-02-04 16:09:00) [17]

[10] Johnmen © (04.02.04 16:01)

Мы пробовали самыми разными способами. Но проблема еще и в том, что должна "бить" сумма по позициям. Поэтому округлять надо сразу, для каждой позиции. Но одна позиция выходной накладной может собираться из нескольких позиций входных накладных. В общем, даже DEC(18,5) не спасает полностью, но существенно снижает погрешности. Ты смеешься, а меня из-за этих копеек постоянно доставали. За день несколько рублей набегало, причем у нас валюта крупнее, чем в России, 1 бан (наша "копейка") примерно равен 2.5 российским копейкам

Dedushka_Mazai (2004-02-04 16:05:00) [18]

2Johnmen:
округлять надо как раз перед суммированием, а то погрешность действительно большая получится

Sandman25 (2004-02-04 16:04:00) [19]

[9] Dedushka_Mazai © (04.02.04 15:54)

Есть 3 партии одного вида колбасы: с количествами 1.333, 2.333 и 3.334 (так получилось из-за предыдущих продаж). Клиент покупает все 7 кг. По цене 11.01. Он должен заплатить 77.07.
И платит 14.67633+25.68633+36.70734=77.07
Но при расчете получается 14.68+25.69+36.71=77.09. На 2 копейки больше.

Johnmen (2004-02-04 16:01:00) [20]

>Sandman25 © (04.02.04 15:50)

Да, это сумма просто огромна...:)
И ещё. Округлять надо после суммирования, чтобы максимально нивелировать погрешности разрядной сетки...
Или же, сначала цену к int(*100), потом *, потом /, и уж потом sum.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »