![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
округление-потеря копейки [D7, XP]
dis12345 © (2014-05-04 20:16:00)Здравствуйте!
При вычислении стоимости, умножая количество=вес на цену, получаем значение. При передаче цены и количества в фискальный регистратор, получаем подитог, отличающийся от вычисленного в 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 подскажите плиз
Труп Васи Доброго (2014-05-05 13:26:00) [21]В банках и кассовых аппаратах используется банковское округление, а не математическое. В банковском округлении округление происходит округление к ближайшему чётному, то есть 2,5 → 2, 3,5 → 4.
Соответственно в твоём случае 5,5 округляется до ближайшего чётного 6.
Вот и вся хитрость.
Dimka Maslov (2014-05-05 10:52:00) [22]Удалено модератором
junglecat (2014-05-05 00:08:00) [23]Удалено модератором
Германн (2014-05-05 00:02:00) [24]
> 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.
kilkennycat (2014-05-04 23:24:00) [25]Удалено модератором
antonn (2014-05-04 23:12:00) [26]
> В последнее время в некоторых торговых сетях вообще производится
> округление в меньшую сторону до рубля.
речь, наверное, о сумме в чеке? наверное округляют вниз до рубля чтобы избавиться от копеек, причем просто "рубят" копейки уже после "обычного" округления перед выводом в чек. А вот по "карточной" оплате вполне может быть что и без округления. Ведь мало в программе работающей с ФР округлить, округлять точно так же должна и БД, например. Потому для покупателя копейки просто отбрасываются
junglecat (2014-05-04 22:51:00) [27]Удалено модератором
SergP (2014-05-04 22:29:00) [28]Удалено модератором
SergP (2014-05-04 22:28:00) [29]Удалено модератором
Inovet (2014-05-04 20:54:00) [30]И это
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1217
Inovet (2014-05-04 20:49:00) [31]раз
http://delphikingdom.com/asp/viewitem.asp?catalogid=374
два
DecimalRounding_JH1
Хранить всё округлённым до копеек с фиксированной точкой, считать всё в double float, не забывать округлять в нужных местах.
junglecat (2014-05-04 20:37:00) [32]а самому не проверить, что-ли?
rmUp, надо полагать
Dimka Maslov (2014-05-04 20:34:00) [33]В последнее время в некоторых торговых сетях вообще производится округление в меньшую сторону до рубля.
А вообще есть тип Currency (c фиксированной точкой) введённый специально для уменьшения ошибок округления в финансовых расчётах. Он может спасти ОРД.
Кроме того, можно считать всё в копейках. Это даже выгоднее получается. Если мы возведём в квадрат 1 рубль, то и получим один рубль. А если возведём в квадрат 100 копеек получим 10000 копеек, а это уже 100 рублей!!!