|
|
|
|
| Changed: |
<
< |
| >
> |
|
| Changed: |
<
< |
| >
> |
|
| Changed: |
<
< |
- Savings Account Screen
- Savings Transaction Screen
| >
> |
- Meeting Screens
- Bulk Entry Screen
|
| Added: |
>
> |
- Definition of XML data formats for reporting
- Ability to Create Customized Reports
- Generating Reports - Implement base set of reports
|
| Deleted: |
<
< |
Phase 2 would be intended to finish the major data entry parts of the portfolio system, and to start the main work of the Moap Data Toolkit. Here would start making the key architectural decisions linking the MOAP Framework.
|
| Changed: |
<
< |
- Meeting Screens
- Bulk Entry Screen
- Financial Product Screen
- Branch Screen
| >
> |
Phase 2 would be intended to finish the major data entry parts of the portfolio system, and to start the main work integrating systems. Here would start making the key architectural decisions linking the MOAP Framework.
|
| Added: |
>
> |
- Savings Account Screen
- Savings Transaction Screen
|
| Changed: |
<
< |
| >
> |
- Financial Product Screen
- Branch Screen
|
| Changed: |
<
< |
- Definition of XML data formats for reporting
| >
> |
- Data import / export functionality
|
| Deleted: |
<
< |
- Transfer Branch Data to Central Office
- Generating Reports - Implement base set of reports
|
| Changed: |
<
< |
| >
> |
|
| Added: |
>
> |
- Ability to create custom User Classes
|
| Changed: |
<
< |
Phae 3 would intend to round out the development of the MOAP Architecture, including optional features and features that are currently only hazily designed. It would also include development of an Open Source Accounting System, or adaptation of an existing one, to offer a full solution to prospective MFI users. This is also the point where we could start thinking about localising the system and tailoring it for use in specific institutions.
| >
> |
Phae 3 would intend to round out the development of the first release of the MOAP reference implementation, including optional features and features that are currently only hazily designed. It could also include development of an Open Source Accounting System, or adaptation of an existing one, to offer a full solution to prospective MFI users. This is also the point where we could start thinking about localising the system and tailoring it for use in specific institutions.
|
| Changed: |
<
< |
| >
> |
|
| Changed: |
<
< |
- Complete set of Reports
- Ability to Create Customized Reports
| >
> |
|
| Changed: |
<
< |
- Ability to create custom User Classes
| >
> |
|
|
|
| Changed: |
<
< |
Starting point for Mo-Ap development:
| >
> |
Starting point for Mo-Ap development. Both the MicroFinanceUseCases and the SoftwareRequirementsSpecification should be referenced.
|
| Deleted: |
<
< |
Both the MicroFinanceUseCases and the SoftwareRequirementsSpecification should be referenced.
|
| Changed: |
<
< |
Proposed: Start with a few limited use cases and develop to that - the idea is to demonstrate value quickly.
| >
> |
Phase I would be intended to get the basic data entry parts of the Portfolio System completed, and develop the security layer for the MOAP system. It would allow us to iron out some of the basic issues regarding data structures and development platform, and provide some quick demonstrable results.
|
| Changed: |
<
< |
| >
> |
- Client Information Screen
- Group Information Screen
- Loan Application Screen
- Loan Account Screen
- Loan Repayment Screen
- Savings Account Screen
- Savings Transaction Screen
- Business Logic for Interest Calculations, Loan Amortization, etc.
|
| Changed: |
<
< |
- Portfolio: Entering meeting transactions and notes
- specifically, create report for loan officers to take to field of expected transactions
- Common: Setting up Data Transfer to Accounting System
| >
> |
|
| Deleted: |
<
< |
In most MFIs, the Loan Officers are the key to success and the key item that they use is the "Expected Payments Sheet" which shows all members of a group, all groups in a center, for a weekly meeting. Exceptions to these expected transactions are then entered into the system at the branch office, and then those transactions go to the accounting system. The details for the expected payments sheet do vary from organization to organization, so this should be a flexible setup. Commonly, the sheet includes all current products (savings, loan product, and insurance) with amts due and outstanding balance.
|
| Changed: |
<
< |
If we populate an "Expected Payments Sheet" (Pymt Sheet) with dummy data, print it out, then make changes to the online form, then confirm all transactions and send to accounting system, that would be a huge demonstration.
| >
> |
Phase 2 would be intended to finish the major data entry parts of the portfolio system, and to start the main work of the Moap Data Toolkit. Here would start making the key architectural decisions linking the MOAP Framework.
|
| Added: |
>
> |
- Meeting Screens
- Bulk Entry Screen
- Financial Product Screen
- Branch Screen
- Loan Officer Screen
- Daily Closing
- Finish Business Logic modules
|
| Changed: |
<
< |
| >
> |
- Definition of XML data formats for data import / export
- Definition of XML data formats for reporting
- Develop plug-in for one existing third party Accounting System
- Export Portfolio Data to Accounting System
- Transfer Branch Data to Central Office
- Generating Reports - Implement base set of reports
|
| Changed: |
<
< |
| >
> |
- Development of Report Formatter Module
|
| Changed: |
<
< |
| >
> |
Phae 3 would intend to round out the development of the MOAP Architecture, including optional features and features that are currently only hazily designed. It would also include development of an Open Source Accounting System, or adaptation of an existing one, to offer a full solution to prospective MFI users. This is also the point where we could start thinking about localising the system and tailoring it for use in specific institutions.
|
| Changed: |
<
< |
| >
> |
|
| Added: |
>
> |
- Develop or adapt an Open Source Accounting System
|
| Changed: |
<
< |
| >
> |
- Complete set of Reports
- Ability to Create Customized Reports
- Ability to create custom User Classes
-- Main.Tapan Parikh - 3 April 2004
|
| Deleted: |
<
< |
-- JamesDailey - 10 Oct 2003 |
|
|
| Added: |
>
> |
%META:TOPICINFO{author="guest" date="1065821100" format="1.0" version="1.1"}%
%META:TOPICPARENT{name="WebHome"}%
Starting point for Mo-Ap development:
Both the MicroFinanceUseCases and the SoftwareRequirementsSpecification should be referenced.
Proposed: Start with a few limited use cases and develop to that - the idea is to demonstrate value quickly.
- Portfolio: Entering meeting transactions and notes
- specifically, create report for loan officers to take to field of expected transactions
- Common: Setting up Data Transfer to Accounting System
In most MFIs, the Loan Officers are the key to success and the key item that they use is the "Expected Payments Sheet" which shows all members of a group, all groups in a center, for a weekly meeting. Exceptions to these expected transactions are then entered into the system at the branch office, and then those transactions go to the accounting system. The details for the expected payments sheet do vary from organization to organization, so this should be a flexible setup. Commonly, the sheet includes all current products (savings, loan product, and insurance) with amts due and outstanding balance.
If we populate an "Expected Payments Sheet" (Pymt Sheet) with dummy data, print it out, then make changes to the online form, then confirm all transactions and send to accounting system, that would be a huge demonstration.
-- JamesDailey - 10 Oct 2003 |
|
|
