Uma dúvida que continua sempre presente no universo da tecnologia para a área fiscal: se os DF-es (documentos fiscais eletrônicos) vieram para padronizar e unificar, por que ainda são tão diferentes?
Os documentos fiscais eletrônicos começaram a ser criados há mais de 15 anos e vêm evoluindo significativamente. Porém, a impressão que temos é que eles estão cada vez mais diferentes, ao invés de se tornarem cada vez mais padronizados.
Continue lendo esse artigo que vamos explicar os principais motivos dessa falta de padronização e dar mais detalhes sobre a fragmentação da SEFAZ.
Por que os documentos fiscais continuam tão diferentes?
Com a complexidade da legislação fiscal brasileira, muitos foram os benefícios de transformarem os documentos em papel em documentos eletrônicos.
De acordo com aquele ditado popular: “papel aceita qualquer coisa”. E era assim que funcionava a nossa antiga nota fiscal em papel. Tudo muito complexo, difícil de entender, difícil de acertar, difícil de fiscalizar e, quando algum erro era descoberto, era difícil e dolorido para resolver.
Com os documentos eletrônicos, aquele ciclo do documento fiscal que podia se estender por mais de um mês, agora é praticamente em tempo real. Dependendo do tipo de erro apresentado na emissão de uma nota fiscal, você nem consegue autorizá-la, e a rejeição é imediata.
Ganhamos em velocidade, melhoramos a qualidade das nossas informações, estamos mais integrados, mas os documentos fiscais continuam muito diferentes. Por que isso acontece?
Inicialmente, de uma forma macro, podemos citar que a legislação fiscal não conseguiu unificar os documentos fiscais e ainda exige um tipo de documento fiscal para cada tipo de operação. Restringindo apenas aos documentos eletrônicos que estão no âmbito do ENCAT, temos por exemplo:
- Venda de produtos: NF-e.
- Transporte de mercadorias: CT-e e MDF-e.
- Transporte de pessoas: CT-eOS e BP-e
- Venda no varejo: NFC-e
- Energia Elétrica: NF3-e
Mas esse não é o maior problema, pois se tivéssemos somente layouts distintos seria um cenário controlável. O problema é que cada tipo de documento sofre com suas próprias variações, porque os estados são autônomos. Sendo assim, estamos falando de dezenas de SEFAZ.
Embora exista um padrão para a NF-e, cada estado tem autonomia para criar suas especificidades obrigatórias ou facultativas. Nesse caso estamos falando de 27 UFs (Unidades Federativas) independentes e criativas.
Quais os principais motivos dessa diferença?
Os principais motivos que causam essa grande variedade de layouts de documentos fiscais eletrônicos são a multiplicidade de ambientes autorizadores e a legislação fiscal própria de cada ente arrecadador.
Essa falta de padronização provoca uma fragmentação dos ambientes autorizadores, dificultando muito a vida das software houses.
Quando ocorre a Fragmentação?
Cada DF-e tem um layout XML que é documentado pelos MOCs (Manual de Orientação ao Contribuinte) e pelas NTs (Notas Técnicas). Conforme a legislação tributária avança e evolui, novas NTs são lançadas provocando atualizações e consolidações periódicas nos MOCs.
O objetivo de uma NT é informar quais são as modificações que serão necessárias e quando os ambientes autorizadores das SEFAZ estarão disponíveis com essas alterações.
Vale ressaltar que não basta acompanhar as 27 legislações fiscais simultâneas, pois, em muitos casos, ocorre também o descompasso entre as datas de liberação dos ambientes autorizadores.
Ou seja, na prática, é comum ver as SEFAZ liberarem as atualizações em datas diferentes, de acordo com sua capacidade de liberação de modificações.
Também, não é raro que haja algum erro de implementação. Por exemplo, a ativação de uma regra indevida ou com falha na verificação. Isso causa uma fragmentação dos ambientes autorizadores, transferindo para os sistemas que fazem a emissão a complexidade de controlar qual versão de leiaute e de preenchimento usar para cada ente autorizador. Ou seja, a Software House precisa lidar com mais essa complexidade para atuar em locais com administrações tributárias diferentes.
Quanto tempo dura a fragmentação?
A fragmentação pode ocorrer por algumas horas ou por alguns dias. Por exemplo, é comum uma SEFAZ liberar as atualizações à meia-noite, outras às sete horas da manhã e outras às nove da manhã.
Além disso, existem exceções nos padrões de tratamento do DF-e ao aplicar as regras de validação. Essas regras são separadas em dois grupos: obrigatórias e facultativas.
Uma regra obrigatória significa que será seguida por todos os estados, entretanto, isso não reduz a complexidade, pois cada UF poderá definir seu “critério” de atendimento a essa regra. Por exemplo, o preenchimento do campo pode ser obrigatório, mas a informação contida no campo poderá variar em cada estado.
A facultativa já nasce como opcional, ou seja, cada UF poderá adotar ou não essas regras.
Além de tudo isso, o que mais complica é que as regras facultativas e os “critérios” das obrigatórias não estão – necessariamente – descritos no MOC ou nas NTs, tornando-se necessário consultar cada SEFAZ sobre a aplicabilidade de cada regra.
Quais são as implicações para o desenvolvedor de software de gestão?
De forma geral as implicações são grandes, pois é necessário investir muita energia para fazer a gestão de todas essas regras e isso, invariavelmente, acaba desviando o foco do desenvolvimento para fora do cerne do software de gestão.
Para minimizar os efeitos desses cenários, é importante tratá-los de forma individual. Para contornar a falta de padronização provocada pelas regras de negócio, tanto facultativas como obrigatórias, o software de gestão precisa estar bem parametrizado para suportar essa infinidade de variantes de uma UF para outra.
Já a fragmentação exige uma atenção maior, pois não há uma documentação acessível de quando acontecerá a diferenciação ou falha de uma regra no ambiente autorizador. Não existe um consenso de horário entre as SEFAZ e, dificilmente, se consegue descobrir a hora exata que ocorrerá cada mudança.
Sendo assim, as atualizações sempre geram momentos de estresse, pois o que funciona numa região, pode não funcionar na outra. Uma implementação pode ser desfeita para corrigir algum problema e o sistema que foi atualizado para a nova versão para de funcionar.
Uma rede de lojas que atua em vários estados poderá ter o mesmo sistema, mas que precisará operar com várias versões simultâneas até que todos os ambientes autorizadores se estabilizem.
Tudo isso consome muito tempo, energia e dinheiro dos desenvolvedores de software de gestão.
Como a VINCO pode ajudar?
A VINCO é uma empresa de tecnologia especializada na emissão e gestão de documentos eletrônicos, oferecendo soluções completas para serem acopladas aos sistemas de gestão produzidos por software houses.
Integrações transparentes via APIs e sofisticados portais white-label proporcionam todo o conforto para que as software houses possam disponibilizar em seus produtos a emissão e gestão de NF-e, NFC-e, NFS-e, CT-e e vários outros tipos de DF-e.
Tudo isso com robustez, estabilidade e escalabilidade. Além disso, temos mecanismos para gerenciar e controlar a fragmentação e a falta de padronização dos ambientes autorizadores de forma transparente com o mínimo impacto possível.
Gostou? Então, entre em contato conosco e faça sua inscrição em nosso BLOG para ficar por dentro das novidades!
Posts relacionados
Deixe um comentário Cancelar resposta
POSTS POPULARES
- 5 técnicas para o levantamento de requisitos de software 63.7k visualizações
- Sou obrigado a informar o CPF em todas as compras? 51.2k visualizações
- Você sabe como funciona o Número Sequencial Único (NSU) da NF-e? 29.2k visualizações
Stay connected