Difference between defining payment method on the level of strategy vs on beneficiary level

Initial setup for example:

1. There’s one Individual named John that is assigned to 3 programmes: Programme A, Programme B, Programme C

   1. Programme A has following payment methods: 

      1. On site payment 

      2. Bank Transfer 

      3. Cheques

   2. Programme B has following payment methods: 

      1. Mobile payment

   3. Programme C has following payment methods: 

      1. On site payment 

      2. Bank Transfer 

   4. John’s data was submitted through 2 forms

      1. first:

2. Second:

3. Third:

5. For the first benefit John has bank transfer for the latter mobile payment 

Scenario when payment method is determined on the basis of strategy

1. User create a payrolls:

   1. Programme A, Payment Adaptor: BankTransfer(Bank_Account), Condition: Household =< 20

   2. Programme A, Payment Adaptor: Cheque(cheque), Condition: Household =< 20

   3. Programme B, Payment Adaptor: MobilePayment(MobileNumber, Mobile_Provider), Condition: Location == Dodoma

   4. Programme C, Payment Adaptor: BankTransfer(Account), Condition: Location==Dodoma

   5. For John 3 relevant reconciliations processes are generated: 

      1. Programme A

      2. Programme B

      3. Programme C

2. As the adaptors are Payroll oriented they are managed as such, process is triggered for each Payroll separately 

3. When 3rd party system finishes processing it informs IMIS about the results and the payroll can be reconciled 

Scenario when payment method is determined on the beneficiary (defined as being enrolled in the programme)

1. We can assume following conditions:

   1. Bank Transfer Adaptor expects field account_number

   2. Mobile Expects fields mobile_phone_number and mobile_provider

2. With each new programme added ETL process have to be normalized, as adaptors rely on specific fields from the schema, so in John’s case: 

   1. ETL for Programme 1 has to rename Bank_Account column to the account_number

   2. Payload for Programme 3 has to rename Account to account_number

   3. Payload for Programme 2 has to rename number and provider accordingly  

3. For each Programme User create a payrolls:

1. Programme A, Condition: Household =< 20

2. Programme B,  Condition: Location == Dodoma

3. Programme C, Condition:  

4. For John 3 reconciliations processes are generated: 

   1. Programme A

   2. Programme B

   3. Programme C

5. As the adaptors are not Payroll oriented they are different payment methods in scope of one Payroll

6. When 3rd party system finishes processing it informs IMIS about the results and part of the bills in scope of payroll change at the time 

7. Until all processes are finished it’s not possible to reconcile payroll 

Biggest drawback of this approach is that with each new programme:

• The ETL pipeline has to be updated with additional data transformation - could cause consistency issues in case of reusable ETLs that serve more than one programme
  OR

• New ETL process has to be defined for every new programme - could be a bottleneck as defining ETL is a programming task that would require knowledge of openIMIS and Payment Adaptor requirements. It’s also harder to maintain in the long term. 

• Adding new Adaptors could cause trouble with backward compatibility, if new Adaptor would be added with intention to use in existing systems then data for each Programme would have to be upgraded using yet another ETL process.