A comunicação com a SEFAZ

Na emissão de uma nota fiscal eletrônica, gerar o XML, transmitir o XML e obter a autorização são etapas diferentes. Separar essas etapas evita tratar uma rejeição como falha de Internet e evita concluir que um tempo esgotado significa um documento não processado.

Os serviços fiscais

A NF-e, nota fiscal eletrônica, e a NFC-e, nota fiscal de consumidor eletrônica, usam serviços SOAP sobre HTTPS, com mensagens em XML. Os serviços cobrem estas operações:

• a autorização do documento;
• o retorno da autorização, quando o processamento é assíncrono;
• a consulta da situação de um documento pela chave de acesso;
• a consulta do status do serviço;
• a inutilização de uma faixa de numeração;
• o registro de eventos, como o cancelamento.

O endereço de cada serviço, o ambiente de homologação ou de produção e as regras dependem do modelo do documento e do autorizador, que é a secretaria da fazenda do estado do emitente ou um ambiente compartilhado que atende esse estado. O Manual de Orientação do Contribuinte, o MOC, os schemas e as notas técnicas vigentes formam o contrato, e um manual de versão anterior não traz as mudanças posteriores.

Da venda à resposta

O sistema monta o XML com os dados fiscais e assina o documento com o certificado digital do emitente. A assinatura comprova a autoria e a integridade do documento. O mesmo certificado identifica o emitente na conexão HTTPS, no mTLS, e os dois usos são diferentes.

Na autorização, o documento assinado vai dentro de uma estrutura de lote, que segue dentro da mensagem SOAP. Em uma representação simplificada da NF-e, a mensagem tem estes níveis:

• o Envelope e o Body do SOAP;
• o elemento nfeDadosMsg, com os dados da mensagem;
• o elemento enviNFe, o lote, com o número do lote em idLote e a indicação de processamento síncrono em indSinc;
• o elemento NFe, o documento, com os dados em infNFe e a assinatura em Signature.

A SEFAZ valida a estrutura pelo schema, a assinatura e as regras fiscais. A resposta pode informar o recebimento, o processamento, a autorização ou a rejeição.

Processamento síncrono e assíncrono

• Síncrono: o resultado do processamento volta na própria resposta da chamada de autorização.
• Assíncrono: a resposta informa o recebimento do lote com um número de recibo, e o resultado é consultado depois, em outro serviço.

Na NFC-e, a autorização normal usa o modo síncrono. Na NF-e, a modalidade aceita depende das regras vigentes, que mudam por notas técnicas, e por isso o comportamento exigido é conferido na versão em uso.

cStat e xMotivo

Na resposta, o cStat é o código da situação, e o xMotivo é a descrição desse código. Os códigos são lidos no nível em que aparecem, que pode ser o do lote, o do documento ou o do evento. Alguns códigos da autorização são estes:

• 100: o uso do documento foi autorizado;
• 103: o lote foi recebido com sucesso, nos fluxos assíncronos;
• 104: o lote foi processado, e o resultado de cada documento ainda precisa ser lido;
• 105: o lote ainda está em processamento;
• 108 e 109: o serviço está paralisado, por pouco tempo ou sem previsão;
• 204: a nota já existe no autorizador, uma duplicidade que exige conferir a situação do documento;
• 215: o XML falhou na validação do schema.

Esses códigos fiscais não são status HTTP. Um cStat também não significa sempre rejeição, porque o código pode indicar autorização, recebimento ou processamento pendente.

Falha, rejeição e resultado desconhecido

Uma falha na resolução do nome, na conexão ou na negociação TLS impede o envio daquela tentativa. Um tempo esgotado à espera da resposta, por outro lado, deixa o resultado incerto, porque o autorizador pode ter processado o XML. A situação é consultada pela chave de acesso, de 44 dígitos, ou pelo recibo, conforme o procedimento fiscal, antes de qualquer repetição.

Uma rejeição explícita orienta a correção indicada pelo código e pelo motivo. A troca de números ou o envio de outro documento para contornar uma situação desconhecida cria um problema novo, sem resolver o anterior.

A contingência da NFC-e é uma modalidade com condições, adesão e prazos próprios, definidos pela regra de cada estado. A falta de comunicação não concede uma autorização automática para qualquer documento nem para qualquer prazo.

A consulta certa antes do reenvio

O status do serviço não é a situação de um documento. O serviço pode estar em operação e uma nota continuar com resultado desconhecido no sistema. A recuperação relaciona a chave, o emitente, o modelo, o ambiente, o autorizador e o recibo, quando existe.

A duplicidade 204 pede a consulta da situação da chave e do protocolo disponível, e não a geração automática de outro documento. Uma autorização encontrada precisa corresponder ao XML preservado e é incorporada pelo procedimento fiscal do sistema. Cancelamento, inutilização e reenvio são operações diferentes, com regras próprias.

Quando a consulta não encontra o documento, a mensagem, o serviço e o ambiente consultados entram na análise, junto com o histórico das tentativas. Uma consulta feita no destino errado não elimina a possibilidade de processamento no destino certo. O XML original também fica guardado sem alterações, porque a reformatação de um XML assinado invalida a assinatura.