Integração de WMS para pequenas operações de comércio eletrônico
A questão de quando um sistema de gestão de armazéns vale a pena integrar surge mais cedo do que a maioria das pequenas operações de e-commerce espera. As planilhas funcionam bem até que não funcionam mais — e o ponto de inflexão geralmente não é o volume de pedidos, mas a complexidade dos pedidos: múltiplos SKUs com rastreamento de variantes, kits, pedidos pendentes por falta de estoque em múltiplos locais de processamento e envio ou a necessidade de valores precisos de estoque disponível para promessa de entrega (ATP) no checkout. Este artigo cobre nossa experiência integrando o GreaterWMS com uma pequena operação de e-commerce: o que funcionou, o que exigiu mais planejamento do que esperávamos e onde as planilhas ainda são a resposta certa.
Por que GreaterWMS
GreaterWMS é um sistema de gestão de armazéns de código aberto com uma API REST, um backend Django e um frontend Vue. Ele suporta estoque em múltiplos armazéns, rastreamento de lotes e lotes de produção, gerenciamento de pedidos de entrada e saída e relatórios básicos. O código-fonte é ativamente mantido e a documentação da API, embora não seja exaustiva, cobre as operações principais.
Escolhemos o GreaterWMS em vez de alternativas hospedadas por dois motivos. Primeiro, já executávamos uma infraestrutura auto-hospedada e não queríamos adicionar outra dependência SaaS com precificação por pedido em escala. Segundo, a natureza de código aberto significava que poderíamos estender o modelo de dados sem esperar por um ciclo de solicitações de recursos ao fornecedor. Para uma pequena operação com necessidades específicas de rastreamento da validade dos lotes, essa flexibilidade importava.
Nossa implantação é uma stack Docker Compose com o aplicativo Django, PostgreSQL e Redis; o arquivo Compose do projeto original inclui apenas os contêineres de frontend e backend, e as configurações padrão usam SQLite. Em um VPS modesto, ele é executado sem dificuldade ao lado de outros serviços. A configuração inicial leva algumas horas; o trabalho de integração leva consideravelmente mais tempo.
Padrões de integração de API
O GreaterWMS usa autenticação baseada em token. Cada usuário tem um token (o valor openid), que você passa em um cabeçalho de requisição personalizado token, em vez de passá-lo como um token Bearer no cabeçalho Authorization. Não há fluxo OAuth ou mecanismo de rotação de chaves de API integrado, o que significa que você deve criar um usuário de serviço dedicado com permissões mínimas em vez de usar uma conta de administrador.
A API segue, em grande parte, o padrão RESTful com payloads JSON. Os principais recursos com os quais você interage para uma integração de e-commerce são: goods (seu catálogo de produtos em termos de WMS), inventory (níveis de estoque atuais por armazém e produto), inbound orders (pedidos de compra e devoluções) e outbound orders (pedidos de clientes para processamento e envio).
Um padrão que estabelecemos cedo: nunca chamar a API do WMS de forma síncrona a partir do caminho de checkout. O WMS não está no caminho crítico da transação, e se ele estiver lento ou temporariamente indisponível, não deve afetar a capacidade do seu cliente de concluir uma compra. Todas as interações com o WMS passam por uma fila assíncrona. O checkout registra o pedido no seu banco de dados principal e publica um evento. Um worker em segundo plano recebe o evento e cria o pedido de saída no GreaterWMS. Após uma falha, o worker tenta novamente com espera progressiva exponencial (backoff); falhas persistentes geram alertas. Esse desacoplamento é inegociável.
Sincronização de pedidos
A chamada de criação de pedido de saída recebe um ID de produto, uma quantidade e informações de endereço de destino. O mapeamento entre os itens do seu pedido de e-commerce e os IDs de produtos do WMS precisa ser mantido explicitamente. Armazenamos o ID de produto do WMS como um campo adicional em cada variante de produto no nosso banco de dados de catálogo. Esse mapeamento é definido manualmente quando um novo produto é criado e verificado no worker de sincronização antes de despachar a solicitação de criação do pedido de saída.
A sincronização de status funciona na direção oposta: o GreaterWMS atualiza o status do pedido de saída conforme o armazém o processa, e seu sistema de e-commerce precisa refletir isso. O GreaterWMS não envia atualizações de status; você faz polling. Executamos uma tarefa de consulta periódica (polling) a cada poucos minutos que consulta pedidos de saída com status “em andamento” e verifica se o status mudou para “despachado” ou “cancelado”. Quando isso acontece, atualizamos o pedido correspondente no nosso banco de dados de e-commerce e acionamos quaisquer ações subsequentes — e-mails de notificação ao cliente, atualizações de número de rastreamento.
A idempotência na criação do pedido de saída é importante. Se o worker em segundo plano tentar novamente após uma falha transitória, ele não deve criar pedidos de saída duplicados no GreaterWMS. Armazenamos o ID do pedido de saída do WMS no nosso registro de pedido interno imediatamente após uma chamada de criação bem-sucedida. Em uma nova tentativa, o worker verifica se um ID do WMS já existe antes de fazer a chamada de criação. Se existir, o worker pula a criação e prossegue com qualquer ação subsequente que estava tentando executar. Essa verificação não cobre uma chamada de criação que é bem-sucedida no GreaterWMS, mas cuja resposta se perde antes de o ID ser armazenado; nesses casos, ainda é necessário fazer uma conciliação com o WMS antes de tentar novamente.
Atualizações de estoque
Manter as contagens de estoque do seu e-commerce sincronizadas com o WMS é a parte que requer mais atenção contínua. Há duas direções: sua plataforma de e-commerce precisa de níveis de estoque precisos para evitar vendas acima do estoque disponível, e o WMS precisa refletir compras e devoluções que se originam fora dele.
Para consultar os níveis de estoque, obtemos snapshots do estoque da API de estoque do GreaterWMS de forma programada e gravamos os valores em um cache Redis que a loja de e-commerce lê. O intervalo de polling depende da sua velocidade de vendas. Para produtos de giro lento, de hora em hora é suficiente. Para produtos que vendem em picos, você precisa de um intervalo menor ou de um modelo de reserva — onde um cliente colocando um item no carrinho reserva temporariamente o estoque independentemente do ciclo de sincronização do WMS.
As devoluções são o caso mais complexo. Um item devolvido pode retornar ao estoque, ir para um local de quarentena para inspeção ou ser baixado. O GreaterWMS tem um fluxo de pedido de entrada para devoluções, mas mapear os estados de devolução do seu e-commerce para os estados de pedido de entrada do WMS exige um mapeamento definido explicitamente. Criamos uma máquina de estados que traduz os códigos de motivo de devolução do sistema de e-commerce em códigos de destinação do WMS, e revisamos o mapeamento com a equipe do armazém sempre que um novo motivo de devolução é adicionado. Sem esse mapeamento, o estoque devolvido deixa de reaparecer no estoque disponível sem que o problema seja percebido.
Condições de corrida e estoque de reserva
Mesmo com a sincronização de estoque baseada em polling, condições de corrida são possíveis. Se dois pedidos chegarem simultaneamente e ambos lerem o mesmo nível de estoque em cache antes que qualquer um deles seja refletido no WMS, você pode vender acima do estoque disponível pelo total de unidades vendido durante o intervalo entre consultas. Para produtos onde a venda acima do estoque disponível é inaceitável — itens de edição limitada, perecíveis com restrições rígidas de lote — a abordagem correta é uma camada de reserva que reduz a quantidade disponível localmente no checkout e concilia com o WMS de forma assíncrona.
Uma mitigação mais simples é o estoque de reserva: manter uma contagem disponível no seu banco de dados de e-commerce que é o nível de estoque do WMS menos uma pequena reserva. Os pedidos consomem esse saldo. Quando o saldo chega a zero, o produto aparece como fora de estoque, mesmo que o WMS ainda mostre unidades. Isso cria um pequeno risco de manter estoque que os clientes não podem pedir, mas reduz o risco de venda acima do estoque disponível e não requer nenhuma lógica de reserva. Para a maioria das pequenas operações, essa abordagem oferece o equilíbrio adequado.
Quando usar um WMS em vez de planilhas
Um sistema de gestão de armazéns adiciona complexidade de integração, sobrecarga operacional e um novo sistema para manter. Antes de se comprometer com uma integração, vale a pena avaliar com honestidade se os problemas que você está tentando resolver realmente exigem um WMS.
As planilhas são adequadas quando: sua contagem de SKUs é pequena e estável, você tem um único armazém ou local de processamento e envio de pedidos, os pedidos são processados manualmente e o volume é baixo, e você não precisa de valores de estoque disponível para promessa de entrega (ATP) em tempo real no checkout. Nesse caso, uma integração de WMS custa mais para implementar e manter do que o custo dos problemas que resolve.
Um WMS começa a valer a pena quando: você tem múltiplos armazéns ou locais de separação, você precisa de rastreamento de lote ou lote de produção por razões de conformidade ou qualidade, sua taxa de devolução é alta o suficiente para que a destinação dos itens devolvidos precise de tratamento sistemático, ou seu processamento de pedidos é automatizado e requer reserva precisa de estoque para evitar vendas acima do estoque disponível. Esses são problemas operacionais que as planilhas não conseguem resolver com um nível razoável de rigor.
O trabalho de integração que descrevemos neste artigo levou várias semanas de trabalho de engenharia, incluindo testes. Esse tempo poderia ter financiado uma quantidade significativa de trabalho manual de coordenação de armazém. Seja preciso sobre quais problemas você está resolvendo e se o software é a ferramenta certa para eles antes de começar.