Print & Email formats — buying side

What the supplier receives for a Purchase Order, a Goods Received Note and a Purchase Return. Only a settled document goes out — nothing still being agreed inside the business. Pick a document, a status and a view.

Document
Length
View
Status

Notes

How a long document breaks across pages show
  • Page 1 carries the full letterhead. Later pages carry a short one — buyer, document, number, date — so a loose page still says what it belongs to.
  • Column headings repeat on every page (thead + display:table-header-group, which wkhtmltopdf honours).
  • Carried forward / brought forward. A page cannot be swapped or removed unnoticed.
  • Totals and sign-off appear once, on the last page.
  • The watermark repeats on every page. Prove it on a 3-page document before shipping.
  • The footer says “Continued on page N” until the last page, and every page is numbered n of m.
Rows per page are fixed numbers here (10, then 20) so the break is easy to see. The real renderer breaks on height. A buying-side row is taller than a selling-side one because it carries the supplier's own item code.
What this design changes show

From ft_purchase_header and ft_purchase_detail:

  1. Only a settled document goes out — same rule as the selling side. A draft, one waiting for approval and a rejected one are still being agreed inside the business, so Print and Send Email are not offered. The earlier “send the supplier a review copy” idea is dropped.
  2. Nothing on the buying side prints today. The report module carries a sales receipt template and nothing else, so these three are new templates.
  3. A GRN is about quantities, not money. Its columns lead with Ordered · Received · Difference, because the question a receiving clerk answers is “did it all arrive?”. The value is shown, but second.
  4. A GRN has one sendable status — Received. There is no approval step, so nothing earlier exists to send.
  5. No LHDN block. A purchase document is not submitted to MyInvois by us — the supplier submits their invoice. The selling side's e-Invoice switch has no meaning here.
  6. The document number is always the real one, because every sendable status is past approval. A cancelled document keeps its number so the record stays traceable.
Two things still open show
“PR” means Purchase Return here, not Purchase Requisition. ft_purchase_header.doc_type offers PO · PR = Purchase Return · GRN_PO · CPO. There is a REQ status list in the code with no document type and no table behind it, so a requisition cannot be printed today. If you meant the internal request to buy, it needs a schema decision first.
Two label lists still SHOUT. PO, PR and GRN statuses read in sentence case, but CPO and REQ still read “RECEIVED PARTIALLY”, “OPEN”, “WRITE OFF (ESPECIALLY FOR FNB)”. Same problem as the Source Type that was fixed on the selling side. Not in scope here.

Mockup only — nothing here is wired to the server. Supplier, items and figures are realistic sample data.