Rule assignment, recalculation, recovery fee — behaviour
The four endpoints of the apply right: writing the interest rule, recalculating outstanding balances, reviewing recovery fees and producing the EUR 40 fee document.
The apply function right (legacy permission table only, interest_v1.sql) opens four endpoints and the recovery fee buttons of the invoice list. Every endpoint also checks core modify and content scope (getAllowedCompanyIds, filterIdsByClients).
Endpoints
| Endpoint | Behaviour |
|---|---|
applyrule | Writes the interest rule onto the selected invoices narrowed to scope (invoice.interest_rule_id); error: error_apply_input. |
refreshall | Recalculates the outstanding balance of the filtered invoices from the transactions (recalcInvoiceOutstanding) and reports how many changed; with the interest right it also refreshes interest documents. Above 3,000 rows it returns an error (error_refresh_scope) and starts no background job. |
recheckrecovery | Refreshes the “paid on time” flags (refreshPaidOnTime), repairs base document links (repairRecoveryBaseLinks), revokes recovery fees that are no longer justified (revokeRecoveryFeesPaidOnTime) — keeping and listing settled documents — and gives diagnostics. |
generaterecovery | For the selected overdue invoices a EUR 40 recovery fee document at the MNB EUR rate of the first day of delay (dlbtfxrate), via addInvoice(): doc_type = recovery_fee, base_invoice_id = the base invoice, number derived from the base invoice; note and PDF. Skipped if a live fee exists; PDF error: error_recovery_pdf. |
Tables involved
Table names carry the installation's own prefix in the database: invoice, invoice_item, transaction_settlement; models: finance/invoice, finance/transaction, masterdata/analytic, company/company.
Known limitations
Above the 3,000-row limit refreshall does not queue a background job but returns an error; the user has to narrow the filter.