RFQ (Request for Quotation) Sourcing Event

The control flow a finance team actually needs.

The ERP surface involved.

RFQ must support multi-line, multi-supplier bidding; supplier portal submission must not require internal credentials; bid submission must be accepted up to the exact deadline timestamp (server-side enforcement); late submissions must be rejected with a timestamped record; buyer must be able to split award across suppliers by line; PO conversion from award must preserve all RFQ line details; all bids must be immutable after deadline; bid data must be encrypted in transit and at rest.

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.

rfq_event { id: string, entity_id: string, deadline: timestamp, status: enum, evaluation_criteria: jsonb, external_id: string };
rfq_line { id: string, rfq_id: string, item_id: string, quantity: int, delivery_location: string };
rfq_bid { id: string, rfq_id: string, supplier_id: string, submitted_at: timestamp, status: enum };
rfq_bid_line { id: string, bid_id: string, rfq_line_id: string, unit_price_minor: int64, currency_code: char(3), lead_time_days: int };
rfq_award { id: string, rfq_id: string, supplier_id: string, rfq_line_id: string, po_id: string };
(reference, product may differ).

POST /v1/rfq-events { lines[], invited_suppliers[], deadline, evaluation_criteria[] } -> 201 { id, status, portal_links[] };
POST /v1/rfq-events/{id}/bids { supplier_id, lines[{rfq_line_id, unit_price_minor, currency_code, lead_time_days}] } -> 201 { bid_id };
POST /v1/rfq-events/{id}/award { awards[{rfq_line_id, supplier_id}] } -> 201 { po_ids[] };
emits procurement.rfq_closed, procurement.rfq_awarded events;
idempotent via external_id.

DRAFT -> OPEN -> CLOSED -> AWARDED;
terminal CANCELLED;
guard: bid submission blocked after deadline;
all bids immutable after CLOSED;
award converts directly to PO in one action.

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.

`rfq_event` { id: string, entity_id: string, deadline: timestamp, status: enum, evaluation_criteria: jsonb, external_id: string }; `rfq_line` { id: string, rfq_id: string, item_id: string, quantity: int, delivery_location: string }; `rfq_bid` { id: string, rfq_id: string, supplier_id: string, submitted_at: timestamp, status: enum }; `rfq_bid_line` { id: string, bid_id: string, rfq_line_id: string, unit_price_minor: int64, currency_code: char(3), lead_time_days: int }; `rfq_award` { id: string, rfq_id: string, supplier_id: string, rfq_line_id: string, po_id: string }; (reference, product may differ).

`POST /v1/rfq-events` { lines[], invited_suppliers[], deadline, evaluation_criteria[] } -> 201 { id, status, portal_links[] }; `POST /v1/rfq-events/{id}/bids` { supplier_id, lines[{rfq_line_id, unit_price_minor, currency_code, lead_time_days}] } -> 201 { bid_id }; `POST /v1/rfq-events/{id}/award` { awards[{rfq_line_id, supplier_id}] } -> 201 { po_ids[] }; emits `procurement.rfq_closed`, `procurement.rfq_awarded` events; idempotent via `external_id`.

`DRAFT -> OPEN -> CLOSED -> AWARDED`; terminal `CANCELLED`; guard: bid submission blocked after deadline; all bids immutable after CLOSED; award converts directly to PO in one action.