1         Problem Scope

MFI’s typically generate client-facing documents (whose format varies from MFI to MFI) from their MIS. These documents are usually limited to the context of a Client (Client registration documents) and Loans (Loan Contracts, Passbooks etc.)

The actual functionality (wherein a user defines document templates in the system) could be reused for many other related tasks like SMS Integration (https://mifosforge.jira.com/browse/MIFOSX-119), E-mail integration etc.

2         Template Definition Workflow

We would ideally want a user to select an Entity (Only Clients and Loan for the first cut) and associate documents against it using a very simple workflow

A user would have a layout like the one shown below with

a)      A Rich Text Editor for generating WYSIWYG (What You See Is What You Get) documents

(Simple Jquery based editors like http://pietschsoft.com/demo/jHtmlArea/ could do the trick. Other Java-script editors like http://ckeditor.com/demo offer more functionality...and added complexity)

b)      An accordion (or any other UI Element) that would list the context sensitive “placeholders” for the selected entity in an visually (easily) discernible manner.

Placeholders would be used in the rich text editor enclosed by “${}” for easy detection and parsing Ex :${clientName}

1.1        Entity Types

Clients would work as a “simple” entity (as in a user selects a "client" as an entity and then associates a document Template against it)

Loans would work as a “Compound” entity (That is a user would also have to select a particular Loan product for associating templates against them. Since contracts etc. could vary from one Product to another)

1.2        Placeholder Types

Initially we could have two types of placeholders

• Simple Placeholders (generate Text Content): That would be replaced by the Text value the placeholder represents

Ex: ${clientName} would be replaced by “Andy Jones” etc

• Complex Placeholders (That generate HTML Mark-up): They would be used primarily for generating Tabular Data.

Ex: The placeholder ${repaymentSchedule('date','principalAmount','interestAmount') } would create a HTML table for repayments with the table columns based on the passed in parameters ‘date', 'principalAmount', 'interestAmount'

2         Parser

2.1 Server Side Parser

Ideally, we would have a parser at the server side (Java) which would replace the placeholders with context sensitive data and spit out HTML reports.

Some of the advantages of having the parser at the server side would be

• Better performance
• We can carry out various optimizations like fetching values for only those placeholders which are present in the particular document etc
  
  

The Restful service for server side document generation would look similar to

/{entityName}/user.defined.report/{reportId}?entityId=10&parse=true

where

• {entityName} = Name of the entity (Client, Loan etc)
• {reportId} = The Identifier for the report template
• entityId = (Optional Query param) Identifier for compound Entities (Ex: The Loan Product Id for a Loan)
• parse= An Optional Query param, when present causes the server to replace placeholders with actual values. When not specified, the server would return the actual report Template (used for reading the actual template as a part of CRUD operations on "m_report_templates" table)

2.2 Client side Parser

Alternatively, we could also have an additional service at the server side (in addition to CRUD services for "m_report_templates" table) that exposes the context sensitive data and a Client side parser that would take care of merging the report template with the actual values exposed by the RESTful service for (so the actual report is created at the client side)

The Restful service would have a URL similar to 

/{entityName}/report.params?entityId=10

and return all possible reporting parameters for the selected  "entityName"

3         Database changes

We could store the HTML templates directly in the database (as they would be quite small)

Table: “m_report_templates”