← voltar para o blog

// produto / PDV

Hórus PDV: modernização de uma frente de caixa.

Um projeto para transformar um sistema PDV em uma base moderna, com frontend React, API separada, banco SQL Server e fluxo operacional.

O Hórus PDV representa bem um desafio comum: modernizar um sistema que precisa continuar pensando em operação real. Um PDV não pode ser apenas bonito. Ele precisa abrir caixa, vender, baixar estoque, registrar histórico, lidar com usuários, imprimir comprovantes e proteger regras de negócio.

Frontend para operação rápida

A frente de caixa exige pouca fricção. Botões precisam ser claros, produtos precisam aparecer com rapidez, pagamentos precisam orientar o operador e mensagens de erro devem explicar o próximo passo. React ajuda a organizar essa experiência com componentes, estados e telas reutilizáveis.

No balcão, cada segundo importa. O operador não pode depender de telas confusas, campos pequenos ou ações escondidas. A experiência precisa favorecer leitura rápida: produto, quantidade, preço, desconto, subtotal, forma de pagamento e status do caixa. Quando a interface deixa esses pontos evidentes, ela reduz erro operacional e acelera atendimento.

Regra de caixa é regra de negócio

Uma das regras mais importantes em um PDV é impedir venda sem caixa aberto. Parece simples, mas esse tipo de decisão não deve ficar apenas no botão do frontend. A tela pode bloquear o fluxo e orientar o usuário, mas a API precisa confirmar a regra antes de registrar a venda. Isso evita inconsistência quando uma requisição é refeita, quando há múltiplas abas abertas ou quando alguém tenta chamar o endpoint diretamente.

$ venda --validar
usuário autenticado → caixa aberto → estoque suficiente → pagamento → baixa de estoque

API separada para proteger regra

Ao separar a API, regras como abertura de caixa, fechamento, baixa de estoque, venda e histórico deixam de depender apenas da tela. Isso melhora segurança, facilita testes e permite que outros módulos conversem com o sistema de forma previsível.

Estoque precisa conversar com venda

Em sistema de frente de caixa, estoque não pode ser um módulo isolado. Quando uma venda é confirmada, a quantidade precisa baixar. Quando uma devolução acontece, a regra precisa decidir se o item volta para estoque ou se entra como perda, troca ou ajuste. Esses detalhes parecem operacionais, mas são fundamentais para relatório e compra futura.

Também é importante registrar histórico. Saber que o estoque mudou é pouco; o sistema precisa indicar por qual motivo mudou, quem executou a ação e qual venda, compra ou ajuste originou aquela movimentação. Esse rastreio é o que transforma o módulo em ferramenta de gestão.

Banco e testes importam no MVP

Mesmo em MVP, um PDV precisa ter dados consistentes. Por isso, SQL Server, scripts de banco e smoke tests ajudam a garantir que criar, editar, excluir, vender e consultar funcionem de ponta a ponta. Isso reduz regressões enquanto o produto evolui.

Para mim, MVP não significa descuidar das regras centrais. Significa entregar o menor conjunto que já opera com consistência. No caso do Hórus PDV, isso passa por autenticação, empresa, produtos, clientes, fornecedores, caixa, venda, estoque, histórico e configurações. Sem esse núcleo, a interface pode parecer pronta, mas ainda não sustenta uso real.

$ horus-pdv --fluxo
login → abrir caixa → selecionar produto → vender → baixar estoque → histórico

Comprovante e reimpressão fazem parte da experiência

Mesmo sem impressora fiscal conectada no ambiente de desenvolvimento, a prévia de impressão ajuda a validar conteúdo e ordem das informações: dados da empresa, itens, quantidade, valor unitário, total, forma de pagamento, operador e data. A reimpressão da última venda também é uma necessidade prática, porque comprovante pode falhar, cliente pode pedir segunda via ou o operador pode precisar conferir o fechamento.

Configuração precisa ser simples para loja pequena

Um PDV não pode exigir conhecimento técnico para operar preferências básicas. Dados da empresa, impressão, e-mail, tema, caixa, usuários e permissões precisam ficar em telas compreensíveis. Quanto mais simples a configuração inicial, menor a barreira para o sistema sair do teste e entrar em operação.

Essa simplicidade não significa remover controle. Significa nomear as opções de forma clara, mostrar feedback ao salvar e evitar que o usuário precise entender termos técnicos para decidir como quer usar o sistema.

O aprendizado principal

Sistemas de venda exigem equilíbrio entre UX e regra. Não adianta uma tela bonita que deixa vender sem caixa aberto, nem uma API completa que trava o operador. O produto precisa respeitar o balcão, o estoque e o fechamento financeiro.