11.09.2011 Developer Meeting

Who Attended

Kakha (Georgia)
Keith W (Ireland)
Udai G (India)
Ed C (USA

Notes

Offline Discussion
Kakha: Is it the right decision to go with JSON format?
Udai: it's a compact format - better than XML
JSON is more readable, also natively supported by java script so it's more programmable.
Boils down to convenience - see JSON as a REST implementation. Not limited, you could split out XML output from REST API if needed.
Kakha: May be confusing for business users who are not familiar with JSON - was hard for him to find the converter.
Keith: His view of offline client - field officer has offline tool installed on computer.
    Worried that REST API spits out an output that is not understandable by a user // Udai: this output is not for direct consumption for a user but is rather for a client.
    Keith: what is this output? Collection Sheet Service Facade - exposing the this through REST API - Get Collection Sheet and Save Collection Sheet - need to convert these two.
    Keith: At what point is business user looking at data?
        Business user just writes out ten or fifteen fields into Excel that save as csv and import into tool.
    Keith: don't need to build open office plugins - just get data from their field.
    Keith: confused
    Udai: idea was to prove that you have a client - once you have a successful process and can go lots of ways. Preference may be an Excel or CSV that download, edit, and submit it. Probably wouldn't be extendable in terms of offline client.

    Vision: start with data collection and think where offline would want to go. If you don't have the code outside of Mifos - can't extend it to cover more meetings, functionality. If everything in Mifos, not actually building an offline client. Creating a way that someone can take data that is in an editable format that you can send it back.

    No business rules, data validation in that data format. Like an excel module with lots of macros.

    If you want to do simple entry have the way of doing this with the current plugins - can develop one plugin and they deploy.

    Offline client - code outside of mifos.

    Keith: couldn't this offline tool also support importing a csv into that offline tool.
    Udai: why do need direct API? REST API make it easier to build a client interface. Feature that we have now - it's possible to build a rich client. data format is just a way of presentation.

    Keith: whether the HTML5 app or what not, have to get JSON data into that which talks to REST - could enter that manually or import it via .csv into the offline client.

    Udai: with JSON itself could build something that can integrate with Excel

    Kakha: Ideal world have a browser-based offline client with everything in place - nobody cares what type of file is used for export/import. Reason why am talking about format of file. Requirement of client side - make cost-effective, quick, user-friendly suggestion - only reason for now - suggesting spreadsheet-based solution.

    Kakha: business users can manipulate spreadsheet. if have to change HTML client - costly.

    Keith: Would like to do an export from Mifos to create this Excel file so field officer can modify - when they want to update Mifos - just read from this spreadsheet.
    Kakha: All the formatting, sorting that is in spreadsheet would be hard to program a new in a client. // Keith: Would be very hard to read this spreadsheet, the data, talking to services that could detect the changes.

    Kakha: right now have the JSON format which getting now but if just had it as .csv which could then open in excel and edit // Keith: column by row format is easier for end user to modify.

    Easier if whatever data came out of mifos - open up in spreadsheet - business user edit their fields, that could then be inputted back into Mifos.



    Discussion on Monthly Recalculation of Interest

    See: http://mifosforge.jira.com/browse/MIFOS-5182

    Reason why ThoughtWorks left it at daily was that if someone repaid early or later - interest was recalculatd based on number of days early or later. If monthly or later - saying that they're one or two months late and recalculate based on that. Keith: not sure why they want recalculation on a monthly basis.

    Kakha: When client is repaying and doing early repayment - principal and interest are not calculated correctly. Binny is closer to this issue.
    Nobody repays according to schedule - system not adequately recording interest or principal.

    Keith: Binny had sent an email - will stick his head in and knock out exactly what is happening - have a good amount of knowledge around loan schedule and loan calculation - refactored a lot of that.

    Keith: will get on to binny and get further details about what is required and see if can easily add that on.

    WIll connect separately.

    Kakha: critical because 99% of the clients loans are outside of the normal time.

    Migration Toolkit:
    Kakha: Can it support savings import?

    Ed: Data migration toolkit in question is that which SunGard developed - only is loan and client data (not savings) --> http://mifos.org/community/news/sungard-releases-data-migration-toolkit

    Ed: Alternate approach is through the UI with Selenium-based scripts - used by Sam Birney in Lebanon and SBS in Mozambique.
    Notes on Selenium Scripts for Data Migration

    Keith: Same approach used by Conflux for their data migration tool - Moving system dates back and forth and running scripts to get data in and out.


    Keith: Some sections are hard-fixed on transactions happening today and not on a specified date - not designed for data migration.

    See also the Data Migration Documentation section: