Isn’t that a discount shop? (tongue in cheek)
5 Likes
Yes, both allegedly approximations of 125 gram with the ‘e’ symbol … maybe it was for approximations of 3 dollars? or just an approximation of accuracy? I’m approximately not sure …
4 Likes
I realise I’ve come quite late to this topic, but when I noticed it I was reminded about some very expensive Weetbix I saw at Woolworths a while back!
Only $2012.50 per box!
6 Likes
They have been saying that the Ukraine war/invasion has been pushing up wheat prices, but this is a bit ridiculous. Might be time to stockpile Weetbix if one can get them at the old price.
2 Likes
It’s left to wonder if the staff person placing the pricing label was also amused at the price, lol.
The ultimate test would be the price scanned at the checkout. Assuming it was more reasonable, would the pricing difference entitle one to $2012.50 of wheatbix for free?
The part that I do not understand is how this kind of error comes about. The entire stock control is done by software, the tickets are (or should be) printed out of the same system. It is fundamental to system design that you do not allow data dependencies that can generate anomalies.
The correct way is to store Item Price and Number of Units and then to compute Unit Price on the fly as needed. The only way to have absurd unit prices is if they are stored separately or derived in some other way. These errors ought to be impossible.
1 Like
FFS. fat finger syndrome.
Some data entry person entered a computation unit in kilograms rather than grams or vice versa.
Larger Weetbix packs are in Kg, eg 1.2 Kg, and smaller in grams, eg 575 g.
So some calculation was out by a factor of a thousand.
Now barcode scanning at checkout has been around for a long time. Unit pricing display is quite recent. There is no reason to assume that one computer application does both functions and therefore use the same data.
1 Like
If that was so the weight on the label would also be wrong, ie 575 kg instead of 575g.
If they keep two different prices in the system one for display and one for computing they are breaking another closely related basic rule that you only keep each datum on the system once. This is even more stupid than having internal dependencies.
There are good reasons that databases are normalised. This is a good example of why.
After decades in IT for big companies, sensible is not often a primary factor that I have observed.
And trying to keep a single unified copy of all data used by all applications in a big business is really, really hard.
Each application uses its own data as required, some unique to the application, some via common database calls in real time, and some via a synchronisation and merger process.
1 Like
That isn’t what I am suggesting. I am saying the inventory database - one application - ought to be well designed and internally consistent.
Allowing internal inconsistencies is just dopey and produces silly results as we see with the results shown here. You can design with much flexibility within that constraint allowing for different selling prices at different locations and times for each product - but only one each not two. This is quite do-able.
This topic dates back to the early days of unit pricing when mainly supermarkets had to scramble to get some sort of shelf display system in place to show unit pricing. This was a legislated requirement.
As can be seen from early posts there were lots of problems in conversion between units shown on the actual product, and the per unit price calculated and displayed on the shelf label.
I am pretty sure these teething problems have now been largely sorted out and what we have today is the rare and obviously wrong unit price on a shelf label.
These are due to humans entering wrong data into the application that prints out the labels.
Sure, an application can put more constraints on allowable inputs, and do sanity checks on results, but sometimes they do not.
It is not a matter of grafting on a sanity check it is building in internal consistency to the basic design. The price per unit should be derived not entered, thus no data entry checking of its validity is ever required if the design is correct. This is standard stuff that beginning database builders learn.
Let us agree the outcome shows a large degree of incompetence and leave it at that.
… especially given at the checkout they seem to know to within about a microgram what each product should weigh …
2 Likes
$8.49 for 500g at Aldi. Today’s comparisons.
From an online nut merchant…
Another way to look at it is that the Costco price is very sharp. One can click the ‘notify me when available’ and hope. We have been waiting months for smoked almonds to reappear. Sometimes there is a premium to buy something you can hold in your hand, not order, and not get in queue to order 
Would you please clarify your issue? The yellow tag? The unit pricing of ‘each’ not per 100g?
Is your post really about their [mis]use of unit pricing rather than ‘[looking like] great value’?
The yellow tag shows $8.49 per kilo at Aldi, but the pack is only 500g so they make it look like great value, but it isn’t all that great.
1 Like
The ‘per’ was the last I could see on the image as posted so I incorrectly thought it might be ‘each’. Zooming in on the image does reveal ‘per kg’. A bit wrong as you indicated.
Thanks for the clarification.
