Home

Project
Sourceforge
Tasks
Bugs

Collaboration
Mailing Lists
Chat

Attendees

• Ben, Felipe, James, Tapan

Key Notes

• Ben posted the MoApBusinessPlan
• James updated us on the grant proposal: he already submitted it and we have good chances.
• We all wish to thank Jordane for his great work on the SanghamithraDataModel
• Tapan looked through data model that James has done.

• We discussed GnuCashIntegration problems
  • Why Gnucash? Tapan: Very mature, open source, rich functionality, reporting functionality.
  • We have a few integration options, but we have to consider the effort too.
  • Felipe: power of GNUCash is on the business objects. Integration with DB includes financial objects only. Possibility to access business objects from Java still needs research
  • Even if we not decide to integrate Gnucash, we still can copy and reimplement Gnucash's data-model
• Gnucash maybe can't run on Windows: is Windows a requirement?
  • No problem as a proof-of-concept, but we must support Windows at some point: most MFIs use Windows
  • Gnucash's Engine is OS neutral, so it might be possible to port just the engine to Windows.
• We will focus on portfolio-management, integrating with an open source accounting solution.
  • How distinct are accounting and portfolio management system? Makes sense to split since that’s "best practice". Separation of function is important.
  • MFIs already have an accounting system but doesn't have a portfolio-management
  • MFIs' accounting dept are usually conservative, and it would be hard to convince them to migrate to some specific accounting package.
  • Thus integration (or integration's flexibility) will be key.
  • How many accounting systems out there?
• In Philippines, James looked at 3 different systems. They generally started with a good data-model but it becomes very confusing as the software evolved.
• In our discussions we are focusing too much on the integration architecture rather than the functionality / requirements. Let's first have a good set of core functionality and then the architecture would be more clear.
• Developing a proof-of-concept or prototype:
  • James: Let's create a proof-of-concept ASAP to validate our model
  • Felipe suggested that we create a proof-of-concept that can evolve and thus becoming a good foundation, rather than create something that we would through it away.
  • We already have use cases, but we have too many for the prototype. A roadmap braking the use cases in releases might be a good starting point.

Action Items

• Update project spreadsheet, Ben
• Put tasks on Sourceforge Tasks, Felipe
• Product Roadmap, James
• Development Environment, Felipe

-- FelipeAlbertao - 03 Oct 2003