Internet caiu no meio do pico de vendas. Fila no caixa, cliente com o carrinho cheio e o sistema na nuvem fora do ar. Quem trabalha com varejo já viu isso acontecer.
No ERPPro, a gente resolveu isso com um PDV offline que é opcional e ligado em cada computador de caixa. Neste post eu conto como ele funciona e as decisões que tomamos.
O problema: ERP na nuvem x caixa que não pode parar
Um sistema em nuvem precisa de conexão para gravar a venda. Só que o caixa da loja não pode parar porque o link caiu. A saída foi separar duas coisas: registrar a venda e mandar a venda para o servidor.
Como funciona na prática
- Base local primeiro: o caixa precisa abrir o PDV pelo menos uma vez com internet. Nesse momento ele baixa uma cópia dos produtos e preços. Um computador que nunca se conectou não vende offline.
- Fila de vendas: sem internet, cada venda fica salva no próprio computador, numa fila.
- Envio quando a internet volta: com a conexão de volta, a fila é enviada e o sistema atualiza estoque e financeiro, sem duplicar venda.
O que funciona e o que não funciona offline
Escolhemos cobrir só o que trava a fila: a venda normal do caixa. Troca, pré-venda, cadastros, financeiro e relatórios continuam precisando de conexão. Um escopo menor deixa a sincronização mais simples e mais segura.
PDV offline não é contingência da NFC-e
Aqui muita gente confunde. O PDV offline cuida do registro da venda. A contingência da NFC-e cuida da emissão da nota fiscal quando não há comunicação com a Secretaria da Fazenda. Sem conexão e sem contingência instalada, a nota sai quando a internet volta. As regras mudam de estado para estado, então vale alinhar com o contador.
Escrevi a explicação completa, com perguntas frequentes, em como funciona o PDV offline.
Quando vale a pena ligar
- Loja com internet instável ou com um link só
- Horário de pico em que o caixa vira gargalo
- Mercadinhos, conveniências e lojas de alto giro
Para ver o caixa completo, tem a página do sistema PDV do ERPPro.
E vocês? No sistema de vocês, como evitam venda duplicada quando a fila offline sincroniza? 👇
Adriano Fernandes — ERPPro
Top comments (3)
Eu sistemas desse tipo, o que a gente costuma fazer aqui é pensar no funcionamento offline como padrão.
Desse modo sempre mantemos a maior parte do que a aplicação precisa para funcionar de maneira local, e com sincronizações periódicas de tempos em tempos. Por exemplo, cadastro de produtos, cada vez que produtos são criados ou atualizados eles recebem no registro um número que indica a versão do cadastro.
Por exemplo, se atualizei a descrição de um produto, aquele registro recebe o identificador incremental daquele evento, se atualizei ou cadastrei em massa, todos os registros da transação recebem o mesmo id do evento.
Assim a aplicação da estação só precisa buscar por registros a partir do evento que ela já tem. Se o cadastro de produtos que ela tem, o maior registro é de evento 1002, ela precisa buscar apenas do 1003 em diante. Assim, atualiza a base local inserindo e atualizando apenas os registros necessários.
Usamos números ao invés de datas, pois um número é mais simples de identificar e comparar, além de servir de contador de quantas alterações o cadastro recebeu ao longo do tempo. Outra utilidade é servir de identificador do processo para alguma auditoria.
As ações locais também são salvas primeiro de maneira local, e em background são enviadas ao servidor.
Valeu demais pelo comentário, Jhonny! 🙌
Gostei muito da ideia de usar um número de evento que só cresce em vez de data. Isso evita dor de cabeça com relógio desajustado entre a estação e o servidor, e de quebra o histórico já fica pronto pra auditoria. Marcar com o mesmo id todos os registros de uma atualização em massa também é uma sacada boa, porque a estação nunca fica com metade do lote.
Aqui a gente seguiu outro caminho: o offline é opcional e cobre só a venda do caixa, que é o que trava a fila. O resto continua online. Foi uma troca consciente: escopo menor, sincronização mais simples.
Fiquei curioso com uma coisa: no sentido contrário (estação → servidor), como vocês tratam conflito? Por exemplo, duas estações vendendo a última unidade do mesmo produto enquanto estavam offline. O servidor aceita as duas e deixa o estoque negativo, ou tem alguma regra de reserva?
Nos sistemas que criamos que funcionam dessa forma, o PDV não controla estoque, se o operador de caixa passou o código de barras do produto é porque fisicamente o produto está sendo vendido, mesmo que o sistema indique que o estoque acabou.
Se o sistema indica que há apenas uma peça, mas foram feitas duas vendas depois, então certamente o sistema estava com a informação errada, pois não tem como um produto ser registrado se ele não existe. A não ser que o operador de caixa tenha informado o código de barras manualmente.
Portanto, a consistência do estoque não é responsabilidade do PDV, um estoque negativo deve gerar um alerta para que a quantidade de estoque do produto seja analisada.
Imagine barrar a venda de um produto que está na mão do cliente porque o sistema indica que acabou.
Agora se você está lidando com um sistema de força de vendas, onde o produto será separado e enviado posteriormente ao cliente, nesse caso você precisa criar uma política para isso, mas normalmente quem chega primeiro fica com o produto, e depois o pedido que ficou sem gera um corte, ou gera um alerta para ser tratado por alguém.