Mifos-Tally Interface

Owned by Gigi Gatti (Unlicensed)
Last updated: Feb 17, 2011Version comment

Mifos-Tally Interface

Release

v2.0

Current Owners

Gigi, Udai

Status (Draft, In Review, Stable / Approved)

Draft

Contents:

Introduction

This feature will provide a seamless integration between Mifos GL accounts and Tally 9 ERP.  The interface will facilitate posting of Mifos GL accounts into the proper/corresponding Tally 9 ERP ledger accounts. Version 2 builds on improvements to the first version by:

a)  Reducing the number of keystrokes that the user has to perform;

b)  Building a control feature to detect duplicate extracts; and

c)  Providing a control summary prior to posting in Tally.

Goals

  • The interface should:
    • Allow the user to choose which transactions to extract from Mifos (based on creation date, not transaction date)
    • Be able to detect if the extract has been done before (e.g., it is a duplicate) and give appropriate warnings to the user
    • Extract all relevant transactions for a selected branch or all branches 
    • Be able to post the correct entries into the Tally 9 ledgers using the voucher types supported in Tally
    • Be able to display control totals prior to posting
    • Be able to automatically post the entries into the Tally 9 ledgers after user confirmation
    • Allow users at either Branch or Head Office to invoke the interface function
  • The interface should be user-friendly and the user should be able to complete the process with minimum key strokes and time spent

 Two scenarios supported by this interface:

1)  MFI has decentralized processing of accounts, usually daily - MFI has accounting capability at the branch and daily accounting reports are done by the branch.  In this scenario, the branch accountant is responsible for performing the daily extract of Mifos transactions.  The extract required are transactions that are relevant only to the branch performing the extract. 

2)  MFI has centralized processing of accounts - MFI has no accounting capability at the branch and all accounting reports are done at the HO.  In this scenario, the HO accountant is responsible for performing the daily extract of Mifos transactions.  The extract required are transactions from all branches.

Non-Goals

The following items will not be addressed in this release:

  • Reversal of posted transactions - Reversal of posted transactions will not be automated and will remain a function of Tally.  To reverse posted transactions, the normal Tally functions to perform this procedure should apply. 
  • Printing of the interface log file - The log file will be viewed on the screen for this version.
  • Ability to drill down to Mifos transactions from an aggregate GL account - The need for this function should be revisited in the future.
  • Support for product differentiation on the GL level - To support P&L reporting by product, this requirement should be reviewed and taken into consideration in future releases.  EMILY:  My understnading (perhaps wrong) is the most MFIs do p&l by branch, not by product.  So this makes sense.  GIGI: Even if it is by branch, there should be a breakdown of the income by product, at the least.  MFIs (and all organizations for that matter) would want to see which products are more profitable than others)

Definitions and Terminology

Term

Definitions

User

Authorized user for both Mifos and Tally

Tally 9 ERP

Accounting software developed in India

Tally Interface Module

3rd party Tally application that facilitates the posting of Mifos generated XML files to Tally vouchers

 

 
  • Mandatory fields will be preceded by "*" (an asterisk)
  • Links are italicized
  • Buttons are Button

Related Documents

*insert links to related specs here

User Stories/Scenarios

Priority

User Stories

Section in FR

1

As a user (Branch or HO Accountant), I want to be able to export Mifos transactions and import it into Tally 9

 

1

As a user (Branch Accountant), I want to be able to export transactions for my branch

 

1

As a user (HO Accountant), I want to be able to export transactions for all branches

 

1

As a user (Branch or HO Accountant), I want to be able to specify the transaction date to be exported from Mifos

1.2

1

As a user (Branch or HO Accountant), I want to be able to view the control totals of the transactions of the date that I specified

1.1

1

As a user (Branch or HO Accountant), I want to be told if I or someone else has performed the same export already so that I do not perform the same activity over again

 

1

As a user (Branch or HO Accountant), I want to be able to confirm the export after viewing the control totals

 

1

As a user (Branch or HO Accountant), I want the imported transactions to appear as posted vouchers in Tally 9

2.3

1

As a user (Branch or HO Accountant), I want to be able to identify the vouchers in Tally 9 that were created by the interface

1.4 and 2.2

1

As a user (Branch or HO Accountant), I want to be able to re-do the extract after properly reversing the same in Tally

1.9 and 2.5

2

As a user (Branch or HO Accountant), I want to be able to print the control totals after the export is completed

1.5

Use Cases (MIFOS Component)

Use Case 1.0 - ACCOUNTANT RUNS THE INTERFACE FROM MIFOS

Actors

  • Branch or HO Accountant

Preconditions

  • User has the permission to run the interface in Mifos

Basic Flow

AT ANY POINT IN TIME:

  1. User will log-in to Mifos and navigate to "Manage Imports and Exports", "Accounting Exports"
  2. User enters branch to extract (or all)
  3. Mifos displays 7 last dates in chronological order (latest first) and the status for each date ("Success" or "No Transactions") - include holidays/non-working days 
  4. User enters date to extract
  5. Mifos extracts the transactions from the last successful import date/time to the entered date/current time
  6. If these transactions were already processed, go to Use Case "RE-EXPORTING DATA" (Use Case 1.2)
  7. Otherwise, Mifos displays the control totals on the screen (Use Case 2.0)
  8. User confirms or cancels the export transaction
    1. If cancelled, screen will go back to "Accounting Exports" screen (Use Case 1.1)
    2. If confirmed
      1. Mifos generates the XML files for the transactions to be exported while displaying some form of "Progress or Status" indicator so that the user knows that something is happening in the background
      2. Mifos calls the Tally Interface Module
      3. Tally Interface Module will return a status to Mifos of either "Successful or In Error"
        1. If Successful, Mifos updates the interface log file and displays "Export completed"  EMILY:  A requirements for the tally-side of the project should be that the export is atomic-- meaning if there is an error with one voucher, then none of the vouchers are imported. GG: noted
        2. If In Error, Mifos displays an error message and goes back to the "Accounting Exports" screen 

Post-conditions

  • Interface log file is updated
  • XML files are generated and posted to proper Tally Vouchers

Alternative Flows

Use Case 1.1 - ACCOUNTANT CANCELS THE EXPORT TRANSACTION

1.  At step 8a, user chooses "CANCEL", screen will go back to "Accounting Exports"

Post condition:

1.  No data exported, interface log file not updated

Use Case 1.2 - RE-EXPORTING DATA

  1. At step 6,  Mifos determines that the chosen date/time has already been exported successfully.
  2. Mifos warns the user that the extract has been made.
  3. User has the option to:
    1. Cancel the action
      1. If cancelled, screen will go back to "Accounting Exports"
    2. Proceed with the action
      1. Mifos displays a message that the corresponding vouchers in Tally should be reversed first before proceeding  EMILY: Is there anyway for the Tally iterface to confirm whether/not the vouchers were reversed? ie, instead of checking on whether/not Mifos has exported the vouchers correctly, can we check to see if the corresponding vouchers still exist in Tally? GG: Sadly, no.  It has to be a manual procedure
      2. Mifos warns the user for a second time and asks for a confirmation
        1. If not confirmed, screen will go back to "Accounting Exports"
        2. If confirmed:
          1. Mifos displays the control totals on the screen
          2. User confirms or cancels the export transaction
            1. If cancelled, screen will go back to "Accounting Exports" screen
            2. If confirmed:
              1. Mifos generates the XML files for the transactions to be exported (old file will be overwritten to maintain naming convention) while displaying some form of "Progress or Status" indicator so that the user knows that something is happening in the background
              2. Mifos calls the Tally Interface Module
              3. Tally Interface Module will return a status to Mifos of either "Successful or In Error"
                1. If Successful, Mifos updates the interface log file and displays "Export completed"
                2. If In Error, Mifos displays an error message and goes back to the "Accounting Exports" screen 

 Post-condition:

  • Interface log file is updated
  • XML files are generated and posted to proper Tally Vouchers


Use Case 2 - ACCOUNTANT VIEWS THE CONTROL TOTALS AFTER EXPORTING

Actors

  • Branch or HO Accountant

Preconditions

  • User has the permission to run the interface in Mifos

Basic Flow

AT ANY POINT IN TIME:

  1. User will log-in to Mifos and navigate to "Manage Imports and Exports", "Accounting Exports"
  2. Mifos displays a calendar.
  3. User selects a date from the calendar.
  4. If the export file for that date does not exist:
    1. Give message to user that the export file does not exist
    2. Otherwise:
      1. Mifos displays the control totals of  the relevant export file on the screen
      2. User views the control totals
  5. When "Go Back to Previous Page" is selected, screen will go back to "Accounting Exports" screen 

 Post-condition:

  • Control totals are viewed

Use Case 2 - ACCOUNTANT PRINTS CONTROL TOTALS AFTER EXPORTING

Actors

  • Branch or HO Accountant

Preconditions

  • User has the permission to run the access the report in Pentaho

Basic Flow

AT ANY POINT IN TIME:

  1. User will log-in to Pentaho (or Mifos when single log-in is deployed)
  2. User selects "Export Control Totals" from the reporting menu
  3. User selects the date from a calendar
  4. Pentaho report is generated for the chosen date

 Post-condition:

  • Report is generated

Functional Requirements (MIFOS Component)

FR#

Description

Comments/Mockups

1.1

Control totals summary - should display total debits and total credits for each branch, voucher type, by account 

Mockup Tally-Mifos Control Totals.xlsx

1.2

Import parameters:

1) Date parameter - defaults to date today, future dates not allowed
2) Branch parameter - dropdown for all branches and ALL, defaults to branch of user who is logged in

 

1.3

Conditions in which transactions are imported: Extract all transactions from the Mifos transaction file that conform to the following
criteria:

1)  Create date <= Date parameter specified (Typically, the extract includes only current date. But we should be able to detect if there
were transactions created in the past day that were not yet extracted) 
2)  Transaction time <= current time (This gives a time cut-off)
3)  Transaction has not been exported

 

1.4

Interface Log File components:

Import date - Date import was performed
Import time - Time import was performed
From date - From date (this could be yesterday's date if there were left over transactions that were not exported)
From time - From time (there could be transactions left over that were not exported)
To date - date parameter specified
Branch - Branch code
Receipt voucher filename - Receipt voucher name in Tally
Payment voucher filename - Payment voucher name in Tally
Journal voucher filename - Journal voucher name in Tally
Import status - 'SUCCESS' or 'FAIL'
User - user who performed this operation

Voucher naming convention:
Payment voucher: MFPAY<mmddyyyy><branch>
Receipt voucher: MFREC<mmddyyyy><branch>
Journal voucher: MFJOU<mmddyyy><branch>


1.5

Export Control Totals Report (Pentaho report)

Mockup: same as display above
Tally-Mifos Control Totals.xlsx

1.6

XML Generation: Payment Voucher
As related to the transaction mapping, this voucher contains:

contains all Disbursement transactions

1.7

XML Generation: Receipt Voucher
As related to the transaction mapping, this voucher contains:

contains all Collection transactions

1.8

XML Generation: Journal Voucher
As related to the transaction mapping this voucher contains:

contains all other transactions such as interest
posting, writeoffs and adjustments

1.9

Re-exporting transactions:

1)  User selects from past successful submissions
2)  Re-exported transactions should be assigned NEW voucher names because it is not possible to post the same voucher name in Tally

Naming convention for re-exported vouchers:
Payment voucher: MFPAY<mmddyyyy><branch>_n
Receipt voucher: MFREC<mmddyyyy><branch>_n
Journal voucher: MFJOU<mmddyyy><branch>_n

where n is the number of times this file has been
re-exported

Functional Requirements (Tally Component)


FR#

Description

Comment/Mockup

2.1

Mapping of Mifos GL Codes and Tally Ledger Codes

1)  Ability to define the mapping of Mifos GL Codes to the corresponding Tally Ledger Code

Confirm with Mudra if this is necessary or if we can use the ALIAS field in Tally

2.2

Voucher naming:

1) Voucher naming should follow that of Mifos to allow for cross-referencing of transactions.
2) Special vouchers should be created in Tally to differentiate imported data from the rest of the Tally transactions.  Voucher types  MIFOSPAY, MIFOSREC, and MIFOSJOU should be created.  The feature to delete these vouchers and renumber should be TURNED OFF.

 

2.3

Automatic posting of vouchers in Tally: 

1)  Create vouchers based on XML imported file: PAYMENT, RECEIPT, JOURNAL. 
2)  Post vouchers automatically without the need for user intervention

 

2.4

Atomic import and error messaging

1)  All vouchers included in the same import batch should successfully post, if any one is in error, the whole batch is rejected
2)  A status 'FAIL' should be returned if the batch is not posted successfully.  Any posted transactions should be reversed at this point.
3)  A status 'SUCCESS' should be returned if all vouchers are posted successfully.

Can the Tally interface component return an appropriate message to Mifos why the submission was in error?
Example: totals not balanced, ledger code not correct, voucher already existing?

2.5

Dealing with re-exports

1)  Re-exported transactions will have the DIFFERENT voucher name and processing should follow the normal processing routine.  

Users should be given instructions to REVERSE the old vouchers relating to the same imports.  Unfortunately, we cannot control this scenario where users do not reverse the old vouchers referring to the same submission. ANY IDEAS?

 

User Interface

No.

Description

UI Reference

1

Accounting Export Main View

 

2

Specify parameters for export

 

3

View control totals

 

Standard Considerations

Security

Security (Permissions, Roles, and Data Scope)

Yes/No

Comments

Does the user need to be in a particular user hierarchy to use this feature?

 

 

Does the office hierarchy affect use of this feature?

 

 

Are you using any existing permissions to control this feature?

 

 

Are you adding any new permissions or changing existing permission to control this feature?

 

 

Are you using any existing activities to control this feature?

 

 

Are you adding any new activities or changing existing activities to control this feature?

 

 

Are there any special considerations for upgrade scenarios? What will be the default value for new permissions?

 

 

What will be the default values for default roles in a new installation?

 

 

Impacts to System

Impacts to System

Yes/No

Comments

Does this feature affect Bulk Loan Creation? How?

No

 

Does this feature affect Collection Sheet Entry? How?

No

 

Does this feature affect Redo Loans?

No

 

Does this feature affect Reverse Loans?

No

 

Globalization/Localization

Globalization/Localization

Yes/No

Comments

Will this feature support users localizing data that they enter?

 

 

Does this feature involve any date/time related data, and if so how should conversions be handled?

 

 

Is there currency or other numeric data ? If so does it require any special handling or validation?

 

 

Logging

Change Log

Change Log

Yes/No

Comments

Do changes to the data that is collected or stored by the new feature have to be fully logged by the system?

 

 

Does the administrator configuring the system need the ability to turn on or off logging for this feature?

 

 

Is the feature currently logged but the structure of the logged records changing?

 

 

Reporting

Provide any relevant information about reporting requirements for the new features and answer the questions below, providing detail to explain any particular area when necessary.

Reporting

Yes/No

Comments

Does the feature affect any existing reports?

 

 

Does the feature require adding any new reports?

 

 

Performance

Performance

Yes/No

Comments

Will the feature be a high use-case scenario?

Yes

For the indian market

Will the feature have potential for high concurrency?

 

 

Does the feature include complex UI or data gathering logic that will be used by a significant portion of the user base?

 

 

Does the feature contain risks of database connection timeout?

 

 

Will the feature contain any bulk insert/update/delete transactions?

 

 

Will the feature contain any caching mechanisms or cache refreshing mechanisms?

 

 

Could the feature result in a large amount of data being sent to the client or between the database and web server?

 

 

Would users on a low bandwidth connection likely face issues with a part of this feature?

 

 

Does the feature affect existing batch jobs or require adding any new batch jobs?

 

 

Setup and Installation

New Installations

New Installations

Yes/No

Comments

Does this feature require both Mifos Intelligence Suite and Mifos Product?

 

 

Does this feature require special work for hosting?  (sys admin)

 

 

Backward Compatibility and Upgrades

Backward Compatibility and Upgrades

Yes/No

Comments

Is there any data conversion that needs to be done as part of an upgrade?

 

 

Will customers lose data or will the way existing data is stored change significantly?

 

 

Will another feature, workflow or portion of the data model be deprecated as a result of this new feature?

 

 

Will existing role permissions be changed or impacted by this feature? If so provide details in the security section.

 

 

Will existing customers need to learn a new UI process or change the way they use the system as a result of this new feature?

 

 

Hosting Support

Hosting Support

Yes/No

Comments

If different user groups are using the same database, are there concerns over the sharing of data related to the feature?

 

 

Are there expected to be performance related issues with having many customers sharing the same hardware in support of this feature?

 

 

Configuration

Configuration

Yes/No

Comments

Does this feature require changes to configuration files?

No

 

If so, is this feature enabled or disabled by default?

 

 

Open Issues

  • What happens if the extract is being run and transactions are simultaneously being encoded?
  • Is there a maximum size to the XML file?  What are the limitations?  Will it be able to accommodate data for all branches?

Reviews and Approvals

  • ...