Net Flow Position no Odoo: a fórmula que decide quando comprar/produzir

Se você só pudesse olhar um número por SKU bufferizado no DDMRP, esse número seria a Net Flow Position (NFP). Ela resume, em uma única quantidade, quanto estoque “conta” para decidir se preciso pedir mais hoje. Este post abre a fórmula, mostra como o stock.buffer da stack ForgeFlow (autora do código publicado em OCA — KMEE é parceira oficial brasileira para implementação) computa cada parcela em Odoo e quando ela é recalculada.

A fórmula em uma linha

NFP = on_hand + on_order − qualified_demand

Três parcelas, três conceitos. Vamos abrir cada um.

On-hand: o estoque físico disponível

A parte mais óbvia. É o que está fisicamente no armazém(s) do buffer, em locais válidos para reposição (internal no Odoo, excluindo locais de scrap, virtual etc).

Como o Odoo calcula

A stack lê os stock.quant agregados por produto + location, somando quantidades em locations dentro do escopo do stock.buffer. Não conta:

• Quants em locations de transit não pertinentes
• Reservas para pickings (ainda contam como on-hand “disponível”, a reserva entra na qualified demand)
• Quants negativos sem reposição

Cuidados

• Multi-warehouse: um buffer pode ter escopo de mais de um warehouse (típico em distribuição). A definição do escopo (location parent) é parte da modelagem inicial.
• Quarentena: material aguardando QC não deveria contar como on-hand. Tratar via location dedicada fora do escopo.
• Lotes/series com vencimento: material vencendo em breve é tecnicamente on-hand mas operacionalmente um problema. A stack não desconta automaticamente — vale relatório paralelo.

On-order: o que já foi pedido e ainda não chegou

Tudo que está no pipeline de reposição: ordens de compra confirmadas com data de recebimento futura, ordens de produção lançadas, transferências interplant em trânsito.

Como o Odoo calcula

A stack soma:

• Linhas de purchase.order confirmadas com date_planned no horizonte relevante
• mrp.production em estado confirmed/progress com date_planned_finished
• stock.move em transferência (entre warehouses) com date_expected

O horizonte matters: ordem com data muito longe (digamos, 6 meses) tipicamente entra; mas há limite configurável para não inflar NFP com pipeline irrealista.

Cuidados

• Ordens em rascunho: não entram. Só após confirmar/aprovar.
• Ordens atrasadas: entram com sua data efetiva. Se o sistema confia que a ordem vai chegar, ela conta — o que pode mascarar problema de execução.
• Cancelamentos: ao cancelar uma PO, NFP cai e o buffer pode pular para vermelho. Por isso recálculo é importante após mudanças no pipeline.

Qualified demand: o que vai sair em breve

A parte mais sutil. Não é forecast. É demanda que efetivamente conta para reduzir NFP hoje.

Componentes

1. Demanda firme do dia/horizonte curto: sale orders confirmados com data de entrega no horizonte de qualified demand (tipicamente o lead time do buffer ou janela menor)
2. Order spikes qualificados: picos de demanda concentrada no Spike Horizon que ultrapassam o Spike Threshold (ver post dedicado)
3. Outras saídas comprometidas: transferências para outros buffers (downstream), consumo planejado em mrp.production se o item for componente

O que não entra

• Forecast estatístico genérico
• Sale orders em rascunho
• Demanda além do horizonte de qualified demand (essa fica para zonas, não para NFP)
• Reservas implícitas

Por que essa distinção importa

Se você jogasse “todo o forecast dos próximos 90 dias” como qualified demand, a NFP cairia o tempo todo, geraria ordem o tempo todo e o sistema viraria um MRP pioragado. A graça do DDMRP é que a janela de qualified demand é curta e firme: só conta o que está confirmado e iminente.

Cálculo no stock.buffer

O modelo stock.buffer mantém os campos:

• product_location_qty (on-hand)
• incoming_dlt_qty (on-order chegando dentro do DLT)
• qualified_demand (qualified demand acumulada)
• net_flow_position (NFP final)

E os topos:

• top_of_red, top_of_yellow, top_of_green

A cor do buffer é decidida comparando NFP com os topos:

       NFP > ToY  →  GREEN
ToR <  NFP ≤ ToY  →  YELLOW
  0 ≤  NFP ≤ ToR  →  RED
       NFP < 0    →  DARK RED

E há um conceito separado de on-hand status (estado físico) que pode ficar vermelho mesmo com NFP verde, indicando que o pipeline está vindo mas o físico está crítico agora.

Quando o NFP recalcula

NFP não é um campo que recalcula a cada movimento individual — isso seria caro. A stack recalcula em três momentos:

1. Cron periódico (frequência configurável — comum: a cada 1-4 horas em produção, daily em ambientes menores)
2. Sob demanda via botão (“Refresh buffer” na tela do stock.buffer)
3. Após geração de procurement (quando uma ordem é criada a partir do buffer, NFP é atualizada para refletir on-order)

Para ações operacionais críticas (ex.: comprador quer ver NFP atualizada agora após cancelar uma PO), o botão manual existe.

Geração de ordem a partir da NFP

Quando o cron de procurement roda:

1. Recalcula NFP de todos os buffers ativos
2. Para cada buffer com NFP ≤ ToY, calcula qty_to_order = ToG − NFP
3. Aplica MOQ e múltiplos (qty_multiple)
4. Gera procurement na rota apropriada (compra/produção/transferência), respeitando o item type e a rota configurada

O resultado: PO em rascunho, MO em estado de planejamento, ou DO de transferência, dependendo do tipo. Aprovação humana continua sendo passo padrão — DDMRP não é “comprar sozinho”, é recomendar com clareza.

Exemplo numérico

Buffer X com:

• ToR = 750, ToY = 1.750, ToG = 2.250
• on-hand = 600, on-order = 800 (dentro do DLT), qualified demand = 100
• NFP = 600 + 800 − 100 = 1.300

Status: 750 < 1.300 ≤ 1.750 → AMARELO.

Recomendação: 2.250 − 1.300 = 950 un. Se MOQ = 200 e qty_multiple = 50, o sistema sugere 950 (já múltiplo de 50, e acima do MOQ). Gera procurement de 950.

Erros comuns na leitura de NFP

Em projetos reais (FFA em Odoo 18 inclusive), três causas explicam a maioria das reclamações de “NFP errada”:

1. Locations fora do escopo do buffer — material existe fisicamente mas não conta. Solução: revisar location_ids do stock.buffer.profile.
2. PO atrasada com data antiga — entra como on-order mas não vai chegar. Solução: cron de saneamento (reprogramar ou cancelar) e disciplina do comprador em manter datas reais.
3. Sale order com data de entrega errada — distorce qualified demand. Solução: revisão da configuração de prazo de entrega no produto/cliente.

Próximo post

A última peça da NFP é a qualified demand — especificamente, como o DDMRP detecta picos de demanda que merecem entrar no cálculo. Esse é o tema do próximo post sobre Order Spike.

Quer ver NFP rodando em produção (FFA, Odoo 18, distribuidor brasileiro)? Fale com a KMEE.