Pular para o conteúdo
Voltar ao Blog

DDMRP para importador: programação linear de container via PuLP/CBC

Importador precisa fechar container fechado. DDMRP indica o que comprar; PuLP/CBC otimiza a carga. Veja como a stack ForgeFlow integra solver matemático no Odoo.

Luis Felipe Miléo Luis Felipe Miléo Gestão Empresarial 4 min de leitura

Importador tem uma restrição que o distribuidor doméstico não tem: a unidade de compra é o container. Não dá para comprar cinco caixas de um SKU e seis de outro toda semana. A compra acontece a cada 30, 60 ou 90 dias e precisa fechar 28 m³ ou 68 m³, respeitar peso máximo, e ainda assim atender a demanda projetada até a próxima chegada.

O DDMRP responde o que falta e quanto falta de cada SKU em estado vermelho ou amarelo. Mas o DDMRP puro não resolve a pergunta seguinte: dado um conjunto de SKUs em recomendação, qual a combinação ótima de quantidades para fechar um container?

Essa pergunta é um problema clássico de programação linear / inteira mista (MILP). E a stack DDMRP da ForgeFlow integra solver matemático no Odoo via PuLP com backend CBC (COIN-OR Branch and Cut).

O problema formalizado

Variáveis de decisão:

  • x_i = quantidade a comprar do SKU i (na unidade do produto, arredondada pela UdM; múltiplo de caixa entra como restrição)

Função objetivo (a que o módulo ddmrp_prioritized_share monta):

NFP%_i = 100 * (NFP_i + x_i) / TOG_i                         # posição do buffer após a compra
minimize  sum( |NFP%_i - 100| ) + sum( |NFP%_i - NFP%_j| )    # segundo somatório: cada par i, j

Onde NFP_i é a Net Flow Position atual do SKU. O solver busca equilíbrio: aproximar cada buffer do Top of Green e deixar todos com a mesma penetração, então quanto mais vermelho o item, mais quantidade ele recebe. Os valores absolutos viram variáveis auxiliares para o problema continuar linear.

Restrições típicas:

sum( volume_i * x_i ) <= V_container        # capacidade volumétrica
sum( weight_i * x_i ) <= W_container        # capacidade de peso
x_i >= MOQ_i                                # lote mínimo do buffer (buffer_moq)
x_i >= TOP_i - NFP_i                        # TOP = TOG (modo estrito), TOY ou TOR, o maior viável
x_i <= (1 + tol) * (TOG_i - NFP_i)          # opcional: force_top_of_green_target
x_i = k_i * multiplo_i,  k_i inteiro        # múltiplo de compra (buffer_qty_multiple)

Em containers fracionados (LCL) entram restrições adicionais de volume mínimo (volume_min).

Por que PuLP e CBC

PuLP é a biblioteca Python mais usada para modelar MILP de forma legível. Ela é interface, não solver, ela traduz o modelo Python para o formato que o solver entende.

CBC é o solver open-source do projeto COIN-OR, mantido pela própria comunidade científica. Ele resolve problemas de MILP de centenas a milhares de variáveis em segundos a minutos. Para o caso típico de container (50 a 300 SKUs candidatos), o CBC resolve em poucos segundos.

A escolha de PuLP+CBC pela ForgeFlow tem três motivos práticos:

  1. Open source, sem custo de licença Gurobi ou CPLEX
  2. Empacotável em pip, instala junto com o módulo Odoo
  3. Determinístico, mesma entrada produz mesma saída, auditável

Onde o solver entra no fluxo Odoo

O fluxo prático em um cliente importador implantado pela KMEE:

  1. DDMRP gera lista de recomendação, todos os SKUs com Net Flow Position abaixo de Top of Yellow, ordenados por penetration
  2. Comprador filtra por fornecedor / origem: SKUs comprados na China, no Vietnã, etc.
  3. Comprador chama o solver, botão na tela passa a lista, capacidade do container, volumes e pesos cadastrados em product.template
  4. Solver retorna o mix ótimo, quantidades por SKU que maximizam a recuperação de buffer respeitando container
  5. Comprador valida e gera RFQ no Odoo, purchase.order em rascunho com as linhas calculadas

Tudo dentro do Odoo, sem planilha externa.

Onde o solver erra

Modelo matemático só resolve o que está modelado. Erros típicos:

  • Volume cadastrado no produto desatualizado, o solver acredita que cabe; na hora de carregar, não cabe
  • MOQ não modelado, o solver sugere comprar 3 unidades de um SKU cujo lote mínimo é 100
  • Lead time variável não considerado, o solver não sabe que o porto de origem fechou para celebração

A camada DDMRP da ForgeFlow já modela MOQ, volume, peso e Top of Green corretamente.

Caso real

Um cliente brasileiro em Odoo 18 (distribuidor importador) opera com containers fechados a partir da Ásia. A integração DDMRP + PuLP/CBC reduziu o tempo de planejamento de container de dias (planilha + reunião) para minutos (botão no Odoo + revisão).

Stack e papéis

A integração DDMRP + solver matemático é parte da camada Professional da ForgeFlow (Espanha), especificamente os módulos ddmrp_prioritized_share e correlatos. A KMEE é parceira oficial brasileira para implantação Enterprise: instalação, calibragem e treinamento da equipe de compras.

Leituras relacionadas:

  • #ddmrp
  • #pcp

Compartilhar

WhatsApp LinkedIn

Sobre o autor

Luis Felipe Miléo

Luis Felipe Miléo

CEO e sócio-fundador · KMEE

Sócio-fundador da KMEE e PSC da Odoo Community Association. Mantém com o seu time a localização fiscal brasileira do Odoo (l10n-brazil) e outros módulos da OCA desde 2012. Certificado Demand Driven Planner, escreve sobre ERP, open source, fiscal e IA aplicada às operações.

Ver perfil no LinkedIn

Artigos relacionados

Comece por um diagnóstico gratuito

Trinta minutos para entender a sua operação e dizer o que resolver primeiro, na ordem certa. Sem compromisso.