Como o stock.buffer calcula ADU em Odoo: passado, futuro e blended

ADU (Average Daily Usage) é a entrada mais importante do dimensionamento DDMRP. Erre o ADU e todo o buffer é mal-dimensionado: zonas pequenas demais geram rupturas, zonas grandes demais imobilizam capital. Este post abre como o modelo stock.buffer calcula ADU em Odoo na stack DDMRP publicada pela ForgeFlow (parceira oficial Odoo na Espanha, autora do código nos repositórios OCA). KMEE atua como parceira brasileira implementadora.

Os três métodos suportados

A stack expõe três métodos no stock.buffer:

• _calc_adu_past_demand — só passado
• _calc_adu_future_demand — só demanda confirmada futura
• _calc_adu_blended — combinação ponderada

A escolha é por buffer (campo adu_calculation_method), permitindo política diferente para cada perfil de SKU.

Passado — _calc_adu_past_demand

A intuição: o futuro próximo se parece com o passado próximo.

O método olha um horizonte de N dias para trás (configurável via adu_calculation_method.horizon_past) e soma a demanda real consumida nesse período. Divide pelo número de dias úteis para obter a média diária.

A demanda contabilizada vem de movimentos de saída efetivos no stock.move — tipicamente entregas para clientes, consumos de produção, transferências para outros locais. Não inclui pedidos pendentes nem forecast.

Quando usar passado puro

• Itens com demanda razoavelmente estacionária (sem sazonalidade marcada)
• Operação sem pipeline confirmado significativo à frente
• Histórico limpo (sem promoções atípicas no horizonte)

Limitações

• Atrasa em itens com tendência (cresce ou cai)
• Distorce se o horizonte pegou um evento atípico
• Não se beneficia de pedidos firmes já entrados

Futuro — _calc_adu_future_demand

A intuição: se eu já tenho pedidos confirmados pelos próximos 30 dias, eles são mais confiáveis que o passado.

O método olha um horizonte de N dias para a frente (horizon_future) e soma a demanda firme nesse intervalo (sale orders confirmados, pickings planejados). Divide pelo horizonte para obter ADU.

Quando usar futuro puro

• Itens em make-to-order com pipeline visível
• Negócios com forecast contratual (cliente envia plano semanal/mensal)
• Itens com lead time longo onde o pipeline já cobre boa parte do horizonte

Limitações

• Subdimensiona se o canal tem muito pedido de última hora (intra-dia)
• Pode oscilar bruscamente quando um pedido grande entra ou cai
• Inútil em itens vendidos no balcão sem pedido prévio

Blended — _calc_adu_blended

A intuição: combinar é melhor que escolher.

O método combina past e future com pesos. Tipicamente algo como ADU = (past × W_past + future × W_future) / (W_past + W_future), onde os pesos são parametrizáveis.

Quando usar blended

• Itens com mistura de canal (parte forecast, parte spot)
• Negócios em transição de modelo (saindo de MTO para MTS, ou inverso)
• Itens onde nem passado nem futuro sozinhos representam bem a realidade

Cuidado

Blended é poderoso mas tem dois pontos de calibragem extras (os pesos). Em projeto, comece com 50/50 e ajuste com base em service level e cobertura de estoque observados.

A janela móvel e o cron

A ADU não é calculada uma vez. Ela é recalculada periodicamente, tipicamente diariamente, por um cron. Isso é o que permite o buffer respirar com o ciclo do negócio:

• Crescimento orgânico → ADU sobe → zonas crescem → mais estoque programado
• Queda sazonal → ADU desce → zonas encolhem → capital liberado

Esse é um dos dynamic adjustments do componente 3 do DDMRP. Em Odoo, o cron é configurável (campo adu_recalc_frequency) e pode rodar de uma vez para todos os buffers.

Sazonalidade conhecida: DAF

E quando a empresa sabe que vai vender 50% mais em dezembro? Esperar a ADU passar a refletir isso é tarde demais — quando ela percebe, o pico já passou.

A resposta é o DAF (Demand Adjustment Factor): um multiplicador planejado, em janela de datas, que inflaciona o ADU durante o período. Para dezembro, agendo DAF = 1,5 de 01/12 a 31/12 e a ADU usada no cálculo de zonas é multiplicada por 1,5 nesse período. As zonas crescem antecipadamente, criando pipeline de reposição antes do pico.

DAF é o mecanismo correto para sazonalidade. Forçar ADU à mão é antipadrão.

Como escolher o método para cada SKU

Heurística prática que usamos em projeto:

Perfil de demanda	Método sugerido
Estacionária, alto giro, sem pipeline	Past
Pipeline contratual forte, MTO	Future
Sazonalidade conhecida	Past + DAF
Misto / transição	Blended
Lançamento sem histórico	Future (até histórico estabilizar)

Em projeto na FFA (distribuidor brasileiro em Odoo 18), a maioria dos SKUs usa past com horizonte de 60-90 dias e DAF para sazonalidade conhecida. SKUs com pipeline contratual de cliente-âncora usam blended.

O que não fazer

Três antipadrões comuns:

1. Horizonte longo demais (180+ dias) em mercado volátil. ADU fica preguiçosa e não acompanha mudanças.
2. Horizonte curto demais (15 dias) em item de baixo giro. ADU vira ruído puro.
3. Trocar de método toda hora. Defina, deixe rodar 60 dias, meça service level e cobertura, depois ajuste.

Próximos posts

ADU resolve a entrada. Os próximos dois posts cobrem o que vem depois: os 9 fatores que dimensionam o buffer e a fórmula da Net Flow Position.

Quer ver os métodos de ADU configurados em cliente real (FFA, Odoo 18)? Fale com a KMEE.