Grupo de Impostos

[Leonardo Gregianin]

Bom dia pessoal,

Estou mapeando todos os campos de impostos que estão faltando implementar, logo vou enviar um PR com as alterações e depois disso vou criar um wiki pra documentar tudo.

Dúvidas:

na linha 284 da serializacao.py tem "if produto_servico.icms_modalidade == 'ST'"

Não poderiamos seguir o layout e testar o próprio CST 60 ou 70 para ICMS Substituição tributária?  

Att,

Leonardo Gregianin

[Junior Tada]

Leonardo, o problema da substituição tributária é que envolve muita legislação estadual que não é acobertada em toda a operação nacional.

Uma determinada regra para uma UF pode gerar um xml inválido para outra UF autorizador.

Fora isso ainda tem o fato de ST estar sendo alterado constantemente com novas legislações estaduais e sendo usado com outros benefícios que

anteriormente não estavam previstos.

Estou já a algum tempo querendo desenvolver testes automatizados para serialização de impostos complexos,

pq pequenas modificações nessa parte exigem multiplos testes em todos os autorizadores por essas questões de diferentes legislações estaduais.

No momento estou com pouca demanda para serviços fiscais ou ERP, quando conseguir mais tempo livre vou me dedicar melhor a estas questões.

[Leonardo Gregianin]

Olá Junior,

Entendo sua preocupação mas acredito que o entendimento seja diferente.

O layout da NFe e NFCe é único para todo o Brasil, quem o desenvolve é o ENCAT em conjunto com outros órgãos como o SERPRO e a Receita Federal.

No próprio layout cita que alguns grupos e campos podem ou não serem implementados e validados pelas Secretarias Estaduais.

Cada Secretaria Estadual pode implementar ou não as rejeições que estão definidas no layout ou cálculos diferentes conforme sua legislação local mas não pode inventar campos ou grupos ou trocar posições dos campos e etc.

Digo isso com bastante tranquilidade pois trabalho e contribui bastante com o projeto ACBr a vários anos e trabalho com documentos fiscais eletrônicos diariamente, emitimos NFe para quase todo o Brasil.

Estou começando agora com o PyNFe e preciso implementar o restante do layout que falta para atender diversos tipos de tributações dos clientes.

Por isso repito que o layout é único e o PyNFe deveria seguir todos os campos do layout e que cada sistema implemente as regras de cálculo conforme a regra de negócio do seu sistema.

Quero, desde já, parabenizar pelo projeto e por manté-lo.

Att,

Leonardo.

--
Você recebeu essa mensagem porque está inscrito no grupo "PyNFe" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para pynfe+un...@googlegroups.com.
Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/pynfe/b4a85f14-dfb8-4691-9308-0f889fbb7fd8%40googlegroups.com.

[Junior Tada]

Leonardo na prática deveria ser assim, mas a realidade é bem diferente.

No próprio código do PyNFe existem inúmeras customizações por falta de padrão em seguir a especificação nacional.

Isso vai desde cabeçalho de comunicação a validação de xml, padrão de url's, etc, etc.

Sempre que lança uma versão nova demora um tempo (com os usuários reclamando)

para os autorizadores irem se adequando e equalizando os códigos.

E não adianta ficar reclamando com SEFAZ, eles corrigem no tempo deles (isto quando corrigem).

Também tenho clientes que emitem em quase todos os estados, 

digo por experiência que algumas UF's são mais problemáticas, principalmente em NFC-e.

Mas sim, concordo com vc, o PyNFe tem por obrigação seguir todos os campos do layout, o preenchimento é de responsabilidade de cada usuário.

Para manter algum nível de retrocompatibilidade e garantir essas inconsistências por falta de padrão é que é difícil garantir a qualidade

do código sem executar múltiplos testes nós vários autorizadores. 

Como mencionei anteriormente, estou com baixa demanda de produtos fiscais no momento. 

Assim que tiver mais tempo pretendo fazer mudanças mais profundas na arquitetura do PyNFe,

principalmente na parte de tributação em uma nova versão futura.

Toda contribuição é bem vinda, mesmo que demore um pouco para entrar no fork principal.

Caso vc tenha intenção de fazer modificações mais profundas, que possam quebrar a retrocompatibilidade,

podemos discutir a criação de um fork específico para isto.

[Flávyo Henrique]

Júnior, esses dias eu estava vendo o generateDS e pode ser uma boa utilizar caso você repense a lib e queira fazer utilizando o mesmo, com isso vai ficar muito mais enchuto o código e fácil de dar manutenção, facilitando até mesmo implementação se outros modelos fiscais.

--

Você recebeu essa mensagem porque está inscrito no grupo "PyNFe" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para pynfe+un...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/pynfe/82713995-e0f9-492c-bf95-913fc37de397%40googlegroups.com.

[Junior Tada]

Podemos fazer um fork com ele, mas acho difícil substituir o lxml por questões de desempenho, principalmente para NFC-e.

Alguns milisegundos em um supermercado por exemplo fazem grande diferença.

Esse é um dos motivos de usar xsd apenas para NFS-e.

Para NF-e não faria diferença, mas como é uma serialização para ambos, fica complicado remover o lxml.

[Flávyo Henrique]

Acho que a perca de performance será ínfima e o ganho de tempo em manutenção compensaria o mesmo. Já fez o teste para ver a perca de performance? 

--

Você recebeu essa mensagem porque está inscrito no grupo "PyNFe" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para pynfe+un...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/pynfe/fcbdafdd-c202-46c1-b4a4-891cccf948de%40googlegroups.com.

[Leonardo Gregianin]

Alguns detalhes de comunicação podem ser diferentes sim como você comentou, mas campos do layout deveriamos seguir.

Vou abrir Issues e fazer PR para cada tipo de CST e CSOSN faltantes, pode ser?

Att.

--

Você recebeu essa mensagem porque está inscrito no grupo "PyNFe" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para pynfe+un...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/pynfe/82713995-e0f9-492c-bf95-913fc37de397%40googlegroups.com.

[Junior Tada]

Flávyo já fiz testes sim, a diferença é MUITO GRANDE para NFC-e.

O Leonardo Tada pode explicar melhor, chegamos a desenvolver uma versão na época que estávamos escrevendo NFS-e 

que foi descartada por performance.

Para alguns usuários que tem pouca demanda poderia servir, para a grande maioria não.

No meu caso a emissão de NFC-e depende da serialização, assinatura, comunicação, geração do DANFE e comunicação com a impressora.

Qualquer mínimo atraso em qualquer um desses passos gera um atraso grande em fila de caixa.

Atualmente meu gargalo está no DANFE, estamos trabalhando em uma lib para geração de relatórios, um dos motivos é este.

A serialização com o lxml é MUITO RÁPIDA, mesmo com toda a complexidade do código.

Fora isso também é mais fácil fazer essas customizações de código que não deveriam existir por erro de falta de padrão dos autorizadores.

Já peguei xsd com erro da própria SEFAZ e autorizadores privados das prefeituras para NFSe.

A manutenção se resume a correção de url's/adição de novos campos no xml ou implementação de campos que não eram atendidos.

PS: estão discutindo no congresso a reforma tributária, provavelmente esse ano ainda teremos que reescrever novamente tudo de novo.

[Flávyo Henrique]

Junior, aproveitando o gancho, como que está a NFS-e? Logo irei precisar implementar a mesma em um projeto e já estou começando a sondar as opções. Para Danfe o que vc está pensando em fazer para resolver o gargalo? Eu estou usando para gerar o gerador do projeto PyTrust mais eu sempre me pergunto o porque não implementamos um para o PyNfe, ate pensei em fazer um usando um schema desenhado no XML e renderizando usando o Jinja para diminuir a complexidade da implementação que teremos, mais eu já vi algumas tentativas nos históricos do GitHub do projeto e que está meio parado.

--
Você recebeu essa mensagem porque está inscrito no grupo "PyNFe" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para pynfe+un...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/pynfe/d6b26870-122e-42b6-87f4-a661c5ae3a6d%40googlegroups.com.

--

Não tentes ser bem sucedido, tenta antes ser um homem de valor.

Albert Einstein

[Junior Tada]

NFS-e estava operando para Betha e Ginfes, mas faz muito tempo que não faço manutenção nem recebemos pull request.

O DANFE depende mais do ERP do cliente do que do próprio PyNFe.

A minha ideia no início era criar módulos complementares com vários tipos de geração de DANFE,

mas que fossem desacoplados da lib principal para não adicionar dependências desnecessárias.

Aqui na empresa utilizamos python e java para relatórios, mas estamos migrando tudo para python 

com ferramentas próprias que estamos desenvolvendo.