Flow
Building a sale price, and where it can slip
1Read the unit price
For packaged flower this is the price of one gram.
2Check the category
Only items with flower in the category get multiplied.
3Read the weight from the name
If the name has no weight at the end, the gram price is kept.
4Find the discount
If no record matches the tag, the tag number becomes the percent.
5Take the discount off
Always from the package price, never the gram price.
Every flower price on my staff sale sheet was too low, and the math behind it was perfect.
The sheet is a report I build for the stores. It pulls live stock from the register, keeps items with a sale tag, finds the discount for each tag, and prints a regular price and a sale price. The same data goes out as an email and a PDF. All of it came from the register, so I trusted it.
Per gram, not per package
For most things in the store, the unit price is the price of what you buy. For pre-packaged flower, it's the price of one gram. A small package and a big jar of the same strain show the same number. Take a percent off that and both prices come out short by the weight of the package, while the discount percentage itself still looks right and the rows still sort fine. You'd only catch it if you knew what a jar costs at the counter.
Every number built on top of that price is off by the same amount, including the summary's estimate of what the sale costs.
Getting the weight
The feed has no package size field I can use. The stores put the weight at the end of each flower name, so the change reads it from there and multiplies. It only does this for flower, since other categories are already priced per package, and only after that conversion does the discount get taken off the package price.
Fallbacks that never raise a hand
The weak spots are all fallbacks. If a name doesn't end in a weight, the price isn't multiplied, and the old bug is back for that row. The flower check just looks for the word flower in the category, so a gram-priced item filed somewhere else gets missed. Probably pre-rolls.
The discounts have fallbacks too. If a tag has no matching discount record, its number is used as the percent, and the sheet can show a price the register won't charge. If the discount list fails to load, every tag falls back that way and the sheet still looks done. If one store's stock request fails, that store is just left out. Almost none of this leaves a mark on the sheet.
Pricing code with no history and no tests
The pricing code shows up in history for the first time in this commit, so I can't compare it to an old version. The commit message and the notes in the code are what tell me flower was priced per gram before. There are no tests, and the same commit also sets the PDF's date and time to a fixed time zone. I don't know for sure what that was fixing.
The next thing I want on the sheet is a count of the flower rows where no weight could be read, so a renamed product shows up as a number instead of a wrong price.