Introdução ao Sistema de Distribuição de DF-e
Entendendo o mecanismo de consulta de documentos fiscais eletrônicos
O serviço de Distribuição de DF-e (Documentos Fiscais Eletrônicos) permite que empresas e contadores consultem documentos fiscais emitidos contra seu CNPJ, como Notas Fiscais Eletrônicas (NF-e), Conhecimentos de Transporte (CT-e) e Notas Fiscais de Consumidor (NFC-e).
O funcionamento é baseado em um Número Sequencial Único (NSU), que atua como um cursor para navegar pelos documentos disponíveis na base da SEFAZ. Cada CNPJ possui sua própria sequência de NSUs, e o controle adequado desse número é fundamental para evitar perda de documentos ou consultas ineficientes.
Para Empresas
Recebimento automático de NF-e emitidas contra seu CNPJ, permitindo conciliação fiscal e controle de compras.
Para Contadores
Acesso a todos os documentos fiscais dos clientes para escrituração e apuração de impostos.
Conformidade Fiscal
Garantia de que todos os documentos emitidos estão sendo devidamente registrados e contabilizados.
O que é o NSU (Número Sequencial Único)
Compreendendo o conceito fundamental das consultas de DF-e
O NSU (Número Sequencial Único) é um número inteiro, crescente e único, atribuído pela SEFAZ para cada evento de distribuição de documentos fiscais de um determinado CNPJ ou CPF. Ele funciona como um identificador de posição na fila de documentos disponíveis.
Características Importantes do NSU
Sequencial e Crescente
Os números sempre aumentam. Não há reutilização ou retrocesso. Cada novo documento recebe um NSU maior que o anterior.
Único por CNPJ
Cada CNPJ/CPP tem sua própria sequência independente. O NSU 100 de uma empresa não tem relação com o NSU 100 de outra.
Irreversível
Uma vez avançado, não é possível retroceder o NSU. Se documentos foram perdidos, é necessário reprocessar todo o intervalo.
Agrupador de Documentos
Um mesmo NSU pode conter múltiplos tipos de documentos fiscais (NF-e, CT-e, NFC-e, manifestações).
maxNSU disponível no momento da consulta.
Diferença entre ultNSU e maxNSU
| Campo | Significado | Origem | Exemplo |
|---|---|---|---|
| ultNSU | Último NSU efetivamente processado pelo seu sistema | Controlado pela aplicação cliente | Seu sistema gravou que já processou até o NSU 150 |
| maxNSU | Maior NSU disponível na SEFAZ naquele momento | Informado pela SEFAZ na resposta | A SEFAZ informa que o maior NSU atual é 200 |
maxNSU como se fosse o ultNSU. Isso faria seu sistema pular documentos! Grave sempre o NSU do último documento efetivamente processado.
Como Funciona o Mecanismo de Consulta
O passo a passo do processo de distribuição de DF-e
1. Preparação da Requisição
O sistema monta um XML de requisição informando o CNPJ consultado e o ultNSU (último NSU processado). Para a primeira consulta, utiliza-se o valor "0".
2. Assinatura Digital
O XML é assinado digitalmente com o certificado A1 (ou A3) da empresa, garantindo autenticidade e integridade da requisição.
3. Envio via SOAP
A requisição assinada é enviada para o Web Service NFeDistribuicaoDFe da SEFAZ do estado da empresa, utilizando o protocolo SOAP sobre HTTPS.
4. Processamento pela SEFAZ
A SEFAZ localiza todos os documentos com NSU maior que o ultNSU informado e os agrupa em um lote de resposta, respeitando limites de tamanho.
5. Recebimento e Processamento
O sistema recebe o XML de resposta contendo o maxNSU atual e até 50 documentos por lote. Cada documento deve ser processado e armazenado individualmente.
6. Atualização do Controle
Após processar todos os documentos do lote, o sistema grava o NSU do último documento processado como novo ultNSU para a próxima consulta.
O Problema dos Dois Sistemas
Por que múltiplos sistemas consultando o mesmo CNPJ causa conflitos
Este é um dos problemas mais comuns enfrentados por empresas e contadores. Quando dois sistemas independentes (ex: ERP da empresa e sistema do contador) consultam a SEFAZ usando o mesmo CNPJ e certificado, ocorrem conflitos no controle do NSU.
Simulação do Problema
Recebe docs 100-120
Grava ultNSU=120
Recebe docs 100-150
Grava ultNSU=150
Sistema A perde docs 121-150
Dessincronização total
Consequências do Conflito
- Documentos duplicados: Ambos sistemas recebem os mesmos documentos, gerando duplicidade nos registros.
- Documentos perdidos: Um sistema avança o NSU mais que o outro, fazendo com que documentos fiquem inacessíveis para o sistema atrasado.
- Dessincronização: Os controles de NSU ficam diferentes, impossibilitando rastrear quais documentos foram realmente processados.
- Bloqueio na SEFAZ: Múltiplas consultas frequentes podem ser interpretadas como uso indevido do serviço.
Restrições e Limitações da SEFAZ
O que você precisa saber para evitar problemas com o fisco
Limites de Consulta
| Restrição | Descrição | Recomendação |
|---|---|---|
| Frequência mínima | Consultas com intervalo menor que 20 minutos podem ser bloqueadas | Agendar para cada 1-2 horas |
| Tamanho do lote | Cada resposta contém no máximo 50 documentos | Implementar loop de consulta até esgotar |
| Timeout | A SEFAZ pode encerrar conexões longas (30-60 segundos) | Implementar retry com backoff exponencial |
| Consumo indevido | Consultas sem novos documentos são consideradas uso indevido | Verificar se maxNSU > ultNSU antes de consultar |
| Certificado único | Mesmo CNPJ com certificados diferentes pode gerar conflitos | Centralizar em um único ponto de consulta |
Cenários de Conflito Comuns
Situações reais onde os problemas de NSU se manifestam
Empresa + Contador
O cenário mais comum: a empresa tem um ERP que consulta NF-e para controle de compras, enquanto o contador usa outro sistema para escrituração fiscal. Ambos competem pelo mesmo NSU.
Múltiplos ERPs
Empresas que usam sistemas diferentes para departamentos distintos (compras, fiscal, financeiro) podem ter cada um fazendo sua própria consulta, sem sincronização.
Sistemas Legados + Cloud
Durante a migração de sistemas on-premise para cloud, ambos podem ficar ativos simultaneamente, consultando o mesmo CNPJ.
Apps de Terceiros
Aplicativos de gestão financeira ou conciliação bancária que se conectam diretamente à SEFAZ sem coordenação com o ERP principal.
Arquitetura Ideal: Captador Central
A solução recomendada para múltiplos consumidores de DF-e
A solução mais robusta é implementar um Captador Central: um serviço único responsável por toda a comunicação com a SEFAZ, que armazena os documentos e os distribui para os demais sistemas.
Armazenamento em banco
API REST de distribuição
Vantagens desta Abordagem
- Controle único de NSU: Elimina conflitos de sincronização.
- Economia de recursos: Uma única consulta à SEFAZ em vez de múltiplas.
- Distribuição flexível: API REST permite que qualquer sistema autorizado consuma os documentos.
- Auditoria centralizada: Logs e histórico de consultas em um único local.
- Alta disponibilidade: Os sistemas consumidores não dependem da SEFAZ estar online para acessar documentos já baixados.
Guia de Implementação
Como construir o Captador Central passo a passo
Tecnologias Recomendadas
Backend / Worker
PHP com Laravel (Jobs) ou Symfony (Messenger), C#/.NET (Hangfire), Python (Celery) ou Node.js (Bull).
Banco de Dados
PostgreSQL (recomendado), MySQL 8+ ou SQL Server. Essencial ter suporte a transações e locks.
Certificado Digital
Certificado A1 (arquivo .pfx) armazenado de forma segura. Para A3, usar bibliotecas de integração com token.
Scheduler
Cron (Linux), Task Scheduler (Windows) ou bibliotecas nativas da linguagem escolhida.
Checklist de Implementação
Fase 1: Estrutura Base (Semana 1)
Criar as tabelas no banco de dados: controle_nsu, documentos_fiscais, log_consultas. Implementar o worker de consulta com agendamento básico.
Fase 2: Processamento de XML (Semana 2)
Desenvolver o parser dos schemas de resposta (resNFe, resCTe, resNFCe). Implementar extração de chave de acesso e dados principais.
Fase 3: API de Distribuição (Semana 3)
Criar API REST autenticada para consulta de documentos por período, tipo, chave de acesso. Documentar com Swagger/OpenAPI.
Fase 4: Resiliência (Semana 4)
Implementar retry com backoff, tratamento de timeout, lock distribuído para evitar consultas simultâneas, alertas de falha.
Estrutura de Banco de Dados
Modelo de dados otimizado para o Captador Central
-- Tabela de controle de NSU (UMA POR CNPJ)
CREATE TABLE controle_nsu (
cnpj VARCHAR(14) PRIMARY KEY,
ult_nsu VARCHAR(20) NOT NULL DEFAULT '0',
max_nsu_conhecido VARCHAR(20),
ultima_consulta TIMESTAMP,
em_consulta BOOLEAN DEFAULT FALSE,
erros_consecutivos INT DEFAULT 0,
bloqueado_ate TIMESTAMP
);
-- Tabela principal de documentos fiscais
CREATE TABLE documentos_fiscais (
id BIGSERIAL PRIMARY KEY,
cnpj_destinatario VARCHAR(14) NOT NULL,
nsu VARCHAR(20) NOT NULL,
chave_acesso VARCHAR(44),
tipo_documento VARCHAR(10),
schema_xml VARCHAR(20),
xml_documento TEXT NOT NULL,
json_dados JSONB,
data_emissao DATE,
data_recebimento TIMESTAMP DEFAULT NOW(),
cnpj_emitente VARCHAR(14),
razao_social_emitente VARCHAR(200),
valor_total NUMERIC(15,2),
UNIQUE(cnpj_destinatario, nsu)
);
-- Índices para performance
CREATE INDEX idx_docs_cnpj_data ON documentos_fiscais(cnpj_destinatario, data_recebimento);
CREATE INDEX idx_docs_chave ON documentos_fiscais(chave_acesso);
CREATE INDEX idx_docs_tipo ON documentos_fiscais(tipo_documento);
CREATE INDEX idx_docs_emitente ON documentos_fiscais(cnpj_emitente);
-- Tabela de log para auditoria
CREATE TABLE log_consultas (
id BIGSERIAL PRIMARY KEY,
cnpj VARCHAR(14) NOT NULL,
data_consulta TIMESTAMP DEFAULT NOW(),
ult_nsu_consultado VARCHAR(20),
max_nsu_retornado VARCHAR(20),
documentos_recebidos INT DEFAULT 0,
tempo_resposta_ms INT,
erro TEXT,
tentativas INT DEFAULT 1
);
json_dados armazena uma versão processada dos dados do XML, facilitando consultas sem precisar parsear o XML a cada requisição. Utilize índices apropriados para os campos mais consultados.
Fluxo Completo de Consulta (Pseudocódigo)
Algoritmo detalhado do processo de consulta ao DF-e
função consultar_distribuicao_dfe(cnpj):
// 1. Obter lock para evitar concorrência
lock = adquirir_lock_banco("consulta_dfe_" + cnpj, timeout=60s)
se lock falhou:
retornar erro("CNPJ em consulta, aguarde")
tentar:
// 2. Recuperar último NSU processado
ult_nsu = banco.consultar_valor(
"SELECT ult_nsu FROM controle_nsu WHERE cnpj = ?", cnpj
)
se não encontrou:
inserir em controle_nsu valores (cnpj, ult_nsu='0')
ult_nsu = '0'
// 3. Verificar bloqueio por erros
se bloqueado_ate > agora():
retornar erro("Consulta bloqueada temporariamente")
// 4. Loop de consulta até esgotar documentos
total_processado = 0
repita:
// 4.1 Montar XML de requisição
xml = montar_xml_consulta(cnpj, ult_nsu)
// 4.2 Assinar com certificado
xml_assinado = assinar_xml(xml, certificado)
// 4.3 Enviar para SEFAZ via SOAP
resposta = enviar_soap(
url=url_sefaz_uf(cnpj),
soap_action="NFeDistribuicaoDFe",
xml=xml_assinado,
timeout=60
)
// 4.4 Validar resposta
se resposta.erro:
incrementar erros_consecutivos
se erros_consecutivos >= 3:
bloquear_por(horas=2)
retornar erro(resposta.mensagem_erro)
// 4.5 Extrair dados
max_nsu = resposta.extrair_campo("maxNSU")
documentos = resposta.extrair_documentos()
// 4.6 Processar documentos em transação
iniciar_transação():
para cada doc em documentos:
// Evitar duplicados
se não existe_documento(cnpj, doc.nsu):
dados = parse_xml(doc.xml)
inserir em documentos_fiscais(
cnpj, doc.nsu, dados.chave,
dados.tipo, dados.schema,
doc.xml, dados.json, ...
)
total_processado++
// 4.7 Atualizar controle com último NSU processado
se documentos não está vazio:
ultimo_nsu = documentos[último].nsu
atualizar controle_nsu
SET ult_nsu = ultimo_nsu,
max_nsu_conhecido = max_nsu,
erros_consecutivos = 0
WHERE cnpj = cnpj
fim_transação()
// 4.8 Registrar log
inserir em log_consultas(cnpj, ult_nsu, max_nsu, len(documentos))
// 4.9 Verificar se há mais documentos
se len(documentos) == 50:
ult_nsu = ultimo_nsu // Continua do último recebido
senão:
sair do loop // Todos os documentos foram processados
retornar sucesso(total_processado)
capturar qualquer erro:
registrar_log_erro(cnpj, erro)
incrementar erros_consecutivos
retornar erro(erro.mensagem)
finalmente:
liberar_lock(cnpj)
fim_função
Agendamento da Execução
| Período | Frequência | Observação |
|---|---|---|
| Horário comercial (08h-20h) | A cada 1 hora | Maior volume de emissão de documentos |
| Fora do horário comercial | A cada 3 horas | Menor volume, evita consultas desnecessárias |
| Contingência / Fechamento | A cada 30 minutos | Períodos de apuração fiscal e fechamento contábil |
| Sábados, domingos e feriados | A cada 6 horas | Volume mínimo de emissão |
Estratégia de Migração
Como migrar de múltiplos sistemas para o Captador Central
Fase 1: Implantação Silenciosa (2 semanas)
Implementar o Captador Central e deixá-lo rodando em paralelo com os sistemas existentes. Monitorar logs para garantir que todos os documentos estão sendo capturados corretamente.
Fase 2: Migração do Sistema A (1 semana)
Redirecionar o primeiro sistema (ex: ERP da empresa) para consumir da API do Captador Central em vez da SEFAZ. Manter o fallback para consulta direta em caso de falha.
Fase 3: Migração do Sistema B (1 semana)
Redirecionar o segundo sistema (ex: sistema do contador) para a API. Ambos agora consomem do Captador Central.
Fase 4: Desligamento (após 1 mês)
Remover a funcionalidade de consulta direta dos sistemas antigos após validar que não houve perda de documentos por um mês completo.
Boas Práticas e Recomendações
Diretrizes para um sistema robusto e confiável
Lock Distribuído
Implemente mecanismo de lock (via banco de dados ou Redis) para garantir que apenas uma consulta por CNPJ execute por vez, mesmo em ambientes com múltiplos servidores.
Retry Inteligente
Use backoff exponencial (1min, 5min, 15min, 1h) em caso de falhas. Após 3 falhas consecutivas, notifique os administradores e pause as consultas temporariamente.
Idempotência
Utilize o NSU como chave de idempotência. Nunca processe o mesmo NSU duas vezes para o mesmo CNPJ. A constraint UNIQUE no banco é essencial.
Monitoramento
Implemente métricas: documentos processados por hora, tempo de resposta da SEFAZ, taxa de erros, NSU atual vs maxNSU. Dashboards ajudam a identificar problemas rapidamente.
Logs Detalhados
Registre cada consulta com: CNPJ, NSU consultado, maxNSU retornado, quantidade de documentos, tempo de resposta, erros. Essencial para auditoria e troubleshooting.
Segurança do Certificado
Armazene a senha do certificado em variável de ambiente ou cofre de segredos (Vault, AWS Secrets Manager). Nunca hardcode a senha no código.
Comparativo de Abordagens
Vantagens e desvantagens de cada estratégia
| Abordagem | Vantagens | Desvantagens | Recomendada para |
|---|---|---|---|
| Captador Central |
✓ Sem conflitos de NSU ✓ Economia de consultas ✓ Auditoria centralizada ✓ Alta disponibilidade |
✗ Requer desenvolvimento inicial ✗ Ponto único de falha ✗ Maior complexidade |
Empresas com 2+ sistemas consumidores |
| Banco Compartilhado de NSU |
✓ Sistemas independentes ✓ Sem ponto único de falha ✓ Flexível |
✗ Requer sincronização ✗ Múltiplas consultas à SEFAZ ✗ Complexidade de lock |
Quando não é possível centralizar |
| Sistema Único Consulta |
✓ Simples de implementar ✓ Sem conflitos |
✗ Outros sistemas ficam sem acesso ✗ Dependente de exportação/importação |
Cenários com apenas 1 sistema |
| Consultas Independentes |
✓ Nenhuma integração necessária ✓ Implementação rápida |
✗ Documentos duplicados ou perdidos ✗ Risco de bloqueio SEFAZ ✗ Sem rastreabilidade |
Apenas para testes ou cenários temporários |