Emissão de NFS-e

A emissão de NFS-e (Nota Fiscal de Serviços Eletrônica) é a geração digital de um documento que formaliza a prestação de serviços por uma empresa. Ela comprova o serviço, assegura a regularidade fiscal, substitui o papel e é obrigatória para registrar operações, sendo essencial para o recolhimento dos tributos.

Uma NFS-e pode ser autorizada pelo sistema local da prefeitura ou pelo Emissor Nacional.

O eDocs, solução de mensageria fiscal da Senior Sistemas, atua como intermediário entre o ERP e os sistemas das prefeituras e/ou Emissor Nacional, realizando a tradução dos diversos layouts, garantindo a comunicação segura e automatizando o envio, assinatura digital, armazenamento e impressão das notas fiscais.

A documentação a seguir tem por objetivo esclarecer o funcionamento do produto, descrevendo os fluxos de integração e orientações gerais sobre o processo.

Fluxo de Emissão

O processo de emissão de NFS-e é realizado conforme ilustração abaixo:

Basicamente:

1. O ERP é responsável por gerar o XML com as informações da prestação do serviço através de um layout único de integração com o e-Docs. O e-Docs é compatível com dois layouts de integração:
   • Layout Senior 1.00 (antes da Reforma Tributária): esse layout é composto pelo XML do padrão ABRASF 1.00 + tags específicas do grupo InfSenior;
   • Layout Senior 2.00 (após Reforma Tributária): esse layout é composto pelo XML do padrão DPS Nacional + tags específicas do grupo InfSenior.
2. O e-Docs converte o XML gerado pelo ERP para o XML no layout da prefeitura e realiza a transmissão do documento.
   • O destino dessa transmissão poderá ser o webservice do fornecedor do sistema da prefeitura (Nota Control, Ginfes, Betha, IPM, etc.) ou o Ambiente Nacional, a depender do que estiver parametrizado no e-Docs na tela de Manutenção de Prefeituras (em caso de fornecedor próprio) ou na configuração da filial, em caso da prefeitura usar o Ambiente Nacional.
   • Para saber quais os municípios homologados no e-Docs para emissão de NFS-e e qual o fornecedor integrado, clique aqui.
3. A prefeitura ou Ambiente Nacional recepciona o XML enviado pelo e-Docs, faz as validações e retorna se o documento foi autorizado ou rejeitado.
4. Ao receber a resposta da prefeitura/Ambiente Nacional, o e-Docs altera o status do documento e retorna as informações para o ERP.
   • Para saber quais os possíveis status da NFS-e no e-Docs, clique aqui.

DANFSE

O DANFSE é gerado pelo e-Docs a partir dos dados do XML de integração gerado pelo ERP. Atualmente existem três templates padrões do produto:

• DANFSE Nacional – DANFSE no modelo Nacional, conforme as diretrizes da NT 08 da NFS-e Nacional. Uso exclusivo para documentos emitidos gerados pelo ERP no Layout 2.00;
• DANFSE Senior – esse é o modelo padrão do e-Docs para todas as prefeituras. Uso exclusivo para documentos gerados pelo ERP no Layout 1.00 (pré-Reforma);
• RPS Senior – esse é o modelo padrão do e-Docs para todas as prefeituras, independente do layout de integração, gerado quando o documento ainda não foi autorizado na prefeitura/AN, ou seja, ainda não existe uma NFS-e, apenas as informações do RPS.

Abaixo, seguem algumas informações importantes sobre as premissas para geração do DANFSE:

• A geração do DANFSE é gerada com base no arquivo .XML Senior
• Para apresentar o Item da Lista de Serviço que será exibido no PDF do DANFSE/RPS, o sistema desconsidera zeros à esquerda e pontos na sua composição. Por exemplo, se o campo for preenchido com 0107 e o Item da Lista de Serviço for 1.07 na Lei Complementar 116/2003, o sistema entenderá que se trata do mesmo código;
• Para verificar as regras de impressão das informações do tomador no arquivo PDF, acesse Regras de definição de informações de prestador.
• No leiaute utilizado para a impressão do RPS, o valor exibido nos campos Município e UF do prestador se baseiam na configuração da filial. Porém, a filial pode estar cadastrada para uma cidade e o RPS estar sendo enviado para outra cidade que foi cadastrada na tela de inscrições municipais. Quando existir um cadastro de inscrição municipal, o leiaute não exibirá a cidade cadastrada na inscrição municipal e sim a cidade do prestador
• As quebras de linhas são consideradas no item Discriminação dos Serviços do arquivo .PDF no momento da impressão. Caso a quantidade de caracteres seja maior que dois mil, algumas informações serão ocultadas
• O .PDF gerado pelo eDocs destinado à distribuição/impressão da NFS-e segue um modelo padrão para todas as prefeituras. No entanto, é importante que cada cliente observe a legislação municipal vigente. Caso seja necessário personalizar o modelo para atender a requisitos específicos de alguma prefeitura, é possível abrir uma solicitação junto ao setor de serviços da Senior Sistemas
• No DANFSe Nacional, as informações do prestador (nome, endereço, CEP, código do município e inscrição municipal) são obtidas prioritariamente da DPS. Caso essas informações não estejam presentes, o sistema utiliza como fallback os dados informados pelo ERP no XML de integração (InfSenior).

Cancelamento

Quando disponível na prefeitura, o e-Docs permite que seja realizado o cancelamento de NFS-e via webservice. Nesse caso, o fluxo segue o mesmo da emissão de NFS-e, ou seja, o ERP gera a requisição para o e-Docs, que converterá para o XML de cancelamento da prefeitura e fará a transmissão. Caso o cancelamento seja aprovado, o status da NFS-e será alterado para "Cancelado".

Para confirmar se o e-Docs está homologado para cancelamento via webservice para uma determinada prefeitura, consulte a documentação das particularidades do fornecedor, através da lista de prefeituras homologadas.

Cancelamento por substituição

O e-Docs permite o cancelamento de NFS-e por substituição para alguns fornecedores. A lista dos fornecedores que têm essa opção pode ser consultada através da lista de prefeituras homologadas, na documentação do respectivo fornecedor.

No caso da substituição, a NFS-e substituída é cancelada automaticamente pela prefeitura quando a nota substituta for autorizada. Uma NFS-e é substituída quando há necessidade de complemento ou correção das informações, então a nova NFS-e é gerada com base na nota substituída.

Fluxo básico:

1. O ERP gera o XML de NFS-e com o grupo de informações que indica a NFS-e que será substituída;
2. O eDocs recebe o XML gerado e verifica se existem as tags relativas a substituição. Caso sim, emite a nova NFS-e e caso ela seja autorizada, faz uma consulta da NFS-e que foi substituída;
3. A consulta retorna da prefeitura a situação de cancelada e o eDocs altera a situação NFS-e para "Cancelada por Substituição";
4. O eDocs envia um retorno para o ERP com a autorização da nova NFS-e e outro retorno com o cancelamento da NFS-e antiga.

Exemplo:

Emitida a NFS-e 10 com código de serviço 7.02. Após alguns dias o prestador identificou que o código do serviço estava incorreto, então emitiu a NFS-e 15 com o serviço 7.05, informando a NFS-e 10 como substituída. Após a autorização da NFS-e 15, a 10 foi cancelada. O eDocs, ao receber a autorização da substituta, faz a consulta da NFS-e 10, alterando seu status para "Cancelada por Substituição", e envia um retorno para o ERP de autorização da NFS-e 15 e outro retorno de cancelamento da NFS-e 10.

Boleto

Consulte a documentação específica do assunto:

FAQ