Flow
What each sheet row gets
1Live row
Look up numbers by exact product code and write them with their sum.
2Parked row
Keep the name and cost, leave the numbers blank, keep the spot.
3Divider
Write a fully empty line. No zero in the sum column.
4Saved copy check
Compare the output with an expected copy, cell by row id and column name.
5Totals check
Rebuild each order export and compare summed numbers with the saved order.
The order was right, and the paste was wrong. I copied the numbers from the ordering system into a vendor's sheet, and a whole section's numbers sat one block too high, next to the wrong products.
The vendor uses a fixed sheet. Each product gets a row, and each of my stores gets a column. I copy the store numbers and paste them over their block. A paste only knows position. Line one goes on row one. Nothing checks the names. And a zero is a real value, not a blank.
The browser theory that went nowhere
Before this, the same export had a different problem: the bottom rows pasted blank. The notes from that hunt blamed the browser, like an old cached page or the wrong copy button. The server's own export looked right. I cleared the cache and tried other devices. Same issue. The export got a version tag so I could tell which code made a paste.
The same day, a change cut the template down to only the slots I order from. Later, the notes named that cut as the cause of the drift. I can't tell if the blank rows and the drift were one bug.
Sparse order, dense sheet
My system thinks a row is something I'm buying. The sheet thinks a row is a place. It has slots I'm not using, slots with the same generic name, and blank lines between sections.
Cutting those rows broke the paste. Each missing slot pulled everything below it up one row. The next section's numbers moved into the empty slots above. Every number was real. They were just on the wrong rows.
The blank divider lines had a zero in the sum column, and that pasted as a fake "ordered nothing" line. The script that saves the template also skipped blank lines when it counted rows. Both changed: dividers now come out empty, and the count includes them.
The green check and its reference frame
I had a script that rebuilt the order and compared it to my plan. It found zero mismatches, and it was right. But it only compared the order to the plan. It never looked at the export, so it couldn't see the paste.
Rendering from the sheet
The export now walks a copy of the vendor's sheet, row by row, not my order. Each row is one of three kinds:
- a live row looks up its numbers by exact product code
- a parked row keeps its name and cost but leaves the numbers blank
- a divider comes out fully empty, with no zero
The sheet sets the number of lines, so a change in the order can't shift anything. Rows match by product code, not by name. Name matching with "the third one called this" breaks as soon as a row is added. If an order line has no code, its numbers don't show up anywhere, and that's a gap you have to watch.
Pinning the layout
I saved an expected copy of the finished block. Tests look up cells by row id and column name, so a failure tells you which row broke. One test checks the cost column too, because that paste is just as positional. A side-by-side check with the real sheet also found one product sending units to the wrong store. That got corrected, and the saved copy holds it.
After the deploy, the row count went back to what it was before the cut. The plan check still passed. The export had one line per sheet row and nothing in the parked rows.
Demand with nowhere to land
The saved copy only proves the export matches my map. It can't catch an order line with no row to land on. So a second check now rebuilds every order's export, adds up the numbers per store, and compares them with what the order saved. Most vendors' latest orders passed. A few other vendors' templates don't cover every line. A name-matching bug for one of them turned up too and got fixed.