17-03-21 Entry: Resolving the ROB Mismatch Issue

Was busy working on a main issue today:

Client G's bunker balance calculation issue.

Client G's bunker balance calculation issue

After each bunkering job, the user have to key in the actual bunker being supplied to the receiving vessel (RV), and system will calculate the balance bunker that's remaining on the supplying vessel, or, as we usually call it, bunker vessel (BV).

How system calculates the balance bunker is that it will do a lookup on the previous job of this BV, retrieve its balance bunker from it, and deduct it from the current job's actual quantity supplied to derive the number.

It's all fine and dandy if, we usually assumed, the user keys in the data in chronological order, meaning the user will key the data from the earliest job to the latest one.

But if they don't follow the sequence of jobs, the calculated balance will be incorrect.

For example, the quantity and balance for a 12:00hrs job A (entered later) was 1,000 metric tonne (MT) and 1,234 MT, and the quantity and balanace for a 18:00hrs job B (entered earlier) was 1,200MT and 1,034MT.

Visually, you can already tell something was off. The balance of job B is clearly incorrect: 1,234MT (balance of job A) minus 1,200MT (quantity supplied for job B) will give you 34MT. And not 1,034MT.

Well, yesterday, the user did just that. They first keyed in the details for a 09:00am job, then followed by a 03:00am job, and discovered that the scenario explained above has happened.

Of course, a point to consider was that they missed out entering the earlier job and the form was discovered later. Thus the incorrect sequence.

The raised up this issue and after investigation, we concluded that it was the sequence of entering the job details that caused the bug. We even provided a solution as remedy.

To our surprise, they did not buy our reasoning, and said that it was the system's responsibility to make sure the balance calculation is correct regardless of sequence. They use excel software as an example, saying that the balance column will always be correct in anyways:

For our case, when the job details are keyed in and saved, they are all saved as absolute values to the DB. There are no equation for any fields that would allow data manipulation in the the DB.

But looking at the user's point of view, we can empathize that it was not on purpose but more of the nature of the job that they themselves might not receive the details in sequence, only to receive them later for data entry.

Current Solution and Challanges

In fact, this recalculation function exists but it requires the user to click on the button for each job that needs to do so.

For example, if there are 10 jobs after that earlier job which I just entered, I need to go into each of those 10 jobs to click the button.

It takes 5 mouse clicks to reach the button, which means 50 mouse clicks for 10 jobs. It just does not scale. We released it just the same because we were not so sure of the repercussions if we opt for the automatic mode.

Proposed Solution

In order to fulfil our own system data integrity and also provide a streamlined user workflow to recalculate the balance, we proposed to allow user to first do the data entry, regardless of the sequence, and then allow the user to process the recalculation for all jobs within a daterange with minimal steps.

I started to work on the screens of the proposed solution to flesh out how we envisioned it to be and to show it to the client G for feedback before development.

We start by having a alert bar once there's balance mismatches after the data entry:

Once the user clicks on that "Run Recal Process" button, a popup modal will appear to allow user to select the date for the function to start running from:

When user click "Recalculate", the function will retrieve all the jobs within the daterange and go through each of them to generate the new balance.

Once the process is completed, the modal will resize, update its content and display the results for the user to review:

By grouping the jobs in chronologically for each BVs, the user can easily review the bunker balance for each of them.

Initially, our idea is to display them ungrouped, but we realised that the user would need to scroll up and down the list in order to review each BV. I.e. after reaching the bottom of the list for BV 1, the user needs to scroll back up and repeat the process for BV 2, and then BV 3, etc..

Finally, we did screen recording to walk through the entire flow using Loom, sent it to our product manager for review before firing it off to Client G.