Back to Feed
article 3m read

Half-case option ordered more than a whole case

Turning a half-case step into whole units early made split orders on odd-sized cases land above the plain whole-case answer. I moved the rounding into cases and capped split orders at the whole-case quantity, though the minimum still rounds the old way.

Article DepthPractice

Flow

Where the rounding happens now

  1. 1Need in cases

    Divide the need by the case size.

  2. 2Round to halves

    Round the case count up to the next half, with a tiny trim for float drift.

  3. 3Back to units once

    Multiply back and round up a single time.

  4. 4Cap

    Take the smaller of the split answer and the whole-case answer, and save the reason.

  5. 5Missing test

    A small need on an odd case, expecting half a case back instead of a full one.

A new half-case option could order more than whole cases would have. A store needing one full case could get a case and a bit. A split is meant to make an order smaller, so that's wrong.

Some suppliers will break a case, so a store can take half of one. That day I added split rules to the ordering system: a step size as a part of a case, a minimum, and a nudge up to a whole case when the extra is small. One function runs all of them and hands back the number the rest of the system uses. Later that same day I was back in it fixing the math.

Half of seven is four, apparently

The first version turned the half-case step into units right away and rounded up. Half of an even case is a whole number. Half of an odd case is not. Say a case holds seven. Half is three and a half, which became four, so every order landed on a multiple of four. A need of seven became eight. With splitting off, it would have stayed seven.

The nudge to a whole case didn't help. From eight, the next whole case is fourteen, and that's not a small jump.

I rounded too soon. The step was about cases, and I turned it into units before I was done with it. A grid of fours skips seven, so it can only land above it. Eight is a legal size for a product that splits, so I doubt anything later would have questioned it.

Rounding in cases, then a cap

Now the math stays in cases. Turn the need into cases, round up to the next half, and turn it back into units once at the end. Floats can drift a hair over an exact multiple, so the real code trims a tiny bit before each round-up. The minimum order goes through the same math.

Then there's a cap, and it's the part worth copying first.

The final order is the smaller of the split answer and the whole-case answer.

The whole-case answer is the need rounded up to full cases. After every other rule runs, a bigger split answer gets cut down to it, and the reason is saved. Both numbers cover the need, so the cap can't make an order short.

Three tests, one blind spot

One test checks an odd case with a need of exactly one case. One loops over several case sizes and every need up to three cases and checks the split never tops the whole case. One runs the full report and expects one case at one case's cost.

The loop checks the same limit the cap enforces, so I think it would still pass if the case math broke again. It never checks for the smallest allowed size, and it only tries halves.

The minimum still rounds the old way

The minimum is still turned into units and rounded up first. Half of seven becomes four again, and the case math then carries four to a full case. If I'm reading it right, a store that needs two units of a seven-unit product now gets all seven. The next test I'd want is a small need on an odd case, expecting half a case back.

Keep reading

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

5 paths forward