Menu
▾
▴
Re: [Mifos-developer] Improvements in Teller Module
|
From: Jamal I. <ji...@gm...> - 2025-08-08 07:24:40
|
Many Thanks Ed, I'm available for further discussions on this. Just let me know when and I will create the time. regards, On Thu, Aug 7, 2025 at 10:49 PM Ed Cable <ed...@mi...> wrote: > Hello Jamal, > > Thank you for suggesting these improvements. Bharath and myself would be > happy to discuss these further with you as we've had others in the > ecosystem express a willingness to share contributions regarding the teller > module back with the community. > > Ed > > > > On Thu, Aug 7, 2025 at 1:26 PM Jamal Inkoom <ji...@gm...> wrote: > >> Hello Team, >> >> >> >> I’d like to propose significant improvements to the Teller module in >> alignment with FINERACT-204 >> <https://issues.apache.org/jira/browse/FINERACT-204>. >> >> While global financial services are increasingly shifting toward cashless >> transactions — with account-to-account transfers becoming the norm — the >> reality remains that branch banking is still widely practiced, especially >> in emerging markets. As such, cash handling and teller operations continue >> to be critical components of day-to-day banking. >> >> Most mature core banking platforms offer robust teller modules that >> support cash management, reconciliation, and audit trails. By strengthening >> Fineract’s teller capabilities, we can: >> >> - Better support institutions operating in cash-heavy environments >> - Improve adoption rates by offering parity with commercial systems >> - Increase conversion from legacy platforms to Fineract >> >> I believe this enhancement aligns with the broader goal of making >> Fineract more versatile and enterprise-ready. If the community supports >> this direction, I’m committed to contributing the necessary improvements to >> deliver a more mature and feature-complete Teller module. >> >> >> >> The following outlines the backend enhancement plan for the Teller Module >> >> >> >> >> >> 1. We maintain the m_tellers entity in the code base and christen it >> as branch vaults, then modify it to have attached to it a dedicated GL cash >> account - users can set it up as a multi-branch GL like all other GLs or a >> dedicated Vault Cash GL per branch >> 2. We Maintain the m_cashiers entity and christen it as Teller Tills, >> then modify it to have attached to it dedicated GL cash account - this >> means that each teller can have a dedicated GL account >> 3. At the moment, there's a setup in the accounting module to link >> Teller and Cashier to GL accounts but the associated transactions in the >> journal entries entity cannot be directly linked to cash allocation and >> settlement transactions performed by cashiers making tracking of branch >> cash balances and overages/shortages impossible >> 4. The platform also doesn't even provide for other cash transactions >> other than movement and settlement of cash between cashier and teller. >> 5. We will include the transaction types to enable us to perform cash >> deposit and cash withdrawal at the branches. >> 6. The m_cashier_transaction entity will be modified to include >> debit_account and credit_account to capture a cash deposit or withdrawal >> transaction >> 7. For cash deposit, accounting entry will be - CREDIT the customer >> account and DEBIT the GL associated with the Till performing the transaction >> 8. For cash withdrawal, the accounting entry will be - DEBIT the >> customer account and CREDIT the GL associated with the Till performing the >> transaction >> 9. Each branch will have one vault (which means one GL for the branch >> vault) but multiple tills can be created and associated with this vault for >> the branch - this means multiple Cash GLs, one for each cashier in the >> branch >> 10. A till with its associated GL account can either be for a human >> teller or an ATM machine >> 11. Cash should be transferred into the tills (the associated GL >> account should have a positive balance) before withdrawals are performed >> against the tills - this will be simpler if we maintain balances for these >> GL accounts (more on balance maintenance in another proposal) >> 12. Balance update for both the tills, vault, customer accounts are >> going to be online >> 13. Till cash can be transferred back to the vault after the day's >> transactions >> 14. At any point, the total cash in the branch will reflect the sum >> of balances on all cashier tills in the branch and the balance on the >> branch vault account - this is essential to cash position management and >> therefore risk management at the branches >> 15. Branch cash position management implies we have to introduce the >> concept of interbranch entries - at any point in time the sum of all inter >> branch balances must be zero >> 16. We can also enable denomination management to enhance cashier >> cash balancing procedures for those working with denominations >> 17. There will be overage/shortage accounts in the branch that will >> hold cash in the branch that would have been recorded in the system but >> cannot be accounted for >> 18. With this, financial institutions can ensure some controls by >> requiring that all cashier till balances are zero at the close of each >> working day >> 19. We will also introduce mandates on accounts. Mandate is a >> regulatory requirement in many countries. Introduction of mandates will >> make it easier to support joint accounts >> 20. At the moment, we could use the groups feature to handle joint >> accounts once mandates are available >> >> >> >> >> >> Front-end Changes >> >> 1. We'll rework the teller management screens within the >> *Organization* setup menu to reflect the changes >> 2. We'll have a dedicated screen for teller transactions - precisely, >> cash deposit and cash withdrawal - cheques will come in later >> 3. The dedicated screen will have a lazy list of all accounts with >> search criteria to enable tellers search for specific accounts >> 4. The details displayed on the account should include the available >> balance on the account, the status of the account, the last few >> transactions on the account, and most importantly the mandate on the account >> 5. We will also include an option to verify the identity of the >> originator of the transaction. In here, we can show the image of the >> account owner, their signature or do biometric verification if there is an >> integration into an external verification service or all of the above >> 6. A withdrawal transaction without corresponding balance on the >> cashier till account will fail >> 7. Each cashier can print their call over report at any point in time >> 8. This dedicated cashier screen will only show up in the menus of users >> who have been designated and setup as cashiers >> >> >> Please let me know what you think. >> >> regards, >> >> Jamal >> > > > -- > *Ed Cable* > President/CEO, Mifos Initiative > ed...@mi... | Skype: edcable | Mobile: +1.484.477.8649 > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > Mifos-developer mailing list > mif...@li... > Unsubscribe or change settings at: > https://lists.sourceforge.net/lists/listinfo/mifos-developer |
