Page Comparison

Receipt

Yes

Receipt ID is proof of payment and a unique MPESA identifier that can be cross-reference with clients phone receipt. Need to be imported into Mifos since needed in the KEEF Collection Sheet.

Receipt ID is exclusive to MPESA

Check that there is not an existing RECEIPT ID

Alphanumeric

Y29DW127

Transaction Details - Receipt ID

Date

Yes

Payment date

Validate date is in range (see above)

YYYY-MM-DD time

2009-08-26 12:39:42

Transaction Date

Details

No

Contains information payment received from phone number, telephone number, MFI account number

Ignore

Status

Yes

Completed

Check that Status says Completed. 

Must be Completed, anything else IGNORE

Completed, Attempted, Cancelled, Declined

Completed

Withdrawn

No

Amount paid from MFI

Only use for Disbursals, Phase 2

00

Paid In

Yes

Transaction amount paid to MFI

Validate it's an amount and check same validations in Mifos against digits after decimal

Should be digits after decimal = 0

200

Transaction amount

Balance

No

Balance of MFI

Ignore

520,499

Balance Confirmed

No

automatic check in system

Ignore

true

Transaction Type

No

Determines if this is a payment or disbursal

Check that this is Pay Utility, else ignore row

Must be Pay Utility, anything else IGNORE.

Pay Utility
Business Payment

Pay Utility

N/A

Other Party Info

Yes

Safaricom generated phone number and name associated with phone number

Compare first 10 digits to phone number. If none exists, throw error.  This will be used to identify where the transaction goes.

First 10 digits must correspond to a Phone Number

Numeric

0722926212 - CYNTHIA OMONDI 

Phone Number

Transaction Party Details

Optional

Will include Mifos Product Code if there is one, and other information such as Client's Group ID, etc

We will use this to include short names) of product(s) applied to the client's accounts if it is different than the default order set in ke.co.safaricom.MPesaXlsImporter.ImportTransactionOrder

CHANGE from previous: no more client national ID's and this field is now optional - only use if transactions to be applied are different than default order

Validate 3-4 letter codes (everything before first space) corresponds to a loan or savings product in Mifos

If not, ignore this field

Mifos product codes

SP1

Savings Product 1

4.2

P1

Date is actual repayment date recorded

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. 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 is applied in the following order to each loan account - Loan Penalties, Loan 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.  All transactions accepted will be tagged with Payment Mode MPESA.

4.6

P1

If there is an overpayment of the entire loan, Mifos should throw an error.   This situation can occur if the savings product is not found for the client. 

4.7

P1

Default order of transactions is set in new setting in a properties file called ke.co.safaricom.MPesaXlsImporter.ImportTransactionOrder.
Accounts to which repayments and deposits are made should be applied to in the order specified here when importing a row.
Example: ke.co.safaricom.MPesaXlsImporter.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  ke.co.safaricom.MPesaXlsImporter.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  ke.co.safaricom.MPesaXlsImporter.ImportTransactionOrder, THEN an error should be thrown indicating accounts were not found.

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