bar chart
Demand asked for versus units placed after rounding each share
Illustrative numbers computed from the formula, matching the examples in the text. Not measured data.
Each share is 2.5, rounded up to 3.
Each share is about 1.43, rounded down to 1.
A zero in my buyer's sheet reads as yes and a blank as no in my new demand splitter. It relies on that, and I'm not sure the rest of the system keeps it straight, or that the splitter keeps the total right.
The ordering system reads two files. One says how much each store should order for a brand at a given size. The other is the buyer's sheet: one row per product, one column per store. Demand comes as one number for the whole group. The sheet needs a number on each product. So if the buyer marked four products for a store, that store's demand gets split four ways.
I gave the agent an example with the answer I wanted. It wrote a splitter that adds up demand, counts the marked rows, divides, rounds, and writes the share into each marked cell.
A zero is a yes
The splitter counts a cell as marked if it holds anything at all, even a zero. To the splitter, a blank means the store doesn't carry that product, and a test makes sure blanks stay blank. That's its own assumption, though. The sheet reader in the same commit looks for checkbox columns and only counts a store when the cell says TRUE. If any step before this fills blanks with zeros, every product becomes a yes and every share shrinks. Also, a marked cell that already has a number gets overwritten.
Rounding each row on its own
Each row's share is the demand divided by the number of rows, rounded on its own.
Each row gets the same rounded share, so the pieces don't add back up. Ten units over four rows places twelve. Ten over seven places seven. The main test uses my example, which lands on a half, so it passes with a total that's a bit too high. Rounding down and handing out the leftovers one at a time would fix the sum. I still need the buyer to say who gets the leftovers. The same commit has a second splitter that always rounds up.
Sizes and store names
The group needs a package size, which is usually guessed from the product name. There are four separate guessers, and they don't agree on what an unlabeled product weighs, so some demand may never find its rows. Store names are matched loosely, and a record with no match is dropped without a word.
What I want next is two numbers at the bottom of every run: demand in and units placed.