Supplier Catalog and Guided Buying

The control flow a finance team actually needs.

The ERP surface involved.

Catalog must support OCI/cXML punchout standard (SAP Ariba-compatible); catalog items must display real-time price validity dates; guided buying rules must surface preferred suppliers and preferred items at the top of search results; non-catalog items must require a justification reason when catalog coverage exceeds a configurable threshold; catalog import must support CSV bulk upload with validation; price changes in the catalog must not affect already-approved POs.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Audit evidence is a chain, not a folder.

supplier_catalog { id: string, supplier_id: string, entity_id: string, status: enum, valid_from: date, valid_to: date };
catalog_item { id: string, catalog_id: string, sku: string, description: string, unit_price_minor: int64, currency_code: char(3), lead_time_days: int, moq: int, is_preferred: bool };
punchout_session { id: string, supplier_id: string, requester_id: string, cxml_session_id: string, started_at: timestamp, status: enum };
(reference, product may differ).

GET /v1/catalog-items?q=&category_code=&entity_id= -> 200 { items[], preferred_first: bool };
POST /v1/punchout-sessions { supplier_id, requester_id } -> 201 { redirect_url, session_id };
POST /v1/purchase-requisitions/from-punchout { session_id, cart_items[] } -> 201 { requisition_id };
emits procurement.catalog_requisition_created event;
idempotent via external_id.

Catalog DRAFT -> ACTIVE -> EXPIRED;
punchout session INITIATED -> ACTIVE -> RETURNED -> COMPLETED;
guard: price changes do not retroactively affect approved POs;
non-preferred items require justification when catalog coverage threshold exceeded.

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

`supplier_catalog` { id: string, supplier_id: string, entity_id: string, status: enum, valid_from: date, valid_to: date }; `catalog_item` { id: string, catalog_id: string, sku: string, description: string, unit_price_minor: int64, currency_code: char(3), lead_time_days: int, moq: int, is_preferred: bool }; `punchout_session` { id: string, supplier_id: string, requester_id: string, cxml_session_id: string, started_at: timestamp, status: enum }; (reference, product may differ).

`GET /v1/catalog-items?q=&category_code=&entity_id=` -> 200 { items[], preferred_first: bool }; `POST /v1/punchout-sessions` { supplier_id, requester_id } -> 201 { redirect_url, session_id }; `POST /v1/purchase-requisitions/from-punchout` { session_id, cart_items[] } -> 201 { requisition_id }; emits `procurement.catalog_requisition_created` event; idempotent via `external_id`.

Catalog `DRAFT -> ACTIVE -> EXPIRED`; punchout session `INITIATED -> ACTIVE -> RETURNED -> COMPLETED`; guard: price changes do not retroactively affect approved POs; non-preferred items require justification when catalog coverage threshold exceeded.