As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

7

Seems the only thing special about this is that it is ridiculously high for a FREE steak salad.
–
XQYZMay 27 '12 at 8:34

As you were charged in $&c the number is actually 122300 (= 11101110110111100) Still no insight there though.
–
NWSMay 27 '12 at 8:39

2

I doubt there's anything special about that number.
–
WormboMay 27 '12 at 9:20

2

Apparently the salad is also a liquor. Maybe it was spiked.
–
Pieter BMay 27 '12 at 12:01

3 Answers
3

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:

The first word is "free". Do you see a lot of stuff with its name starting with "free" in your market/restaurant?

The name starts with a whitespace. Why?

The name is written in capitals, while the other names are written using Capitalize Each Word style.

At the bottom, you see "Food: $6.95; […]quor: $1,249.90". If the half-hidden word is "Liquor", it means that the steak salad was defined as a beverage instead of food.

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.

So why this data appears in a ticket?

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.

Completely agree with your answer, but I wanted to point out that on receipt tape, with no bolding or italics, all caps and indentation is often used for emphasis. My guess is that the software requires the cashier to enter the price for "special" items, and instead of entering zero, typed the item number for the next item, or something similar. In other words, the manager wanted a "free item" feature but the software didn't support it so he hacked it in to data.
–
Steven BurnapMay 27 '12 at 16:48

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.

Good point. But this doesn't explain why the name is written in all capitals and why it is (probably) qualified as a beverage.
–
MainMaMay 27 '12 at 12:02

@MainMa: I did provide a possible (although speculated) explanations of the all caps, and why the item become a suboption of a beverage. The button that caused the error is probably a button that is meant to make the next purchased item to be free/discounted due to the purchase of the preceeding item. A quick google search of TK's Urban Tavern, they do seem to have "Steak Salad" in their menu: urbanspoon.com/r/22/1576622/restaurant/Phoenix/North-Scottsdale/… which is inconsistent with the theory that it is a purely test database entry.
–
Lie RyanMay 27 '12 at 13:50

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.