PR #2573 reintroduces the exact bug that issue #2562 was opened to kill

How credits work, and the bug we already know about

Before reading the code, hold this mental model. Two kinds of wallet hold credits, and one flag on each outlet decides which wallet its jobs spend from.

Counts from the dump: SELECT job_credit_deduction, COUNT(*) FROM locations WHERE status = 1. Most outlets are HQ-funded — the path the bug lives in is the common path, not the edge case.

Two numbers every credit calculation needs

What PR #2573 builds

Four files. A command that loops companies, a service that does the credit math, an email sender, and a Blade template. The data flow below is the part that matters.

The data flow inside buildPools()

Data flow when the command runs. The red box is where the bug lives; the amber box is computed and then thrown away.

The heart of it: computeBalance()

Every outlet's "Balance" column comes from this one method. It has two branches — one for self-funded outlets, one for HQ-funded outlets.

protected function computeBalance(int $locationId, bool $isLocationFunded, float $reserved): float
{
    $location = Location::find($locationId);
    if (!$location) { return 0.0; }

    if ($isLocationFunded) {
        // SELF-FUNDED outlet — this branch is CORRECT
        $availableCredits = $location->available_credits;
        return $availableCredits - $reserved;            // outlet wallet − its own reservations  ✓
    } else {
        // HQ-FUNDED outlet — this branch is WRONG
        $company = Company::find($location->company_id);
        if (!$company) { return 0.0; }
        $availableCredits = $company->available_credits;
        return $availableCredits - $reserved;            // company pool − ONE outlet's reservations  ✗
    }
}

One shared pool, counted as if each outlet owned it

The $reserved value handed to computeBalance() is one outlet's reservations — loadReservations() groups the sum by location_id. For a self-funded outlet that is right. For an HQ-funded outlet it is wrong, because the company pool is shared by many outlets, and one outlet's reservations are not the reservation load on the pool.

Worked example A — FairPrice Hyper (company 78)

First, the original bug, reproduced against the dump. FP Hyper's company pool holds $5,427.18. Its 9 enabled outlets are all self-funded.

The $43,685.25 matches issue #2562 to the cent. The dump gives −$38,258.07; the AM saw −$41,622.68 on 4 May because live reservations had grown since this 10 March snapshot — same formula, later day. FP Hyper has zero HQ-funded outlets, so the correct method subtracts $0 and lands on +$5,427.18.

Worked example B — NTUC Foodfare (company 106)

This is a mixed company: 15 self-funded outlets and 16 HQ-funded outlets. The company pool holds $70,179.51. Total reservations across the 16 HQ-funded outlets are $28,844.60, so the one true applicable balance for that pool is:

All 16 HQ-funded outlets share that pool, so all 16 rows should show $41,334.91. Here is what PR #2573's computeBalance() actually produces — $70,179.51 − (that one outlet's reservations):

Three smaller problems in the same area

The runway "0" is visible in the PR's own Area Manager screenshot: outlet "JP Kitchen" shows Balance 16,060.22 next to Runway 0, because Paid 14 days was 0.00.

Compute the company pool once, the right way

The model from issue #2562: a company has one company pool plus N self-funded outlet pools. Compute each pool's applicable balance once, against the reservations that actually draw from it.

The change to computeBalance()

Verification — the fix against the same real data

What this means for the email

Once the pool is one number, the table stops repeating it. HQ-funded outlets that share a pool collapse into one merged row; self-funded outlets keep a row each. This is the layout already being agreed in the design discussion — the merged-cell table — and it depends on the math above being correct first.