Бухгалтерия

Расчет НДС. Обратным счетом, т.е. дается сумма с НДС, а дальше рассчитывается НДС и сумма без НДС. Ставка НДС - 18%.
И что бы вы думали? Ставки для расчета две!

Первая: 18/118. Именно так - бесконечная периодическая дробь. С учетом потенциально больших сумм для хранения этой ставки типа currency не хватает (money, итд, итп - тип с фиксированной точкой и 4 знаками после запятой). Т.е. надо считать именно так как указано - умножать на 18 и делить на 100+18.

Вторая: 15.25%, т.е. округленная до двух знаков после запятой та же ставка в процентах. C учетом того, что скорее всего эта сумма вводится с множества готовых документов с разными суммами - реальная ставка для итоговых сумм будет колебаться около заданной.

Про правила округления налогов в случае, когда одна сумма и налог с нее суммируются из тысяч других из документов с уже посчитанными налогами, я не слышал. Суть такая: налоговая хочет проверить сумму, умножив ставку на налоговую базу. Но дело в том, что из-за ранее проведенного округления в документах сумма будет отклонятся от проверочной. Любой способ - показать сумму налогов или рассчитать налог заново - вызывает вопросы у налоговой: 1) почему не проверяется сумма 2)почему сумма налогов по документам не равна итоговой.

Отдельная история с выбором метода округления .5 - к ближайшему целому или ближайшему четному. Правильный способ - второй. Но в школе учили первому и поэтому у всех едет крыша.

Еще есть такая хреновина, как книга покупок, особенно в случае, если один товар или услуга оплачивается несколькими платежками. Возникает разбиение первичного документа - накладной на несколько записей в книге покупок. Опять возникает вопрос с разбиением налогов и округлением. Да еще если в разных отчетных периодах.

Реально вся эта дрянь лечится только вводом ручной коррекции сумм налогов в итоговых документах в пределах ошибки и перекидыванием всей ответственности на конечного пользователя - пусть ставит как ему надо и сам разбирается с остальными инстанциями.

Вот такую смерть приходится делать.