Documentação

English

Português
Español

English

Português
Español

Appearance

Recurring Charges (Manage recurring charges) ​

Access prerequisites

  • Permission (module): processPaymentQueue
  • License/Feature: None specific.
  • Menu container: GENERAL → group Charges (route /manage-recurrences)

What it is / when to use ​

This is the listing and management screen for monthly recurring charges that debit users over a defined period (start date → end date). It is the entry point for the Charges group (the root route /manage-recurrences of the menu): here the operator views all registered recurring charges, creates new ones, and removes existing ones.

The registration itself (form fields, installment generation, BRL × token rail) is documented in detail in Charge registration for users — this page focuses on the listing, columns, and actions of the screen.

Unlike Automatic charges (perpetual, executed by day of the month) and the Payroll (which pays the user on behalf of the company), recurring charges have a closed window: upon saving, the backend generates one installment per month between the two dates and a FinanceManagementService (FMS) job applies each installment on the due date.

Prerequisites ​

  • Permission: processPaymentQueue registered for the operator's role (dual permission — CPM enum on the backend + dynamic module in the DB; without the module in the DB the menu item/button does not appear, even with the correct enum).
  • License/Feature: None specific.
  • Dependencies on other screens: the target user of each charge must exist and be APPROVED — the charge debits their balance (crypto wallet or BRL digital account). The listing resolves the email of each charge by crossing userIdTo with the user list (CPM).

Step by step ​

  1. Go to Charges → Recurring Charges (route /manage-recurrences).
  2. The page loads in parallel the recurring charges (GET /v1/recurrently) and the user list, and displays the table already in descending creation order (coming from the backend).
  3. To create, click Create new charge — opens the registration modal (RecurrencyModalComponent). Fields and rules are in Charge registration for users.
  4. To inspect the client of a row, click the eye (visibility) icon: navigates to the user's Details.
  5. To remove a charge, click the trash icon.

Filters and columns ​

The screen is a listing (no search filters): it shows all registered recurring charges, paginated (5/10/25/100 per page, default 25).

ColumnWhat it showsData source
Start dateFirst billing period of the chargecreationDate (creation_date)
End dateLast billing periodexpirationDate (expiration_date)
DescriptionText that goes to the statement/transactiondescription
AmountAmount debited per installmentamountRequested (amount_requested) — treated as BigNumber in processing
CurrencySymbol of the charge's currencyunitOfMoneyRequested (unit_of_money_requested) — defines the rail (BRL via digital account × token via wallet)
UserEmail of the debited clientresolved from userIdTo crossed with the user list (CPM); not stored in the charge itself
ActionsTrash (delete) and eye (open user) icons—

The User column shows the email, but what the charge records is the userIdTo (internal ID). If the user is not found in the list, the email appears empty — the charge remains valid.

Actions and modals ​

  • Create new charge: opens the RecurrencyModalComponent. Upon saving, sends POST /v1/recurrently/create; on success, the list is reloaded. See fields and validations in Charge registration for users.
  • Delete (trash): calls POST /v1/recurrently/delete with the recurrencyId. Removes the charge and the monthly installments not yet applied; the page is reloaded after success. There is no confirmation modal — the click already triggers the deletion.
  • View user (eye): navigates to /users/informations/details of the recipient (User Details).

Business rules / considerations ​

Attention

  • Delete has no confirmation: one click on the trash already removes the recurring charge and its pending installments. Check the row (user, description, amount) before proceeding.
  • Deleting removes pending installments, but does not reverse already applied installments (debits already made).
  • The Currency defines the debit rail: BRL debits via the digital account; any other symbol debits via the crypto wallet. This is a value chosen during registration — check it in the Currency column when reviewing an existing charge.
  • The listing does not filter/search: on large databases, use pagination to locate the recurring charge.
  • Financial values: the Amount is treated as BigNumber in the FMS scheduler — no rounding; check the decimal places of the currency/token.
  • Idempotency: each installment is applied with an externalId equal to the installment's id. On reprocessing after a crash, FinLib returns E00021 ("already processed") — this is success, not an error: the amount has already been debited and the installment remains marked as applied.
  • APPROVED status: the target user must be approved for the debit (wallet or digital account) to be executed.