Padrão Único NFSe - O que é?

[Karina Harumi]

Esse artigo tem como objetivo explicar o que é o modelo de padrão único de nota fiscal de serviços (NFS-e) oferecido pelo Componente NFSe da Tecnospeed, e quais são as vantagens em usá-lo.

Cenário atual da NFS-e

Para se entender o problema abordado pelo Padrão Único, primeiramente é necessário se explicar como está o cenário de NFS-e atualmente.

Existem no momento inúmeros sistemas de NFS-e empregados pelos munícipios, cada um com seu modelo de comunicação de dados. Nós da Tecnospeed costumamos nomeá-los de acordo com seu fabricante ou, no caso dos padrões desenvolvidos pela própria prefeitura do município, o próprio nome do município ou órgão municipal que o desenvolveu. Alguns dos mais conhecidos são Ginfes, Betha, Ábaco, IssNetOnline, SIGISS, Simpliss, GovBR, dentre outros.

Existe também um padrão criado pelo próprio governo federal, mais precisamente pela Associação Brasileira das Secretarias de Finanças das Capitais (ABRASF), que desenvolveu um padrão que tinha como objetivo servir de base para todos os sistemas de NFS-e. Naturalmente nós o chamamos de padrão ABRASF. Não vou me alongar nos detalhes desse padrão, mas vale citar que esse modelo especificava o esquema dos XMLs usados em toda a comunicação entre os ERPs e o sistema de NFS-e da prefeitura.

De fato, muitos dos padrões de NFS-e são baseados no padrão ABRASF, porém, pelo fato de o padrão ABRASF não ser mandatório, mas sim apenas um modelo conceitual, existem os que são bastante diferentes, tanto na estrutura dos XMLs usados para envio dos lotes de notas quanto no modelo de comunicação. Ao passo que o padrão ABRASF estabeleceu um modelo assíncrono (o lote não é processado imediatamente) alguns padrões são síncronos (os lotes são processados no momento do envio). Alguns possuem serviços a mais além dos estabelecidos pelo padrão ABRASF, outros a menos, ou com parâmetros diferentes, outros com comportamentos diferentes. Mesmo os que seguiram o padrão ABRASF, cada um seguiu à sua maneira, fazendo adaptações conforme suas necessidades. A verdade é que cada padrão tem sua própria maneira de trabalhar, suas peculiaridades, etc.

Vários padrões, vários layouts de integração diferentes

O Componente NFSe, em relação aos serviços de NFSe especificados pelo padrão ABRASF (envio de lotes, consulta de situação do lote, consulta do lote, consulta de nota por NFSe, consulta de nota por RPS e cancelamento) consegue estabelecer uma interface razoavelmente comum entre os diversos padrões. Uma consulta de nota por NFSe, por exemplo, para dois padrões com funcionamento bastante diferente, vai ser chamada pelo ERP ao componente de uma única maneira.

Porém, para o layout do envio dos lotes de notas não havia um “denominador comum”. Cada padrão exige um conjunto diferente de dados, com campos com nomes diferentes e até mesmo formatos de dados diferentes, e cabia ao desenvolvedor que se utilizava do Componente NFSe estudar os campos dos inúmeros padrões existentes, e saber quais dados usar em quais campos desses padrões. Isso aumentava muito a complexidade do uso do Componente NFSe.

Padrão Único: vários padrões, um único layout de integração

Foi pensando em diminuir esse problema de “Torre de Babel” que a Tecnospeed criou o Padrão Único NFSe. Ele funciona como um “esperanto”, ou seja, uma “linguagem universal”, que será traduzida para os diferentes layouts exigidos pelos padrões.

O objetivo do Padrão Único é possibilitar a emissão de NFS-es para todos os padrões através de um único layout, e ainda ser flexível o suficiente para permitir se trabalhar com as particularidades de cada padrão. Ou seja, um ERP se utilizando do Padrão Único irá especificar sempre os mesmos campos com os mesmos formatos de dados independente do município para o qual ele estará emitindo notas, e deixar ao Componente NFSe a tarefa de saber que campos do Padrão Único correspondem a que campos do padrão do município, e que formato de dados ele usa.

O Padrão Único estabelece um “denominador comum” entre os padrões, e com ele é possível se emitir NFS-e para para a grande maioria dos casos de emissão de notas de serviço. Em um cenário típico, o Padrão Único oferece tudo o que é necessário para se emitir NFS-es para os municípios homologados no Componente NFSe. Porém é importante ressaltar que ele não cobre todos os campos particulares de todos os padrões, apenas os essenciais e que tem funcionalidade em comum. Pode eventualmente surgir a necessidade de se informar dados particulares ao um padrão que não são cobertos pelo Padrão Único. Nesses casos, o Padrão Único oferece uma maneira de se especificar esses dados especiais, informando no arquivo de integração o nome do campo do padrão do município com um “@” (arroba) no início. Vale lembrar que esses casos são bastante raros de se acontecer.

Raros também são os padrões que não são cobertos pelo Padrão Único, devido a um grau de diferença tamanho entre esse padrão e o padrão ABRASF que impossibilitou traçar qualquer paralelo entre os campos dos dois padrões. Até o momento nos deparamos com apenas um padrão assim, usado por poucos municípios, para o qual deve ainda ser usado o layout próprio do padrão.

No final, o Padrão Único vem se mostrando uma poderosa ferramenta capaz de reduzir imensamente o esforço dos desenvolvedores na implementação da emissão de NFS-e pelos seus produtos.

Tópico originalmente criado por: @Jonathan Santos