Otimização de frete via solver matemático (ForgeFlow + PuLP)

DDMRP responde com precisão a duas perguntas: o que repor e quanto repor. Mas em operações onde o frete é a restrição dominante, essas duas respostas precisam ser combinadas com uma terceira: como consolidar a compra para fechar carga eficiente.

Carga eficiente significa coisas diferentes em cada contexto:

• Container marítimo: ocupar 100% do volume útil (28 m³ ou 68 m³) sem ultrapassar peso
• Carreta fechada: combinar SKUs de fornecedores diferentes para fechar M³ ou peso
• FTL doméstico: decidir quais SKUs vão na próxima carga semanal
• Frota própria: rotear veículo com restrição de cubagem por entrega

Em todos esses casos, a pergunta é a mesma: dado um conjunto de SKUs candidatos (vermelhos e amarelos) e uma capacidade limitada (volume + peso), qual mix maximiza recuperação de buffer?

Essa é a função do módulo prioritized share da camada Professional da ForgeFlow.

A natureza do problema

Tecnicamente, é um problema de knapsack multi-restrição com função objetivo customizada. Em forma compacta:

maximize  sum( weight_i * x_i )

subject to:
  sum( volume_i  * x_i ) <= V_max
  sum( massa_i   * x_i ) <= W_max
  x_i ∈ {0} ∪ [MOQ_i, TOG_i - on_hand_i]
  x_i inteiro

Onde weight_i é uma função de prioridade DDMRP — tipicamente (TOG_i - NFP_i) / TOG_i (penetration), eventualmente combinada com margem ou política de mix do cliente.

Resolver esse problema na mão para 50 SKUs já é difícil. Para 300 SKUs, é impossível sem solver. Para 1.000 SKUs (caso de container importador com fornecedor multi-categoria), só com programação inteira mista.

PuLP + CBC dentro do Odoo

A escolha técnica da ForgeFlow foi modelar o problema com PuLP (biblioteca Python de modelagem MILP) e resolver com CBC (solver open source COIN-OR). Tudo embarcado no Odoo via dependência pip.

Vantagens dessa stack:

• Sem custo de licença — Gurobi e CPLEX cobram por core
• Resolve em segundos problemas de centenas a poucos milhares de variáveis
• Determinístico e auditável — mesma entrada = mesma saída
• Modelo legível — quem entende programação linear lê o código direto

Detalhes técnicos da modelagem em container importador estão no post sobre programação linear de container.

Onde o solver agrega valor real

1. Container importador

Caso já discutido em outro post da série. O comprador escolhe origem e fornecedor, o DDMRP filtra SKUs em recomendação, o solver define quantidades por SKU para fechar container.

2. Carga consolidada doméstica

Distribuidor com múltiplos fornecedores na mesma região pode consolidar coleta. O solver decide qual fornecedor incluir na carga da semana e quanto comprar de cada SKU para fechar capacidade da transportadora.

3. Transferência inter-warehouse

Quando um CD tem excesso e outro tem ruptura projetada, a transferência interna pode ser otimizada — não basta transferir todos os SKUs em vermelho do destino, é preciso consolidar carga.

4. Reposição em frota própria

Operação varejo com frota própria distribui SKUs para 50–200 lojas. Cada loja tem buffers próprios; o caminhão tem capacidade fixa. O solver responde: que mix de SKUs por loja maximiza recuperação total de buffer respeitando cubagem do veículo?

Função objetivo é decisão de negócio

O ponto onde a implantação realmente exige especialista é a calibragem da função objetivo. As variantes que aparecem na prática:

• Pura DDMRP — peso = penetration. Maximiza recuperação de buffer.
• DDMRP ponderado por margem — peso = penetration × margem. Prioriza buffer de itens lucrativos.
• DDMRP ponderado por estratégia de mix — peso inclui multiplicador para SKUs que o comercial quer empurrar.
• DDMRP com restrição de mix mínimo — força inclusão mínima de cada categoria de produto.

Não existe “função correta”. Existe a função que reflete a estratégia da empresa. O papel da KMEE na implantação é discutir com diretoria comercial e financeira qual ponderação faz sentido, codificar e validar.

O que o solver não resolve

• Não prevê demanda — usa ADU já calculada
• Não modela fila de fornecedor — assume MOQ atendido = ordem aceita
• Não considera ruptura de outro CD — visão local da carga
• Não substitui análise humana de risco — comprador valida antes de gerar PO

Stack e papéis

A integração DDMRP + solver matemático (prioritized share) é parte da camada Professional da ForgeFlow (Espanha). Os módulos OCA ddmrp e correlatos não incluem o solver. A KMEE é parceira oficial brasileira para implantação Enterprise — calibragem da função objetivo, integração com fluxo de compra Odoo (purchase.order), treinamento.

Leituras relacionadas:

• DDMRP para importador: PuLP/CBC
• DDMRP Dashboard 13 módulos
• DDMRP em distribuidor com 5.000 SKUs
• Serviço DDMRP em Odoo