Back to Feed
article 3m read

Splitting an order by store left the supplier's PDF unable to say which store wanted what

Splitting one store out of a multi-store purchase order is a single transaction that rewrites revisions, PDFs and sent state, and it exposed a supplier PDF that summed the same product across stores and a file-name marker for replaced revisions that, as far as I can tell, never gets applied.

Article DepthPractice

Flow

The split, step by step

Everything after the checks is saved together or not at all.

  1. 1Checks

    Refuse a store with no lines, a split that leaves no store behind, or an inactive delivery spot.

  2. 2New order

    Create it with the moved store's lines, flagged for review.

  3. 3New version

    Write the old order's next version with the remaining lines.

  4. 4PDFs

    Build fresh internal and supplier PDFs for both orders.

  5. 5Mark replaced

    The previous version and its files are marked replaced.

  6. 6Back to draft

    Clear the old order's sent record so it shows as not sent.

Two stores order the same product from the same supplier. My copy of the order shows two lines, one for each store. The supplier's copy showed one line with the two amounts added up and no store on it.

I fixed that on the same day I added a way to split an order by store. The split came first.

Taking one store off an order

One order goes to one supplier but can cover many stores. When one store needs to come off, the split moves that store's lines into a brand new order and writes a new version of the old order without them. Both orders get fresh PDFs, then the old version gets marked as replaced, and the old order goes back to draft with its "sent" record cleared.

All of that happens in one database transaction. If any step fails, including making a PDF, nothing is saved. The split also says no if the store has no lines, or if no store would be left on the old order.

Clearing the "sent" record is the part I care about most. The supplier hasn't seen the new, shorter order, so my system shouldn't say they have.

Picking where each half goes

Later that day I added a choice of delivery spot for each half. The server checks that each spot exists and is still active before it saves anything. One odd detail: the blank choice at the top doesn't mean "nowhere." It means "keep the old order's spot." Each half sends everything to one place, so a fancier plan on the old order gets flattened.

Ten of A, for nobody in particular

The supplier PDF used to bundle lines by product alone. So 6 of A for one store and 4 of A for another became 10 of A, for nobody in particular. After a split, that's useless, because the supplier can't tell which store wanted what. The bundle key changed.

The bundle key now includes the store, so each store's quantity stays its own.

The PDF now shows a section for each store, sorted in a fixed order, with its own subtotal.

The same bundling code lived in several places, so the change had to hit every copy. If one had been missed, nothing would have flagged it.

Old orders, new layout

Downloading a supplier PDF now rebuilds it from the saved order data each time. Old orders get the new layout too, but the file you download may not exactly match the one that was emailed.

None of this came with a test.

A marker that never shows up

Replaced versions are meant to download with an "invalid" tag in the file name. The pattern that adds the tag has an extra backslash. Reading it, it can't match a normal file name. So an old PDF probably downloads looking just as current as the new one.

There are a few other gaps. Nobody gets reminded to resend the order to the supplier, which means the supplier might still be working from the long version. Two splits at the same moment could grab the same new order number. And the split records a generic user, not me.

Keep reading

Pick up a connected idea or branch into a nearby one.

5 paths forward