DDMRP + OCA l10n-brazil: planejamento puxado com NF-e nativa

DDMRP em Odoo é uma camada de planejamento. Ele decide quando criar purchase.order, mrp.production e stock.picking (transferências internas). Mas quem efetiva esses documentos no Brasil é o l10n-brazil, conjunto de módulos OCA que implementa NF-e, NFS-e, CT-e, escrituração fiscal e regimes brasileiros.

Para uma operação real no Brasil, DDMRP e l10n-brazil precisam conviver tecnicamente. Não é trivial, mas é resolvido. Este post detalha onde os dois mundos se encontram e onde ainda há cuidado a tomar na implantação.

A arquitetura em camadas

A operação completa em Odoo brasileiro com DDMRP tem três camadas:

1. OCA l10n-brazil — fiscal e tributário (NF-e, ICMS, PIS/COFINS, transferência interna entre filiais com CFOP correto, escrituração)
2. Camada DDMRP da ForgeFlow — planejamento puxado (stock.buffer, ADU, NFP, dashboard)
3. Odoo nativo — stock, purchase, mrp, sale

DDMRP não substitui o módulo purchase ou stock do Odoo. Ele atua antes deles, criando os documentos em estado rascunho. Da mesma forma, l10n-brazil atua sobre os documentos do Odoo, completando dados fiscais e gerando documentos eletrônicos.

A camada DDMRP é, na prática, indiferente a quem assina a NF-e. Para o stock.buffer, importa apenas que o stock.move aconteça e atualize o on-hand. Para o l10n-brazil, importa o documento que rege esse stock.move.

Pontos de atenção na integração

1. Transferência interna entre filiais

Operação multi-warehouse com filiais em CNPJs diferentes exige NF-e de transferência (CFOP 6.151, 5.151 ou equivalente). Quando o DDMRP sugere transferência interna (porque um CD tem excesso e outro tem ruptura projetada), o documento gerado precisa passar pelo fluxo l10n-brazil para emissão de NF-e.

A integração ocorre porque ambos os módulos atuam sobre o mesmo stock.picking. O DDMRP cria o picking; o l10n-brazil completa CFOP, tributação e dispara emissão.

2. Lead time real considerando autorização de NF-e

Em compras interestaduais, a entrega depende da autorização da NF-e do fornecedor. Em operação normal, isso é minutos. Em rejeição, é horas ou dias. O lead time real medido (ver post sobre auditoria de lead time) capta esse efeito naturalmente — porque mede data_recebimento - data_emissao_PO.

3. Fechamento mensal de estoque para SPED

SPED EFD ICMS/IPI exige reconciliação mensal. O DDMRP opera em ADU contínuo, sem ciclo mensal próprio. Os dois mundos coexistem: SPED roda sobre os stock.move registrados; DDMRP roda sobre saldo e ADU.

Detalhe importante: ajustes de inventário feitos no fechamento (correções, perdas, quebras) afetam on-hand e, portanto, NFP. Em operação madura, esses ajustes entram no Odoo via stock.inventory ou stock.scrap e o DDMRP recalcula automaticamente.

4. Regime de substituição tributária (ST)

ST não afeta o DDMRP diretamente — afeta o custo, não o fluxo físico. Mas afeta a decisão de comprar mais ou menos quando o item tem ST recolhida pelo fornecedor (custo total maior). Essa decisão é do comprador, fora do DDMRP. O método indica o que repor; o comprador, ciente do custo ST, ajusta priorização entre fornecedores.

5. Devolução fiscal

Devolução de cliente (entrada) é evento que o DDMRP precisa registrar como retorno de estoque, não como demanda negativa. O stock.move de devolução já entra naturalmente no on-hand. O detalhe está em não contar a venda original como ADU quando ela é devolvida — ou seja, descontar a venda do consumo histórico. A camada ForgeFlow trata isso via campo qty_returned no histórico.

Estrutura de repositórios

Para implantação, o stack típico em Odoo 18 brasileiro inclui:

• OCA/l10n-brazil — núcleo fiscal
• OCA/ddmrp — camada DDMRP community
• OCA/account-financial-tools, OCA/sale-workflow, OCA/stock-logistics-warehouse — dependências auxiliares
• ForgeFlow proprietário — camada Professional (dashboard, simulation, BOM optimization, prioritized share)

A KMEE mantém configuração testada com l10n-brazil ativo + DDMRP ForgeFlow em Odoo 18, com fluxo de NF-e operando junto com sugestão de reposição automática.

O que muda em relação a uma implantação europeia

DDMRP em Espanha, França, Alemanha — onde a ForgeFlow tem outros clientes — tem complexidade fiscal menor. NF-e nativa em cada stock.picking é peculiaridade brasileira. Os pontos de atenção que efetivamente mudam:

• Tempo de emissão de NF-e entra no lead time efetivo
• Recálculo de ADU em devoluções é mais frequente (consumidor brasileiro devolve)
• Transferência interna sempre tem documento fiscal (não é movimento “gerencial”)
• Integração com CFOP exige mapping correto (compra puxada por buffer vs transferência puxada por buffer geram CFOPs diferentes)

Nada disso impede DDMRP. Apenas exige integração cuidadosa.

Caso real

Um cliente brasileiro em Odoo 18, indústria/distribuição com filiais em diferentes estados, opera DDMRP da ForgeFlow integrado com l10n-brazil. O fluxo de transferência interna entre CDs, sugerido pelo método, gera NF-e de transferência automaticamente. Compras interestaduais com ST recolhida pelo fornecedor entram no fluxo padrão. Reconciliação SPED mensal não interfere no método.

Stack e papéis

A stack DDMRP é da ForgeFlow (Espanha). O l10n-brazil é mantido pela comunidade brasileira da OCA (KMEE é uma das empresas mantenedoras ativas). A integração entre os dois é trabalho de implantação Enterprise — papel da KMEE como parceira oficial brasileira da ForgeFlow.

Leituras relacionadas:

• DDMRP em distribuidor com 5.000 SKUs
• DDMRP em manufatura discreta com BOM profunda
• Lead time real vs prometido
• Serviço DDMRP em Odoo