My second internship @ OMERS (2023)
From January 2023 until April 2023, I interned at OMERS as a Full Stack Engineer on the MSS Refacing Team. If you don't know what OMERS is, please read my blog post about my previous experience there. For this experience, I was part of the MSS Refacing Team. The MSS Refacing Team was in charge of rebuilding a legacy PowerBuilder pension transaction application. The target platform was a React/Node/Oracle application, that was built as a part of an existing internal pension platform.
The Product
The specific product I worked on was a business transaction that allowed pensioners to withdraw funds from their additional contributions. Over the 4 months, I built out the functionality to accomplish the main steps of this transaction.
- Initiating a transaction
- Assigning the transaction to a specalist
- Choosing/Editing the transaction variant
- Creating/Editing/Validating payment headers to complete a specific transaction
- Electing amounts to be withdrawn from specific accounts to specific payment headers
- Submitting a transaction for further review
- Reviewing a transaction
- Returning a transaction for further changes
- Completing a transaction
While I can't get into the specific details of how everything worked, this list provides a basic framework for the flow of data through the transaction.
My Role
My day-to-day work involved picking up an item from the sprint board or the backlog, writing React + TypeScript code for the frontend and Node + TypeScript + SQL for the backend, and sending the ticket off to QA. Some tickets obviously took longer than others and spanned multiple days. I also picked up QA work whenever there was a large backlog in the QA board.
Over the course of four months, I was able to build out the entire business transaction and get it tested and verified with multiple stakeholders.
Challenges
Working with money is really challenging, because you have zero room for any kind of error. One of the challenges I faced involved distributing pensions of the deceased to their beneficiaries in the desired percentages. For example, if a pensioner had an odd amount of money left in their plan (ex. 45999.99) but had two beneficiaries that were both entitled to 50%, then one of the beneficiaries would have to receive one cent more since you can't evenly divide an odd number like that. This is a very trivial problem but had an interesting solution. The solution involved sequentially calculating each beneficiary amount one by one through PL/SQL functions. For example, if the amount was 49,999.99 and there were two beneficiaries who were both entitled to 50%, then the first step would involve finding the amount that the first beneficiary would receive. This would be calculated to 49,999.99 / 2 = 25,000 (24,999.995 rounded up). Now, since we have this number calculated and saved, we can use it to our advantage in the next calculation. The next calculation would do the same thing, but it would take the minimum of the remaining funds and the calculated amount. It would calculate the same number (25,000) but since there is only 24,999.99 remaining, it would use the second value instead. This idea was generalized for n number of beneficiaries - and this is how the problem was solved.
