Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

  • 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

...

  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 

...

  • 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"

...

  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 

...

  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 

...