Posição de estoque do ERP, e-commerce e marketplaces, e venda faturada
Disponível líquido, chave de produto única, venda média e parâmetros de ruptura
Cobertura em dias e status de ruptura por produto e filial
Dashboard de reposição, IA de disponibilidade e alertas
O que resolve
- O disponível para vender é o que sobra depois de reservas, sem dobrar estoque nem contar ilimitado.
- Cada produto tem cobertura em dias e um status único: ruptura, crítico, atenção, saudável, excesso ou sem giro.
- A série histórica guarda os dias em zero, que é o que mede ruptura e giro de verdade.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- ERP, e-commerce e marketplaces conectados na Nekt, com a posição de estoque e a venda faturada
- O cadastro de filiais com quais compartilham o mesmo estoque físico
- Prazo de reposição por produto ou grupo e o estoque alvo em dias
O que você recebe
- Uma tabela de posição atual por produto e filial com total, reservado, disponível e em trânsito
- Um histórico com duas medições por dia, incluindo saldo zero
- Semáforo de ruptura com curva ABC, cobertura e venda perdida estimada
- Monitor de frescor e tabela de exceções de cadastro
Onde ativar
Semáforo por produto, filial e canal, evolução diária da ruptura e necessidade líquida por curva.
Vendedor pergunta pelo nome do produto e recebe o disponível por filial, com a hora da última medição.
Item de curva A que entrou em ruptura ou crítico, e carga de estoque que passou do limite sem atualizar.
A posição atual sai rápido. Chave de produto entre fontes, filiais espelho e o histórico com estado são o que tomam tempo. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
Cada fonte chama o estoque de um jeito (total, reservado, committed, available, sellable, inbound) e identifica o produto de outro: código com zeros à esquerda no ERP, SKU com cor e tamanho embutidos no e-commerce, SKU com sufixo no armazém do marketplace. Filiais espelho dobram o saldo e sentinelas de estoque ilimitado inflam o total. A posição atual não tem passado: sem guardar a série, não há como medir quantos dias o item ficou zerado.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
Guarde em colunas próprias: total, reservado (committed, pedidos já vendidos e não expedidos), disponível = maior entre (total menos reservado) e zero, e em trânsito (incoming, inbound, em abastecimento). Na Shopify, leia as quantidades por nome (available, committed, incoming). No armazém da Amazon, disponível é fulfillableQuantity e em trânsito é a soma de inbound working, shipped e receiving. Nunca misture em trânsito com disponível.
Padronize o código antes de cruzar estoque com venda e cadastro: zeros à esquerda até o tamanho do ERP (18 posições no SAP; 6 no Protheus, só para códigos de 4 a 6 dígitos), nunca aplicado a SKU de marketplace. Extraia o código do campo de referência do produto, não do slug da URL. Quando o SKU embute cor e tamanho, extraia produto e cor com uma expressão documentada e agregue sem tamanho se a venda for comparada nesse nível. Kits recebem prefixo próprio (P para produto, K para kit) para não colidir com produtos.
SKU de marketplace resolve para o produto em ordem: tabela de alias, código direto, e expressão regular para sufixos de armazém (por exemplo, o sufixo FBA). Guarde qual regra resolveu. SKU sem mapeamento e com estoque fica visível como "não mapeado"; SKU sem mapeamento e com zero (anúncio inativo) sai do painel.
Produtos marcados com estoque ilimitado (hasunlimitedquantity verdadeiro) saem do saldo. Alguns marketplaces devolvem uma quantidade enorme e fixa como sentinela de ilimitado (na casa de 10.000 ou mais): marque com flag e exclua da soma, com o limiar validado com o cliente. Filiais espelho do mesmo estoque físico agregam pelo grupo de estoque, como no assistente de IA.
A venda média diária usa itens de notas não canceladas cuja operação movimenta estoque: saída soma e devolução (entrada) subtrai; operações que não movimentam ficam fora. Janela de 30 dias para a média; guarde 400 dias de venda para comparar ano contra ano. Quando o canal entrega a venda pronta (unitsShippedT30 no armazém da Amazon), use a do canal.
Cobertura em dias = (disponível + em trânsito) / venda média diária de 30 dias. Em trânsito entra no numerador: no canal que usa armazém do marketplace, ignorá-lo subestima a cobertura em dias. Sem venda nos 30 dias, a cobertura é nula e o item vai para o status sem giro, nunca para infinito ou zero.
Sortimento ativo = faturou nos últimos 90 dias, não está inativo e não tem venda suspensa. Fora disso: fora de sortimento. Dentro: ruptura (disponível zero), crítico (cobertura abaixo do prazo de reposição do produto, com o prazo do grupo como reserva), atenção (abaixo do prazo mais uma margem), saudável, excesso (acima do estoque alvo em dias) e sem giro. Todos os limiares ficam numa tabela ou bloco de parâmetros, nunca espalhados na consulta.
Ordene os produtos pela receita dos últimos 90 dias e acumule: até 80% da receita é A, até 95% é B, o resto é C. Recalcule todo dia na janela móvel. Produto sem venda na janela fica sem curva ("SEM_CURVA"), não C.
Consulta SQL na Nekt é sem estado: para ter série, use notebook que acrescenta a foto. Duas medições por dia (abertura de manhã e fechamento à noite, em horário de Brasília), classificadas pela hora antes ou depois do meio-dia para resistir a mudança de agendamento. Grave saldo zero. Um passo diário depois do fechamento expurga além da retenção e deixa uma linha por produto, filial, dia e medição. Sem foto, reconstrua o dia pelo razão de estoque: o último movimento do dia dá o saldo e dias sem movimento herdam o anterior.
Necessidade líquida = requisição aberta menos (disponível + pedido de compra aberto), por produto e curva. Venda perdida estimada = venda média diária x dias em ruptura no período x preço médio, só para itens de sortimento ativo. Valor do estoque = quantidade x custo contábil. Produto com saldo e sem cadastro vai para uma tabela de exceção para o cadastro corrigir, fora do consumo analítico.
Semáforo de ruptura
Ordem de avaliação; parâmetros numa tabela única.
Definições
Armadilhas que já aconteceram
Uma consulta tirava os zeros à esquerda do código de um lado e o estoque do ERP mantinha. Praticamente nenhum SKU casava com o estoque até a chave virar texto com zeros.
Código canônico em texto, padding pela regra do ERP, nunca em SKU de marketplace.
Extrair o código do produto da URL amigável, em vez do campo de referência, deixou de fora cerca de 80% do estoque de um país.
Código do campo de referência do produto; slug só para extrair atributos quando não há campo.
Um marketplace devolvia uma quantidade fixa enorme para anúncios de estoque ilimitado e a cobertura do canal disparou.
Flag de sentinela com limiar validado e exclusão da soma.
O cálculo usava só o disponível. Ao incluir o estoque em trânsito para o armazém do marketplace, a cobertura daquele canal subiu cerca de cinco dias e alguns itens saíram do crítico.
Em trânsito no numerador da cobertura, como o BI de origem fazia.
O histórico foi montado como consulta SQL e cada execução sobrescrevia a anterior. Não havia como dizer quantos dias um item ficou zerado.
Notebook que acrescenta a medição, com saldo zero, dedup e retenção.
O campo de quantidade do cadastro vinha zerado para muitos itens com movimento. O saldo real estava no razão de movimentos.
Saldo pelo último movimento do razão, com forward fill nos dias sem movimento.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Para 10 produtos e 3 filiais, o disponível bate com a tela de estoque do ERP ou da plataforma no mesmo horário (diferença zero).
- Nenhum produto com estoque ilimitado ou sentinela entra na soma, e o saldo de um grupo de filiais espelho é igual ao de uma filial do grupo.
- O histórico tem no máximo uma linha por produto, filial, dia e medição, e inclui as linhas de saldo zero.
- Todo produto de sortimento ativo tem exatamente um status do semáforo, e a soma dos status é igual ao total de produtos.
- Para um produto de exemplo, a cobertura recalculada à mão com disponível, em trânsito e venda de 30 dias bate com a tabela.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Estoque e cobertura - Posição atual: uma linha por produto e filial. Histórico: uma linha por produto, filial, dia e medição (abertura ou fechamento, horário de Brasília). - Disponível = maior entre (total menos reservado) e zero. Em trânsito é coluna separada. Ilimitados e sentinelas ficam fora da soma. - Filiais espelho agregam pelo grupo de estoque, nunca somadas. - Código do produto é texto canônico com a regra de padding do ERP. SKU de marketplace resolve por alias, código direto ou sufixo de armazém. - Venda média diária = unidades de notas não canceladas que movimentam estoque nos últimos 30 dias / 30. - Cobertura em dias = (disponível + em trânsito) / venda média diária. Sem venda em 30 dias: sem giro, cobertura nula. - Status: FORA_SORTIMENTO, SEM_GIRO, RUPTURA, CRITICO, ATENCAO, SAUDAVEL, EXCESSO. Parâmetros na tabela de parâmetros. - Curva ABC por receita acumulada de 90 dias: A até 80%, B até 95%, C o resto. - Ruptura no período: use o histórico de medições de fechamento, não a posição atual. - Diga se o produto não existe no cadastro ou se existe e está sem estoque. - Informe a data e hora da última medição em toda resposta de disponibilidade. Exceções por cliente: - <cliente>: filiais <A> e <B> no grupo de estoque <grupo>. - <cliente>: estoque alvo <dias> dias; margem de atenção <dias> dias; prazo de reposição padrão <dias> dias. - <cliente>: limiar de sentinela do canal <canal> = <quantidade>.
Construa no meu workspace Nekt o caso "Estoque e cobertura" seguindo as regras em https://academy.nekt.com/industrias/varejo/estoque-cobertura.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Posição por país e produto-cor, cruzada com a venda do país pela mesma chave, e câmbio diário para valorizar.
Estoque no armazém de cada marketplace por SKU base, com estoque alvo em dias por canal.
Estoque de peças por empresa e fornecedor, com requisições de oficina e pedidos de compra na necessidade líquida.