Client, Group and Center Charges

Target release15.06
Epic
Document statusDRAFT
Document ownerVishwas Babu A J
Designer
DevelopersVishwas Babu A J
QASSN

Overview

This feature introduces the ability for collecting either periodic or one-time charges against Center , Group and Client accounts.

Background and strategic fit

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

Requirements/User Stories

#TitleUser StoryImportanceNotes
1Define 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

  • A one time fee ( applied at a particular lifecycle event for the entity or applied as on a given day)
  • A periodic fee (tied either to the meetings in the case of Organizations following the meeting concept or specified periodicity
    for other Organizations)

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
  • We might need to identify the Asset account which get debited when a fee is paid
    on a per fee basis instead of at an Organization level (not required for the first cut of
    the functionality though)
2Configure 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:

  • Fee specific income account credited and Organization specific Asset account (Fund source) gets debited on payment
  • Activities like waiving a fee, applying a fee do not generate accounting entries
  • Reversing a fee payment would also generate accounting reversals

 

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

3Apply 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

  • In case of a one-time charge, I must be able to associate the date on which the charge becomes due with the Charge or specify that
    the charge becomes due at the next meeting (In which case, a change in the meeting date changes the due date of the charge)
  • In case of a recurring charge, I must be able to associate the date on which the first occurrence of the charge becomes due (In
    cases where the charge is associated with meetings, the charge would become effective only on or after the due date)
Must Have 
4Pay 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

  • I must be allowed to select the date on which I made the payment
  • I must be able to select the amount I wish to pay ( multiple payments might be made for mapping off a single charge)
  • I must also be able to store comments and details against the payment (the check number, routing number etc)
Must Have 
5Pay 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)

  • In this scenario, I must be allowed to select the date on which I make the payment
  • I must be able to select the amount I wish to pay
  • I must be able to store comments and details against the payment
  • In case the amount being payment is lesser than the total amount due (across all charges combined), then the charges should be
    processed in a predictable order (Overdue payments first, then one time charges and finally recurring charges)
Nice to haveNot a must of the first cut
6Waive 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 HaveFor the first cut, it is okay to not allow waiving a part of the charge
7Adjust 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 
8Collect 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 
     

Business Rules

 

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

  • You may not over pay a charge (or pay an amount greater than sum of all charges due in case of bulk payment)
  • You are allowed to pay off an individual charge before its due date

The business rules for an adjustment would be as follows:

  • If a charge is paid off in a single transaction, you are allowed to edit this transaction (undo or reduce the payment amount etc)
  • If a part of a charge is paid off in a single transaction, you are allowed to edit this transaction (undo or increate the payment amount unto the charge amount)
  • If a charge is paid off in multiple transactions, edits to a payment amount should ensure that the total amount paid is not greater than charge amount
  •  

 

Attributes

AttributeDescriptionNotes
   
   
   

Security and Permissions

Mifos Functionality Enhancements

New Screens

Changes to Existing Screens

Changes/Enhancements to Batch Jobs

Changes/Enhancements to Accounting Entries

User interaction and design

Exception Handling

Reporting

APIs

Notes

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcome
What happens when a Client with a recurring charge linked to the center meeting is disassociated from the center ?

Out of Scope