AlliahEstoque
Sistema operacional de inventário com IA agêntica: sente a demanda, prevê rupturas e excessos, recomenda e — com aprovação — executa as ações corretivas.
Números do ambiente de demonstração, calculados sobre uma base semeada de 90 dias. A acurácia real da previsão é medida por SKU e aparece na tela de Previsão, com o método escolhido e o intervalo — as contas que produzem cada um desses números estão abertas mais abaixo, em "A matemática por trás".
A IA agêntica observa, prevê e age — e só te interrompe quando há uma decisão de verdade a tomar.
Acompanha o giro em tempo real e entende o consumo real de cada SKU, dia após dia.
Antecipa faltas e sobras antes que aconteçam, com janela e quantidade recomendadas.
Recomenda e, com a sua aprovação, executa a reposição automaticamente. Você decide, ela faz.
Sem ruído. Só te chama quando precisa de uma decisão — nunca para informar o óbvio.
Interface estilo Linear / Stripe / Mercury: rápida, limpa e feita para você ler num relance.
Produtos e movimentações fluem para o AlliahEstoque em tempo real.
Sente a demanda e prevê ruptura ou excesso para cada SKU continuamente.
Sugere ações corretivas e, com a sua aprovação, executa a reposição.
Você só entra em cena quando há uma decisão de verdade a tomar.
Faltar é venda perdida. Sobrar é dinheiro parado no galpão. A maioria dos sistemas mostra o saldo e deixa a decisão inteira com você.
Tem cem unidades, mas trinta estão reservadas para pedidos de marketplace e quarenta estão em quarentena. Vender as cem é vender o que não existe — e o sistema não avisa porque, para ele, tudo é "estoque".
O ponto de pedido é um número redondo que alguém digitou há dois anos. Ele não sabe que a demanda dobrou, que o fornecedor está atrasando ou que dezembro é diferente de fevereiro.
Dois marketplaces vendem a mesma última unidade no mesmo segundo. Quem descobre é o cliente, por e-mail de cancelamento — e a conta é reputação, não estoque.
"Deixa vinte de reserva." Vinte para um item que vende dois por dia e é entregue em cinco é excesso; para um que vende trinta e demora vinte dias, é ruptura garantida. O número certo depende de três variáveis, e nenhuma é redonda.
Sem controle por lote e validade, o que chegou primeiro sai por último. A perda é registrada como quebra e ninguém liga ao fato de que dava para ter vendido com desconto trinta dias antes.
Quarenta alertas por dia viram ruído em uma semana. O que falta não é aviso: é uma fila curta e ordenada do que muda o resultado hoje, com o valor em reais de cada linha.
A regra da casa: estatística para número, linguagem para narrativa. Nenhuma previsão desta ferramenta sai de um modelo de linguagem.
Cada produto em cada local tem seis contadores disjuntos: em mãos, alocado, em trânsito, em pedido, quarentena e consignado. "Em mãos" significa livre — o que já está reservado não está mais lá.
É o que permite a pergunta que importa: a posição projetada, que é o em mãos somado ao que está a caminho e ao que foi pedido. Vender olhando o saldo bruto é o erro mais comum do setor.
Toda escrita passa por um caminho só: lê a posição, aplica o movimento (que recusa qualquer estado que ficaria negativo), grava o movimento e atualiza a posição — tudo na mesma transação.
A posição é uma projeção, não a verdade. A verdade é a sequência de movimentos, e existe uma função que reconstrói a posição inteira replicando o histórico. A carga de demonstração usa exatamente ela: antes de gravar qualquer posição, o roteiro reconstrói a partir dos movimentos e falha se não bater.
As escritas são serializadas: uma trava no processo põe as reservas em fila, e a checagem de saldo acontece dentro da transação. Vinte e cinco reservas simultâneas de uma unidade com dez em estoque resultam em exatamente dez sucessos e quinze recusas — e isso é um teste que roda contra um banco de verdade, não um comentário no código.
A recusa chega em português para quem está na tela: "estoque insuficiente — oversell bloqueado pelo motor de reserva".
Para cada SKU, quatro estimadores clássicos são testados: média móvel, suavização exponencial, Holt (que captura tendência) e ingênuo sazonal. O sistema separa uma janela final da série, prevê para trás, mede o erro percentual de cada um e escolhe o vencedor por SKU.
O método escolhido e o erro medido aparecem na tela junto com a previsão. Um número previsto sem o erro dele ao lado é uma opinião disfarçada de dado.
Não é um número redondo: sai da fórmula clássica que combina a variação da demanda e a variação do prazo do fornecedor, ponderadas pelo nível de serviço desejado. O fator de serviço vem de uma aproximação da normal inversa calculada no próprio código.
Cada sugestão vem com o motivo escrito em português, montado com os números reais daquele item — não um rótulo genérico de "reposição sugerida".
Lotes ordenados por validade, com faixa de status: vencido, crítico até quinze dias, atenção até quarenta e cinco, e o resto em dia.
Quando o giro não escoa o lote antes do vencimento, o sistema recomenda um desconto proporcional à distância entre o tempo de escoamento e o prazo restante, limitado a metade do preço. E recusa-se a sugerir desconto para lote vencido: aí a recomendação é bloquear ou descartar, não vender.
Um agente de previsão sinaliza itens de alta volatilidade que não são cauda longa; um de reposição transforma a sugestão em ação executável; um de exceção separa dois casos que ninguém pode deixar passar: ruptura em item classe A e excesso em perecível.
Cada decisão carrega o porquê, a lista de evidências, a confiança e a severidade — e nasce marcada como sandbox, ou seja, sem efeito real até alguém aprovar. Isso é uma constante no código, não uma configuração que dá para esquecer ligada.
A saúde do inventário é uma nota de zero a cem, composta por quatro partes com peso declarado: disponibilidade, cobertura adequada, eficiência de capital e acurácia da previsão. O anel mostra a nota; as quatro barras ao lado mostram de onde ela veio.
Abaixo dela, a fila do dia: o que precisa de decisão, cada linha com o motivo, o impacto em reais e a confiança — e sinais com atalho direto para a tela filtrada.
Se um número aparece na tela, ele saiu de uma destas fórmulas. Todas determinísticas, todas cobertas por teste.
O alocado não entra porque já saiu do em mãos — os estados são disjuntos. É essa a diferença entre "tenho cem" e "posso vender cem".
Onde z é o fator do nível de serviço, LT o prazo de entrega, σ_d a variação da demanda diária e σ_LT a variação do prazo do fornecedor. Fornecedor irregular exige mais reserva mesmo com demanda estável — e essa é a metade da fórmula que quase todo mundo esquece.
Quando a posição projetada cai abaixo do ROP, nasce uma sugestão. A quantidade fecha o gap até um nível-alvo que cobre prazo mais ciclo de revisão, para não gerar sugestão nova a cada consulta.
Item sem demanda registrada não é classificado como ruptura — sem giro, cobertura infinita não quer dizer nada, e forçar um número ali seria inventar.
Calculada sobre a receita real dos últimos 90 dias, ordenada e acumulada. A classificação XYZ é separada e mede regularidade: coeficiente de variação abaixo de 0,25 é X, abaixo de 0,5 é Y, o resto é Z.
O custo das vendas é anualizado a partir da janela de 90 dias. Estoque morto é definido explicitamente: menos de cinco unidades vendidas em 90 dias com valor parado maior que zero.
Só é sugerido quando o giro atual não escoa o lote a tempo. Lote já vencido não recebe sugestão de desconto — recebe recomendação de bloqueio.
Pesos fixos e visíveis. A nota nunca aparece sozinha: as quatro parcelas são desenhadas ao lado dela, porque um índice composto sem as partes é um número que ninguém sabe consertar.
O vocabulário do motor. Cada movimento move quantidade entre estados, e nenhum outro caminho grava estoque.
| Estado | Significa | Entra na projeção? |
|---|---|---|
| em_maos | Fisicamente no local e livre para vender. | Sim |
| alocado | Fisicamente no local, mas já reservado para um pedido. | Não — já foi prometido |
| em_transito | Saiu de outro local da empresa e ainda não chegou. | Sim |
| em_pedido | Pedido ao fornecedor, ainda não embarcado. | Sim |
| quarentena | Retido para conferência, avaria ou bloqueio de qualidade. | Não |
| consignado | No local, mas de propriedade de terceiro. | Não |
| Movimento | Efeito |
|---|---|
| entrada | Soma ao em mãos. Compra recebida, devolução de cliente, produção. |
| saida | Subtrai do em mãos. Venda expedida, perda, consumo interno. |
| ajuste | Define o saldo final; o sistema deriva a diferença. É o resultado da contagem cíclica. |
| reserva | Move do em mãos para o alocado. É aqui que o oversell é barrado. |
| liberar_reserva | Devolve do alocado para o em mãos quando o pedido cai. |
| transferencia_saida | Retira do em mãos na origem. |
| transferencia_em_transito | Credita em trânsito no destino, com a mesma referência da saída. |
| transferencia_entrada | Converte trânsito em em mãos no recebimento. |
| pedido_compra | Soma ao em pedido. É a única ação de agente que grava algo. |
| cancelar_pedido | Retira do em pedido. |
| quarentena_entrada | Move do em mãos para quarentena. |
| quarentena_liberar | Devolve de quarentena para o em mãos. |
Um contêiner só, sem serviço externo — e a escolha de banco é a decisão mais incomum do projeto.
App Router com React 19 e Tailwind 4. As telas leem no servidor; as escritas são ações de servidor. Não existe uma rota de API sequer na aplicação.
PGlite é o Postgres compilado para WebAssembly, rodando dentro do processo. Sem serviço, sem porta, sem cliente externo — e ainda assim Postgres, com enumerações e índices de verdade.
Motor de estoque, previsão, reposição, FEFO e agentes são funções sem entrada e saída de dados — recebem números, devolvem números. É o que torna cada regra testável isoladamente.
Migração e carga rodam na construção da imagem. O contêiner sobe com a demonstração pronta e mantém os dados em volume; recriar o volume recria a mesma base.
A serialização das escritas que garante o anti-oversell é uma trava no processo, não no banco. Isso é correto e suficiente com um processo só — e deixa de valer no instante em que a aplicação escalar horizontalmente ou for para um ambiente sem estado.
A saída está desenhada: as migrações são de Postgres padrão, então trocar para um Postgres gerenciado é mudar a conexão e substituir a trava por bloqueio de linha no próprio banco. Está documentado no repositório como dívida assumida, e é assim que preferimos que apareça aqui também.
Uma loja fictícia com três locais — um centro de distribuição em São Paulo, uma loja no Rio e um operador logístico em Extrema — e 36 produtos em cinco categorias de varejo brasileiro, dos quais vinte e um são perecíveis.
Marketplace, loja virtual própria e PDV disputando o mesmo saldo. O motor de reserva é o que impede a mesma última unidade de ser vendida duas vezes.
tela · canaisCentro de distribuição, loja e operador logístico. Transferência em três etapas, com o material aparecendo como em trânsito enquanto está na estrada.
tela · estoque e transferênciaSuplemento, cosmético, alimento e ração. Lote com validade, ordenação por vencimento e desconto sugerido enquanto ainda dá tempo de vender.
tela · validadeFila ordenada por urgência com quantidade sugerida, motivo escrito e o botão de aprovar em cada cartão. Aprovar registra o pedido no estoque na hora.
tela · reposiçãoGiro, cobertura em dias, curva ABC por receita real, estoque morto e margem — calculados sobre os últimos 90 dias, não sobre a intuição da diretoria.
tela · relatóriosServe como contraexemplo útil: aqui a previsão é estatística clássica, com o erro medido e exibido. Vale comparar com ferramentas que prometem previsão por modelo de linguagem e não mostram o erro.
avaliação · previsão auditávelDezoito páginas no total. Abaixo, o que sai de cada frente — e a seção de limites diz o que ainda não sai em arquivo.
Zero a cem, com as quatro parcelas desenhadas ao lado — disponibilidade, cobertura, capital e previsão.
O que precisa de decisão hoje, com motivo, impacto em reais e confiança. Curta de propósito.
Série histórica, linha tracejada de previsão, método escolhido, erro percentual e intervalo.
Agrupadas por urgência, com quantidade, motivo e aprovação em um clique que grava o pedido no estoque.
Ordenada por vencimento, com dias restantes, faixa de status e o desconto sugerido por lote.
Todo movimento com tipo, quantidade, motivo, referência, usuário e horário — a base para reconstruir qualquer saldo.
Cada decisão com porquê, evidências, confiança, severidade e a marca de sandbox — mais a ação recomendada.
Giro, cobertura, valor total, capital parado, estoque morto, margem, curva ABC e os campeões de receita.
Prazo prometido contra prazo real, taxa de atendimento, capital sob cada um e uma nota de confiabilidade.
Perguntas sobre o estoque respondidas com dados do banco, por intenções determinísticas — sem modelo de linguagem no meio.
A parte mais curta desta página, porque hoje o AlliahEstoque não conversa com nenhum sistema externo.
Marketplace, loja virtual e ponto de venda existem como registros com status de sincronização e fila de pedidos pendentes, e a tela tem um simulador de pedido que exercita a reserva de verdade. O que não existe é conector: nada chama a API de marketplace nenhum.
O motor de reserva anti-oversell — a parte difícil — está pronto e testado. O que falta é o encanamento até cada canal.
Existe uma camada trocável de provedor com implementação para Gemini, mas ela não é chamada por nenhuma tela, ação ou agente. Toda a inteligência que você vê é estatística e regra explícita.
A decisão de projeto está escrita no repositório: estatística para números, modelo de linguagem para narrativa — e nunca confiar o número cru ao modelo. Hoje o produto vai além disso e simplesmente não usa modelo.
Quer dizer: interface e domínio escritos em português, inclusive os nomes das colunas do banco; valores em real com separador brasileiro; campos de CNPJ e UF; catálogo, canais e categorias modelados no varejo brasileiro.
Não quer dizer: não há NCM, CFOP, CEST, ICMS, NF-e, NFC-e nem Pix. Não há módulo fiscal de espécie alguma. Se você precisa de emissão fiscal, precisa de outra coisa junto — e é melhor saber agora.
Curta e sem rodeio. Leia inteira antes de colocar dado real.
Quatro papéis e quatro permissões. Toda ação de escrita começa exigindo a permissão — a checagem não está só na interface.
Movimentos nunca são editados nem apagados; correção é um movimento novo. Qualquer saldo pode ser reconstruído a partir deles.
Sem chamada externa, sem provedor de IA ligado, sem telemetria. O banco vive dentro do próprio contêiner.
Toda decisão nasce em sandbox e a única ação que grava exige clique humano com permissão de aprovação.
Não existe tela de entrada. A sessão é uma constante no código, sempre com o papel de maior privilégio — então a matriz de permissões sempre passa. Mantenha a instalação em rede restrita.
Toda tabela carrega a organização, mas o isolamento depende de a consulta filtrar — não há isolamento por linha no banco.
Marca da casa: esta lista tem o mesmo destaque que a lista de recursos.
O custo do produto é um valor único e estático. Não há histórico de custo, média ponderada, PEPS nem UEPS — toda valoração é quantidade vezes esse custo fixo. Para contabilidade de estoque de verdade, falta essa camada inteira.
A tabela de lotes existe e alimenta a tela de validade, mas nenhum movimento consome um lote específico. A quantidade nos lotes e o saldo em mãos são dois números que nada reconcilia. FEFO aqui é relatório e recomendação, não separação.
Não há CSV, Excel nem PDF, em nenhuma direção. Cadastrar catálogo grande hoje é digitar. A própria tela de relatórios avisa que a exportação fica para a próxima iteração.
Aprovar uma reposição grava um movimento que soma ao "em pedido" — e só. Não existe documento de pedido com rascunho, envio, recebimento parcial e fechamento. Também não há sugestão de fornecedor por custo total.
"Aprovar auto-executáveis", "Configurar autonomia", "Ativar execução", "Simular" e "Exportar resumo" estão desenhados e inertes. Os que funcionam de verdade são os de aprovar de cada sugestão de reposição, e o simulador de pedido na tela de canais.
Há valores de teto por classe de curva ABC decidindo o rótulo "auto-executável" ou "requer aprovação". Nada executa automaticamente em nenhum caso: não existe caminho no código que dispense o clique.
A classe gravada no cadastro do produto vem da carga de demonstração; a tela de relatórios recalcula por Pareto sobre a receita real. As duas podem discordar, e é a recalculada que tem significado.
A parcela de acurácia da previsão no índice do cockpit está fixa no código, assim como a variação de sete dias mostrada ao lado. A acurácia calculada de verdade é a por SKU, na tela de Previsão.
A garantia anti-oversell depende de uma trava dentro do processo. Não escala horizontalmente nem sobrevive a execução sem estado sem antes trocar para um Postgres gerenciado com bloqueio de linha.
O produto é uma linha só: sem grade, sem combo, sem múltiplas unidades de medida com conversão, sem rastreabilidade por número de série.
Os agentes rodam quando a página é aberta, não em segundo plano. Não há tarefa agendada, não há transmissão de evento e as decisões dos agentes não são persistidas — são recalculadas a cada visita.
Setenta e nove testes cobrindo motor de estoque, previsão, reposição, FEFO, agentes, permissões e o fluxo crítico contra um banco real. Não há teste de componente nem de navegador.
Não no sentido de modelo de linguagem. Usa quatro métodos estatísticos clássicos e escolhe, para cada SKU, o que teve menor erro num teste retroativo. Nenhuma chamada a modelo generativo acontece em nenhum ponto do produto.
Isso é uma decisão de projeto, não uma limitação temporária: número previsto precisa de erro medido ao lado, e é isso que um modelo de linguagem não entrega.
Pela arquitetura, não pelo modelo. Existem três agentes que observam continuamente, decidem sozinhos o que merece atenção, produzem uma recomendação com evidências e confiança, e — num caso — geram uma ação executável. O que os torna agentes é a autonomia de decisão e a explicabilidade, não a tecnologia por baixo.
E todos nascem em sandbox: recomendam, não agem.
A reserva move quantidade de "em mãos" para "alocado" dentro de uma transação, e as escritas são serializadas. Se o saldo não cobre, a operação é recusada — não há caminho que grave um estado negativo.
O teste que garante isso dispara vinte e cinco reservas simultâneas de uma unidade com dez em estoque contra um banco de verdade, e exige exatamente dez sucessos e quinze recusas.
Não. Só uma ação grava alguma coisa — aprovar uma sugestão de reposição — e ela exige clique de alguém com permissão de aprovação. Toda decisão de agente carrega a marca de sandbox, que é uma constante no código, não uma configuração.
Os rótulos de "auto-executável" existem na tela, mas não há caminho de execução automática por trás deles.
Não. O banco é Postgres compilado para WebAssembly, rodando dentro do processo da aplicação. Sobe um contêiner e pronto — sem serviço de banco, sem porta exposta, sem senha para gerenciar.
A contrapartida está na seção de limites: isso amarra a aplicação a um processo só.
Ainda não. Os canais existem como cadastro com status de sincronização, e a reserva anti-oversell — que é a parte difícil — está pronta e testada. O que falta é o conector de cada marketplace. Não escrevemos "integração com marketplaces" na página principal por isso.
Não, e não há nada perto disso: sem NCM, CFOP, CEST, ICMS ou NF-e. "Nativo-BR" aqui significa o idioma, a moeda e o domínio modelados no varejo brasileiro — não módulo fiscal.
Para enxergar e decidir, sim: lotes ordenados por vencimento, faixa de status e desconto sugerido antes que vire perda. Para separar por lote, ainda não — nenhum movimento de estoque consome um lote específico. Está na seção de limites com todas as letras.
Hoje, digitando. Não há importação de planilha nem de CSV. Para um catálogo grande isso é impeditivo, e é a razão de constar entre os limites em vez de ser omitido.
Provavelmente porque a sua conta considera só a variação da demanda. A fórmula usada aqui soma também a variação do prazo do fornecedor — fornecedor que promete sete dias e às vezes entrega em quinze obriga a mais reserva, mesmo com venda perfeitamente estável.
E o nível de serviço adotado é alto por padrão, o que empurra o fator multiplicador para cima.
“ Pare de gerenciar estoque. Deixe o estoque se gerenciar — e te avisar só quando precisar de você.
Comece a prever rupturas e excessos hoje. A IA cuida do operacional — você cuida das decisões.