The Kirana Billing Project
Two Class 12 students are building the billing program for a relative's kirana shop in Bikaner as their vocational project. The program asks the counter operator for the item name, quantity and rate, then prints a bill with 5% GST. Version A has every rate written into the code, for example rate_sugar = 44, followed by a long series of if-else blocks. Version B keeps items in a list of dictionaries with name, rate and GST rate, and uses a loop and a function to compute the line total. In testing, the shop owner found four things: the printed bill once ended in ₹0.30000000000000004; cash is rounded to the nearest rupee at the counter, so the printed total disagreed with the cash taken; when the operator pressed Enter without typing a quantity, the program crashed with a ValueError; and a three-item bill printed the same item twice because the operator typed 'Sugar' and then 'sugar'. The owner changes rates most weeks and wants the bill to always match the cash box.
1. Which version, A or B, should the students submit, and what must be fixed in it before the shop depends on it?
Read the worked answer
Submit Version B, and say why in the project report. The owner changes rates weekly. In Version A every rate change is an edit to source code, which means the student is called to the shop, or the owner edits code he does not understand and introduces a typo with no record of the old rate. Version B separates data from logic: rates live in a structure the owner can maintain, and GST plus rounding are computed in exactly one function, which is the only way the bill and the cash box can be made to agree. B is also testable - one function can be checked with fixed inputs - and extendable to discounts or stock later.
But B does not pass yet. Four defects must be closed first.
- Name matching. A dictionary lookup is case-sensitive, which is exactly why 'Sugar' and 'sugar' became two lines. Normalise with strip and casefold before lookup, and reject an unknown item instead of silently charging rate 0.
- Input validation. Wrap the quantity and rate prompts in try/except ValueError and re-prompt, so a blank Enter cannot crash the till.
- Money. Never use binary floats for rupees. Store paise as integers, or use Decimal with an explicit rounding rule.
- Rates as data. Move the item list into a small external file the owner can edit, keep a dated backup of it, and print the bill number and date on every bill.
Reasoning. A school project can be graded on elegance; a till cannot. The judgement here is that maintainability and a single rounding rule matter more than the shorter code.
2. Explain the ₹0.30000000000000004 and the cash mismatch, and give a fix with a worked example.
Read the worked answer
Why the long decimal appears. Binary floating point cannot represent 0.1 or 0.2 exactly, just as decimal cannot represent one-third. Try 0.1 + 0.2 in Python and you get 0.30000000000000004. A bill sums many such values, so the error accumulates and eventually prints. It is not a bug in Python; it is the wrong number type for money.
Why the cash box disagreed. There are two separate rounding decisions: rounding GST on each line and rounding the grand total to the nearest rupee for cash. If the program rounds each line and then totals, while the counter rounds only the final amount, the two will differ by a rupee or two. If the program does not round at all, they will differ by paise every time.
Fix. Keep money in paise as integers, apply one rounding rule (round half up) at defined points, and print the round-off as its own line so nothing is hidden.
Worked example. 3 items at ₹15.75 = ₹47.25 = 4725 paise. GST at 5% = 236.25 paise, rounded half up to 236. Total = 4961 paise = ₹49.61. Cash rounded to ₹50.00, so round-off = +39 paise, shown separately on the bill.
Also decide and state one thing the students often skip: whether the printed rate is GST-inclusive or exclusive. If inclusive, the GST is extracted from the total rather than added, and the bill must say so. Either way, the day's round-off column must be totalled and reconciled, otherwise the till is always slightly out and nobody knows why.
3. Write the validation rules and a test table the students should run before handing the program over.
Read the worked answer
Validation rules.
- Item name: strip and casefold; must exist in the rate table; if not, show the closest matches rather than guessing.
- Quantity: whole number, 1 to 99; anything else re-prompts and never crashes.
- Rate: positive, two decimal places, normally read-only from the rate file; any manual override must be logged with time and operator.
- Payment mode: cash or UPI from a fixed list; cash triggers the round-off line.
- Bill total: recomputed independently and compared before printing, as a cheap self-check.
Test table (input, expected behaviour). Blank quantity; 0; -1; 1.5; 'abc'; a very large number; 'sugar'; 'SUGAR '; an unknown item; a missing rate file; two items with the same name in the file; printer offline mid-bill; power cut after the total is computed but before printing.
Reasoning behind these cases. The first four are the failures the owner has already seen. The rest are the boundary cases he will meet in the first week, because a kirana till is operated by a non-technical person under time pressure with a queue in front of him. Every failure must be recoverable by re-typing, not by restarting the program with a customer waiting.
One operational safeguard. Print or save a day-total at closing and back up the bill file nightly, so a crash does not erase a day's sales. Testing the happy path only proves the program works when nothing goes wrong, which is not what a shop needs to know.