Arquitetura do Sistema
2.1 Visão Geral
O sistema financeiro do CCMBR foi projetado para garantir controle total, rastreabilidade individual e precisão histórica de todas as movimentações envolvendo compras, vendas, leilões, consignações, créditos virtuais, Real Numismático e resgates.
O núcleo do sistema é a tabela caixa_ccmbr, onde cada operação gera um registro independente, contendo:
-
valores antes e depois,
-
tipos de movimento,
-
usuários afetados,
-
origem e destino,
-
hash de auditoria interna,
-
identificação de pedido, lance, leilão ou operação bancária.
Toda a arquitetura foi pensada para permitir controle financeiro granular, atendendo as necessidades de comércio especializado e colecionismo.
2.2 Fluxo Financeiro Central
2.2.1 Compras e Vendas (Preço Fixo e Leilões)
Toda compra gera:
-
Débito de 100% no comprador
-
Crédito distribuído entre os operadores, seguindo a regra definida:
-
80% → Vendedor
-
10% → Leiloeiro ou Agência (quando aplicável)
-
5% → CCMBR
-
5% → Nilton
-
Movimentações são registradas individualmente na tabela caixa_ccmbr.
2.2.2 Recompras
O saldo recebido por um vendedor pode ser reutilizado para novas compras, respeitando:
-
até 95% do valor recebido na compra anterior,
-
comissões aplicadas sempre no novo vendedor, estimulando fluxo interno e reduzindo necessidade de saques.
2.2.3 Leilões
-
Cada lance bloqueia temporariamente o valor ofertado no saldo do usuário.
-
O bloqueio é revertido se outro lance superar.
-
Após o encerramento, o lance vencedor gera:
-
um pedido normal,
-
uma operação financeira idêntica às vendas de preço fixo,
-
os registros correspondentes na tabela de caixa.
-
2.3 Consignação e Seguro Cooperativado
Quando um item entra em consignação:
-
Ele é automaticamente inserido no seguro cooperativado, mesmo sem pagamento direto do fornecedor.
-
Em caso de sinistro, o fornecedor recebe créditos internos para recompor estoque.
-
O sistema grava:
-
data de entrada,
-
data de venda,
-
percentual de seguro aplicável,
-
referência da peça.
-
O cálculo é proporcional ao período em que o item permaneceu consignado.
2.4 Gestão de Créditos e Saldos
2.4.1 Créditos Cash
-
Obtidos via vendas, PIX ou cartão.
-
Usados para recompras, leilões e resgates.
-
Registrados integralmente na tabela
caixa_ccmbr.
2.4.2 Créditos Troca
-
Obtidos exclusivamente via venda com preço fixo.
-
Não são convertíveis em reais.
-
Utilizados somente para recompras.
2.4.3 Controle de Saldo
O saldo pode ser:
-
recalculado pela
caixa_ccmbr(forma mais segura), ou -
mantido em cache no perfil (para performance, com auditoria cruzada).
Bloqueios temporários para leilões também são registrados.
2.5 Real Numismático (Moeda Física)
O sistema permite emissão e circulação do Real Numismático, utilizado principalmente por:
-
Presidentes de Sociedades,
-
Colecionadores organizados,
-
Operações de compra interna entre sócios.
Regras:
-
Presidente pode receber limite de crédito interno para comprar moedas dos associados.
-
Ele não pode comprar peças repetidas com finalidade de revenda.
-
Sócios só podem vender por meio de lojas cadastradas, gerando:
-
comissões na compra,
-
comissões na recompra.
-
2.6 Integração com PIX
O PIX é utilizado para:
-
aquisição de Créditos Cash,
-
conferências bancárias,
-
resgates.
Todos os pagamentos via PIX geram:
-
crédito ao usuário,
-
registro de débito interno equivalente,
-
associação com número de operação bancária para auditoria.
Chave PIX verificada garante segurança nos resgates.
2.7 Relação entre Módulos
Os módulos se comunicam respeitando a seguinte lógica:
-
Pedidos → geram operações financeiras
-
Leilões → geram pedidos especiais
-
Consignação → cria vínculos com seguro
-
Seguro → pode gerar créditos
-
PIX → cria créditos Cash
-
Real Numismático → gera ou consome saldo interno
-
Caixa → registra tudo
A tabela caixa_ccmbr é o ponto de convergência.
2.8 Observação Importante
No momento, algumas operações — como resgates via PIX, conferências e emissão do Real Numismático — são processadas manualmente pela administração e apenas registradas tecnicamente no sistema.
À medida que os fluxos forem aprovados e estabilizados, novas funções poderão ser incorporadas, sempre após testes internos.
Nenhuma automação é assumida como ativa antes de ser validada.
Comentário
