|
This feature introduces the ability for collecting either periodic or one-time charges against Center , Group and Client accounts.
Many of the traditional MFI's have the concept of transactions (only fees) against Client, Center and Group Accounts.
These MFI's often operate in countries where they are recognized as NBFC's (Non Banking financial Institutions) . i.e they are not permitted to open savings/current account for customers.
Since these MFI's are hesitant to create transactional (current) accounts for Clients which could be used for associating fees that are not directly linked to loans (Ex: A one time joining fee, an annual membership fee etc), the need arises to track fees directly against Center, Group and Client accounts
# | Title | User Story | Importance | Notes |
---|---|---|---|---|
1 | Define Client, Group and Center Fees | As a system administrator, I must be able to define the fees which are applicable to the various entities in my system The Fees might be
I must also be able to define the Income account against which all Income from each fee would be tracked. The asset account (Cash/Bank) that would get Debited on fee payment would be Configured at an Organization level | Must Have |
|
2 | Configure accounting rules (Cash, Accrual) for a fee | As an accountant, I should be able to specify the accounting rule for each fee (Cash or accrual based accounting). For fees following Cash based accounting, the following rules would apply:
| Nice to Have | We do not need support for accrual accounting in the first cut and Cash based accounting shall be automatically used for all Center, Group and Client fees |
3 | Apply Client, Group and Center Charges | As a loan officer, I must be able to associate a pre-defined charge (either one time or periodic) to a Client, Group or Center
| Must Have | |
4 | Pay Individual Client, Group and Center Charges | As a Loan Officer, I must be able to pay any of the charges associates (Applied) to a Client, Group or Center
| Must Have | |
5 | Pay Multiple Client, Group and Center Charges | As a Loan Officer, I must be able to pay off multiple charges from single repayment screen (all charges would be associated with the same entity)
| Nice to have | Not a must of the first cut |
6 | Waive a previously applied charge | As a loan Officer, I must be able to waive either a part / or the entire charge In case of recurring charges, I must be allowed to select the date from which the waiver would be effective or the amount I wish to waive | Must Have | For the first cut, it is okay to not allow waiving a part of the charge |
7 | Adjust a payment | As a loan officer, I must be able to view all payments made (for Client charges) I must be able to adjust any of these payments to modify the amount paid or the date of the payment subject to not causing data integrity violations in the system | Must Have | |
8 | Collect Charges through collection sheet | As a loan officer, I must be able to see all charges linked to meetings in the collection sheet against the Client account I must then be able to update the charges collected in the same and the payment logic should be identical to those listed in the use case "Pay Multiple Client, Group and Center Charges"
| Must Have | |
When Charges are associated with Meetings, the following scenarios would update the charge due dates
a) Updates to meeting dates (meetings moved from Monday to Friday) should result in the recurring charges being
b) Updates to meeting date as a result of a Transfer (Client moved to a new group/Center) with a different frequency
Making a payment would follow these business rules
The business rules for an adjustment would be as follows:
List of attributes to be captured for the new functionality
Attribute | Description | Notes |
---|---|---|
List of security areas to be considered and permissions to be added/considered for a user/role to have access to this functionality
List of new screens required
List of existing screens that need any kind of changes
Functional changes to Batch jobs that may be needed - along with suggested frequency at which it should be run for various scenarios
With sample accounting entries with dates
Include any mockups, diagrams or visual designs relating to these requirements.
List of error scenarios and the action - if message is to be displayed, then text of the message.
List of changes/enhancements/new reports to support this functionality
From a functional perspective, list of new APIs needed.
From a functional perspective, list of existing APIs that need changes.
Points to be handled during upgrades
Any reference data that needs to be prepopulated or defaulted for clients/users
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
---|---|
What happens when a Client with a recurring charge linked to the center meeting is disassociated from the center ? | Communicate the decision reached |