Manifestação do destinatário (DF-e) no Odoo: importação automática de XMLs

Toda empresa brasileira lida com o mesmo problema: notas fiscais de fornecedores chegam por e-mail, em PDF anexado, no XML perdido na caixa do contas a pagar, ou — pior — só aparecem no espelho do Sintegra meses depois. Quem usa o Odoo certo não tem esse problema: a SEFAZ entrega as notas fiscais emitidas contra o CNPJ da empresa, e o ERP as importa automaticamente, abrindo contas a pagar com tudo pronto para conciliação.

Esse fluxo se chama DF-e — Distribuição de Documentos Fiscais Eletrônicos — e a manifestação do destinatário é o protocolo associado. A KMEE, entre as mantenedoras da OCA Brasil há mais de 14 anos, é uma das responsáveis pelo módulo l10n_br_fiscal_dfe, que implementa esse fluxo no Odoo.

O que é o DF-e

O DF-e é um serviço da Receita Federal/SEFAZ que disponibiliza ao destinatário todos os XMLs de NF-e e CT-e emitidos contra seu CNPJ, em até 24 horas após a autorização do documento. O destinatário consulta o serviço (autenticando com seu certificado digital) e baixa os XMLs em lote.

Junto com o DF-e vem a manifestação do destinatário — um conjunto de eventos que o destinatário registra no SEFAZ informando o que aconteceu com a operação:

• Ciência da operação — o destinatário viu que a nota existe (não confirma nada, só registra ciência).
• Confirmação da operação — o destinatário recebeu a mercadoria/serviço, está tudo certo.
• Operação não realizada — o destinatário não recebeu (devolveu, sinistro, recusa).
• Desconhecimento da operação — alguém emitiu uma nota contra o CNPJ da empresa sem que ela tenha pedido (fraude, erro de cadastro do emitente).

O desconhecimento é o mais crítico: sem ele registrado, a nota fica como aceita por inércia, e o destinatário pode ser cobrado por créditos indevidos ou enquadrado em alguma operação que nem existiu.

Por que isso importa

Sem DF-e, o fluxo de contas a pagar é o seguinte:

1. Fornecedor emite NF-e.
2. Fornecedor manda PDF (ou XML, se for organizado) por e-mail.
3. Alguém no contas a pagar recebe.
4. Alguém digita os dados no ERP, ou anexa o PDF.
5. Quando há divergência, descobre-se semanas depois.

Com DF-e, o fluxo vira:

1. Fornecedor emite NF-e.
2. SEFAZ disponibiliza o XML para o destinatário.
3. Cron job do Odoo (a cada hora, por exemplo) consulta o DF-e, baixa XMLs novos, registra como l10n_br_fiscal.dfe no Odoo.
4. Para cada XML, o Odoo cria automaticamente uma account.move em rascunho, com fornecedor, valor, impostos e linhas de produto/serviço.
5. O contas a pagar revisa, manifesta, aprova.

A diferença operacional é gigantesca. E a chance de divergência cai porque a fonte da verdade passa a ser o XML autorizado pelo SEFAZ — não o PDF que o fornecedor mandou.

Como o Odoo implementa

O módulo principal é o l10n_br_fiscal_dfe (https://github.com/OCA/l10n-brazil/tree/16.0/l10n_br_fiscal_dfe). Os componentes:

Modelo l10n_br_fiscal.dfe

Cada XML baixado vira um registro de DF-e com:

• Chave NF-e (44 dígitos).
• Emitente (CNPJ, razão social, IE).
• Data de emissão e data de autorização.
• Valor total.
• XML completo (campo Binary).
• Status do destinatário — não manifestado, ciência, confirmada, desconhecida, não realizada.
• Vínculo com account.move — quando importado, o DF-e referencia a fatura criada.

Cron de consulta

Um cron job chama a SEFAZ via webservice (NFeDistribuicaoDFe) com o certificado digital da empresa. A cada execução, ele puxa o próximo lote de documentos novos (ultNSU — último número sequencial único). Cada lote pode trazer:

• NF-e completa (resXML).
• Resumo da NF-e (resNFe).
• Cancelamento de NF-e.
• Carta de correção eletrônica (CC-e).
• Eventos de confirmação de outros destinatários (uso interno).

Importação para account.move

Quando uma NF-e nova chega, o módulo:

1. Faz parse do XML usando o nfelib (biblioteca Python mantida pela OCA).
2. Cria/identifica o fornecedor pelo CNPJ.
3. Cria/identifica os produtos pelo NCM e descrição.
4. Monta a account.move em modo borrador, com linhas, impostos calculados e CFOP.
5. Anexa o XML como ir.attachment.

A operadora do contas a pagar abre a account.move, confere, eventualmente ajusta categorização, e confirma. O DDA banco e a Reinf de retenções entram a partir daí — veja DDA no Odoo: contas a pagar automatizadas e EFD-Reinf R-2010, R-2030, R-2040.

Manifestação automática

O módulo permite configurar regras de manifestação automática. Por exemplo:

• “Toda NF-e do fornecedor X de valor abaixo de R$ 5.000 → manifestar como confirmada automaticamente.”
• “Toda NF-e sem CNPJ cadastrado como fornecedor → manifestar como ciência (alguém revisa depois).”
• “Toda NF-e duplicada (mesmo número emitido duas vezes) → flag para revisão manual.”

Para CNPJs muito grandes (atacadistas, indústrias com milhares de NF-e por mês), essa automação é a diferença entre uma equipe de 5 ou de 20 no contas a pagar.

Pontos de atenção

• Janela de manifestação — confirmação tem prazo de 180 dias da emissão; desconhecimento, 10 dias. Passou do prazo, perde a manifestação.
• Volumetria — empresas grandes podem receber centenas de NF-e por dia. O cron precisa rodar com frequência (a cada 30 minutos é razoável).
• NSU — o controle de sequência é crítico. Perder o ultNSU significa ter que reprocessar a partir do início ou aceitar um gap.
• CT-e — o mesmo serviço de DF-e entrega CT-e (conhecimento de transporte). Se a empresa contrata frete, precisa tratar também.

Conclusão

DF-e + manifestação do destinatário transforma o contas a pagar de digitação manual em revisão de rascunhos automatizados. O ganho é grande não só em produtividade, mas em integridade fiscal — toda nota que entra no ERP é necessariamente uma nota que existe no SEFAZ, com chave válida e XML preservado.

Para o panorama completo, veja Localização Fiscal Brasileira no Odoo e o Glossário Fiscal Brasileiro.