Regras de Negócio - LucasXRosas/utfprarena GitHub Wiki

Aqui está o documento atualizado com as suas novas regras. As alterações foram feitas para refletir a régua de notificações a cada 7 dias e o bloqueio automático após 30 dias de atraso (1 mês de inadimplência em uma fatura), mantendo a coerência na reativação e nas permissões do sistema.

Regras de Negócio

Esta página detalha a lógica financeira do sistema, especificando as regras que o back-end deve seguir para automatizar a cobrança, o bloqueio por inadimplência e a reativação de contas.

1. Ciclo de Vida da Mensalidade

A gestão financeira de cada aluno obedece ao fluxo padrão abaixo:

  • Geração: A cada 30 dias, o sistema gera uma nova fatura vinculada ao plano do aluno com o status PENDENTE.
  • Vencimento: Toda fatura possui uma due_date (data de vencimento). Caso a data atual ultrapasse a data de vencimento e o status continue PENDENTE, a fatura é considerada em atraso.
  • Liquidação: Quando o pagamento é confirmado, o status muda para PAGA e o campo paid_at armazena o momento exato da baixa.

2. Lógica de Bloqueio Automático (RN001)

A suspensão temporária do direito de uso da arena (acesso às quadras e reservas) ocorre de forma automatizada assim que o aluno atingir 30 dias consecutivos de atraso (1 mês) em pelo menos uma fatura pendente.

Critério Técnico para Bloqueio

Para que o gatilho de bloqueio seja disparado, a rotina diária do sistema (Cron Job) deve identificar que o aluno cumpre o seguinte requisito no banco de dados:

  • Possuir pelo menos 1 fatura com status = 'PENDENTE'.
  • A referida fatura deve estar com a due_date há 30 dias ou mais em relação à data atual (current_date >= due_date + 30 dias).

Exemplo Prático

  • Fatura: Venceu em 10/05 (due_date = 10/05) com status PENDENTE.
  • Cenário: Em 09/06 (29 dias de atraso), o status permanece ativo. Em 10/06 (30 dias de atraso), o sistema dispara o gatilho e altera o status do usuário automaticamente para BLOQUEADO.

3. Régua de Cobrança e Notificações Preventivas (RN002)

Durante o período de tolerância de 30 dias, o sistema dispara notificações automáticas a cada 7 dias a partir do vencimento para incentivar a regularização antes do bloqueio definitivo:

  • No dia do vencimento (Dia 0): Envio de lembrete de cobrança preventiva no dia do vencimento.
  • Após 7 dias de atraso (Aviso 1): Envio do primeiro aviso formal de pendência financeira.
  • Após 14 dias de atraso (Aviso 2): Envio do segundo aviso, alertando sobre o meio do prazo de tolerância.
  • Após 21 dias de atraso (Aviso 3): Envio do último alerta preventivo, informando que o bloqueio automático ocorrerá em 9 dias caso o débito não seja regularizado.
  • Após 30 dias de atraso (Notificação de Bloqueio): Envio de notificação informando que o acesso à arena foi suspenso/bloqueado devido ao atraso superior a 1 mês.

4. Lógica de Reativação Automática / Desbloqueio Dinâmico (RN003)

A reativação da conta e a liberação imediata do acesso do aluno ocorrem de forma automatizada assim que o aluno quitar a(s) fatura(s) que possui(em) mais de 30 dias de atraso.

O aluno não precisa necessariamente quitar todo o histórico de dívidas se houver outras faturas mais recentes dentro do prazo de tolerância (com menos de 30 dias de atraso). Basta eliminar a pendência que gerou a restrição para sair da zona de bloqueio.

Exemplo Prático

  • O aluno possui 1 fatura atrasada há 35 dias e 1 fatura atrasada há 5 dias (Status: BLOQUEADO).
  • O aluno realiza o pagamento apenas da fatura de 35 dias.
  • A fatura restante possui apenas 5 dias de atraso (dentro do prazo tolerado de 30 dias).
  • O sistema identifica que não há mais nenhuma fatura com $\ge 30$ dias de atraso e altera o status do usuário de volta para ATIVO instantaneamente.

5. Impacto do Status BLOQUEADO no Sistema

O status do usuário afeta diretamente as permissões do back-end através dos Middlewares de Autenticação:

  • Bloqueio no Login (Opcional): Ao tentar autenticar, o sistema pode retornar o token JWT normalmente, mas deve incluir a flag status: 'BLOQUEADO' para que o front-end exiba um aviso financeiro na tela.
  • Bloqueio de Ações Básicas (Obrigatório): Qualquer rota de agendamento de quadras, check-in ou inscrição em campeonatos (Ex: POST /reservas, POST /checkin) deve validar o status no banco de dados e recusar a operação caso o retorno seja BLOQUEADO.