| Hi all, Just wanted to quickly join in on this discussion. From a system perspective I can't see any harm in giving every client a current account when registering. I even think it is a requirement in situations whereby the moment of charging a fee, and the moment of paying it are not in sync, such as mobile money, ATMs etc. By using a current account the client can deposit the money during the initial meeting, or whenever he or she has it available. At the time the account is now setup and the charges applied the payment will be deducted. In the same way the current account can provide easy ways of having one cash-in/out point in your system and allow the other products to tap into that account. Obviously all the setup and creation of these accounts can be done completely automatically as part of the on-boarding process to reduce workload on the end-user. It is already possible to do most of this by setting up an account with a minimum opening balance, and by then applying a charge, the balance goes back to 0 assuming the loan officer took a (cash/cheque) payment from the client for the same amount as the opening balance. In terms of transparency to a client, it is also beneficial to have a current account which can be easily tracked with a variety of fees. Behind the screens a feature that is proposed here, should work this way anyway to maintain sufficient levels of tracking both on portfolio and accounting side (Vishwas, your thoughts?) I can see that this might run into problems whereby a client needs to be active in the system before they can pay fees. However I've not yet come across situations where a client would be paying fees if they were not registered with the institution, same thing for applying for credit, this normally follows after registering with the institution. So in these cases there is always the option to close the client if the decision is made not to fund them. We could avoid this by already allowing certain products (by configuration) to be given in pending approval stages of the client. It works the same way in regular banks, where even clients who are declined for a product will already go through an on boarding process and will be fully registered in the system and have to be given (internal) accounts to work with these fees. @Binny: I think the different worklow-statuss'es you mention are the way to go forward, however they will be organisation specific, and should not become a burden and clutter in the system for organisations who do not want to use it. The way I've seen it work in other systems is that you can use your workflows to map certain client-types/client-statuses to actual system statuses. For instance during the Application, Group test etc the client remains pending approval from a system perspective, but just gets different (customisable) labels as they proceed (this is a different feature requirement obv). After completing they can become active, and the same type of labelling can be applied to differentiate between active funded, active non-funded, dormant, non-performing etc clients. All of them are active, but can just have different labels at the time. A good example is the way the JIRA workflows can be setup. The statuses in there are also just mapping of the 4/5 system defined to organisation specific workflows. But maybe we should park this one for the speccing out of the workflows feature ;-) To get back to this feature, I think that the current backend platform already provides the features to fulfil 95% of the requirements that are currently there in the request, and anything that needs to be added in the future can easily be done. The adjustments (if any) could therefore be a UI thing to make sure the look and feel align with the expectations. That should be pretty easy and can be part of the modifications done during implementation for this (prospective) client. -- Sander van der Heyden CTO Musoni Services  Mobile (NL): +31 (0)6 14239505
Mobile (Kenya): +254 (0)707211284 Skype: s.vdheyden Website: musonisystem.com Follow us on Twitter! Postal address: Hillegomstraat 12-14, office 1.11, 1058 LS, Amsterdam, The Netherlands On 30 Mar 2014, at 09:49, Ed Cable <edca...@mifos.org> wrote:
|
------------------------------------------------------------------------------
_______________________________________________ Mifos-users mailing list Mifos-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mifos-users
