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).

Importante: O NSU não fica armazenado na SEFAZ de forma consultável. É responsabilidade de cada aplicação cliente manter o controle do último NSU processado. A SEFAZ apenas informa qual é o 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
Cuidado: É um erro comum gravar o 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.

Frequência recomendada: Em produção normal, recomenda-se consultar a cada 1 a 2 horas. Em contingência, pode-se reduzir para 30 minutos. Consultas com menos de 20 minutos de intervalo podem gerar bloqueios.

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

SEFAZ
Documentos NSU 100 a 200
Sistema A (Empresa)
Consulta NSU 100
Recebe docs 100-120
Grava ultNSU=120
Sistema B (Contador)
Consulta NSU 100
Recebe docs 100-150
Grava ultNSU=150
Resultado
Docs 100-120 duplicados
Sistema A perde docs 121-150
Dessincronização total

Consequências do Conflito

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
Atenção: O uso indevido do serviço pode resultar em bloqueio do CNPJ por até 24 horas. Em casos recorrentes, a SEFAZ pode exigir justificativa formal.

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.

SEFAZ
NFeDistribuicaoDFe
⬇️
Captador Central
Único controle de NSU
Armazenamento em banco
API REST de distribuição
⬇️
ERP Empresa
Consome via API
Sistema Contador
Consome via API
Outros Apps
Consomem via API

Vantagens desta Abordagem

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

SQL
-- 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
);
Dica de performance: O campo 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

Pseudocódigo
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.

Atenção na migração: Durante a fase de transição, NÃO execute consultas diretas à SEFAZ em nenhum sistema. Apenas o Captador Central deve fazer isso. Se houver falha, utilize a API com os documentos já armazenados.

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
Conclusão: Para qualquer cenário com mais de um sistema que precisa acessar os DF-e do mesmo CNPJ, o Captador Central é a solução mais robusta e profissional. O investimento inicial de desenvolvimento se paga rapidamente com a eliminação de problemas de sincronização, retrabalho e riscos fiscais.