PalmStat ERP · Operations
Palm Stationery Manufacturers (Pty) Ltd · Cape Town
12 Industria Crescent, Epping 2, Cape Town, 7460
Tel +27 21 534 0000 · ops@palmstat.co.za

Delivery Note + POD · Standard Operating Procedure

Step 8 of 8 · goods leave the factory · customer signs · FG → CUSTOMER inventory move
APPROVED
SOP-DN-007
v1.0 · Last reviewed 2026-05-08
← Previous: FGRN · Index
Lifecycle step
Step 8 of 8
Module owner
Dispatch Hub · Logistics
Trigger event
SO line PACKED → DISPATCHED → DELIVERED
Approval matrix
Picker + Loader + Driver + Customer

1. Purpose

The Delivery Note (DN) and Proof of Delivery (POD) are two views of the same document that closes the order-to-cash flow. The DN is generated at the PACKED stage and travels with the goods on the truck. When the customer signs at the receiving end, the same spec is overlaid with the receiver's name, signature, date/time and condition note — that overlay is the POD. The signed POD is the legal evidence that the customer accepted the goods, and triggers the FG → CUSTOMER inventory move plus the SO line transition to COMPLETE.

This document mirrors NetSuite WMS Pick/Pack/Ship + POD, SAP S/4HANA Outbound Delivery + Goods Issue confirmation (VL02N + VL01N), Oracle WMS Cloud Shipment + Delivery Confirmation, and Sage X3 "Delivery + Customer Confirmation". The POD is also the SARS / VAT supporting document for the sales-tax point-in-time invoice.

The DN-POD pair is the only place in the lifecycle where an external counterparty (the customer) signs — so capture quality matters: receiver name, condition flag (Acceptable / Damaged / Short), photo where required.

2. When to use

3. Data sources

The DeliveryNote spec (frontend/js/erp-templates/delivery-note.js) and the PodDoc overlay (frontend/js/erp-templates/pod-doc.js) build from sales orders + customers + vehicle / route metadata. Each row below is wired to a real column.

Field on documentAPI endpointDB table.columnExample value
DN Ref No.generated client-side · previewRef()(stamped on print)DN-2026-0481
POD Ref No.derivedpodRef(dnRef) · DN- swapped to POD-POD-2026-0481
DN datePOST /api/sales-orders/…sales_orders.due_date / dispatch date2026-05-08
Sales Order refGET /api/sales-orders/:idsales_orders.order_noSO-2026-1142
Customer code & nameGET /api/customerscustomers.code & customers.nameSHOPRITE · Shoprite Checkers
Customer P.O.POST /api/sales-orderssales_orders.notes (PO captured here)PO-SHO-882139
Bill-to addressGET /api/customers/:idcustomers.notes (parsed) / external CRM1 Brackenfell Bvd, Brackenfell
Ship-to addressGET /api/customers/:iddelivery fields on customer / SO14 Voortrekker Rd, Goodwood
Item codeGET /api/productsproducts.code (FK sales_order_lines.product_id)A4_72PG_FM
Item descriptionGET /api/productsproducts.nameA4 72-page FM
UoMmaster dataproducts.codeitems.uomEA
Qty orderedGET /api/sales-orders/:idsales_order_lines.qty5 000
Qty packedcaptured at packingsales_order_lines.qty_planned (post-packing)5 000
Qty deliveredcaptured at PODsales_order_lines.qty_produced at delivery4 980 (20 short)
Lot / batch refFGRN cross-refproduction_batches.batch_refBATCH-2026-0481
Route code & labellogistics mastervehicle.route_code (planned in dispatch view)CT-NORTH
Truck reglogisticsvehicle.truck_regCA 184-329
Driver name & clockGET /api/employeesemployees.first_name + last_name + clock_noS. Goosen (clock 4407)
Picker / Loader signcaptured on dispatchcross-ref to employees.clock_noP. Mokoena (1042)
Dispatch warehouseGET /api/warehouses?type=FGwarehouses.codeFG-MAIN
Special instructionsPOST /api/sales-orderssales_orders.notes"Deliver before 11:00"
Receiver name (POD only)captured by driver / appnot stored on SO · carried in document_links + POD specT. Khumalo
Received date / time (POD)captured by driver / appFG → CUSTOMER inventory_transactions.txn_date2026-05-08 09:42
Condition (POD)captured by driver / appencoded in POD spec · "Acceptable / Damaged / Short / Rejected"Acceptable
Proof photo URLcaptured by driver / appdocuments.s3_key · document_links.entity_type='sales_order_line's3://…/pod-2026-0481.jpg
FG → CUSTOMER inventory movePOST /api/inventory/transactionsinventory_transactions.txn_type='ISSUE' with reference_type='sales_order'−5 000 EA from FG-MAIN

4. Step-by-step workflow

  1. SO confirmed & allocatedPOST /api/sales-orders creates the header + lines. SO lines pegged against FG stock once FGRN posts.
  2. Pick & pack — dispatch team picks against the SO; packs to spec on products (ream count, shrink-wrap, pallet height).
  3. Generate DN — from the dispatch board, click Print Delivery Note. Frontend calls DeliveryNote.print(salesOrder, lines, customer, vehicle). Spec status starts as CONFIRMED at PACKED stage.
  4. Picker / Loader sign — the printed DN carries 4 signature blocks (Picker, Loader, Driver, Customer Receipt). Picker signs at pick; loader signs at truck load.
  5. Truck dispatch — driver signs the Driver block, takes 2 copies (one for customer, one for return). The system marks the SO line as DISPATCHED.
  6. Customer receipt — on arrival, customer's receiver checks the goods, signs the Customer Receipt block on the printed DN. Driver records: receiver name, date, time, condition (Acceptable / Damaged / Short / Rejected), and takes a photo if required.
  7. Convert DN → POD — back at the dispatch hub, the driver hands over the signed DN. Operations clerk runs PodDoc.build(deliveryNote, receivedBy, receivedAt, condition, photoUrl) in the dispatch view, which overlays the receiver block on the existing DN spec, swaps title to "Proof of Delivery", and stamps a "RECEIVED ✓" subtitle.
  8. Post FG → CUSTOMER movePOST /api/inventory/transactions with txn_type='ISSUE', from_warehouse_id = FG-MAIN, reference_type='sales_order', reference_id=sales_order.id. FG units leave PalmStat stock.
  9. Update SO linesales_order_lines.qty_produced += qty_delivered. When all lines deliver, sales_orders.status flips to COMPLETE.
  10. Trigger invoice — finance picks up the COMPLETE SO and raises the customer invoice; POD is the supporting document for the VAT-point-in-time.
  11. Archive — signed POD scanned + photo attached, uploaded via POST /api/documents with kind=POD. document_links ties to entity_type='sales_order'. Retained 7 years for SARS audit.

5. Roles & permissions

ActionAdminDispatchDriverFinanceCustomer
Generate DN
Sign Picker / Loader / Driver
Capture POD (receiver, condition)✓ (signature only)
Post FG → CUSTOMER move
Reprint after archive
Email externally to customer
Reverse / void (returns)✓ (with audit reason)

Permission gate enforced by requireRole('admin','planner') on POST /api/sales-orders and the standard inventory write gate on the FG → CUSTOMER move.

6. Common scenarios

Scenario A · Single-drop, customer accepts

Happy path: 5 000 units delivered, customer signs Acceptable. Driver returns signed DN. Operations runs PodDoc.build, posts FG → CUSTOMER, SO closes, finance invoices. Cycle time pick→invoice < 8h.

Scenario B · Short delivery

Happy path: Truck loaded with 5 000 but only 4 980 arrive intact (20 damaged in transit). Customer signs Short, condition: 20 EA damaged. POD reflects 4 980 delivered. SO line stays partial-open. Replacement run scheduled.

Sad path: Driver records full 5 000 as Acceptable. Customer disputes invoice. Recovery: cycle-count + investigation, retroactive credit note + adjustment txn.

Scenario C · Refused delivery

Happy path: Customer refuses goods because batch ref is not the agreed one (lot mismatch). Driver records condition Rejected. Goods return to FG-MAIN via reverse PROD_IN. SO line reopens. Dispatch retries with the correct batch.

Scenario D · Multi-drop run

Happy path: Truck visits 4 customers. One DN per customer is generated upfront; each DN becomes a separate POD when signed. Driver returns 4 signed PODs at end of route. Each posts its own FG → CUSTOMER move.

Scenario E · Damaged in transit, photo evidence

Happy path: 1 of 4 pallets has water damage. Driver photographs at unloading, customer signs Damaged with note. POD photo URL stored. Insurance claim opens against the carrier with POD as supporting evidence.

7. Related documents

Upstream  ·  STEP 6: FGRN (FG units in stock)
Upstream  ·  Sales Order header + lines (sales_orders, sales_order_lines)
Upstream  ·  Customer master (customers) & Product master (products)
   →  STEP 7: Delivery Note · printed at PACKED stage
   →  STEP 7: Proof of Delivery · same spec, signed by customer
Downstream  ·  inventory_transactions rows of type ISSUE (FG → CUSTOMER)
Downstream  ·  Customer Invoice (finance system)
Cross-ref  ·  fg_stock_snapshots (month-end FG closing position)
Cross-ref  ·  SARS / VAT audit trail (POD = point-in-time evidence)

8. Approval signatures

Document Owner
Dispatch Supervisor — ____________
Signed: ____ / ____ / ______
Quality Lead
Driver — ____________ (clock ____)
Signed: ____ / ____ / ______
Operations Director
Customer Receiver — ____________
Signed: ____ / ____ / ______ · Condition: ☐ Acceptable   ☐ Damaged   ☐ Short

9. SLA & escalation

Stage Target Owner Escalation
FG ready → DN print 15 min Dispatch supervisor Logistics Manager
Pick + load + truck depart 2h from print Dispatch + Driver Logistics Manager
Customer receipt Within booked window Driver Customer Service if > 30 min late
POD captured (electronic) At unloading Driver / app Dispatch supervisor
POD scanned + filed End of route · same day Dispatch clerk Operations Director
FG → CUSTOMER inventory move Same day as POD Dispatch / Finance Finance Controller
Customer invoice raised Within 24h of POD Finance CFO

10. Glossary