Plano de compra por departamento
As colunas em amarelo são lançamento seu. O resto o painel calcula.
Foto do estoque
No USE, extraia o Relatório de Estoque Saldo — sem marcar “produtos com estoque 0” nem “produto desativado” — e solte o arquivo aqui. É dele que saem a atribuição por loja e o custo com imposto.
Como este número é calculado, e onde ele ainda é frágil
OTB = estoque meta + venda prevista − estoque de partida − carteira. O estoque meta é a venda prevista multiplicada pela cobertura meta. É a mesma fórmula da planilha mestre. Positivo significa OPEN: ainda cabe compra. Negativo é OVER: já se comprou além do plano.
A carteira é digitada, e isso é uma fragilidade real. A rota de pedidos em aberto do ERP responde “Rota não permitida” — ela existe, falta liberar o nosso acesso. Enquanto isso, o que não for lançado aqui simplesmente não entra na conta, e o OTB dirá que cabe mais compra do que realmente cabe.
O custo aqui é o custo real, com imposto. A API devolve só o preço de compra; o imposto vem do fator medido na foto do estoque, por referência. Com ele a margem do painel dá 56,7% contra 56,4% do ERP — antes eram quatro pontos de diferença. É por isso que a foto precisa ser atualizada todo mês: se a alíquota mudar ou entrarem produtos novos, o fator envelhece sem avisar.
Como a visão por loja funciona. O plano continua sendo lançado uma vez só, para a rede. Ao escolher uma loja, a meta dela não é digitada de novo: é a fatia que aquela loja tem da venda daquele departamento nos últimos 12 meses. Essa fatia vem da loja onde o caixa passou o produto — dado exato, sem reconstrução no meio. Por isso os campos amarelos ficam travados no modo loja: para editar o plano, volte para Rede.
A atribuição por loja vem da foto, não do nosso cálculo. A transferência entre lojas não é publicada por endpoint nenhum — um lote ficaria creditado para sempre à loja que o comprou. A foto resolve por outro caminho: ela não diz por onde a mercadoria andou, mas diz onde ela está. Cada lote é repartido entre as lojas na proporção da foto, em peças inteiras, preservando a idade.
Isso levou a soma dos erros por loja de 22.143 para 5.101 peças — o CD, que aparecia com R$ 274 mil que não estavam lá, ficou exato. O que sobra são referências que não constam na foto (6% das peças, que continuam na loja de compra) e o excesso que temos contra o ERP, que é devolução e ajuste de inventário, não atribuição.
O CD não vende, então sua fatia é zero e ele aparece sempre como OVER. O estoque que está lá não entra em nenhuma loja quando se filtra — some da soma. É pouco, cerca de 3% do total, mas convém lembrar ao comparar loja a loja.
Clique num departamento para abrir os tipos, e num tipo para abrir as marcas. O plano continua lançado uma vez, por departamento: a meta de cada linha aberta é a fatia que ela tem da venda daquele departamento nos últimos 12 meses. Por isso as linhas abertas ficam travadas — meta por tipo não existe, é derivada.
A marca abre dentro do tipo, não ao lado dele. São 5 marcas por tipo em média contra 71 por departamento — e a pergunta fica melhor: “que marca pesa dentro de Tamanco Rasteiro” vale mais que “que marca pesa em Calçado Feminino”, onde se compara chinelo com bota.
Tipo com estoque e nenhuma venda em 12 meses aparece como “sem histórico”. Sem venda não há fatia, e sem fatia não há meta. Não é falha do cálculo: é o tipo que só encalha, e ele merece aparecer assim.