Just came across this post on reddit, where someone was charged $1,223 for a "FREE STEAK SALAD".
I was trying to figure out 'Why 1223?' thinking that this might be a programming error somewhere. But 1223 seems to be pretty much an ordinary number (= 100110001112).
Any ideas?
The price is not the only thing which is special with the concerned product. You can also notice that the name is a bit strange:
Given that, it seems more like an human error, like those test entities you may see on low quality websites when they are just opened¹ and didn't get rid of demo data. You may often find products entitled "Hello Hello", or "TEST" or something similar, with 12345, 1111 etc. for integer-type fields, like prices or quantities. Since this data is entered quickly, sometimes you can see typos like "TTEST" or "Hlelo" or 1223.
To be short, because nobody cares.
When you release a software product, you have to test it on data close to the real. One way is to:
Define the data how it is meant to be in production,
Set the demo data which is close enough; for example, Adventure Works contains demo data which is still close to real: if you see the table containing customers, there are people with real but fictive names, and you'll not find anybody called Mr. Test Test.
The case is similar for example for Oracle database Express Edition, when you create an application in Application Express.
Test the website with the development database containing demo data.
Push the website to production environment, using production database with no demo data.
The same comes for any bug. Where a bug is reported, you test it in development environment, solve it, test it in staging, and then push the update to the server.
This process is both hard and expensive, so beginner developers or developers working on products with insufficient funding are testing the bug reports directly in production. So when a bug report says that the product management software crashes when creating a product with a specific property, a developer might just go and create a "·free·steak·salad" with a random price of 1223. Then the developer finds that there is actually a bug, solves it, but after four hours of spaghetti code debugging, he forgets to remove the test data, and mixes it up with a real product which ends up in a ticket.
¹ Some contain test data for years, since nobody cares.
It is impossible to say for sure without getting our hands on the software.
My guess from doing Point of Sale programming for many years:
Point of Sale software tends to be very configurable at the store. I suspect that this particular software doesn't have support for "special deals". That is, the software itself has no way to support things like "Buy a Mojito, get a free steak salad". The manager pokes around the software trying to figure out how to get this to work.
The software probably supports items with fixed prices and items with variable prices. Variable priced items ask for price. The manager things "aha! I'll make set up one of these for the steak salad and instruct my people to just enter zero!" He does so, capitalizing and indenting the "FREE STEAK SALAD" because he wants to highlight the special deal.
This works well enough. Cashiers sell mojitos, enter the "FREE STEAK SALAD" item number, then zero, then enter.
One day, a cashier isn't paying attention and forgets the price prompt. They are probably just typing blind from an order. They enter the "Free Steak Salad" item number than the "Angel Food Cake" item number. The latter is 1223. They look up, and the prompt says "FREE STEAK SALAD". "Huh", they say, at enter it again. It works, and they figure "must be a computer glitch" and stuff the receipt in the bill without looking at the price.
This may be exacerbated by the fact that older registers don't have CRTs but rather only a 2-line display. The display may not have the total price on it.
That's my guess. It's just a theory, though. There are many possible explanations. As others have said, it could also be that "FREE STEAK SALAD" is a fake item and the cashier got it by accident by mistyping the item number. I think that's less likely though.
Adding indentation is a common in some bills to mark that the item is a subitem or options of the preceeding unindented bill. This means that the FREE STEAK SALAD may be a bonus from purchasing Berry Mojito.
As to how its price becomes $1223.00, it may be a 0xDEADBEEF number; the programmer uses that number to initialize variables which is supposed to be overwritten by the proper price, but somehow a bug in the code when processing subitems/options causes the variable to not be written and instead gets printed into the bill. In this case, the number $1223 is chosen because it's a distinctive huge number and would attract attention if there is a bug in the POS system (and it does save the day in this bill).
It may be that this particular establishment doesn't use subitem/options in the program, but the POS machine still has the button to create them and a staff pressed that button by accident. And it's probably that the POS software has never been tested when pressing the subitem/option button when there is no entries in the subitem/option database; that's why the magic number showed up.
Also, as to how it's in ALL CAPS; it may be because the POS software is hardcoded to capitalize subitems/options, to make it easy to distinguish them while scanning the bill.
All these are speculations though, unless you contacted the establishment and their POS developer.
