EVOLUÇÃO PARA PLATAFORMA SaaS MULTI-SERVIÇO

Você deve evoluir a aplicação existente para uma arquitetura SaaS profissional, mantendo intactos os módulos já implementados:

Processamento de relatórios

Geração de ZIP

Upload de relatório

Download de ZIP

Lógica de status

Fluxo operacional atual

⚠️ REGRA CRÍTICA:
Não reescrever módulos existentes.
Não alterar lógica validada.
Apenas expandir a arquitetura ao redor dela.

🎯 OBJETIVO

Transformar o sistema em uma plataforma:

Multi-tenant

Hierárquica

Multi-serviço (manual ou API)

Créditos por serviço

Permissões granulares

White label parcial

Isolamento total de dados

🧱 FASE 1 – HIERARQUIA DE CONTAS

Criar tabela:

accounts

id (UUID)

parent_id (nullable)

role (ADMIN | REVENDA | CLIENTE | OPERADOR)

nome

email_login

password_hash

ativo (boolean)

criado_em

Regras:

ADMIN → parent_id = null

REVENDA → parent_id = ADMIN

CLIENTE → parent_id = REVENDA

OPERADOR → vinculado a um CLIENTE ou REVENDA

Implementar validação de escopo:

Cliente só vê seus próprios dados

Revenda só vê contas cujo parent_id = ela

Admin vê tudo

Toda query deve obrigatoriamente filtrar por account_id.

🧩 FASE 2 – SERVIÇOS DINÂMICOS

Criar tabela:

services

id

nome

tipo (manual | api)

regra_cobranca (todos | enviados)

api_endpoint (nullable)

api_token (nullable)

ativo

criado_em

Regras:

Serviços são criados pelo ADMIN

Devem ser independentes

Cada serviço possui fluxo próprio

Manual usa fluxo operacional existente

API será implementado futuramente

💳 FASE 3 – CRÉDITOS POR SERVIÇO

Criar tabela:

account_service_balance

account_id

service_id

creditos_disponiveis

Criar tabela:

credit_transactions

id

account_id

service_id

tipo (credito | debito | estorno)

quantidade

campanha_id (nullable)

criado_em

Regras:

Cada serviço possui saldo independente

Nunca permitir saldo negativo

Toda movimentação deve gerar registro em credit_transactions

🧠 FASE 4 – INTEGRAÇÃO COM CAMPANHAS EXISTENTES

⚠️ NÃO REESCREVER O MÓDULO DE CAMPANHAS

Apenas adicionar campos na tabela existente:

Adicionar em campaigns:

account_id

service_id

total_numeros

creditos_reservados

finalizado_em

LÓGICA DE COBRANÇA

No momento da criação da campanha:

Verificar saldo do cliente para aquele serviço

Se insuficiente → bloquear

Se suficiente:

Se regra_cobranca = todos:
debitar total_numeros

Se regra_cobranca = enviados:
reservar total_numeros

Registrar transação

Após finalização da campanha:

Se regra_cobranca = enviados:

calcular total_enviados

estornar diferença

registrar estorno

Não alterar lógica de processamento de relatório.
Apenas usar resultado final já existente.

🔐 FASE 5 – ISOLAMENTO ABSOLUTO DE DADOS

Obrigatório:

Toda entidade deve conter account_id.

Toda consulta deve validar:

WHERE account_id = sessão.account_id

Revenda deve usar:

WHERE parent_id = sessão.account_id

Nunca confiar em dados vindos do frontend.

🎛️ FASE 6 – PERMISSÕES GRANULARES

Criar tabela:

feature_permissions

role

pode_criar_campanha

pode_ver_creditos

pode_baixar_zip

pode_subir_relatorio

pode_ver_relatorios

pode_gerenciar_usuarios

pode_ver_servicos

pode_personalizar

Implementar:

Backend valida permissões

Frontend exibe botões apenas se permitido

ADMIN pode editar permissões

🎨 FASE 7 – WHITE LABEL PARCIAL

Criar tabela:

branding

account_id

logo_url

primary_color

platform_name

Regras:

REVENDA pode configurar sua identidade

Cliente herda branding da revenda

ADMIN pode sobrescrever

🧠 FASE 8 – OPERADORES

Operadores:

Devem estar vinculados a serviços específicos

Devem ter acesso apenas ao módulo operacional

Não podem ver créditos

Não podem criar campanhas

Criar tabela:

operator_services

operator_account_id

service_id

Aplicar validação no download e upload:

Operador só acessa campanhas do service_id permitido.

🧩 FASE 9 – MANTER MÓDULO OPERACIONAL EXISTENTE

Reforçando:

Manter geração de ZIP atual

Manter processamento de relatório atual

Manter normalização de status

Apenas adicionar validação de account_id e service_id

Não alterar fluxo operacional já implementado.

🏗️ ORDEM DE IMPLEMENTAÇÃO

Criar estrutura de contas

Implementar hierarquia

Criar serviços dinâmicos

Criar sistema de créditos

Integrar créditos às campanhas

Implementar isolamento total

Implementar permissões

Implementar white label

Adaptar módulo operacional para validar service_id

🔒 REGRAS CRÍTICAS

Nunca permitir acesso cruzado entre clientes

Nunca permitir saldo negativo

Nunca remover funcionalidades existentes

Nunca reescrever lógica validada

Sempre validar service_id + account_id

🎯 RESULTADO ESPERADO

Uma plataforma:

Multi-tenant

Hierárquica

Multi-serviço

Crédito inteligente

White label parcial

Operacional robusta

Isolamento absoluto de dados