Cadastro de cobranças para usuários
Pré-requisitos de acesso
- Permissão (módulo):
processPaymentQueue - Licença/Feature: Nenhuma específica.
- Contêiner do menu: GERAL → grupo Cobranças (rota
/manage-recurrences)
O que é / quando usar
Esta tela cria cobranças recorrentes mensais que debitam o usuário dentro de uma janela de datas (início e fim). É a ferramenta para mensalidades, assinaturas, taxas administrativas e qualquer débito que precise se repetir por alguns meses contra o saldo de um cliente.
Diferente da Folha de pagamento (que paga o usuário em nome da empresa) e das Cobranças automáticas (perpétuas, por dia do mês), esta cobrança tem período definido: ao salvar, o backend calcula quantos meses cabem entre a data de início e a data de fim e agenda uma parcela por mês. Um job no FinanceManagementService (FMS) percorre essas parcelas pendentes e as aplica na data devida.
Pré-condições
- Permissão:
processPaymentQueuecadastrada para a role do operador (permissão dupla — enum CPM no backend + módulo dinâmico no DB; sem o módulo no DB o botão não aparece, mesmo com o enum correto). - Licença/Feature: Nenhuma específica.
- Dependências de outras telas: o usuário-alvo deve existir e estar
APPROVED— a cobrança debita o saldo dele (carteira de cripto ou conta digital BRL). O ID informado no modal é ouserIdTo(identificador interno do usuário), não o e-mail.
Passo a passo
- Acesse Cobranças → Cadastro de cobranças para usuários (rota
/manage-recurrences). - A listagem traz todas as cobranças já cadastradas, em ordem decrescente de criação, com o e-mail do usuário resolvido a partir do
userIdTo. - Clique em Criar nova cobrança para abrir o modal de cadastro.
- Preencha ID do usuário, Descrição, Moeda, Valor, Data de início e Data fim (formato
dd/mm/aaaa). - Confirme em Salvar. O backend grava a cobrança e gera as parcelas mensais entre as duas datas.
- Para remover uma cobrança, use o ícone de lixeira na linha; para abrir o usuário, use o ícone de olho (visibilidade), que navega para os detalhes do usuário.
Campos (modal de cadastro)
| Campo | O que é | Obrigatório? | Efeito no sistema/backend |
|---|---|---|---|
| ID do usuário | Identificador interno (userIdTo) do cliente que será debitado | Sim | Grava user_id_to em recurrently_charges (FMS). É o ID interno, não o e-mail. Define de quem o valor sai a cada mês. |
| Descrição | Texto livre que aparece no extrato/transação | Sim | Vira transactionDescription da transação de carteira ou o descritivo do crédito BMS. Máx. 250 caracteres no formulário / 140 no banco. |
| Moeda | Símbolo da moeda da cobrança (ex.: BRL, tBRL, símbolo de token) | Sim | Grava unit_of_money_requested. Decide o trilho de pagamento: se BRL, o débito é feito via conta digital (BMS giveUserBalance contra a conta principal); qualquer outro valor é tratado como transação de carteira cripto para a walletForBonus. |
| Valor | Quantia a debitar por parcela | Sim (> 0) | Grava amount_requested. Tratado como BigNumber no processamento (sem arredondamento). O mesmo valor é replicado em cada parcela mensal. |
| Data de início | Primeira competência da cobrança (dd/mm/aaaa) | Sim | Grava creation_date. É a data da primeira parcela. |
| Data fim | Última competência (dd/mm/aaaa) | Sim (≥ início) | Grava expiration_date. O backend calcula o nº de meses entre início e fim e cria uma parcela (recurrently_charges_payments) por mês. Se o intervalo for menor que ~1 mês, nenhuma parcela mensal extra é gerada. |
Como as parcelas são geradas
Ao salvar, o FMS calcula a diferença em dias entre início e fim e converte em meses (dias / 30). Para cada mês, cria um registro de parcela com applied = false e a data daquele mês. O scheduler de recorrências varre as parcelas pendentes e aplica cada uma na sua data, marcando applied = true ao concluir.
Ações e modais
- Criar nova cobrança: abre o modal
RecurrencyModalComponent. Valida que todos os campos estão preenchidos, valor > 0 e data fim ≥ data início antes de habilitar Salvar. - Salvar: envia para
POST /v1/recurrently/create. Em sucesso, fecha o modal e recarrega a lista. - Excluir (lixeira): chama
POST /v1/recurrently/deletecom orecurrencyId. Remove a cobrança e as parcelas mensais ainda não aplicadas. Após a confirmação a página é recarregada. - Visualizar usuário (olho): navega para os Detalhes do usuário do destinatário.
Regras de negócio / cuidados
Atenção
- O campo ID do usuário é o identificador interno (
userIdTo), não o e-mail. Pegue-o nos Detalhes do usuário. - A Moeda define o trilho:
BRLdebita pela conta digital; qualquer outro símbolo debita pela carteira cripto. Informar a moeda errada faz o débito sair do lugar errado (ou falhar por saldo/rota inexistente). - O número de parcelas depende exclusivamente do intervalo início → fim. Datas muito próximas podem não gerar nenhuma parcela mensal.
- Excluir uma cobrança apaga as parcelas pendentes, mas não estorna parcelas já aplicadas.
- Valores financeiros: tratados como BigNumber no scheduler — sem arredondamento; confira as casas decimais da moeda/token.
- Idempotência: cada parcela é aplicada com
externalIdigual aoidda parcela. Se o serviço reprocessar após crash, o FinLib retornaE00021("already processed") — isso é sucesso, não erro: o valor já foi debitado e a parcela é marcada como aplicada. - Status APPROVED: o usuário-alvo precisa estar aprovado para que o débito (carteira ou conta digital) seja efetivado.
Exemplos
Cenário 1 — Mensalidade de 6 meses em BRL
O operador cria uma cobrança para o usuário u-1234, descrição "Mensalidade Plano Pro", moeda BRL, valor 49,90, início 01/06/2026 e fim 01/12/2026. Ao salvar, o FMS gera 6 parcelas mensais (junho a dezembro). A cada mês o scheduler debita R$ 49,90 da conta digital do usuário para a conta principal via BMS, e marca a parcela como aplicada. Em dezembro, encerrada a janela, não há mais parcelas pendentes.
Cenário 2 — Taxa administrativa em token utilitário
Cobrança em moeda UTK (token utilitário), valor 10, início 01/06/2026, fim 01/09/2026. Como a moeda não é BRL, cada parcela vira uma transação de carteira que move 10 UTK da carteira do usuário para a walletForBonus configurada. São 3 parcelas (junho, julho, agosto). Útil para descontar taxas em token sem tocar a conta bancária.
Cenário 3 — Correção por exclusão antes do primeiro débito
Operador percebe que digitou o valor errado logo após cadastrar. Como nenhuma parcela foi aplicada ainda, ele clica na lixeira: a cobrança e todas as parcelas pendentes são removidas. Em seguida cria a cobrança novamente com o valor correto. Nenhum débito foi feito no intervalo.