Project: shop receipt generator

The brief

Cedar Corner Market is a family-run grocery shop. Its old till broke, and until the new one arrives the owner, Huda, wants a small program that prints receipts. She writes down what she needs:

As the person at the till, I want to type in each item the customer buys and get a clear, correct receipt, so that customers trust the total and I can give the right change.

Input. One item per line in the form name, quantity, unit price, for example Milk 1L, 3, 6.20. The word done (in any capitals) ends the list. After that, one more line: the cash the customer hands over.

Output. A receipt like this one:

CEDAR CORNER MARKET
Item               Qty    Price     Total
-----------------------------------------
Coffee beans         2    32.50     65.00
Dates 500g           1    24.00     24.00
Milk 1L              3     6.20     18.60
  multi-buy -10%                    -1.86
Olive oil 1L         2    48.00     96.00
Items: 4
-----------------------------------------
Subtotal                           201.74
Order discount 5%                  -10.09
VAT 15%                             28.75
TOTAL                              220.40
Paid                               250.00
Change                              29.60

Acceptance criteria.

1. Every item line shows the name, quantity, unit price and line total, in aligned columns.
2. Buying 3 or more of the same item takes 10% off that line (a "multi-buy").
3. If the subtotal after multi-buys is 200 SAR or more, a further 5% comes off the order.
4. VAT of 15% is added to the amount after all discounts.
5. Each discount and the VAT are rounded to 2 decimal places when they are calculated.
6. The receipt shows what was paid and the change, or how much is still owed.
7. A badly typed line never crashes the till: it is skipped and listed at the bottom of the receipt.

You'll build this in six milestones. Each one is a complete, working program; the next milestone starts from it.

Design: inputs, calculations, outputs

Before writing code, sort the brief into the three parts every program has:

Three decisions shape the code:

• A sentinel loop. You don't know how many items a customer has, so the program reads lines in a while loop until it meets done. The word that stops the loop is called a sentinel.
• Accumulators. count and subtotal start at 0 and grow by one item each time round the loop.
• Constants for the rules. The 15% VAT, the 10% multi-buy and the 200 SAR threshold are business rules that will change one day. Naming them once at the top (VAT_RATE = 0.15) means one edit, not a hunt through the code.

Here is the core loop on its own, with fixed lines so you can watch it work:

Notice that int(" 2") and float(" 11.50") both accept the spaces left over after split(",") — but the name keeps its leading space, so it needs strip(). And line.strip().lower() lets the till operator type done, Done or DONE .

Milestone 2: totals and VAT

The list works; now the money. Keep a running subtotal beside count, then work out the VAT once after the loop. Because the VAT is money the shop pays to the tax authority, round it to 2 decimal places when you calculate it, and add the rounded value to the subtotal. That way the printed VAT and the printed total always agree.

Milestone 3: aligned columns

Huda tapes a sample receipt to the wall: columns must line up so a customer can run a finger down the totals. An f-string format specification sets a width and alignment: {name:<18} pads to 18 characters, left-aligned; {price:>9.2f} right-aligns in 9 characters with 2 decimals. Adding the widths 18 + 4 + 9 + 10 gives a 41-character receipt. Labels in the totals block take the first 31 characters (18 + 4 + 9), so their amounts sit under the Total column.

A long name like Saffron threads premium grade would push its row out of line, so you cut names to their first 17 characters with a slice, name[:17], leaving at least one space before the quantity.

Milestone 4: discounts in the right order

Discounts are where real tills go wrong, because the order of the rules changes the answer. The brief fixes it:

1. Multi-buy comes first, per line: 10% off a line of 3 or more.
2. The subtotal is the sum of the lines after multi-buy.
3. The order discount (5% from 200 SAR) is worked out on that subtotal.
4. VAT is charged on what the customer actually pays for: subtotal minus order discount.

"200 SAR or more" means >=, not >. A subtotal of exactly 200.00 gets the discount — boundary values like this are exactly where tests look.

Milestone 5: taking payment

After done, the till reads one more line: the cash handed over. Two outcomes are possible, and the receipt must show the right one. Round the change when you calculate it: 250 - 220.4 is 29.599999999999994 in floating point, and a till must say 29.60.

Milestone 6: bad lines and empty orders

Real typing is messy. In the first hour of use Huda types Bananas, two, 4.50, Water 6pk, 1 and a line with a quantity of 0. With the current code each of these crashes the till: int("two") raises ValueError, and unpacking two fields into three names raises another.

Instead of letting Python decide, check each line before using it. A line is valid when:

• it splits into exactly 3 fields;
• the name is not empty after stripping;
• the quantity is all digits (qty_text.isdigit()) and not 0;
• the price is a number such as 6.20 or 24: removing at most one dot leaves only digits, price_text.replace(".", "", 1).isdigit().

Invalid lines are kept in a list and printed at the end so nothing is silently lost. This is called validating input: the program decides what it accepts instead of crashing on whatever arrives.