Известна

Ошибка округления при расчёте суммы

Версия для Android.

Предположим у меня есть рублёвый счёт и я покупаю 775 грамм сосисок (количество 0.775) по цене 425 рублей за килограмм. Я последовательно ввожу цену, количество и автоматом получаю сумму. С виду сумма рассчитается правильно 329.38 (как раз с учётом округления до копеек).

Однако, в остатке на счёте я вижу лишнюю копейку!

Откуда? Ответ прост: хотя точность для рублей стоит 2 и в сумме вроде бы стоит 329.38, однако, нажав на калькулятор рядом с суммой я увижу, что реально в этом поле стоит 329.375 (т.е. в проводку идёт не округлённая сумма, а автоматически рассчитанная по паре цена+количество). Эта сумма и будет вычитаться из остатка по счёту, который тоже будет визуально округлён до 2-х знаков.

Пришлось для исправления ситуации записать себе в налог пол копейки.

Комментировать

Комментарии (5)

фото
1

p.s. И это грубая ошибка, как бы ни лень было её править (говорю, как человек, занятый разработкой банковского ПО последние 20 лет). На счетах в принципе не может быть не округлённого остатка, иначе тупо не сойдётся баланс. По-этому, округлять необходимо в любом случае, иначе, не видно, какой мусор лежит в остатке.

n.b. И способов избежать этой ошибки не ноль: от ведения сумм в целых числах с последующим делением на 10^"точность округления", до использования специальных типов на уровне БД.

фото
1

Поймите меня правильно, программа замечательная!

Но когда все транзакции умещаются на экране и их общая сумма не совпадает с "итого", это выглядит несколько ... обескураживающе.

фото
1

Это побочный эффект возможности легко сменить количество знаков после запятой у валюты.

фото
1

Спасибо за ответ :-)

Честно говоря, аргумент не сильный. У большинства валют количество знаков не меняется, тем более задним числом. Можно было бы итоговую сумму транзакции округлять. А то получается, что точность округления есть, но она работает не самым очевидным образом.

Впрочем, для округления я обхожусь налогами/скидками, а реальные скидки отражаю отдельной строкой в чеке. Что, конечно, не очень удобно.

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

фото
фото
1

В каких-то транзакциях есть доли копейки. При сложении они образовали лишнюю копейку.