Разная математика в бухгалтерии
by Евгений Викторович Арбатский - Создаем подсистему для отдела закупок и потребовалось подсчитать сумму договора на основе нескольких сумм по группам товаров, входящим в договор. Вроде бы простая задача - сложить 2+2 и получить 4. Но эта простая задача начинает таить интересные моменты, связанные с копейками. Мало того, что JS не совсем корректно всегда производит преобразование parseFloat, так и математика тут может быть чуть другой, о чем разработчикам, а особенно проектировщикам, следует помнить всегда.
Рассмотрим простой пример, представленный на снимке. Там есть два варианта с двумя одинаковыми суммами: 33 тыс. 333 руб. 3 коп. и 2 руб. 44 коп. С бухгалтерской точки зрения сложение этих сумм всегда должно давать одинаковый результат: 33 тыс. 335 руб. 47 коп.
Но если рассматривать с математической точки зрения, то в первом варианте мы получаем 47 копеек, а во втором 74 копейки. И математика тут абсолютно права. Но у пользователя, который будет вводить сумму, может возникнуть паника, так как он не будет понимать из-за чего итоговая сумма не верна, если введет данные как во втором варианте. Тут можно вспомнить о том, что всех в школе учат разнице между 0.3 и 0.03, но в жизни апеллировать к школьным знаниям уже будет поздно, особенно если ошибка в расчетах скажется в многотысячных санкциях. Следовательно интерфейс следует проектировать таким образом, чтобы у пользователя даже не возникло возможности допустить ошибку.

Рассмотрим простой пример, представленный на снимке. Там есть два варианта с двумя одинаковыми суммами: 33 тыс. 333 руб. 3 коп. и 2 руб. 44 коп. С бухгалтерской точки зрения сложение этих сумм всегда должно давать одинаковый результат: 33 тыс. 335 руб. 47 коп.
Но если рассматривать с математической точки зрения, то в первом варианте мы получаем 47 копеек, а во втором 74 копейки. И математика тут абсолютно права. Но у пользователя, который будет вводить сумму, может возникнуть паника, так как он не будет понимать из-за чего итоговая сумма не верна, если введет данные как во втором варианте. Тут можно вспомнить о том, что всех в школе учат разнице между 0.3 и 0.03, но в жизни апеллировать к школьным знаниям уже будет поздно, особенно если ошибка в расчетах скажется в многотысячных санкциях. Следовательно интерфейс следует проектировать таким образом, чтобы у пользователя даже не возникло возможности допустить ошибку.

SQL и деньги
by Евгений Викторович Арбатский - Первоначально для хранения сумм использовали тип данных FLOAT. Но перед дальнейшей разработкой отчетов решили провести тестирование того, насколько этот тип данных подходит для хранения информации о финансовых суммах (Изначально, у меня было заблуждение что данные числа будут храниться в том виде, как я их занесу. И это заблуждение не опровергалось на простых небольших числах). Дипломница провела тестирование и получила следующие результаты:
Корректно:
1 коп. - 0.01
1 р. - 1
99 коп. - 0.99
1 р. 99 коп. - 1.99
9`999 р. 99 коп.- 9999.99
Не корректно:
10`000 р. 99 коп. - 10`001
99`999 р. 99 коп. - 100`000
1`000`000 р. 99 коп. - 1e+006
99`000`000р. 99 коп. - 9.9e+007
После этого пришлось садиться за документацию по MySQL и читать ее в очередной раз - в результате выяснил что для чисел, где требуется точность, надо использовать DECIMAL (например, DECIMAL(10,2)).
Что ж - век живи - век учись. Всю же документацию по каждой СУБД пока проблематично прочитать :)
P.S. При работе с MS SQL за последние пять лет не заметил такой проблемы, но анализ документации по MS SQL показал что и там такая ситуация может быть.
Корректно:
1 коп. - 0.01
1 р. - 1
99 коп. - 0.99
1 р. 99 коп. - 1.99
9`999 р. 99 коп.- 9999.99
Не корректно:
10`000 р. 99 коп. - 10`001
99`999 р. 99 коп. - 100`000
1`000`000 р. 99 коп. - 1e+006
99`000`000р. 99 коп. - 9.9e+007
После этого пришлось садиться за документацию по MySQL и читать ее в очередной раз - в результате выяснил что для чисел, где требуется точность, надо использовать DECIMAL (например, DECIMAL(10,2)).
Что ж - век живи - век учись. Всю же документацию по каждой СУБД пока проблематично прочитать :)
P.S. При работе с MS SQL за последние пять лет не заметил такой проблемы, но анализ документации по MS SQL показал что и там такая ситуация может быть.
Re: Разная математика в бухгалтерии
by Евгений Викторович Арбатский - Сегодня оформлял бумаги по отпуску и обнаружил что на железнодорожных билетах присутствует вышеуказанная проблема с суммами. В стоимости билета было указано: 2704,6 руб. И не было никакой ясности что значит 6 - 60 или 06 копеек.
P.S. Судя по чеку это 60 копеек.
P.S. Судя по чеку это 60 копеек.