Flow
Moving the report down to packages
1Read packages
Pull stock one package at a time, with its tracking ID and tags.
2Filter early
Drop untagged and empty packages before any grouping.
3Remove repeats
Key on the tracking ID, with the system's own package number as a fallback.
4Group and keep
Put packages under their product and keep the list.
5Derive totals
On-hand and cost come from the package list.
6Show it everywhere
Web, email, PDF and spreadsheet all carry the package list.
A report of on-sale items was adding up the wrong thing. It grouped by product, but a sale tag sits on one package, not on the product.
The report tells the stores how much marked-down stock they have and what the markdown costs. The same numbers go to a web table, an email, a PDF and a spreadsheet, so a mistake shows up in all four.
Where the tag actually sits
In the point-of-sale system, a markdown is a tag on a package. A package is one lot that came into the store, with its own tracking ID. A product can have three packages on the shelf and only one of them tagged.
The old report added every row for a product into one total. Once that's done, you can't tell which units the tag was meant for. The commit says the goal was to leave out untagged packages, so I'm fairly sure the old totals counted some units that weren't on sale. If a line says forty units with a sale badge, people read forty on sale, even if only twelve are tagged. The cost estimate is units times discount, so it would be off too. I don't have a before-and-after count, so I can't say by how much.
Packages first, products second
If you build something like this, the order is what matters:
- Read stock one package at a time.
- Drop packages with no tag or no stock.
- Skip any package you've already counted.
- Group the rest under their product, but keep the package list.
- Work out the totals from that list.
Then the product total always matches the packages under it, and anyone can open a row and check.
The same package, seen by two stores
Shared stock can show up in two stores' lists. The report now uses the tracking ID to spot repeats, and falls back to the store system's own package number when the tracking ID is missing. That fallback mixes two kinds of ID, so a package could in theory count twice. I haven't seen it happen, but I'd log it when the fallback is used.
Where the best discount wins anyway
The discount is still chosen per product. If two packages have different deals, both get the better one, so the cost estimate runs high. Pricing each package on its own would fix it, and I haven't done that yet.
Getting the detail out to four formats
The web table now opens up to show each package, and search finds tracking IDs. The email and PDF show short IDs, and the spreadsheet keeps the full ones.
There was no test in this change. What I'd do differently is write the small one first: one product, two packages, one tagged, and the report has to show only the tagged one. It still doesn't exist.