Guide
Receipt Fields Explained
Receipt UIs fail in predictable ways: a long station name wraps into the amount column, a high-precision rate looks “wrong” after rounding, a missing optional field leaves an awkward blank. Understanding each field helps you design better fixtures in ReceiptPlay and better assertions in your product tests.
Business / store name
The merchant header sets brand recognition and often includes multi-line addresses. In Fuel, company selection plus custom lines 1–2 drive this block. Test very long names and two-line addresses to catch clipping.
Date and time
Transaction timestamps feed sorting and fraud heuristics in expense apps. Try ISO-looking dates, day-first formats, and times near midnight. Bulk Monthly Receipt Plan spreads dates across a range so month-view UIs have something to chart.
Transaction and reference numbers
Invoice numbers, nozzle numbers, and order IDs exercise monospace alignment and copy-to-clipboard. Include both short codes and long alphanumeric strings.
Item description, quantity, rate
Fuel uses fuel type + litres + rate; ecommerce uses SKU-like names with qty and unit price. Long item names with spaces and punctuation reveal table wrapping bugs. Zero quantity or zero rate (where your product allows) expose divide-by-zero or empty-state issues—use carefully and only as fictional samples.
Subtotal, taxes, discount, total
Money fields are where OCR and visual regression hurt most. Exercise:
- decimal precision (₹1,234.50 vs whole rupees)
- very large totals (many digit groups)
- small amounts (₹0.50-style fractions)
- discounts that change the visual hierarchy of the total
Ecommerce CGST/SGST columns stress multi-tax layouts; fuel often collapses to a single amount.
Payment mode and customer information
Cash / card / UPI labels are short but important for chips and filters. Customer names and vehicle numbers are optional on many slips—toggle them present vs absent to test conditional rows.
Footer and notes
Thank-you lines and promo footers are easy to ignore until they collide with download buttons in your app’s viewer. Put multi-line footers in Fuel’s footer fields and confirm preview + PNG still fit the intended height.
Why these fields matter in UI testing
| Scenario | Field stress | What to watch |
|---|---|---|
| Long values | Customer / station | Overflow, ellipsis, row height |
| Missing optional | Vehicle, phone | Empty labels, collapsed spacing |
| Decimal precision | Rate, litres | Alignment of decimal points |
| Currency formatting | Totals | Comma groups, symbol placement |
| Date formats | Datetime | Locale parsing in your app |
| Very large totals | Amount | Wrapping on mobile width |
| Small screens | Entire slip | Pinch-zoom vs reflow |
Connecting to ReceiptPlay
Use Random fill for a baseline fuel slip, then surgically edit one field at a time while watching the live preview. Download PNG and PDF for the same scenario to compare capture differences. For dense tax columns, switch to the Ecommerce invoice generator; for statement periods, use Postpaid / WiFi.
Worked example — editing one field at a time
Start with Random fill on Fuel. Change only the rate to a value with three decimal places and observe litre×rate totals. Next, lengthen line 2 of the station address until the preview grows. Download PNG after each step if you are building a visual regression pack. This isolates which field broke your viewer.
Cross-generator field map
| Concept | Fuel | Ecommerce | Postpaid | Rent / Driver |
|---|---|---|---|---|
| Party A | Station | Seller | Provider brand | Landlord / employer |
| Party B | Customer / vehicle | Buyer | Subscriber | Tenant / driver |
| When | Datetime | Order / invoice dates | Statement & due | Period / pay date |
| Money | Rate × litres | Line items + tax | Plan + GST | Rent / salary lines |
Reuse the same conceptual checklist across tools so QA language stays consistent even when layouts differ.