"Как правильно" - насколько я знаю, никаких нормативных документов и предписаний, как бороться с ошибками округления для целей учета и отражения в документах, не существует. За исключением ссылок на то, что при заполнении отчетных форм в ГНИ применяются правила арифметического округления. Каждый борется с ними как может и как умеет. По приведенной Вами формуле могу лишь заметить, что для любых случаев, когда цена будет составлять меньше 0.59 копеек (по крайней мере, теоретически такое может быть - отгрузка 100000000 миллиграмм муки, например, по цене 0.40 копеек за миллиграмм :) ) Вы получите на выход сумму, равную абсолютному нулю, даже если отгрузили муки целый железнодорожный состав...

Наличие округлений после каждой арифметической операции, по идее, приводит к накоплению ошибки и увеличивает ее. Самый надежный способ избегания ошибок округления - это подгонка цены таким образом, чтобы ошибок округления вообще не возникало. Когда НДС был 20%, мы делали цену с НДС кратной 6 (а без НДС кратной 5) - и накаких ошибок округления у нас вообще не было. Для НДС 18% уже сложнее - цена без НДС должна быть кратна 50, а с НДС - 59 (выраженная в копейках).

ПМСМ, какого-то другого универсального способа нет. Если ошибки округления имеют место, то в любом случае будет иметься вероятность ошибки либо при расчете слева-направо, либо справа-налево (если Вы не добились кратности цены указанным значениям). То есть, либо при расчете цены через сумму и количество, либо при расчете суммы через цену и количество (а когда добавляется умножение или деление на 18% вероятность ошибки возрастает. Аналогично происходит с "подбиванием итогов" по многостраничному документу. Если в документе N строк, то максимально возможная ошибка в результате накопления ошибки округления составляет 0,5 копейки * N. Для больших N (для большого числа строк) накопление ошибки может быть весьма существенным. Что делать, чтобы их не было? Нужно, чтобы складываемые числа изначально не имели "хвостов" в долях копеек. Эта проблема также лечится опять же заданием кратности цены. Если же кратности цены нет, у Вас будут все основания опасаться получить либо документ, в котором наблюдаемые визуально суммы (с невидимыми долями копеек) при их сложении на калькуляторе не совпадают с наблюдаемой визуально итоговой суммой. Если "вылечить" эту проблему предварительным округлением всех сумм в каждой строке документа, Вы можете сильно удивиться, обнаружив, что сумма полученного в итоговой строке НДС от итоговой же суммы составляет уже не 18%, а несколько иной процент...

Если в собственных документах с ценой и количеством можно бороться с данной проблемой заданием кратности собственных цен, то как бороться с ошибками округления в документах другого рода, не совсем понятно. Например, в бухгалтерском балансе, где нет ни цен, ни количеств, а все суммы округляются до тысячи рублей. Ошибки округлений в активе и в пасиве баланса могут привести к тому, что итоговые цифры просто не сойдутся. Как обычно поступают в таких случаях - либо игнорируют незначительные расхождения, либо подгоняют руками... :)

Ни то, ни другое - ненаказуемо. См, например, выдержку из Постановления Арбитражного суда Липецкой области от 30 сентября 2005 г. N А36-2039/2005:
авторУказание в решении налогового органа суммы 16610 руб. связано с округлением суммы 16609,83 руб. до целого числа. Указанная операция не противоречит действующему законодательству. Данная погрешность составляет 17 коп. и является незначительной.
Внесение налоговым органом изменений в обжалуемое решение вызвано технической ошибкой и не повлекло изменение его содержания.
Налоговый кодекс не содержит запрета на внесение изменений и дополнений в принятые им решения, тем более, в результате внесения указанных изменений произошло уменьшение суммы неуплаченного налога, подлежащего уплате.

По опыту могу сказать, что ГНИ к копеечным расхождениям, даже если они выходят за пределы, обяснимые ошибками округления, обычно не цепляются. У них другая задача - им нужно нарыть СУММИЩИ штрафов, копеечные суммы их обычно не устраивают, и им возиться с мотивацией по копеечным суммам дороже себе выйдет... Слишком низкий КПД.

GaryaСамый надежный способ избегания ошибок округления - это подгонка цены таким образом, чтобы ошибок округления вообще не возникало. Когда НДС был 20%, мы делали цену с НДС кратной 6 (а без НДС кратной 5) - и накаких ошибок округления у нас вообще не было. Для НДС 18% уже сложнее - цена без НДС должна быть кратна 50, а с НДС - 59 (выраженная в копейках).Это САМЫЙ-РАССАМЫЙ надежный способ! Надежнее просто не придумаете!

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

Для варианта, когда исходной считается цена БЕЗ НДС:
[Цена без НДС окончательная]=((int(([цена без НДС предварительная] + 0.25) *100) div 50) *50) / 100 - окончательная цена без НДС получается кратной 50 копейкам
[Цена с НДС] = [Цена без НДС окончательная] * 1.18 - round() ставить нет необходимости, потому что никаких ошибок округления уже в принципе быть не может.
[Сумма без НДС] = [Количество] * [Цена без НДС окончательная] - для целочисленного количества (у нас вся продукция измеряется в штуках) никаких ошибок округления в принципе быть не может.
[Сумма с НДС] = [Количество] * [Цена с НДС] - аналогично для целочисленного количества

Для варианта, когда исходной ценой считается цена С НДС:
[Цена c НДС окончательная]=((int(([цена c НДС предварительная] + 0.3)*100) div 59) *59) / 100 - окончательная цена с НДС получается кратной 59 копейкам
[Цена без НДС] = [Цена с НДС] / 1.18 - round() ставить нет необходимости, потому что никаких ошибок округления уже в принципе быть не может.
[Сумма без НДС] = [Количество] * [Цена без НДС окончательная] - для целочисленного количества (у нас вся продукция измеряется в штуках) никаких ошибок округления в принципе быть не может.
[Сумма с НДС] = [Количество] * [Цена с НДС] - аналогично для целочисленного количества

Разумеется, необходимо учитывать неявные преобразования типов, чтобы не попасть впросак и не получить ошибки округления там, где их уже быть не должно. Там, где умножается и делится на 1.18, необходимо явно преобразовывать его в число с фиксированной точкой. Либо заменить эту операцию на комбинацию, использующего целочисленное деление и умножение с соответствующим масшабированием.

P.S. "+ 0.25" и "+ 0.3" используются для того, чтобы цена "округлялась" до ближайшего кратного 50 или 59 копейкам, а не просто усекалась до меньшего кратного.

Guest_12345А что такое: "у нас вся продукция измеряется в штуках"? Это мы приходим в магазин и говорим: "Дайте нам две штуки колбасы и одну штуку сыра. А горячего - одну куру-гриль". И вам дают? А почему у нас такого нет, чтобы решить проблемы с копейкой повсеместно?

Нет, это не решение проблемы, это решение ее части.Согласен, что для общего случая она не всегда подходит, для колбасы, например, такой вариант не годится. Но мы производим насосы, двигатели, запчасти и т.п. И они всегда измеряются в штуках. В глубокой древности мы торговали еще и кабельной продукцией, которая в чем только ни измерялась (в метрах, и в килограммах, и а бухтах), но, слава богу, это для нас уже не актуально... :)