Refunds landing in the supplier ledger with nobody's name on them

Flow

Putting a supplier on an empty return

1. 1Collect the sales⌄

   Gather the different sales the window's returns point at.

2. 2Fetch with lines⌄

   Ask for each sale by its ID with line detail.

3. 3File by return⌄

   Put each returned line under the return that undid it, not under the sale.

4. 4Resolve the lines⌄

   Use the return's own lines matched by product and stock record, or the filed lines when it has none.

5. 5Split as before⌄

   Share the refund by price so each line's supplier gets a credit.

Returns with no line items were landing in my supplier credits as lumps of money with no supplier, brand or product on them. A credit with nobody's name on it can't be collected.

Where the missing facts were

The stores' point-of-sale system sends a return as its own transaction: a total, the ID of the sale it undoes, maybe a reason, and a list of lines. My sync split each refund across those lines by price and gave every line's supplier its share. When the list was empty, it wrote one credit with no supplier at all.

But the facts weren't gone. The first sale still lists every line, and the lines that came back carry the ID of the return that undid them. My code and my test both rely on that pointer.

Reading the sale backward

So before it handles the returns in a window, my sync now does three things:

1. Collect the different sales those returns point at.
2. Fetch each sale with its lines.
3. File every returned line under the return that undid it.

Then each return picks up its lines.

A return uses its own lines, or, if it has none, the lines found under its ID.

The reason comes from the return, or from the first sale line that has one. The money split works the same as before.

The lookup is keyed by return, not by sale, so a sale that came back in two trips doesn't hand both returns every line. I got that from reading the code. No test checks it yet.

When a return has some lines of its own, they're matched to the sale's lines by product and stock record. The return's values win, and the sale fills the gaps. If nothing matches, it falls back to position, which can pick the wrong line.

One sale, one line, one return

The test serves one sale with one returned line and one return with no lines. After a sync there's one return credit with the right supplier, brand, product and reason, and the counters for missing suppliers and products read zero. It also checks that the sale really was fetched.

If one sale won't load

My product lookup catches its own failures and keeps going. These sale lookups don't. As far as I can tell from the code, one failed fetch stops the whole sync, when it could have fallen back to the old credit with no supplier for just that return. I haven't tried it.