Procurement

Why this is a runtime problem, not a CRUD problem

A procurement cycle touches dozens of suppliers, multi-level approval thresholds, contract commitments, lead-time tracking, three-way matching against invoices, and supplier performance feedback loops. The flow is purchase request → RFQ → quote evaluation → PO → approval → ASN → GRN → invoice match → payment → scorecard — and every transition must be permissioned, audited, and survive amount-threshold changes, currency revaluation, and contract amendments that arrive mid-cycle.

A data-app builder turns each step into a screen but leaves the cross-step contract — "this PO above $50k needs CFO sign-off, that ASN must be matched within tolerance, this supplier is on probation" — to humans and ad-hoc scripts. A packaged suite enforces a fixed approval matrix that rarely matches the org's real signing authority. AuraBoot is the third path: the workflow is a BPM process whose tasks resolve back to commands; the commands enforce ABAC rules tied to amount thresholds and org scope, validate against active contracts, and emit audit and event records that finance, inventory, and supplier-portal modules consume.

Data model summary

The Procurement solution ships as cooperating plugins covering supplier master, ordering, receiving, and analytics. The core models are:

• proc_supplier — Supplier master with category, payment terms, rating, certifications, and bank details; states draft → active → on_hold → blocked.
• proc_rfq — Request for quotation issued to one or more suppliers; states draft → issued → quotes_received → awarded → closed.
• proc_quotation — Supplier response to an RFQ with pricing, lead time, and validity.
• proc_po — Purchase order anchoring downstream receipts, invoices, and payments; states draft → pending → approved → receiving → completed/cancelled.
• proc_po_line — Order line with material reference, qty, price, received qty tracker.
• proc_asn — Advance shipping notice from supplier; states expected → in_transit → arrived → reconciled.
• proc_grn — Goods receipt note recorded against an ASN or PO; states draft → inspected → posted.
• proc_three_way_match — PO vs GRN vs supplier invoice reconciliation with variance flags.
• proc_contract — Framework agreement with price lists and amendment history.
• proc_scorecard — Periodic supplier evaluation across quality, delivery, price, and service criteria.

Each model belongs to a plugin (proc-master, proc-ordering, proc-receiving, proc-analytics). Plugins declare their dependencies in plugin.json — adding the receiving plugin without the ordering plugin is rejected by the resolver, because GRN models reference PO line identities.

Key commands

The full solution defines roughly 80 commands. Five representative ones cover the three command shapes:

A button labeled "Approve PO" is wired to proc.po.approve — not to a raw PUT /api/proc_po. The same command is reachable from automation rules ("auto-approve replenishment POs under $5k for preferred suppliers"), from BPM flow steps, and — because it declares riskLevel: write, idempotent: true, agentHint: "Verify amount threshold matches actor authority" — from an AI agent acting on behalf of a procurement officer for routine spend.

Permission example

A realistic procurement role: "Procurement Officer — APAC Indirect Spend".

• RBAC: granted proc.po.create, proc.po.submit, proc.rfq.manage, proc.grn.read; not granted proc.po.approve above the officer threshold (held by managers and directors).
• Org scope: data visibility limited to the APAC org subtree (data scope = org-and-descendants); cannot see EMEA or Americas POs.
• ABAC — approval matrix tied to amount thresholds:
  • PO amount < $5,000 → officer self-approves
  • $5,000 ≤ amount < $50,000 → procurement manager required
  • $50,000 ≤ amount < $250,000 → director required
  • amount ≥ $250,000 → CFO required plus SoD (the submitter cannot be the final approver)
• ReBAC: can act on POs they created, plus those assigned to their buyer code; cannot disposition POs owned by another officer.
• Field-level — supplier-data masking: sees supplier name, address, lead time, and contract price; does not see supplier bank account, tax ID, or negotiated rebate fields (visible only to finance and category managers).

All five layers are evaluated in order. A single declarative role configuration covers what would otherwise be hand-coded branching across UI, controllers, approval engines, and reports.

Process orchestration

The source-to-pay process is a BPMN diagram. Each task is bound to a command:

                    ┌─────────────────┐
                    │ Purchase request│  ←  proc.pr.submit
                    └────────┬────────┘
                             │
                ┌────────────▼────────────┐
                │ RFQ issued to suppliers │  ←  proc.rfq.issue
                └────────────┬────────────┘
                             │
                ┌────────────▼────────────┐
                │ Quote evaluation        │  ←  proc.rfq.award
                └────────────┬────────────┘
                             │
              ┌──────────────▼──────────────┐
              │ Approval matrix (gateway)   │  ←  proc.po.approve
              └──┬───────────────────────┬──┘
                 │ approved              │ rejected
       ┌─────────▼──────────┐    ┌───────▼──────┐
       │ PO released        │    │ Return draft │
       └─────────┬──────────┘    └──────────────┘
                 │
       ┌─────────▼──────────┐
       │ ASN arrived        │  ←  proc.asn.arrive
       └─────────┬──────────┘
                 │
       ┌─────────▼──────────┐
       │ GRN posted + QC    │  ←  proc.grn.post
       └─────────┬──────────┘
                 │
       ┌─────────▼──────────┐
       │ Three-way match    │  ←  proc.match.run
       └─────────┬──────────┘
                 │
       ┌─────────▼──────────┐
       │ Payment + scorecard│  ←  proc.payment.confirm, proc.scorecard.submit
       └────────────────────┘

Contract amendments mid-cycle do not break the flow: the BPM engine carries the contract revision lock at PO approval time, and proc.contract.amend issues a new revision that downstream pricing checks validate against.

Agent integration

Three command classes are intentionally exposed to AI agents in this solution:

1. Read-and-summarize Commands (proc.po.list_overdue, proc.scorecard.weekly_summary, proc.spend.category_rollup) — read-only, idempotent, low risk. Agents can call freely.
2. Drafting Commands (proc.rfq.draft_from_request, proc.po.draft_from_quotation) — write, idempotent, reversible. Agent assembles an RFQ from a purchase request and shortlists historical suppliers; human approves via the existing issue StateTransition.
3. Operational nudges (proc.grn.flag_late_delivery, proc.supplier.flag_for_review) — write, idempotent. Agent notices a delivery trend or quality miss, raises a review task; cannot disposition it.

What is not exposed: proc.po.approve above the officer threshold (ABAC tied to human authority), proc.po.cancel (irreversible + SoD), proc.payment.confirm (financial), proc.contract.terminate (irreversible). These have agentHint: "Human-only" in their definitions; the platform's agent surface excludes them.

How to get it

• Community: build it yourself. The architecture, plugin manifest format, and command pipeline are all open-source; the procurement-specific plugins are not bundled.
• Standard: white-label the base platform; build your own procurement plugins on top.
• Professional: get the procurement solution package — the cooperating plugins, pre-wired menus, roles, approval matrices, and analytics dashboards.
• Enterprise: same package plus dedicated delivery engineering, integration with finance and inventory systems, supplier portal extensions, and SLA-backed support.

See Pricing for the full edition comparison.

Enterprise note — Marketplace publication of vertical plugin packs, License/Entitlement enforcement on the Command pipeline, cross-tenant Agent Control Plane for multi-entity procurement orchestration, and Observability Pro per-stage trace spans are commercial-only capabilities. The open-core runtime described above is the same in every edition.

Next steps

• System overview — how plugins, commands, and the runtime fit together
• Command pipeline — the execution contract used by every command above
• Permissions — the five-layer model used by the Procurement Officer role
• Plugin manifest — how a solution package declares its plugin dependencies
• Agent readiness — designing agentHint and risk fields for safe execution