Начну без прелюдий - когда сравниваются числа float (в любой системе или языке) в общем случае это делается с учетом погрешности вычислений. Вот нас в 90-е года в Университетах учили делать так:
if(abs($summ - $summ2) < 0.1){
// Суммы равны в учетом погрешности
}Ну и второе - когда рассчитываются общие суммы тоже нужно следить за погрешностью вычислений. Например, сумма округленных значений это далеко не одно и то же, что округление общей суммы:
SELECT ROUND(SUM(summ), 2) as summ1,
SUM(ROUND(summ, 2)) as summ2
FROM ...Особенно критично проблема проявляется в больших системах учета - нужно быть архи-внимательными с подобными расчетами. На больших цифрах и немалом количестве операций такие неточности достаточно сложно отлавливаются. Кроме того, в разных системах/языках принципы расчета float чисел может быть разным. Конечно, программисты с опытом знают о подобных вещах, но новички могут посчитать сумму на примере двух строк и думать, что "дело в шляпе". И будет хорошо, если проблема найдется раньше чем упадет ракета, взорвется АЭС или у кого-то по этой причине будут проблемы с надзорными органами..
Также есть большие вопросы к руководителям - если в вашей системе есть подобные вычисления, а качество подобных вычислений ведет к серьезным последствиям, то ваш профессиональный долг это предусмотреть и если невозможно решить, то максимально нивелировать возможные проблемы.
Ну, а теперь к главному - причем здесь налоговая, спросите вы? Вот два свежих скрина:
Может быть, конечно, я ошибаюсь в причинах произошедшего.. И, надеюсь, 1 апреля - это просто так случайно совпало :-)
