Overview

Date: 2026-03-19 - 10:00 am (UTC)

Room:

Objective: Project

Participants: (kindly only add your own names, not those of other participants)

Agenda:

When (UTC)	Duration	Who	Topic

When (UTC)	Duration	Who	Topic
14:00 (UTC)	5 min	GIZ	Updates & administrative things
14:05 (UTC)	45 min	@Anthony Belem	Performance optimizations for cash transfer

Performance optimizations for cash transfer

https://openimis.atlassian.net/browse/OP-2793
50 minute uploads for 1.000 beneficiaries
WB team added FAILED state on payroll module to keep track of the status of background payroll generation, there is also a GENERATING status.
There is also a graphql mutation added to initiate retry of payroll creation
During Payroll creation, the system has to generate unique code for the payroll - the current solution goes beneficiary by beneficiary to generate the unique code. This code also checks for existing unique code and has to do this for each beneficiary and that process takes a lot of time.
- WB have created triggers for creating unique sequence numbers for beneficiaries
  - One for MySQL and one for PostgreSQL
  - And would like to get feedback from the community
  - https://github.com/openimis/openimis-be-calcrule_social_protection_py/pull/30
- The process is done for Bill Creation, Benefit consumption and so it is done twice per Beneficiary
- The end result is that processing a lot of beneficiaries' payroll generation takes a lot of time
WB team suggesting that the OpenSearch index update should be deferred to after the payroll has been generated and not during/within the process. This may help speed up the process and reduce errors.
WB team was able to reduce the number of queries in the process by almost 10x for the payroll generation which has sped up the process by 15x (e.g. from 15mins to 1min for some test instances)