It's missing a qrcode with a date, uuid, total, tax and unguessable url to the items list and prices (or gzipped json of it) so that we can finally scan import receipts with software.
Qr codes should be mandatory on most paper docs IMO. Forms, invoices, contracts, etc.
Parent comment already covered that case. If the content is included in the code, it doesn't need to be stored anywhere.
Nobody said permanent, either. It'd be reasonable that the data expires after a certain amount of time. Preferable, even, for limiting exposure in the event of a breach.
Additionally, while I don't think this is the case for grocery stores, most stores do actually keep a record of every purchase made. The data and aggregated analytics on said data is huge, and it allows for things like faster returns and personalized coupons/recommendations.
30 bits to represent the 13 digit IAN.
3 bytes for prices up to 167772.16. If you frequently buy things more expensive than that, just have one of your servants transcribe the recipe to your favorite format.
1 byte for the number of items. If you buy more than 255 of one thing, we'll just add another line to the recipe.
That's 60 bits per line item. A QR code holds up to 23,648 bits. That makes up to 394 line items per QR code, without compression, which ought to be enough for anyone.
If you do buy more than that, the POS crashes^H prints another QR code.
>1 byte for the number of items. If you buy more than 255 of one thing, we'll just add another line to the recipe.
You could split prices greater than 167772.16 into chunks, delimited by using zero for the number of items in the subseqent line items.