AIAZHTabelas Principais: Produtos e Categorias
A tabela products é a fundação. Os campos incluem product_id (PK), sku (unidade de estoque única), barcode, product_name, description, category_id (FK), brand, unit_price, cost_price, tax_rate, unit_type (peça/kg/litro), is_active e image_url. A tabela categories organiza produtos hierarquicamente: category_id (PK), name, parent_category_id (FK autorreferenciado para subcategorias) e sort_order. Uma árvore de categorias bem projetada suporta relatórios departamentais.
Estoque e Gestão de Inventário
A tabela inventory rastreia níveis de estoque em múltiplos locais: inventory_id (PK), product_id (FK), store_id (FK), quantity_on_hand, quantity_committed (reservado para pedidos abertos), reorder_point, reorder_quantity e last_count_date. Uma tabela stock_movements registra cada alteração de estoque: movement_id (PK), product_id (FK), store_id (FK), movement_type (recebimento/venda/devolução/ajuste/transferência), quantity, reference_document, movement_date e performed_by. Esta trilha de auditoria é essencial para identificar discrepâncias durante contagens físicas de inventário.
Esquema de Transações de Vendas
O esquema de vendas segue um padrão cabeçalho-detalhe. A tabela sales_orders (cabeçalho) registra: order_id (PK), store_id (FK), customer_id (FK), employee_id (FK — o caixa), order_date, order_time, subtotal, discount_total, tax_total, grand_total, payment_status e order_status. A tabela sales_order_items (detalhe) captura cada item: order_item_id (PK), order_id (FK), product_id (FK), quantity, unit_price_at_sale, discount_percent, line_total e returned_quantity. Armazenar o unit_price_at_sale é crítico porque os preços dos produtos mudam ao longo do tempo.
Processamento de Pagamentos
A tabela payments lida com múltiplos tipos de pagamento por transação: payment_id (PK), order_id (FK), payment_method (dinheiro/cartão/UPI/crédito/vale), payment_amount, reference_number (para transações por cartão/UPI), payment_date e is_verified. Para pagamentos divididos, múltiplas linhas se vinculam ao mesmo order_id. Uma tabela separada registers gerencia operações de caixa: register_id (PK), store_id (FK), opening_balance, closing_balance, opened_by, closed_by, opening_date, closing_date, expected_cash e variance.
Gestão de Relacionamento com Clientes
A tabela customers armazena: customer_id (PK), first_name, last_name, phone, email, date_of_birth, anniversary_date, loyalty_points, total_spent, registration_date e is_vip. Uma tabela loyalty_transactions rastreia pontos ganhos e resgatados por pedido. Para redes de varejo, uma tabela customer_addresses suporta pedidos de entrega com múltiplos endereços. A tabela customer se integra com o esquema de vendas através do FK customer_id em sales_orders, permitindo funcionalidades como histórico de compras e ofertas personalizadas.
Arquitetura Multi-Loja
Para operações em rede, a tabela stores define cada local: store_id (PK), store_name, address, city, state, phone, tax_registration_number e is_active. Transferências entre lojas usam uma tabela transfer_orders: transfer_id (PK), from_store_id (FK), to_store_id (FK), product_id (FK), quantity, status (solicitado/aprovado/enviado/recebido), request_date e completion_date. Esta estrutura suporta relatórios centralizados enquanto permite operações descentralizadas.
Melhores Práticas para Banco de Dados POS
Use transações de banco de dados para cada venda — se qualquer inserção de item falhar, o pedido inteiro deve ser revertido. Indexe a coluna barcode para buscas de produto em menos de milissegundo no caixa. Implemente bloqueio otimista (coluna de número de versão) nas tabelas de estoque para evitar venda excessiva durante períodos de alta concorrência. Particione sales_order_items por order_date para consultas históricas rápidas. Sempre armazene valores monetários na menor unidade monetária (centavos) como inteiros para evitar erros de arredondamento de ponto flutuante.
