Invoice

This program generates printed invoices by collecting company details, billing address, item information, and pricing data through a series of INPUT prompts. It mirrors each entered value to both the screen (PRINT) and a thermal or impact printer (LPRINT), producing a formatted invoice with the word “INVOICE” printed in inverse video via LPRINT TAB 10. Pricing calculations include quantity × unit price, sales tax conversion from percentage to decimal (line 170), and shipping charges, with all monetary results rounded to two decimal places using the INT(100*x+0.5)/100 idiom. After displaying the final totals, the program waits for a keypress via a busy-loop on INKEY$ before clearing the screen and looping back to line 30 for another invoice entry.

---

Program Analysis

Program Structure

The program is divided into three logical phases:

1. Header collection (lines 2–14): Prompts for the seller’s company name, address, and city/state/zip, printing each to both screen and printer, then prints “INVOICE” in inverse video at TAB 10.
2. Billing and item entry (lines 16–165): Collects the recipient address, item description, quantity, unit price, sales tax percentage, and shipping charges, again mirroring all input to screen and printer.
3. Calculation and display (lines 170–320): Computes subtotal, tax, and invoice total; rounds all monetary values; displays and prints results; waits for a keypress; then loops back to line 30 for a new item entry on the same invoice header.

Dual Output Pattern

Every piece of user input is echoed with a paired PRINT/LPRINT sequence. This lets the operator verify data on screen while simultaneously building a hard-copy record. The pattern is consistent throughout, though the screen confirmation lines (e.g. line 4, 8, 12) simply reprint the raw variable rather than adding any label.

Inverse Video in LPRINT

Line 14 uses LPRINT TAB 10;"%I%N%V%O%I%C%E" where each letter is preceded by %, the zxtext2p escape for inverse video. This sends inverse-video character codes to the printer. Whether the attached printer reproduces inverse video depends on its firmware; on many period printers this would print normally or produce unexpected output.

Monetary Rounding

Lines 210–230 apply the standard two-decimal rounding idiom:

• LET A=INT(100*C+.5)/100 — rounded subtotal
• LET B=INT(100*T+.5)/100 — rounded sales tax
• LET D=INT(100*F+.5)/100 — rounded invoice total

Adding 0.5 before truncation with INT provides conventional half-up rounding. Note that the shipping charge H is printed directly without rounding; since it is entered by the user this is generally acceptable but could theoretically display extra decimal places if the user types a value like 2.755.

Sales Tax Conversion

Line 170 converts the entered percentage to a decimal in-place: LET S=S*.01. This reuses the variable S, which is acceptable here since the original percentage has already been printed and is no longer needed. The tax amount is then computed as T=C*S on line 190.

Keypress Wait and Loop

Line 300 implements a busy-wait loop: IF INKEY$="" THEN GOTO 300. This holds execution until any key is pressed, then clears the screen and jumps to line 30. The loop at line 30 re-enters the item/pricing section, meaning the seller address captured at the start is reused across multiple invoice items — useful for batch invoicing to the same customer in one session.

Variable Summary

Variable	Purpose
N$	Seller company name
L$	Seller address
Z$	Seller city/state/zip
Y$	Recipient name
X$	Recipient address
W$	Recipient city/state/zip
V$	Item description
Q	Quantity sold
P	Unit price
S	Sales tax (% input, converted to decimal)
H	Shipping charge
C	Subtotal (Q×P)
T	Tax amount
F	Invoice total (C+T+H)
A	Rounded subtotal
B	Rounded tax
D	Rounded invoice total

Anomalies and Notes

• Line numbers jump unevenly (e.g. 14 to 15, 33 to 40, 65 to 70) suggesting the program was extended after initial entry rather than planned in regular increments.
• The loop returns to line 30 (item entry), not line 2, so the seller and recipient headers are printed to the printer only once per run, even across multiple loop iterations — this may or may not be the intended behaviour for multi-item invoices.
• Line 500 (RUN) is unreachable under normal execution but would restart the program if the file were loaded and a GOTO 500 issued manually.