Skip to content

Book 3 — Procurement & Suppliers (Index)

Bizwiz Guide · Book 3 of 7 · Review instrument How Bizwiz buys: from "we need stock" through "goods received" to "supplier paid" — and the portal that lets suppliers act on their own orders and see their money.

This book covers the procure-to-pay spine of Bizwiz across three chapters. Read it as one story: a requisition becomes a purchase order, the PO is received (handed off to Book 2 Ch9), the receipt becomes a payable, and the payable is settled — with a supplier portal giving suppliers a window (and levers) onto the middle of that chain.

# Chapter One-line scope
12 Purchases & Requisitions Branch requisitions → LPOs → multi-level approval; the buying front door
13 Accounts Payable Creditor ledger, supplier invoices/bills, credit notes, payment vouchers → cheque/EFT/cash, WHT/VAT/statutory
14 Supplier Portal Suppliers accept/change/return LPOs and view invoices/payments — a 3-tier app + portal backend + per-tenant APIs

The procure-to-pay flow

flowchart TD
    NEED[Branch needs stock] --> REQ[External Requisition<br/>wa_external_requisitions<br/>UNAPPROVED→PENDING→PROCESSING→APPROVED]
    REQ -->|ResolveRequisitionToLpo| LPO[Local Purchase Order<br/>wa_purchase_orders]
    DIRECT[Direct buying] --> LPO
    LPO -->|needs_approval queue<br/>multi-level authority| LPOA[LPO Approved<br/>LpoApproved event]
    LPOA -->|to supplier| PORTAL{Supplier Portal Ch14}
    PORTAL -->|accept / change / return / slot| LPOA
    LPOA -->|goods arrive| GRN[GRN — Book 2 Ch9<br/>wa_grns / wa_receive_purchase_orders]
    GRN -->|match supplier invoice| INV[Supplier Invoice<br/>supplier_invoice_process]
    INV -->|creates| LEDGER[(wa_supp_trans<br/>CREDITOR LEDGER)]
    LEDGER -->|payment voucher| PAY[Approve → Cheque / EFT bank-file / Safe]
    PAY --> GL[(wa_gl_trans<br/>DR Creditors / CR Bank)]
    PORTAL -.read view.-> LEDGER
    PORTAL -.read view.-> PAY
    ADV[Advance Payment] -.prepay against LPO.-> LEDGER

The one-sentence version: wa_external_requisitions → (resolve) → wa_purchase_orders → (approve) → supplier acts via portal → (receive) → wa_grns → (invoice) → wa_supp_trans → (voucher) → wa_bank_trans + wa_gl_trans.

Cross-chapter & cross-book seams

Within Book 3: - Ch12 → Ch14: the LPO is the object suppliers act on. The portal writes back to wa_purchase_orders (tri-state supplier_accepted), wa_lpo_portal_req_approval*, and can trigger receipts (wa_receive_purchase_orders, wa_stock_moves). - Ch12 → Ch13: a received/invoiced LPO becomes a payable. Proven via model relations — WaSuppTran, WaGlTran, and AdvancePayment all hang off wa_purchase_order_id. - Ch14 ↔ Ch13: the portal's "invoices / payments / statements" screens are a read view over the AP tables (wa_supp_trans, payment_vouchers, financial_notes, wa_grns, wa_bank_files).

To other books: - ← Book 2 Ch9 (Goods Receiving): the GRN is the physical hinge between "ordered" (Ch12) and "owed" (Ch13). wa_grns.wa_purchase_order_id ← PO; wa_grns.wa_supplier_invoice_id → the AP invoice. - → Book 4 (Finance / GL): every AP posting lands in wa_gl_trans (creditors control, GIT, VAT input, WHT/VAT/statutory liabilities, bank); EFT settlement posts wa_bank_trans. AP is a primary trial-balance feeder. - → Book 1 (Debtors): supplier credit notes flagged affects_debtors=true cross into wa_debtor_trans / customer_credits — a genuine supplier↔customer bridge. - ↔ Petty cash / fuel / tyres / consumables / property: each has its own invoice table but all settle through the same polymorphic payment-voucher engine (payment_voucher_items.payable_type).

Consolidated open questions (the review agenda)

Grouped from each chapter's §7. CODE-PROVEN items are stated as fact in the chapters; the items below are what needs human/dev confirmation.

Configuration / "which is live per client": - Which tenants run: the LPO multi-level approval authority tiers; the AP invoice-posting approval workflow; two-step voucher confirmation; partial payments; extensive (per-category) GL posting? All are capabilities, not defaults. - Are the specialised AP invoice tables — supplier_consumable_invoices, tyre_supplier_invoices, property_supp_trans (all 2025–2026 migrations) — live for any current distributor, or scaffolding?

Data-integrity quirks to verify against the live schema: - Ch12 status='DRAFT' quirk: store() writes DRAFT, but the wa_purchase_orders status ENUM (migration line 28) has no DRAFT value and sendRequisitionRequest only matches UNAPPROVED. MySQL may be coercing DRAFT→''. This affects whether the send-for-approval step ever fires — needs live-schema confirmation. - Ch12 PRELPO-vs-PENDING resolve fork — which branch is taken when a requisition resolves to an LPO. - Ch13 due_date derivation at SupplierController.php:2537 (payment terms) — needs a focused read.

Ownership / architecture boundaries: - Ch14: the Flutter app's /api/mobile/* endpoints (login, lpo-listing, erps) have no matching routes in the bizwiz repo — presumed served by the separate Portal backend (SUPPLIER_PORTAL_URI) or an out-of-repo per-ERP bizwiz. Confirm this boundary, the web-portal repo location (source absent), and wallet/billing ledger ownership. - Ch13: how non-Equity banks are paid (only Equity host-to-host EFT was found in code); whether property_supp_trans is true AP or a parallel property-module ledger.

Semantics to confirm with users: - The business meaning of voucher "confirm" (fraud check? bank-detail verification?) vs "approve". - Whether the supplier-portal impersonation workflow (Pending→Approved→minted login URL) is used operationally and by whom.

Recurring Bizwiz patterns reinforced by Book 3

  • Approval queues everywhere — requisition approval, LPO multi-level authority, invoice-posting approval, two-step voucher confirmation, send-to-bank. The single richest "approvers not curators" AI surface so far: humans mostly match and eyeball data the system already holds.
  • One engine, many payables — the polymorphic payment-voucher settles 9+ document types. A durable abstraction worth preserving in any redesign.
  • Mid-modernization layering — recent (2025–2026) specialised invoice tables and a separate portal backend sit alongside the original wa_* core; "old path kept, new path added" continues (see Book 2's netting note).
  • External integrations are real — Equity H2H (SFTP + encrypted CSV) and the standalone Supplier Portal backend are live dependencies, not stubs.

Book 3 complete: 3 chapters + this index, assembled from static analysis of the bizwiz monolith and the bwsupplierportalapp Flutter app. Ch13's research was recovered from three parallel code-tracing passes after its writing agent was interrupted. Next in the fan-out: Book 4 — Finance & Accounting (General Ledger, Fixed Assets, Petty Cash).