Neste tópico explicarei sobre o porque algumas vezes ocorrem diferenças de arredondamento quando você faz desconto ou acréscimo nas vendas.
O vídeo acima explica isso de forma mais ilustrativa, mas procurarei resumir essa explicação, que é um pouco técnica.
Para começar, vamos tomar uma venda como a dessa imagem como exemplo:
Nessa venda temos 5 produtos com valores variados e um total de R$ 116,00. Ignore o nome do produto, é apenas uma simulação.
Agora vamos imaginar que você quer dar um desconto de R$ 16,00, para o cliente pagar R$ 100,00 redondo. Olha o que acontece:
O desconto acaba indo para R$ 16,01, e o total da venda para R$ 99,99. Particularmente não acho um problema, mas algumas pessoas podem ser mais críticas quanto a isso. Porém existe um motivo para esse arredondamento.
Para começar, veja essa imagem:
Essa é uma consulta SQL, feita direto sobre o banco de dados, sobre essa venda em questão. Temos na primeira coluna a quantidade vendida, depois o valor unitário, o desconto que foi salvo no banco de dados, e um "desconto arredondado", com duas casas decimais. A terceira coluna, que mostra 6 casas decimais, representa como o desconto de cada produto realmente foi salvo. As frações vem do rateio que o sistema fez quando você coloca R$ 16,00 de desconto nessa venda especifica.
O problema aqui é o seguinte: ao emitir uma nota fiscal eletrônica da venda, devido a restrições técnicas do próprio modelo, ela só aceita valores com até duas casas decimais para os descontos. É por isso que criei uma quarta coluna na consulta acima, na qual você enxerga como vai ficar esse desconto na nota emitida, onde você já nota diferenças. E veja essa imagem:
Essa é a soma das duas colunas. Percebeu o problema? Na soma bruta, do que realmente está gravado no banco de dados, o desconto fica em R$ 15,999996, uma diferença de arredondamento aceitável, que na tela você até veria como R$ 16,00. Porém quando é somado o desconto arredondado, é aí que chegamos a R$ 16,01, o valor que apareceu na venda.
Os itens não são salvos arredondados no banco de dados porque não há necessidade, já que eles serão arredondados direto na nota quando ela for gerada. Porém o total não podemos ignorar, pois ele vai dar uma diferença, que vai afetar o valor da forma de pagamento, e vai gerar rejeição por parte da Sefaz.
Mesmo que eventualmente você não emita nota eletrônica em nosso sistema, há pessoas que emitem, então ele tem que estar preparado para transformar a venda em nota de forma automática, sem gerar erros ou rejeições no processo.
Nesse caso, sobram apenas 3 opções: aceitar o valor calculado, alterar um a um os itens para fazer o cálculo bater com o que você deseja, ou, em vez do desconto sobre o total da venda, altere apenas um produto e coloque o desconto todo nele, ou em mais de um se o valor dele não cubrir o desconto.