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.