округление-потеря копейки

← →
dis12345 © (2014-05-04 20:16) [0]

Здравствуйте!
При вычислении стоимости, умножая количество=вес на цену, получаем значение. При передаче цены и количества в фискальный регистратор, получаем подитог, отличающийся от вычисленного в delphi на 1 копейку и чек не пробивается.

Пример:
procedure TForm1.Button1Click(Sender: TObject);
var
a,b : real;

begin

a:=0.211;
b:=105.00;

Label1.Caption:=FloattoStr(RoundTo(a*b,-2));
Label2.Caption:=FloattoStr(RoundTo(0.211*105.00,-2));

end;

0.211х105=22.155
получаем два различающихся итога: 22.15 и 22.16
итог в ФР= 22.16

есть ф-ия SetRoundMode, в ней параметрами настраивается способ округления. Какой из параметров
rmNearest Rounds to the closest value.
rmDown Rounds toward negative infinity.
rmUp Rounds toward positive infinity.
rmTruncate Truncates the value, rounding positive numbers down and negative numbers up.

гарантированно округлит 0,5 до 1 подскажите плиз

← →
Dimka Maslov © (2014-05-04 20:34) [1]

В последнее время в некоторых торговых сетях вообще производится округление в меньшую сторону до рубля.

А вообще есть тип Currency (c фиксированной точкой) введённый специально для уменьшения ошибок округления в финансовых расчётах. Он может спасти ОРД.

Кроме того, можно считать всё в копейках. Это даже выгоднее получается. Если мы возведём в квадрат 1 рубль, то и получим один рубль. А если возведём в квадрат 100 копеек получим 10000 копеек, а это уже 100 рублей!!!

← →
junglecat (2014-05-04 20:37) [2]

а самому не проверить, что-ли?
rmUp, надо полагать

← →
Inovet © (2014-05-04 20:49) [3]

раз
http://delphikingdom.com/asp/viewitem.asp?catalogid=374
два
DecimalRounding_JH1
Хранить всё округлённым до копеек с фиксированной точкой, считать всё в double float, не забывать округлять в нужных местах.

← →
Inovet © (2014-05-04 20:54) [4]

И это
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1217

← →
SergP © (2014-05-04 22:28) [5]

Удалено модератором

← →
SergP © (2014-05-04 22:29) [6]

Удалено модератором

← →
junglecat (2014-05-04 22:51) [7]

Удалено модератором

← →
antonn © (2014-05-04 23:12) [8]

> В последнее время в некоторых торговых сетях вообще производится
> округление в меньшую сторону до рубля.

речь, наверное, о сумме в чеке? наверное округляют вниз до рубля чтобы избавиться от копеек, причем просто "рубят" копейки уже после "обычного" округления перед выводом в чек. А вот по "карточной" оплате вполне может быть что и без округления. Ведь мало в программе работающей с ФР округлить, округлять точно так же должна и БД, например. Потому для покупателя копейки просто отбрасываются

← →
kilkennycat © (2014-05-04 23:24) [9]

Удалено модератором

← →
Германн © (2014-05-05 00:02) [10]

> Label1.Caption:=FloattoStr(RoundTo(a*b,-2));
> Label2.Caption:=FloattoStr(RoundTo(0.211*105.00,-2));
>
> end;
>
> 0.211х105=22.155
> получаем два различающихся итога: 22.15 и 22.16

В первом случае вычисление производятся с типом real, а во втором с типом extended.

← →
junglecat (2014-05-05 00:08) [11]

Удалено модератором

← →
Dimka Maslov © (2014-05-05 10:52) [12]

Удалено модератором

← →
Труп Васи Доброго © (2014-05-05 13:26) [13]

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

← →
Dennis I. Komarov © (2014-05-05 13:53) [14]

> В банках и кассовых аппаратах используется банковское округление,
> а не математическое. В банковском округлении округление
> происходит округление к ближайшему чётному, то есть 2,5
> → 2, 3,5 → 4.
> Соответственно в твоём случае 5,5 округляется до ближайшего
> чётного 6.
> Вот и вся хитрость.

Это откуда такие знания?

← →
Dennis I. Komarov © (2014-05-05 13:59) [15]

> 0.211х105=22.155
> получаем два различающихся итога: 22.15 и 22.16
> итог в ФР= 22.16

Далее div 1 - остаток проводим как скидка. Все довольны...

← →
Труп Васи Доброго © (2014-05-05 14:21) [16]

> Это откуда такие знания?

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

← →
dis12345 © (2014-05-05 15:12) [17]

Всем спасибо! и подсказали, и повеселили :)

← →
antonn © (2014-05-06 12:04) [18]

> Это откуда такие знания?

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

← →
Dennis I. Komarov © (2014-05-07 19:40) [19]

> Труп Васи Доброго © (05.05.14 14:21) [16]

> antonn © (06.05.14 12:04) [18]

Давно?

P.S.
Да я не против что как факт оно есть...

← →
Inovet © (2014-05-07 20:17) [20]

> [19] Dennis I. Komarov © (07.05.14 19:40)

Так применяют, чтобы статистическая ошибка не накапливалась. А где как принято, надо смотреть. В любом случае стандартные функции Делфи будут давать неправильный результат в десятичной системе.

← →
Dennis I. Komarov © (2014-05-07 22:47) [21]

> Inovet © (07.05.14 20:17) [20]
> > [19] Dennis I. Komarov © (07.05.14 19:40)
>
> Так применяют, чтобы статистическая ошибка не накапливалась.
> А где как принято, надо смотреть. В любом случае стандартные
> функции Делфи будут давать неправильный результат в десятичной
> системе.

Приведите факт в настоящем времени

← →
Inovet © (2014-05-07 23:11) [22]

> [21] Dennis I. Komarov © (07.05.14 22:47)

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

← →
Dimka Maslov © (2014-05-07 23:34) [23]

>
> Приведите факт в настоящем времени

В геодезии, например, когда идёт обработка съёмки округление идёт именно в сторону чётной цифры на конце десятичной дроби - чтобы ошибки округления при разгоне погрешности не накапливались

> [23] Dimka Maslov © (07.05.14 23:34)
> В геодезии

Вот в таких применениях при машинной обработке логичней бы было хранить в плавающей точке. Но если на бумаге ведётся обработка, в поле, например, так придётся учитывать.

[23] не понял

> чтобы ошибки округления при разгоне погрешности не накапливались

ведь 200 раз округлили в большую сторону и 10 раз в меньшую, накопили ведь погрешноть, или я не понял ка оно себя уравнивает всреднем...

> [25] brother © (08.05.14 05:38)

При округлениях 5 всегда в большую сторону, ошибка накопится больше, чем при округлениях 5 к чётному.

> Давно?

7 лет назад, при сверке начислений льготникам. А что, с тех пор что-то изменилось? Я так понял в банках это округление применяют, чтобы лишние округлённые деньги не накапливались. У меня таким образом на около 10000 льготниках примерно у 1 - 1,5 тысяч человек результат получался с *,5 коп. А это 1000*0,5коп=5 руб из воздуха. Ну я ,естественно, их в большую сторону округлял, как в школе учили. А при проведении платежей через банк итоговая ведомость отличалась на несколько рублей с копейками. Помню долго я тогда мозг об стену разбивал, копаясь где же ошибка в расчётах, а всё оказалось гораздо проще, при банковском округлении "лишние" добавленные 0,5 копейки на чётных числах компенсируются "отброшенными" 0,5 копейками на нечётных, и на большом количестве операций "накопление" стремится к нулю.

[3] и [10] - деньги - всегда хранить в double

> [28] megavoid © (12.05.14 02:28)
> деньги - всегда хранить в double

И что там нахранится? Просуммируй эти дабл и получишь ошибку.

> деньги - всегда хранить в double

Деньги надо хранить в копейках :)

← →
Дмитрий (2014-05-12 15:57) [31]

Деньги нужно хранить в топорах, запчастях, продуктах и тыды...

> [31] Дмитрий (12.05.14 15:57)
> Деньги нужно хранить в топорах

Такой случай описан у классика.

2 dis12345 © (04.05.14 20:16)
А у вас ФР сам формирует строку?
Если нет, то проще давать ему кол-во = 1, цена = округленная сумма

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