Payment Fees Overdue Notification
This RFC describes the solution to implement a filtered email notification for Payment fees.
Abbreviations, acronyms, and definitions
- Notification: in this RFC context it is an email
- CSP Clients: Corporate Service Providers Clients
Reference Documents
| Reference | Document Location |
|---|---|
| Ticket | Ticket for payment fee overdue notification |
| Product requirements | Exclude invoiced fees from Fees Overdue email |
Problem Description
The Dealing Team is doing a manual process to review client details and communicate to clients the Fees pending to be paid (Payments and Invoices). This process creates a manual operation overload, which is error-prone, and we would like to automate the process.
Background
There is an Overdue Fees notification functionality already in place, but is currently not enabled as we want to avoid sending this communication to CSP Clients which have invoiced fees pending to be paid.
Solution
Considering the Overdue Fee notification is already created but inactive in production, we would like to revisit how is currently implemented, and adapt it to the required needs before proceeding to its activation. To increase efficiency of the Dealing Team and avoid extra work in communicate with clients with payments fee to be paid, we should implement these actions: - Filter fee overdue notification to not consider invoices - Create a switch to control if this functionality is active or not - Improve logging and error handling, to identify issues with notifications sending process - Create a runbook with the steps to follow if the notification process is failing - Enable payment fee overdue notification
After activating the feature, payment overdue fees will be automatically notified. However, the Dealing Team will still need to manually process the overdue invoice fees through a manual process.
Service Ownership
We are going to enable the Overdue Fee notification in a process that is already running in production to automatically send overdue fee payments by email notifications, this process works inside BOS as a Daemon task so the TFT will have the ownership.
| New Service | Service Name | Service Owner |
|---|---|---|
| No | BOS | TFT Team |
| No | BOS command | CODEOWNERS of risk folder |
Alternatives
Currently, sending notification emails and retrieving all overdue payment fees are processes tightly coupled to BOS code. In order to reuse all this already existing functionality, please consult the 'Solution' section above.
If the workflow is to be implemented following the new architecture, allowing some responsibilities to be taken out of BOS, the following services would need to be designed and implemented:
- Service to retrieve all overdue fees from the BOS database, filtering only by payments and marking the results to be notified to clients.
- An email service to send communications/notifications to clients, by taking the previous notification messages (or other services).
- A periodic task to execute the overdue fees retrieval service.
Caveats
No caveats
Operation
We expect the Dealing Team stop the manual process of checking clients for overdue fee payments and send an email for who has an overdue payment fee. Furthermore, the change has an Operation impact on the Dealer Team. They will still need to send overdue invoice emails if needed.
Security Impact
No security impact
Performance Impact
We do not expect any significant impact in the performance. This process is going to run once in a week every Monday, and sending only for clients that have one overdue payment fee pending. FYI in September 2022 we processed around 1.8k pending payment fee.
Developer Impact
No developer impact
Data Contracts
No data contracts will be required
Data Sources
No data source will be required
Deployment
There will be a switch to control this feature state to proper test it, if we find anything that case problem it is easy to roll it back. After all the tests are made on Staging, we are going to rollout this feature in production, there is no need any specific instructions for DevOps Team and no major data transformation for this RFC.
Dependencies
No dependencies
Based on RFC Template Version 1.1