1080p:
Perhaps this is the computer programmer in me thinking but I still cannot understand how there can be so many errors (I have seen some, now that I have looked) the tickets are electronic and so are the price per 100g labels. What I would assume would be that every time a price is changed a math method would run and a price per 100g would be generated. There would be no need for any human interaction with that calculation at all so the only errors you could run into would be incorrect unit pricing. There might need to be an option in which you can specify a percentage of $$$ to 'ignore' in the calculation so you could account for X% value extra for free products and the ability to account for buy one get one free tickets. Both should take an afternoon to implement IMHO.
As for products in the inventory database needing different EAN codes (but everything else remaining the same) this sounds (I haven't much experience here) trivial to implement as well.
Perhaps Foodstuffs should hire a couple of comp-sci students over the summer ;)
No offence to you - but your comments show a serious lack of retail experience. You are taking a very simplistic view of the issue. Here we're talking about maintaining 100% accuracy for approximately 15000 individual SKU's. Each week there are literally hundreds of changes in a supermarket whether they be new products, changes of size/packaging, or deletes of products. Loading all of this and maintaining it is a manual process. Calculating the 100g or unit size is simple - maintaining that backend data to ensure it's correct is not.
The issue with products such as a 10% free is far from trivial - it's an extremely complicated scenario due to the way products are ordered and stock levels maintained in the supply chain.

