"Как правильно" - насколько я знаю, никаких нормативных документов и предписаний, как бороться с ошибками округления для целей учета и отражения в документах, не существует. За исключением ссылок на то, что при заполнении отчетных форм в ГНИ применяются правила арифметического округления. Каждый борется с ними как может и как умеет. По приведенной Вами формуле могу лишь заметить, что для любых случаев, когда цена будет составлять меньше 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 копейкам, а не просто усекалась до меньшего кратного.