This has a dependency on the Self-Service backend API's being available 

Allows a member/client in having a self-service channel allowing them more direct control and visibility into their financial livelihood.

This has a dependency on the Self-Service backend API's being available 

Allows a member/client in having a self-service channel allowing them more direct control and visibility into their financial livelihood.

1. Build a module that extends loan product definition to include specific physical product ordering - e.g. a clean energy loan associated with a specific solar product. Create a daily batch process to send data in JSON or XML to appropriate third party system (e.g. MEC Tracker). Extend this to include "down payments" on the product purchase - i.e. only partially financed.
2. Build a supplier ordering/invoice & financial reconciliation process and transfer funds directly to "Supplier Account" upon fulfillment of order.
3. Create reports on aging of orders, fulfillment timing, and geographic spread.

MFIs become more capable of integrating with third party systems for management of deliveries, after-sales service, and carbon tracking.

This project is a continuation of the initial PayGoSol foundation that was led by 2014 GSOC intern, Antonio Carella.

1. Create a pre-paid account mechanism as an account type or account option in Mifos (perhaps extending existing classes), zero fees.
2. Create a new API for consuming pre-paid account balances.  
3. Create a simple external model that mimics consumption by a household on a daily basis - imagined as a set of data received from solar panel (watts used, time of day, volts present).  
4. Load up pre-paid account by account transfer in P2P interface (my phone to your account) or via trusted agent - i.e. trusted agent receives cash and loads account on Mifos.

Work in 2015 will include adding the following features to make it an out-of-the-box solution that any PAYG hardware provider could use:

Providers of pay-as-you-go solar can use MIFOS for their operations. MFIs can become such providers.

Mifos Android Client on MifosX

• CGAP Research on PAYG Business Models: http://www.cgap.org/publications/access-energy-digital-finance-models-innovation

Data migration can be one of the most challenging and time-consuming phases of an implementation of a core banking system. It's often a barrier to financial institutions moving on to new and better more modern systems. It's critical to cleanly migrate over the historical data of a client and their transactions. Often the legacy system data needs to be cleaned up and transformed before it can be migrated into Mifos X and is one of the most costly and time-consuming phases of a deployment. We have an existing data migration tool for migrating from Mifos 2 to Mifos X that utilizes the Pentaho Kettle ETL tool.

This project would extend the existing Mifos 2 to Mifos X Kettle-based migration tool to provide a standard migration tool from Mambu - another modern system that is widely used by customers potentially looking to migrate to Mifos. It would provide one standard tool that any partner or financial institution could use for migrating from that specific system - it wouldn't require new tools to be made each time a migration is done.

Extend the existing Kettle-based Mifos to Mifos X migration tool

• Write ETL scripts to get data and transform data it from Mambu format to Mifos format

It has many impacts

1. This drastically reduces the time to set up of initial configuration/data of Mifos X for organization adopting this system as MIS.
2. It widely opens the market that Mifos X is applicable for as it lessens the burden of converting from other systems.
3. It dramatically lowers the cost of implementing a system like Mifos X by reducing the complexity of the deployment
4. It increases transparency by ensuring financial institutions using Mifos can retain the full history for their clients.

http://nayan.github.io/move-to-mifosx/

https://github.com/openMF/move-to-mifosx

 Create a POC of a scalable MifosX implementation (with load balanced tomcats and percona servers) on an openstack setup on a public cloud. Also publish a whitepaper with details of Openstack setup

 Mifosx was built to be cloud ready from the ground up. One of the most popular deployment environments for MifosX has been on Amazon EC2, however due to country specific regulation, many implementors are forced to seek alternative models that can scale as effectively

The aim of this project is two-fold

• Propose a scalable deployment model for Mifos (includes load balanced tomcats, percona mysql server etc ) on OpenStack. The POC would be on a public cloud provider (Rackspace?)
• Publish a whitepaper of the same, which can be used as a reference for local implementors (who would additionally take care of provisioning their own hardware)

At present MIfos X platform is shipped with Community-App (SPA) as default UI, but initial load time of the application high. And for users on narrow bandwidth internet it takes a considerable amount of time to load the app.

Instead of loading the app every time, we can convert the Community-App into a Chrome App and user can download them once and install it on the machine, and it can used as thick client.

Community-App is completely developed on top of JavaScript, CSS and HTML. And Chrome apps are also written in same stack. Using grunt we should be able to repackage Community-App(SPA) into Community-App(Chrome App)

Users with slow internet connectivity can use this app (Installed on the machine) instead of loading Community-App (SPA) on the browser. Users will also have a continually updated app. This will also allow MFIs to potentially use Chromebooks as field-based devices for their branches.

MIfos X platform is shipped with a Community-App (SPA) as the default UI which is optimized for Web Browser display on large screens (Mobile, Laptops and Tablets). We need to extend the same to support mobile views (with minor changes to workflow) and provide offline functionality

Community-App is completely developed on top of JavaScript, CSS and HTML. Also since there is a clear separation between the view and the Controllers in Angular JS, we should be able to spin up mobile views fairly easily reusing the same Controllers and Services. As it is quite common for Mobile users to have intermittent data connection, we should also support offline functionality,

Field officers can access MifosX from a Mobile optimized view, capture data offline that can be synced back to the server when an internet connection is available.

It also becomes easier for the community volunteers to maintain the mobile view ( as we reuse most of the code from the Community app) as opposed to maintaining a separate Android app.

Other Resources