ZeusAutomacao / DFe.NET

Biblioteca para Geração de NFe(2.0, 3.10 e 4.0) e NFCe(3.10 e 4.0) e consumo dos serviços necessários à sua manutenção, conforme descritos em http://www.nfe.fazenda.gov.br/portal/principal.aspx
GNU Lesser General Public License v2.1
754 stars 477 forks source link

Truncar valores da Nfe #536

Closed renanaragao closed 6 years ago

renanaragao commented 7 years ago

Boa tarde, Estava verificando e o Zeus sempre arredonda os valores da Nfe. Gostaria de saber por que arredondar e não truncar já que ECF trunca?

robertorp commented 7 years ago

Isso foi pensado por min já. Como estou sem tempo não esquentei com isso, mas se você quiser bolar uma maneira de fazer isso acredito que seria de grande valia. Obrigado.

Irei adicionar como melhoria se alguém surgir para implementar

marcosgerene commented 7 years ago

@renanaragao e @robertorp acredito que este tipo de tratamento deve ser feito pelo ERP e não pelo componente, o componente deve basicamente gerar o arquivo xml e consumir o webservice, caso contrário você perde o foco e cada novidade como uma NFe 4.0 ou uma NT qualquer transforma o projeto em um "Frankstein".

A ideias do motor tributário do Roberto é excelente e só é excelente pois não está anexada ao projeto, lá trata-se de calculos, aqui trata-se de gerar os arquivos no layout exigido e enviar ao Sefaz

renanaragao commented 7 years ago

Mas o Zeus hj arredonda os valores, meu fiscal precisa que ele seja truncado. Seguindo sua lógica, o Zeus não deveria fazer nenhuma manipulação dos valores.

robertorp commented 7 years ago

@marcosgerene Realmente, concordo. Mas hoje você concorda que retirar esse arredonda é perigoso quebrar muitas aplicações por ai ? Quando digo quebrar, uma pessoa simplesmente atualiza o nuget e arrebenta as aplicações com erro de schema , então é algo delicado a se tratar. Alguma ideia?

renanaragao commented 7 years ago

Como essa característica do Zeus está me travando, me disponho a fazer as modificações.

alexmurari commented 7 years ago

@robertorp Esta é uma breaking change que eventualmente terá que ser tomada. A solução para este caso hoje seria uma opção (parâmetro/configuração) para dizer qual tipo de arredondamento seria usado, porém isso entra no caso de manipulação de dados em um projeto que deveria ser read-only apenas.

Minha sugestão é incrementar a versão major do projeto, indicando que houve uma breaking change e retirar completamente o tratamento de valores numéricos e informar no changelog/readme esta alteração, desta forma aqueles que forem atualizar serão notificados.

Aliás, acredito que quase ninguém esteja dependendo ou tenha conhecimento que este projeto já arredonda valores, provavelmente a maioria já passa o valor tratado.

marcosgerene commented 7 years ago

A resposta do @MurariAlex representa minha opinião.

@robertorp Esta é uma breaking change que eventualmente terá que ser tomada. A solução para este caso hoje seria uma opção (parâmetro/configuração) para dizer qual tipo de arredondamento seria usado, porém isso entra no caso de manipulação de dados em um projeto que deveria ser read-only apenas.

Minha sugestão é incrementar a versão major do projeto, indicando que houve uma breaking change e retirar completamente o tratamento de valores numéricos e informar no changelog/readme esta alteração, desta forma aqueles que forem atualizar serão notificados.

Aliás, acredito que quase ninguém esteja dependendo ou tenha conhecimento que este projeto já arredonda valores, provavelmente a maioria já passa o valor tratado.

@renanaragao na minha ótica não deveria existir nenhum tratamento, os valores deveriam ser passados de forma "pura" como o ERP passou, os tratamentos devem ser feitos pelo ERP e não pelo componente, exatamente para não ter casos igual o seu de truncamento, ou algum caso de alguém que quer que sempre arredonde pra cima (ex: 16,214 = 16,22 ja vi casos assim).

rftd commented 7 years ago

Senão me engano segundo a receita federal o certo é arrendondar de acordo com as normas ABNT, o .net não faz assim. Obs.: as ECF não truncam só em postos de combustiveis.

robertorp commented 7 years ago

o .net não faz assim.

certeza? fiz varias comparações. (mas isso dentro da minha aplicação e não esta diferente , usamos decima.round..) Pode postar um exemplo @rftd de os valores não bateriam com a abnt

rftd commented 7 years ago

Rapaz de cabeça não lembro não mas tem casos que não bate agora teria que pesquisar.

robertorp commented 7 years ago

Bom, definido que vou procurar nas NT/Manual o local onde fala oque o @rftd falou ai posto a pagina e tudo mais. Se realmente tiver como arredonda, então não tem problemas deixar. Mas com certeza em um momento oportuno vou retirar o mesmo, so não é agora.

edit: logico alguém pode retirar ele e fazer um pull lindão =D

orochasamuel commented 7 years ago

Talvez a NT 2013/005 ajude.

Em 26/09/2017 19:07, "Roberto Alves Pereira" notifications@github.com escreveu:

Bom, definido que vou procurar nas NT/Manual o local onde fala oque o @rftd https://github.com/rftd falou ai posto a pagina e tudo mais. Se realmente tiver como arredonda, então não tem problemas deixar. Mas com certeza em um momento oportuno vou retirar o mesmo, so não é agora.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe/issues/536#issuecomment-332350504, or mute the thread https://github.com/notifications/unsubscribe-auth/AOvxIi1be6eCYfJyEk2oPB8Qmmbwd5noks5smXW7gaJpZM4PkrBb .

renanaragao commented 7 years ago

@robertorp vou fazer um pull request com as alterações.

robertorp commented 7 years ago

https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe/issues/552

marcosgerene commented 7 years ago

Falei besteira, na verdade não está errado o que eu disse anteriormente, mas torna isso desnecessário o que eu disse anteriormente

na minha ótica não deveria existir nenhum tratamento, os valores deveriam ser passados de forma "pura" como o ERP passou, os tratamentos devem ser feitos pelo ERP e não pelo componente, exatamente para não ter casos igual o seu de truncamento, ou algum caso de alguém que quer que sempre arredonde pra cima (ex: 16,214 = 16,22 ja vi casos assim).

Respondendo a outro tópico eu vi que falei besteira, então aqui vai um novo argumento que vai contra o meu anterior.

https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe/issues/551#issuecomment-335763215

O arredondamento só acontece se algo tiver que ser arredondado, se você passar o valor já truncado/arredondado de forma diferente o componente não vai "desarredondar/destruncar".

Ex: 1,554 * 22,90 = 35,5866, se você passar este valor "35,5866" para o componente ele vai arredondar para 35,59, agora se você passar 35,58 já truncado o arredondamento não vai ocorrer.

Trocando em miúdos, caso o ERP tenha a intenção de tratar de forma diferente, basta ele passar os valores já arredondados/truncados.

O que o componente faz hoje é somente tratar para que o valor tenha 2 casas decimais como exige o manual.

robertorp commented 6 years ago

Vai continuar do jeito que esta. Arredondando somente. No geral os valores vão ser formatados pelo criador do erp.. o arredondamento não irá servir de nada. Agora se o criador do erp mandar valores 88,3288239893289328932 logicamente o zeus ira arredondar isso.