Software & automação · estudo de caso
Conferência de Estoque Bling
Um app web para celular e computador que busca produtos, ajusta estoque sem duplicar lançamentos e imprime etiquetas, integrado ao Bling.
Visão geral
O projeto em poucas palavras
A Conferência de Estoque Bling é a evolução web do aplicativo de conferência para desktop. Em vez de ficar preso a um computador, ele roda no navegador do celular, do tablet ou do computador e reúne, num só lugar, as tarefas do dia a dia do estoque: achar um produto, ver o saldo por depósito, corrigir um cadastro, ajustar a quantidade, cuidar das fotos e imprimir a etiqueta.
O projeto está em desenvolvimento e ainda não passou por um piloto com a operação.
Desafio
O ponto de partida
No chão do estoque, quem está com o celular na mão precisa encontrar um produto pelo nome, SKU, código de barras ou ID, conferir o saldo em cada depósito e corrigir o que estiver errado — sem lançar a mesma quantidade duas vezes se a conexão cair no meio da operação. Tudo isso passa pela API do Bling, que limita o número de requisições por segundo.
Solução
O que o aplicativo faz
Busca por vários caminhos: nome, SKU, GTIN, ID ou leitura do código pela câmera.
Detalhe do produto com saldos físico e virtual por depósito, localização, marca e fornecedores.
Edição cadastral de nome, SKU, preço e localização, com detecção de conflito quando outra pessoa alterou o mesmo produto.
Ajuste de estoque por entrada, saída ou balanço, com chave de idempotência: repetir o envio não duplica o lançamento.
Fotos do produto, hospedadas por API e sincronizadas com o Bling só depois da confirmação, para não deixar links quebrados.
Etiquetas de 5 × 8 cm e 10 × 15 cm em PDF, ZPL ou TSPL, para impressoras comuns e térmicas.
Segurança e rastreio: login individual, proteção contra requisições forjadas e registro de quem alterou o quê, com valores antes e depois.
Processo
Planejar antes de codar
O projeto foi conduzido por especificação. Um brainstorm virou um plano com 18 requisitos priorizados, seis marcos de release e critérios de aceite mensuráveis — por exemplo, busca abaixo de 1,5 segundo com cache aquecido e dimensões de etiqueta dentro de 1 mm. O plano também lista o que o sistema não faz: não substitui o Bling como cadastro principal e não executa ajustes sem uma ação explícita.
Na arquitetura, escolhi um monólito modular com um worker do mesmo código. Escritas passam por uma fila de comandos com registro local antes de chegar ao Bling; travas lógicas por produto e depósito evitam corridas; um limitador compartilhado respeita o teto de requisições da API; e os tokens de acesso ficam cifrados no banco.
Resultados
Estado atual
Os seis marcos foram implementados, com 101 testes automatizados passando (incluindo um teste ponta a ponta no navegador), além de análise estática e checagem de tipos sem erros. Uma auditoria interna feita antes do primeiro piloto gerou um plano de correções, que foi aplicado.
Faltam validações que dependem de fora do código: autorizar o aplicativo numa conta real do Bling para o teste de consultas, configurar o serviço de fotos e fazer o piloto num ambiente de homologação.
Aprendizados
O que guiou as decisões
Em software que altera estoque, o difícil não é a tela, é a retentativa: o que acontece quando a resposta se perde? Tratar idempotência, conflito e reconciliação como requisitos de primeira classe — e registrar por escrito o que o sistema não deve fazer — deu limites claros para o restante do projeto.