Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Accountant logs onto Mifos and navigates to the Admin section. Accountant selects Import transactions.
  2. Mifos displays new screen for Import Transactions.
  3. Accountant selects M-PESA for Import format, and selects file from their computer for import. Accountant clicks on Continue.
  4. Mifos imports file and checks for any errors (see Validations below). If there are no errors, Mifos displays Review & Submit screen with "There are no errors found. Click Submit to continue with import.".

...

  1. Accountant clicks on Submit. Mifos displays confirmation screen that import was successful.

...

  • All data available in the file has been imported and all the correct tables and loan account data correctly populated.

...

  • .

Validations

  • If a row has a cell that's empty in a required column is empty, that row is rejected and appropriate error message displayed.
  • No bad data - ie, no numbers in columns that require text and vice versa. See FR's below.

...

FR#

Pri

Description

Comments / Mockups

1.1

P1

M-PESA is an Excel format (97)

Check if CSV (XML) will work

1.2

P1

M-PESA import file first few lines contain description of file.  These are to be ignored.  Only data after row of column headings will be imported in the Transactions section.

 

1.3

P1

Import file will have columns in below table

 

1.4

P1

There will be error checking - to successfully import the data.

 

1.5

P1

If a row contains a cell that's missing a required field, Mifos displays an error message for each row this occurs.  Only check the rows where Status is Completed.

Row <#> error - <Receipt ID> - missing required data.

where the row # is the original row # of the import file.

 

1.6

 

When importing, must check to see if Receipt ID already exists in any transaction in Mifos - if YES, then ignore the row and

Mifos throws an error message

Row <#> error - <Receipt ID> - Transactions with same Receipt ID have already been imported.

where the row # is the original row # of the import file and <receipt ID> is the receipt ID that was found.

 

1.7

P1

Dates are in the format YYYY-MM-DD HH:MM:ss.  If any value under Date column does not start in format of YYYY-MM-DD, then Mifos displays an error message for each row this occurs.

Row <#> error - <Receipt ID> - Date does not begin with expected format (YYYY-MM-DD).

where the row # is the original row # of the import file.

 

1.8

P1

Compare Other Party Info - Take first 10 digits as phone number, and compare with Client's Phone Number fields in Mifos.  If there is not a match, then ignore the row and

Mifos throws an error message

Row <#> error - <Receipt ID> - Client with mobile number <mobile number> was not found.

where the row # is the original row # of the import file and <mobile number> is the phone number.

If there is a match, use this as identifier for transaction.

 

1.9

P1

Changes to Transaction Party Details - no more taking of National ID - remove this functionality.  Compare first code listed (before first space) with any loan or savings product in Mifos.  If the code exists, import that whole transaction amount to the account associated with that code.  Otherwise, ignore what's in the field.

 

1.10

P1

See FR 4.9 for additional errors to check for.


1.11

P1

Check that Status column says "Completed".  If it has any other status, Mifos throws the following message:

Row <#> ignored - <Receipt ID> - Status of <status> instead of Completed.

where <#> is the row # of import file, and <status> is the status found in the Status column.

According to 1.5, you will IGNORE, NOT ERROR if status is not COMPLETE, which is the right way. ERROR needs to be resolved by the user. IGNORE will just be ignored.ERROR needs to be resolved by the user. IGNORE will just be ignored.  Marie, does that mean you don't want to even see this message that the row has been ignored?

 

1.12

P1

Check if the same file name has been imported.  If so, then throw an error message and reject the whole import.

Same file name has been imported.  Please import a different file.

 

1.13

P1

After clicking on Continue, Mifos will display the Review & Submit screen with the following:

Review the information below.  Click Submit if you want to continue with import or click Edit to make changes. Click Cancel to return to Admin page without submitting information.

Import information

Import file name: <name of file>
Import Status:

<# read> rows were read
       <# imported> rows contained no errors and will be imported
       <# ignored> rows will be ignored  (all rows not Completed or where Paid In is 0)
       <# error> rows contained errors and were not imported

Total amount of transactions imported: <total # imported>
Total amount of transactions ignored: <total # ignored>       <- is this useful?> Nope. Cant see what it will be used for.
Total amount of transactions with error: <total # error>

List all rows with error messages in red

See below FR#7 for additional changes

1.14

P1

User can then either

  1. Click on Edit import information to go back to previous screen and upload new file.
  2. Continue with import and Submit.
  3. Cancel out of the workflow (returning to Admin screen).

 

1.15

P1

If User clicks on Submit, Mifos imports the file and displays confirmation screen
Will the information screen the same as 1.13, which will allow the user to save the save the information on file to process errors later?  No it does not

 

1.16

P1

There is no option to revert a file upload once it has been submitted.

 

1.17

P1

Currency of values imported is directly inherited from the loan product that the loan account is mapped to.

 

1.18

P1

If there are no rows found with import data, the following error message should be thrown:

No rows found with import data.

 

...

FR#

Pri

Description

Comments / Mockups

4.1

P1

Assumption: All transaction detail is for loan repayments (loan fees, interest, principal) and/or savings deposits. There is no data in file for loan disbursals, savings withdrawals, client, group or center fees, or client attendance. There will be data in file. We dont want users to manually clean up the Safaricom file to delete the disbursals and withdrawals, that will be dangerous. 


4.2

P1

Date is actual repayment date recorded . Will need to verify with Chris because if this is declining balance. the interest will change because the payments are done before the due date.

 

4.3

P1

For Loan Accounts: Amount that is being paid - pre-payments, partial payments, and over-payments if there are future installments are allowed. Need to clarify this. If there is no specific loan/savings product. The amount is allocated as configured and only the first upcoming loan amount will be paid... See example worksheet on Requirements document.  Amount in file is applied in the following order - Penalties, Fees, Interest, Principal.

 

4.4

P1

Date cannot be before today in Mifos

If they have backdated transactions on, then date can be before today up til last meeting date

4.5

P1

Mode of Payment must be configured in Mifos to have MPESA/ZAP (Need to verify with Chris. Zap is different and we may want to keep that different for future integration), which will be the mode of payment used for all transactions in that import.

 

4.6

P1

If there is an overpayment of the entire loan, Mifos should throw an error. (Shouldnt the overpayment go to savings?). Do we want to spit out a warning, instead?

 

4.7

P1

Default order of transactions is set in new setting in a properties file called ImportTransactionOrder.
Accounts to which repayments and deposits are made should be applied to in the order specified here when importing a row.
Example: ImportTransactionOrder = AL1, NL1, SP1
In this case, all rows that do not specify a product name after the client ID should have its transaction amount applied to in this order.  Only the next payment due will be applied.  In this example, if the client owes $10 on AL1 next installment and $20 on NL1, and the client pays $100 then those respective amounts would be applied, and then $70 deposited in SP1.
There should always be only 1 savings account and at the end

Will the properties file reside with the plugin as a separate file or in the global properties file

4.8

P1

If there is any product short name specified, then the whole transaction amount should just be applied to that account. The product can be a loan or savings product.
There's existing logic in there to take also a few loan or savings accounts if it's specified.  We'll leave that in there for now but we can choose to remove it later.

 

4.9

P1

Related to 4.7, it is not always necessary for the client to have accounts with all products set in the ImportTransactionOrder  field.  If the first account is not found, the plugin should continue to parse and skip to the next account.  If NO accounts are found bearing any of the products listed in the ImportTransactionOrder , THEN an error should be thrown indicating accounts were not found.

Row <#> error - <Receipt ID> - No valid accounts found with this transaction

 

...