Здравствуйте, pagid,
P> Нет. Налоговую подобные вещи никогда не интересовали.
А вот и да Как раз лет этак 10-15 назад я был весьма плотно связан с бухгалтерским программированием. Так что реальный опыт говорит "все должно быть точно до копеечки".
Еще в те времена я сделал для себя два вывода: 1) все бухгалтерские расчеты нужно вести в целочисленных МДЕ — минимальных денехных единицах, сейчас это копейка, и 2) ТЗ на любые действия, связанные с округлением сумм (математическим или бухгалтерским — без разницы) должно быть подписано ответственным за это бухгалтером. Мое дело — точно реализовать, а с бухгалтерией пусть раз(бираются) бухгалтеры, которые за это деньги получают.
Здравствуйте, Vlad_SP, Вы писали:
P>> Нет. Налоговую подобные вещи никогда не интересовали.
V_S>А вот и да Как раз лет этак 10-15 назад я был весьма плотно связан с бухгалтерским программированием. Так что реальный опыт говорит "все должно быть точно до копеечки". V_S>Еще в те времена я сделал для себя два вывода: 1) все бухгалтерские расчеты нужно вести в целочисленных МДЕ — минимальных денехных единицах, сейчас это копейка, и 2) ТЗ на любые действия, связанные с округлением сумм (математическим или бухгалтерским — без разницы) должно быть подписано ответственным за это бухгалтером. Мое дело — точно реализовать, а с бухгалтерией пусть раз(бираются) бухгалтеры, которые за это деньги получают.
Еще, помнится, была заморочка этого же рода — посчитать сумму НДС за день, так, чтобы она совпадала с данными Z-отчета фискального регистратора. И свести нужно было, вот именно, "в копеечку" Хорошо еще был под рукой нефискализированный девайс, на котором можно было тестироваться. Иначе, я даже не представляю, как бы я решал эту задачу. Это был год 2002-2003, что там сейчас в торговле происходит, понятия не имею.
Здравствуйте, pagid, Вы писали:
K>>Да, оно имеет природу вещественного числа. Но числа с плавающей точкой — это всего лишь один из вариантов представления вещественных чисел. Особенность этого варианта представления в том, что погрешность зависит от величины числа. P>У чисел с фиксированной точкой (с дробной частью) точно так же зависит. И в целом для дробных чисел (если для целых не рассматривать переполнение) с ограниченной разрядностью зависит.
Совсем не точно так же
K>>У этого представления есть свои плюсы и минусы. Но для финансов тут больше минусов чем плюсов. P>В целом да, но можно же рассмотреть вариант двоично-десятичного представления чисел, пусть с плавающей точкой. Часть минусов (именно для денежных расчетов) уйдет. Но насколько оно нужно и чем лучше по сравнению с целыми копейками
Именно BCD чем лучше?
K>>могут отрезать и 0.3 метра, а могут отрезать 1000.3 метра. Вроде все отлично выглядит, но точность у этих чисел разная. И когда мы домножим это на цену, в определенных случаях может получиться, что стоимость у нас уже округляется не до копеек, а до десятков рублей. P>Да без разницы. Когда продаешь 0.3 метра важно округление до копеек, а когда столько метров, что стоимость округлится до десятков рублей, эти десятки никого парить не будут.
Эти десятки будут парить бухгалира, у которого дебе с кредитом не будут сходится.
ЗЫ вроде как общепринято в финансах, что при хранении и расчетах используют сотые доли копеек, не?
Здравствуйте, pagid, Вы писали:
V_S>>Ага. Никого, кроме налогового инспектора, который в непредсказуемый момент доначислит конторе недоуплаченные налоги, пени и штрафы. Знаем, плавали-с.... P>Нет. Налоговую подобные вещи никогда не интересовали.
Сразу видно человека, который никогда ничего не писал для бухгалтерии
_>>получаю снова 1107.08997. Подскажите пожалуйста народ кто знает как просто перевести сумму в копейках в сумму в рублях как в данном примере 110709 коп.= 1107.09 руб. ?
Pzz>Раз уж изначальная сумма целочисленная, я бы работал в fixed point, и округлял бы руками, что позволило бы мне контролировать алгоритм округления.
Для округления денег есть т.н. банковское округление
Здравствуйте, Vlad_SP, Вы писали: V_S>А вот и да Как раз лет этак 10-15 назад я был весьма плотно связан с бухгалтерским программированием. Так что реальный опыт говорит "все должно быть точно до копеечки". V_S>Еще в те времена я сделал для себя два вывода: 1) все бухгалтерские расчеты нужно вести в целочисленных МДЕ — минимальных денехных единицах, сейчас это копейка, и 2) ТЗ на любые действия, связанные с округлением сумм (математическим или бухгалтерским — без разницы) должно быть подписано ответственным за это бухгалтером. Мое дело — точно реализовать, а с бухгалтерией пусть раз(бираются) бухгалтеры, которые за это деньги получают.
К сожалению, довольно часто попадаются бухгалтеры которые не понимают простейших вещей про округление.
Например, табличка из сумм с копейками.
Некоторые бухгалтеры считают, что если вычислять подитоги по столбцам или строкам таблички с округлением до рублей, то сумма таких подитогов должна совпадать.
И другие эффекты, связанные с двойным округлением, порой вводят их в ступор.
Здравствуйте, qaz77, Вы писали:
Q>К сожалению, довольно часто попадаются бухгалтеры которые не понимают простейших вещей про округление.
Че-то вспомнилось сейчас, как главбух заглянула к нам в комнатушку, калькулятор ей срочно понадобился зачем-то. Ее финальная фраза отпечаталась навсегда в моей памяти: "что вы за программисты, что у вас даже калькулятора нету". С этим может сравниться, разве что, широко известное изречение военного: "если программисты такие умные, почему они строем не ходят".
Здравствуйте, Vlad_SP, Вы писали:
V_S>А вот и да Как раз лет этак 10-15 назад я был весьма плотно связан с бухгалтерским программированием. Так что реальный опыт говорит "все должно быть точно до копеечки".
В бухучете все должно быть до копеечки, это верно. Но при этом для бухгалтерии без разницы продали 1000.01м проволоки при цене 5 рублей метр за 5000 руб. 05 коп. или ровно за 5000 руб. Просто остаток на складе должен уменьшиться на 1000.01м (если конечно измерение с такой точностью возможно и нужно), а долг покупателя увеличится на 5000 руб. 05 коп. или на 5000 руб. в зависимости от того какая сумма указана в накладной.
Налоговую в отношении всего этого может заинтересовать лишь то, чтобы итоговая цена продаж (с учетом скидок) не была ниже цены за которую проволоку покупали, причем не разово, а систематически.
Здравствуйте, Marty, Вы писали:
M>Именно BCD чем лучше?
По сравнению с float/double?
M>Эти десятки будут парить бухгалира, у которого дебе с кредитом не будут сходится.
Не может не сойтись, и в дебет и кредит попала одна сумма. А количества и цены там не было.
M>ЗЫ вроде как общепринято в финансах, что при хранении и расчетах используют сотые доли копеек, не?
Нет. Как раз при этом при этом и могут появится интересные эффекты с потерей и появлением копеек. Все должно быть точно в копейках.
Здравствуйте, Marty, Вы писали:
M>Для округления денег есть т.н. банковское округление
Нет. Оно совершенно не нужно и не решает проблем обсуждаемых здесь. Но в общем-то никого не парит, если кто-то использует банковское округление, и оно кроме легкого нечастого недоумения контрагентов тоже проблем не вызовет.
Здравствуйте, rg45, Вы писали:
R>Еще, помнится, была заморочка этого же рода — посчитать сумму НДС за день, так, чтобы она совпадала с данными Z-отчета фискального регистратора.
А в чем проблема? В регистраторе считаться НДС конечно должен "построчно", а не на всю сумму чека, и округлятся должен по одним правилам. Больше вроде никаких проблем быть не должно.
Здравствуйте, pagid, Вы писали:
R>>Еще, помнится, была заморочка этого же рода — посчитать сумму НДС за день, так, чтобы она совпадала с данными Z-отчета фискального регистратора. P>А в чем проблема? В регистраторе считаться НДС конечно должен "построчно", а не на всю сумму чека, и округлятся должен по одним правилам. Больше вроде никаких проблем быть не должно.
Мне тоже так казалось. По факту оказалось все сложнее. И сумма по позициям не сходилась с итогом за день.
Здравствуйте, rg45, Вы писали:
R>Мне тоже так казалось. По факту оказалось все сложнее. И сумма по позициям не сходилась с итогом за день.
Может ты применял банковское округление?
Здравствуйте, pagid, Вы писали:
R>>Мне тоже так казалось. По факту оказалось все сложнее. И сумма по позициям не сходилась с итогом за день.
P> P>Может ты применял банковское округление?
Мне сейчас уже трудно вспомнить детали. Я помню только, что мне потребовалость достаточно много времени на эксперименты, чтобы постичь систему и все нюансы. Задачу решить удалось в итоге, но результаты, выдаваемые регистратором, не раз меня озадачивали.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text.RegularExpressions;
namespace Rextester
{
public class Program
{
public static void Main(string[] args)
{
//Your code goes here
Console.WriteLine("Hello, world!");
double val = 110709;
Console.WriteLine(round_up(val));
}
public static decimal round_up(double val)
{
decimal val2 = Convert.ToDecimal(val);
return val2/100;
}
}
}
Здравствуйте, _agg, Вы писали:
_>Всем привет, уткнулся в простейшую задачу есть сумма в копейках 110709, нужно сделать из нее рубли, чего проще то поделил на 100 и ок, но нет при делении получаем 1107.08997, читал интернет всякие варианты пробовал в том числе:
FIXED DECIMAL в этом случае так себе вариант. decimal упомянутый выше куда как аккуратнее. К тому же, перейти на C# при не некоторой наглости можно посоветовать, но советовать переходить на PL/1 как-то странно.
Если ближе к делу, то перейдя на FIXED DECIMAL никаких особых преимуществ перед использованием целых копеек не получим.
Здравствуйте, qaz77, Вы писали:
Q>Здравствуйте, ksandro, Вы писали: K>>Можно тогда, например, хранить в долях копеек. Можно написать свой класс для десятичного числа с фиксированной, но изменяемой точностью, ну или заюзать какое-нибудь готовое решение. K>>Вообще использование чисел с плавающей точкой для хранения цен и вообще в финансовых расчетах это абсолютное зло. Тут проблема именно в том, что точка плавающая и проконтролировать, куда она уплывет во время эксплуатации системы в продакшене невозможно. Пока у тебя 1 погонный метр, то все нормально, но потом кому-то понадобится подсчитать сколько стоит 100500 погонных метров, и вдруг выяснится, что что-то где-то не сходится. K>>Поэтому надо всеми правдами и неправдами стараться избежать использование любых чисел плавающей точкой в финансах.
Q>В целом, я согласен. Q>Но количество, если это не штуки или коробки, все равно имеет природу вещественного числа. Q>Например, могут отрезать 13.3 метра проволоки.
Не вещественного, а числа с фиксированной точкой.
Q>Чтобы подсчитать сумму, цену надо умножать на вещественное количество, тут будет уместно округление суммы до копеек. Q>Хранение сумм получается в целых копейках, а цен — в double. Я считаю, что так допустимо.
Храни все в decimal.
Как раз лет этак 10-15 назад я был весьма плотно связан с бухгалтерским программированием. Так что реальный опыт говорит "все должно быть точно до копеечки".
