Data model

Understand the records behind requests, approvals, orders and deliveries before connecting or migrating your data.

40 tables · 207 relationships

How the model is organised

Master data

Suppliers with SupplierContacts and SupplierCertifications; Departments, CostCenters, Locations and Users; Categories and Items; MasterAgreements and ContractRates; ApprovalMatrix and ApprovalDelegations. Effective policy and qualification evidence remain traceable to their reviewed version.

Suppliers
SupplierContacts
SupplierCertifications
Departments
CostCenters
Locations
Users
Categories
Items
ContractRates
MasterAgreements
ApprovalMatrix
ApprovalDelegations

Requests and authority

PurchaseRequisitions with RequisitionLines and assigned ApprovalSteps. SpendApprovals and SpendApprovalLines preserve the approved amount and scope separately from a request's later conversion status. CommitmentAllocations prevent several resulting orders from spending the same authority repeatedly.

PurchaseRequisitions with RequisitionLines
assigned ApprovalSteps

Sourcing

RFQs with RFQLines and RFQInvitedSuppliers; RFQResponses with RFQResponseLines; and BidComparisonScores. An award records supplier selection and must not be treated as a new spending approval.

RFQs with RFQLines
RFQInvitedSuppliers; RFQResponses with RFQResponseLines;
BidComparisonScores

Orders and changes

PurchaseOrders and POLineItems; POAmendments and POAmendmentLines; BlanketReleases and BlanketReleaseLines against an agreement. Approval, order revision, cumulative changes and agreement consumption must reconcile before an amendment is applied.

PurchaseOrders
POLineItems; POAmendments
POAmendmentLines; BlanketReleases
BlanketReleaseLines against an agreement

Receiving and exceptions

Receipts and ReceiptLineItems, SupplierReturns, MatchExceptions and Expediting. Accepted quantities satisfy order obligations; rejected arrivals and partial deliveries retain their separate disposition and outstanding work.

Receipts
ReceiptLineItems
SupplierReturns
MatchExceptions
Expediting

Performance

SupplierPerformance retains the reviewed period result. Reject-based quality and on-time delivery answer different questions and are not interchangeable scoring inputs.

SupplierPerformance retains the reviewed period result

Replay and migration

ProcurementEvents identify once-only local effects. IntegrationDeliveries tracks each destination separately. MigrationBatches identifies the reviewed historical baseline and its source records, with normal posting and outbound delivery suppressed during import.

ProcurementEvents identify once-only local effects

Keys and references

Keep immutable identifiers and source-system record IDs alongside document numbers. References connect each receipt or amendment line to the exact order line; approval records retain the revision and scope reviewed. Resolve organizational references to real records before activation rather than relying on typed department or approver names. The baseline model uses USD amounts; additional currency support needs an explicitly designed conversion and approval policy.

An event retains its unique key and payload digest. Replaying the same event cannot repeat a local effect, and a conflicting payload requires investigation. Each destination retains its own acknowledgment and revision so a failed finance delivery can be retried without reposting receipt quantities.

Migration order

Agree the source cutoff, identifier mapping, baseline totals and owners for orders, receipts, inventory and invoice matching. Create a MigrationBatches record and keep imported work inactive until reconciliation passes.
Stage Departments, CostCenters, Locations and Users with preallocated IDs. Resolve department heads, budget owners and user assignments in a second pass, then validate every required reference before activating the masters.
Load Categories and the reviewed ApprovalMatrix, named tier owners and eligible dated ApprovalDelegations. Preserve policy versions needed to explain historical decisions.
Load Suppliers, SupplierContacts and SupplierCertifications with the supporting review evidence; then Items, MasterAgreements and ContractRates in reference order.
Load requests and sourcing records with their lines, invitations, responses and decision history. Establish SpendApprovals only from verifiable legacy authority; unresolved approval evidence returns the affected work for review.
Load open PurchaseOrders, POLineItems, amendments and blanket releases with their approved scope and remaining commitment. Resolve linked records in a second pass where necessary and reconcile CommitmentAllocations to both spending authority and agreement capacity.
Set each open order line's BaselineAcceptedQty from the reconciled cutoff. Import historical receipts, returns and match exceptions as baseline evidence with local effects and outbound messages suppressed. Historical rejected quantities do not satisfy the order; returning already rejected goods must not reduce accepted quantities again.
Reconcile current received quantity to the baseline plus live net accepted effects. Compare open quantities, order values, agreement capacity and in-flight invoice references with the old systems. Assign one owner for inventory movements and do not replay historical receipts into that ledger.
Load reviewed SupplierPerformance history with its period and calculation basis. Confirm that imports have not triggered supplier emails, new approvals or duplicate integrations.
Approve the baseline, activate access and enable live events from the agreed checkpoints. Test recovery of an interrupted event and a failed destination delivery before retiring the previous process.

Tables

Find a table 40 tables

SuppliersThe supplier master: the legal vendor identity that is ordered from and, through accounts payable, paid. Holds EIN, status lifecycle and the GSA contract reference. Vendor risk and financial health live in the vendor management layer; this row is the buy-side identity.master

Field	Type	Required	Details
`SupplierCode`	text	yes	Internal supplier ID
`Name`	text	yes	Legal name
`DBA`	text		Doing-business-as name
`EIN`	text	yes	US Employer Identification Number; masked except Admin / Procurement Manager
`ParentCompany`	reference		→ Suppliers (self) for subsidiaries
`Status`	select	yes	Onboarding, Active, Suspended, Blocked; state controls follow the supplier policy below; transitions require Procurement Manager or Admin review
`PreferredSupplier`	toggle		Surfaces first in catalog search
`GSAContractNumber`	text		For GSA Schedule purchases
`RemitToAddress`	text
`ShipFromAddress`	text
`DefaultPaymentTerms`	select		Net 15, Net 30, Net 45, Net 60, 2/10 Net 30, Prepaid
`DefaultFOBPoint`	select		Origin, Destination
`DefaultFreightTerms`	select		Collect, Prepaid, PrepaidAndAdd, ThirdParty
`W9OnFile`	toggle		Read from the accounts payable vendor record
`OnboardedAt`	date
`Active`	toggle	yes	Directory availability only; cannot override Status eligibility
`StatusChangedBy`	reference		→ Users (Procurement Manager or Admin; required evidence remains independently verified)
`StatusChangedAt`	datetime		Required for a status decision
`StatusReason`	longtext		Required decision evidence; prior transitions retained in ProcurementEvents
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`SourceRevision`	number	yes	Increasing source revision; identical replay is a no-op and conflicting payload for the same revision is rejected

SupplierContactsBuyer-facing contacts at the supplier: sales rep, customer service, accounts receivable, expediter. Line item of Suppliers.line item

Field	Type	Required	Details
`Supplier`	reference	yes	→ Suppliers
`ContactName`	text	yes
`Title`	text
`Email`	text	yes
`Phone`	text
`Role`	select	yes	SalesRep, CustomerService, Expediter, AR, Executive, Other
`Primary`	toggle		Primary contact for RFQ / PO emails
`Active`	toggle	yes

SupplierCertificationsConfigured supplier qualification evidence, reviewed for the relevant activity, location and validity period. The retained category labels include standards, registrations, assessments and diversity qualifications; they are not all certificates and none independently establishes legal compliance. Supplier-submitted evidence remains Pending until the Procurement Manager verifies its stated scope. Line item of Suppliers.line item

Field	Type	Required	Details
`Supplier`	reference	yes	→ Suppliers
`CertType`	select	yes	ISO9001, AS9100, ISO13485, ISO14001, NIST800171, ITAR, SOC2, FDA, OSHA, MBE, WBE, SDVOSB, VOSB, HUBZone, DBE, Other
`CertNumber`	text
`IssuingBody`	text
`IssueDate`	date	yes	Evidence issue or effective date; do not fabricate a registration date
`ExpirationDate`	date	yes	Reviewed expiry or next required review date where evidence has no expiry
`DocumentURL`	text		Supporting evidence or certificate where applicable
`VerifiedBy`	reference		→ Users (Procurement Manager)
`VerifiedAt`	date
`Status`	select	yes	Pending, Active, Expired, Revoked
`EvidenceKind`	select	yes	Certificate, Registration, Assessment, Attestation, Other
`Scope`	longtext	yes	Products, locations, activities and limitations covered
`ReviewNotes`	longtext		Reviewer assessment against configured category requirements; no automatic regulatory qualification

DepartmentsThe organisational units that raise requisitions and own approval rows. The department head is the person the ApprovalMatrix resolves for ApproverRole DepartmentHead.master

Field	Type	Required	Details
`DepartmentCode`	text	yes
`DepartmentName`	text	yes
`DepartmentHead`	reference	yes	→ Users; resolves ApproverRole DepartmentHead
`Active`	toggle	yes
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`SourceRevision`	number	yes	Increasing source revision; identical replay is a no-op and conflicting payload for the same revision is rejected

CostCentersBudget units within a department. The budget owner is the person the ApprovalMatrix resolves for ApproverRole BudgetOwner.master

Field	Type	Required	Details
`CostCenterCode`	text	yes
`CostCenterName`	text	yes
`Department`	reference	yes	→ Departments
`BudgetOwner`	reference	yes	→ Users; resolves ApproverRole BudgetOwner
`Active`	toggle	yes
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`SourceRevision`	number	yes	Increasing source revision; identical replay is a no-op and conflicting payload for the same revision is rejected

LocationsShip-to and receiving places: a dock managed by the warehouse system, an office where desk deliveries land, or a site. The PO ships to one and the receipt is taken at one.master

Field	Type	Required	Details
`LocationCode`	text	yes
`LocationName`	text	yes
`LocationType`	select	yes	Dock, Office, Site
`Address`	text	yes
`Department`	reference		→ Departments; the department that occupies it
`WMSManaged`	toggle		Receipts at this location are written by the warehouse system
`Active`	toggle	yes

UsersInternal user directory for everyone who requests, approves, buys or receives. Department and cost centre default onto a new requisition; ApprovalMatrix.ApproverUser and every Buyer, Approver, Owner and ReceivedBy column point here.master

Field	Type	Required	Details
`UserCode`	text	yes	Employee or login ID
`FullName`	text	yes
`Email`	text	yes
`Department`	reference	yes	→ Departments; defaults onto PurchaseRequisitions.Department
`CostCenter`	reference		→ CostCenters; defaults onto PurchaseRequisitions.CostCenter
`JobTitle`	text
`Manager`	reference		→ Users (self); reporting line, not an approval role
`ApprovalLimit`	currency		USD ceiling for a hand-raised PO with no requisition, RFQ award or blanket release; null or zero disables the explicit Buyer-limit exception; never authorises amendments
`Active`	toggle	yes
`Role`	select	yes	Admin, Procurement Manager, Buyer, Requester, Approver, Receiving Clerk, Supplier, Controller, Viewer; one primary application role per directory row
`BuyerLimitPolicy`	text		Required versioned policy authorising a Buyer-limit exception and its department/category restrictions
`BuyerLimitApprovedBy`	reference		→ Users (Procurement Manager other than this Buyer)
`BuyerLimitEffectiveTo`	date		Required expiry for delegated Buyer-limit authority
`Supplier`	reference		→ Suppliers (required only for Supplier portal identity; cannot be changed by the supplier)
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`SourceRevision`	number	yes	Increasing source revision; identical replay is a no-op and conflicting payload for the same revision is rejected

CategoriesPurchasing taxonomy aligned to UNSPSC (United Nations Standard Products and Services Code). Drives ApprovalMatrix scoping, RFQ eligibility, the contract requirement and the spend hierarchy.master

Field	Type	Required	Details
`CategoryCode`	text	yes	UNSPSC class or internal code
`CategoryName`	text	yes
`ParentCategory`	reference		→ Categories (self)
`UNSPSCSegment`	text		2-digit UNSPSC segment
`RequiresContract`	toggle		Soft control: a PO line in this category with no ContractRate or MasterAgreement is flagged OffContract, held for the Procurement Manager and reported in Maverick Spend
`RequiredCertType`	select		ISO9001, AS9100, ISO13485, ISO14001, NIST800171, ITAR, SOC2, FDA, OSHA; configured evidence category, not a compliance finding; supplier needs Active reviewed evidence covering the line scope at invitation, award and order issuance
`Active`	toggle	yes
`QualificationRequirements`	longtext		Scope and review criteria for required evidence; additional jurisdiction-specific assessment belongs to the configured implementation

ItemsThe purchasable item, part or service catalog. Distinct from the inventory system's SKU master; this is the buy-side view (manufacturer part, supplier part, list price, lead time, MOQ). For stocked items the two reconcile by SKU.master

Field	Type	Required	Details
`ItemCode`	text	yes	Internal item code
`Description`	text	yes
`Category`	reference	yes	→ Categories
`ItemType`	select	yes	Stocked, NonStocked, Service, Capital, Subscription
`UOM`	text	yes	EA, BX, CS, LB, FT, HR, MO
`ManufacturerName`	text
`ManufacturerPartNumber`	text		MPN
`SupplierPartNumber`	text		Supplier's part number
`PrimarySupplier`	reference		→ Suppliers
`BasePrice`	currency		List price for budget estimates
`LeadTimeDays`	number
`MOQ`	number		Minimum order quantity
`HazmatFlag`	toggle
`Active`	toggle	yes

ContractRatesNegotiated prices: a Supplier × Item price valid for a date window, sometimes above a minimum quantity, tied to a master agreement when one exists. The contract-pricing-validation workflow reads this to guardrail buyer-entered prices.master

Field	Type	Required	Details
`Supplier`	reference	yes	→ Suppliers
`Item`	reference	yes	→ Items
`ContractPrice`	currency	yes	USD per UOM; masked from Requester, Viewer and Approver
`MinQty`	number		Minimum quantity for this rate
`EffectiveFrom`	date	yes
`EffectiveTo`	date	yes
`MasterAgreement`	reference		→ MasterAgreements
`Source`	select	yes	Negotiated, GSA, GPO, RFQAward, Catalog
`Status`	select	yes	Draft, Active, Expired, Superseded, Cancelled; Buyer may draft, Procurement Manager approves activation
`Notes`	text
`PreparedBy`	reference	yes	→ Users
`ActivatedBy`	reference		→ Users (Procurement Manager other than PreparedBy)
`ActivatedAt`	datetime		Required before Active
`Revision`	number	yes	Immutable once referenced by a submitted document; corrections create a new rate revision

MasterAgreementsUmbrella contracts with one supplier that authorise a total commitment, with BlanketReleases calling off against it. A GPO or cooperative contract is recorded per supplier with the contracting party named. Tracks renewal so the Procurement Manager renegotiates before lapse.master

Field	Type	Required	Details
`AgreementNumber`	text	yes
`Supplier`	reference	yes	→ Suppliers
`Title`	text	yes
`AgreementType`	select	yes	Direct, GPO, Cooperative, GSA
`ContractingParty`	text		The GPO or cooperative when the agreement was not negotiated directly
`Category`	reference		→ Categories
`Department`	reference		→ Departments; null = releases open to every department
`StartDate`	date	yes
`EndDate`	date	yes
`TermYears`	number
`TotalCommit`	currency	yes	USD authorised maximum, equal to the current Approved SpendApprovals.ApprovedMaximum
`Spent`	formula	yes	fx: SUM(CommitmentAllocations.AmountDelta WHERE MasterAgreement = this agreement AND Status = Posted); signed reservations including amendments and baseline, not initial release totals
`Remaining`	formula	yes	fx: TotalCommit − Spent; nonnegative, checked atomically before committing a release or increase
`RenewalNotice`	select		T-30, T-60, T-90, T-120
`Status`	select	yes	Draft, PendingApproval, Active, Expiring, Renewed, Expired, Terminated; Active requires an approved ceiling and signed evidence
`OwnerBuyer`	reference		→ Users
`ContractURL`	text		Signed PDF
`CostCenter`	reference		→ CostCenters (null means all cost centres within approved department scope)
`SpendApproval`	reference		→ SpendApprovals (current approved agreement ceiling and scope)
`SourceRevision`	number	yes	Changing ceiling, scope, supplier or terms requires a new approval revision
`SignedBy`	reference		→ Users (Procurement Manager)
`SignedAt`	datetime		Required before Active; signing does not replace matrix spend approval
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)

ApprovalMatrixEffective-dated approval rules for Department × CostCenter × Category × full-document USD routing amount × tier. All matching specific and wildcard rows apply; required steps are unioned, not replaced by a narrower match. Routing must cover every distinct line scope and amount, or submission blocks.master

Field	Type	Required	Details
`RuleCode`	text	yes
`Department`	reference		→ Departments; null = all departments
`Category`	reference		→ Categories; null = all categories
`AmountBandFrom`	currency	yes	USD inclusive lower bound; compare full routing amount for each line scope, never category subtotal
`AmountBandTo`	currency	yes	USD inclusive upper bound; overlapping applicable rows add requirements rather than overwrite them
`Tier`	number	yes	1, 2, 3, ... (ascending)
`ApproverRole`	select	yes	DepartmentHead, BudgetOwner, Controller, ProcurementManager, CFO, CEO, Committee
`ApproverUser`	reference		→ Users; empty for DepartmentHead/BudgetOwner, which resolve the named master references; required for Controller, ProcurementManager, CFO, CEO and Committee. CFO/CEO/Committee are business labels resolved to a named active user with application role Approver; Controller and ProcurementManager require their matching application role
`TargetDays`	number		Working days a step may sit Pending before it is marked Escalated
`RequiresRFQ`	toggle		Requisitions in this band must be sourced through an RFQ
`EffectiveFrom`	date	yes
`EffectiveTo`	date
`Active`	toggle	yes
`CostCenter`	reference		→ CostCenters; null = all cost centres
`RuleVersion`	number	yes	Immutable approved rule version used by an approval snapshot
`ApprovedBy`	reference		→ Users (Admin)
`ApprovedAt`	datetime		Required before Active

ApprovalDelegationsEffective-dated, approved delegation of a principal approver to a named eligible delegate. Scope and limit cannot widen the principal authority. Self-approval conflicts, chains, overlapping delegates and expired grants block assignment rather than silently skipping a tier.master

Field	Type	Required	Details
`Delegator`	reference	yes	→ Users
`Delegate`	reference	yes	→ Users
`FromDate`	date	yes
`ToDate`	date	yes
`Reason`	text
`Active`	toggle	yes
`Department`	reference		→ Departments; null means the principal authorised scope
`CostCenter`	reference		→ CostCenters
`Category`	reference		→ Categories
`ApprovalLimit`	currency	yes	Positive USD maximum no greater than the principal authority
`ApprovedBy`	reference		→ Users (Procurement Manager or Admin, not Delegator or Delegate)
`ApprovedAt`	datetime		Required before Active

PurchaseRequisitionsThe requisition header: a department user's request to buy something. Lifecycle Draft → Submitted → Approved (or Rejected → Draft on revision, or Cancelled) → Converted once the Buyer picks a conversion path.transaction

Field	Type	Required	Details
`ReqNumber`	text	yes
`Requester`	reference	yes	→ Users
`Department`	reference	yes	→ Departments
`CostCenter`	reference	yes	→ CostCenters
`BusinessJustification`	text	yes	Why this purchase is needed
`Priority`	select		Routine, Expedited, Emergency
`TotalAmount`	formula	yes	fx: SUM(RequisitionLines.LineTotal)
`Status`	select	yes	Draft, Submitted, Approved, Rejected, Cancelled, Converted; lifecycle does not determine validity of the independent SpendApproval
`SubmittedAt`	date
`ApprovedAt`	date
`ConversionPath`	select		DirectPO, RFQ, BlanketRelease; set by the Buyer on Convert
`ConvertedToPO`	reference		→ PurchaseOrders (convenience link when exactly one direct order exists; all resulting orders link back through PurchaseOrders.FromRequisition)
`ConvertedToRFQ`	reference		→ RFQs (set when sourced by bid)
`ConvertedToRelease`	reference		→ BlanketReleases (set when covered by an agreement)
`RejectionReason`	text
`SourceRevision`	number	yes	Incremented on draft content changes; Submitted content is frozen
`ContentDigest`	text		Canonical submitted header, lines, routing dimensions, dates and terms
`SpendApproval`	reference		→ SpendApprovals (approved source authority survives conversion)
`ConversionEvent`	reference		→ ProcurementEvents (idempotent conversion key)
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)

RequisitionLinesPer-item lines on a requisition: what the Requester wants, when, and against which budget. Line item of PurchaseRequisitions.line item

Field	Type	Required	Details
`Requisition`	reference	yes	→ PurchaseRequisitions
`Item`	reference		→ Items (null for free-text line)
`ItemDescription`	text	yes	Free-text fallback when Item null
`Qty`	number	yes
`UOM`	text	yes
`EstimatedPrice`	currency	yes	Per UOM
`LineTotal`	formula	yes	fx: Qty × EstimatedPrice
`NeedByDate`	date	yes
`GLAccount`	text	yes	Expense GL
`ProjectCode`	text		For project-costed buys
`SuggestedSupplier`	reference		→ Suppliers
`Status`	select	yes	Draft, Submitted, Approved, Rejected, Sourced, Cancelled
`Category`	reference	yes	→ Categories (snapshot from Item or explicitly selected for free-text lines)
`LineNumber`	number	yes	Stable line identity within a requisition

ApprovalStepsOne row per approval tier a requisition, purchase order or amendment passes through. The audit trail: which matrix row, which person, on whose behalf, when, and what they said.transaction

Field	Type	Required	Details
`StepNumber`	text	yes
`DocumentType`	select	yes	Requisition, PurchaseOrder, Amendment, MasterAgreement
`Requisition`	reference		→ PurchaseRequisitions (when DocumentType = Requisition)
`PurchaseOrder`	reference		→ PurchaseOrders (when DocumentType = PurchaseOrder)
`Amendment`	reference		→ POAmendments (when DocumentType = Amendment)
`Tier`	number	yes
`ApprovalRule`	reference	yes	→ ApprovalMatrix
`Approver`	reference	yes	→ Users; named current assignee; must be eligible for this rule and independent of requester/buyer
`ActedOnBehalfOf`	reference		→ Users; principal approver when the actual assignee is an approved delegate
`Status`	select	yes	Pending, Approved, Rejected, Skipped, Cancelled; Skipped is not affirmative authority and cannot satisfy a required tier
`DueAt`	datetime		From ApprovalMatrix.TargetDays
`Escalated`	toggle		Set when Pending past DueAt; the Procurement Manager is notified to reassign
`ActionedAt`	datetime
`Comments`	text
`SpendApproval`	reference	yes	→ SpendApprovals (immutable reviewed source revision)
`MasterAgreement`	reference		→ MasterAgreements (when DocumentType = MasterAgreement)
`Delegation`	reference		→ ApprovalDelegations (grant frozen when assigned)
`ActionedBy`	reference		→ Users (actual decision signer; must equal eligible assignee)
`SourceRevision`	number	yes	Copied from SpendApprovals
`RuleVersion`	number	yes	Copied from ApprovalMatrix
`AssignmentHistory`	longtext		Append-only previous assignees, authorising user, timestamps and reasons for reassignment

RFQsRequest-for-quote header: sourced spend that needs a competitive bid. One RFQ per scope, several suppliers invited, the weights and the award decision recorded on the header.transaction

Field	Type	Required	Details
`RFQNumber`	text	yes
`FromRequisition`	reference		→ PurchaseRequisitions (when sourced from a requisition)
`ScopeDescription`	longtext	yes	Statement of work
`IssuedBy`	reference	yes	→ Users (Buyer)
`IssuedAt`	date
`ResponseDeadline`	date	yes
`PriceWeight`	number	yes	0–100; set before Sent
`LeadTimeWeight`	number	yes	0–100; set before Sent
`QualityWeight`	number	yes	0–100; set before Sent
`AwardedSupplier`	reference		→ Suppliers
`AwardedResponse`	reference		→ RFQResponses
`AwardedPO`	reference		→ PurchaseOrders
`AwardedBy`	reference		→ Users
`AwardedAt`	date
`RecommendationOverridden`	toggle		True when the awarded response is not the Recommended one
`AwardReason`	longtext		Required when Status = AwardedToSupplier or NoAward
`Status`	select	yes	Draft, Sent, ResponseReceived, AwardedToSupplier, NoAward, Cancelled
`Department`	reference	yes	→ Departments
`CostCenter`	reference	yes	→ CostCenters (belongs to Department)
`SourceRevision`	number	yes	Scope and weights frozen at Sent; substantive changes require a new revision and refreshed bids
`ContentDigest`	text		Sent scope, quantities, weights, deadline and commercial terms
`RecommendationReviewedBy`	reference		→ Users (Procurement Manager, required when RecommendationOverridden)
`RecommendationReviewedAt`	datetime		Required before a non-recommended award is final
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`RecommendationReviewedRevision`	number		SourceRevision and awarded response revision recorded in review evidence; a new scope, response or award selection clears the review
`RecommendationReviewEvidence`	attachment		Required when RecommendationOverridden; exact selected response, rationale and source digest reviewed before award

RFQLinesWhat is being sourced, one line per item or service, copied from the requisition lines or keyed by the Buyer. Response lines point at these so bids compare line by line. Line item of RFQs.line item

Field	Type	Required	Details
`RFQ`	reference	yes	→ RFQs
`LineNumber`	number	yes
`Item`	reference		→ Items
`ItemDescription`	text	yes
`Qty`	number	yes
`UOM`	text	yes
`NeedByDate`	date
`FromRequisitionLine`	reference		→ RequisitionLines
`Category`	reference	yes	→ Categories (item category snapshot or explicit free-text category)
`GLAccount`	text		Copied from requisition or selected for standalone sourcing
`ProjectCode`	text		Optional project scope

RFQInvitedSuppliersThe supplier invite list for an RFQ. Line item of RFQs.line item

Field	Type	Required	Details
`RFQ`	reference	yes	→ RFQs
`Supplier`	reference	yes	→ Suppliers
`InvitedAt`	date
`InviteSentVia`	select		Email, Portal
`ResponseStatus`	select	yes	Invited, Acknowledged, Declined, Responded, NoResponse

RFQResponsesA supplier response revision to an RFQ. Only complete comparable Submitted responses enter scoring. Submission freezes header and line content; withdrawal and resubmission before the deadline creates a new revision, retains the previous version, and invalidates its scores and recommendation.transaction

Field	Type	Required	Details
`ResponseNumber`	text	yes
`RFQ`	reference	yes	→ RFQs
`Supplier`	reference	yes	→ Suppliers
`ResponseDate`	date	yes
`TotalQuotedPrice`	formula	yes	fx: SUM(RFQResponseLines.LineTotal); masked from Requester / Viewer
`LeadTimeDays`	number	yes	Quoted overall lead time
`ValidityDays`	number		Quote validity window
`PaymentTerms`	select		Net 15, Net 30, Net 45, Net 60, 2/10 Net 30, Prepaid
`FOBPoint`	select		Origin, Destination
`FreightTerms`	select		Collect, Prepaid, PrepaidAndAdd, ThirdParty
`Notes`	text
`Status`	select	yes	Submitted, UnderReview, Awarded, Rejected, Withdrawn
`SourceRevision`	number	yes	Increasing response revision per supplier and RFQ
`ContentDigest`	text	yes	Frozen submitted header and lines
`SubmittedBy`	reference	yes	→ Users (own Supplier seat, or Buyer recording evidenced supplier response)
`SubmittedAt`	datetime	yes	Must be within the RFQ response window
`ResponseEvidence`	attachment		Required when entered on a supplier behalf
`Supersedes`	reference		→ RFQResponses (prior withdrawn revision)

RFQResponseLinesPer-line quoted detail: what the supplier proposed for each requested line. Line item of RFQResponses.line item

Field	Type	Required	Details
`RFQResponse`	reference	yes	→ RFQResponses
`RFQLine`	reference	yes	→ RFQLines
`Item`	reference		→ Items
`ItemDescription`	text	yes
`Qty`	number	yes
`UOM`	text	yes
`UnitPrice`	currency	yes
`LineTotal`	formula	yes	fx: Qty × UnitPrice
`LeadTimeDays`	number		Per-line lead time when different from header
`AlternateOffered`	toggle		Supplier proposed an alternate part
`AlternateNotes`	text

BidComparisonScoresComputed score per response: normalised price, normalised lead time and the supplier's quality score, weighted by the RFQ's weights. Drives the award recommendation. Line item of RFQs.line item

Field	Type	Required	Details
`RFQ`	reference	yes	→ RFQs
`RFQResponse`	reference	yes	→ RFQResponses
`NormalizedPriceScore`	number	yes	0–100: 100 × lowest eligible total / this total; if lowest is zero, zero-price bids score 100 and positive bids 0; negative totals rejected
`NormalizedLeadTimeScore`	number	yes	0–100: 100 × shortest quoted days / this quoted days; if shortest is zero, same-day bids score 100 and positive days 0; negative days rejected
`QualityScore`	number	yes	0–100 from latest Published scorecard with QualitySampleQty > 0; fallback 50 is explicitly NoHistory, not observed performance
`TotalScore`	formula	yes	fx: (NormalizedPriceScore × PriceWeight + NormalizedLeadTimeScore × LeadTimeWeight + QualityScore × QualityWeight) / 100; frozen weights sum to 100
`Rank`	number		1 = best within RFQ
`Recommended`	toggle		True for the system-recommended award
`ComputedAt`	date	yes
`Scorecard`	reference		→ SupplierPerformance (published source used; null for NoHistory)
`QualityBasis`	select	yes	PublishedHistory, NoHistory
`PriceWeight`	number	yes	Frozen RFQ weight, 0–100
`LeadTimeWeight`	number	yes	Frozen RFQ weight, 0–100
`QualityWeight`	number	yes	Frozen RFQ weight, 0–100; all three sum to 100
`ResponseRevision`	number	yes	Scored response revision
`RFQRevision`	number	yes	Scored frozen RFQ scope and weights
`Eligible`	toggle	yes	False when response withdrawn, superseded, incomplete or not comparable; cannot be recommended

PurchaseOrdersSupplier order with immutable approved revisions. SpendApprovals records its authority separately from lifecycle; an RFQ award is selection evidence only. Prior requisition or agreement authority may be reused only within its approved scope and remaining capacity. Otherwise full matrix approval or the explicitly configured Buyer-limit exception is required before issuance.transaction

Field	Type	Required	Details
`PONumber`	text	yes
`Revision`	number	yes	Starts at 0; increments only on an applied approved amendment; identifies the exact supplier and AP mirror revision
`Supplier`	reference	yes	→ Suppliers
`FromRequisition`	reference		→ PurchaseRequisitions
`FromRFQAward`	reference		→ RFQResponses (when sourced by RFQ)
`MasterAgreement`	reference		→ MasterAgreements (when drawn against an agreement)
`CompetitionType`	select	yes	Competed, SingleBid, SoleSource, Blanket, Catalog
`SoleSourceJustification`	longtext		Required when CompetitionType = SoleSource above the competition threshold
`ClauseSet`	text		Terms and flow-down clause set printed on the order
`OrderDate`	date	yes
`ExpectedDelivery`	date		Header-level promise; per-line in POLineItems
`Status`	select	yes	Draft, PendingApproval, Approved, Sent, Acknowledged, PartiallyReceived, Received, Closed, Cancelled
`TotalAmount`	formula	yes	fx: SUM(POLineItems.LineTotal WHERE Status != Cancelled); includes accepted fulfilled portions
`ShipToLocation`	reference	yes	→ Locations
`BillToEntity`	text	yes	Legal entity to invoice
`FOBPoint`	select	yes	Origin, Destination
`FreightTerms`	select	yes	Collect, Prepaid, PrepaidAndAdd, ThirdParty
`PaymentTerms`	select	yes	Net 15, Net 30, Net 45, Net 60, 2/10 Net 30, Prepaid
`Buyer`	reference	yes	→ Users
`PriceOverrideApproved`	toggle		Set by the Procurement Manager when a line failed the guardrail or is OffContract
`PriceOverrideReason`	longtext		Required when PriceOverrideApproved
`OffContractReason`	longtext		Required when a line is OffContract in a RequiresContract category
`PriceOverrideBy`	reference		→ Users (Procurement Manager)
`ApprovedBy`	reference		→ Users; final human signer, inherited source decision signer, or authorised Buyer under the recorded Buyer-limit exception; never falsely attributes an automated check as a new human decision
`ApprovedAt`	date
`SentAt`	date
`AcknowledgedAt`	date		When the supplier confirms
`AcknowledgedRevision`	number		The Revision the supplier last acknowledged
`ClosedAt`	date
`Notes`	text
`Department`	reference	yes	→ Departments
`CostCenter`	reference	yes	→ CostCenters (belongs to Department)
`Requester`	reference		→ Users (source requester; all source requesters are checked for approval conflicts)
`SourceRevision`	number	yes	Draft approval-content revision; frozen at PendingApproval
`ContentDigest`	text		Frozen approval scope including all lines, supplier, pricing, dates and terms
`SpendApproval`	reference		→ SpendApprovals (decision for the current approved PO revision)
`OriginalApprovedTotal`	currency		Frozen first-approved TotalAmount; never reset by amendments
`CurrentCommitment`	formula	yes	fx: SUM(POLineItems.LineTotal WHERE Status != Cancelled); includes fulfilled amounts
`CumulativeIncrease`	currency	yes	Sum of positive line-level value increases across all applied amendments; decreases on other lines or later reductions never offset it
`PriceOverrideRevision`	number		SourceRevision reviewed by Procurement Manager; stale override blocks approval
`PriceOverrideAt`	datetime		Required with PriceOverrideApproved
`CompetitionThreshold`	currency		Frozen configured competition threshold used for this approval
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`APCompletionEvent`	reference		→ ProcurementEvents (current-revision confirmation that all expected invoices, returns and credits are resolved)
`APCompletionEvidence`	attachment		Required for Closed; entire-order completion from configured AP, not a single matched invoice
`CompletedRevision`	number		Must equal Revision for closure; amendments, returns and corrections invalidate completion

POLineItemsPer-item lines on a PO. The level at which receipts and the invoice match reconcile, and where the contract price check is recorded. Line item of PurchaseOrders.line item

Field	Type	Required	Details
`PO`	reference	yes	→ PurchaseOrders
`LineNumber`	number	yes
`Item`	reference		→ Items
`ItemDescription`	text	yes
`Qty`	number	yes	Current approved quantity; nonnegative and never below net accepted QtyReceived
`UOM`	text	yes
`UnitPrice`	currency	yes
`LineTotal`	formula	yes	fx: Qty × UnitPrice
`ContractRate`	reference		→ ContractRates (matched on create)
`ContractPrice`	currency		Frozen matched ContractRate; masked from Requester, Viewer and Approver
`PriceVariancePct`	formula		fx: (UnitPrice − ContractPrice) / ContractPrice × 100 when ContractPrice > 0; zero rate with positive price requires explicit override, never divide by zero
`PriceOverrideRequired`	toggle		Set when PriceVariancePct exceeds the guardrail
`OffContract`	toggle		Set when the category has RequiresContract and no ContractRate or MasterAgreement backs the line
`NeedByDate`	date	yes
`QtyReceived`	number		Net accepted fulfilment = BaselineAcceptedQty + posted live accepted deliveries − accepted corrections − shipped returns of previously accepted goods; rejected arrivals never fulfil the order
`QtyOpen`	formula		fx: Qty − QtyReceived; cannot be negative; a rejected or returned quantity remains open until replacement or approved cancellation
`GLAccount`	text		From RequisitionLines
`ProjectCode`	text
`Status`	select	yes	Open, PartiallyReceived, Received, Closed, Cancelled
`Category`	reference	yes	→ Categories (frozen item or free-text routing category)
`FromRequisitionLine`	reference		→ RequisitionLines
`FromRFQLine`	reference		→ RFQLines
`OriginalNeedByDate`	date	yes	Frozen first-issued delivery commitment; reschedules do not rewrite delivery-performance history
`BaselineAcceptedQty`	number	yes	Accepted quantity at migration cutoff; 0 for live-native orders
`LastAcceptedAt`	date		Latest active accepted delivery date, used for completed-line reporting
`FulfilledAt`	date		Date net accepted quantity first satisfied the current approved ordered quantity; recomputed from retained events after returns/corrections

POAmendmentsA reviewed change to an issued or approved PO revision. All amendments route on the proposed total and cumulative positive increases, including new scope; decreases cannot reset the escalation basis. Applying the approved change atomically updates lines, commitments and the exact order revision once.transaction

Field	Type	Required	Details
`AmendmentNumber`	text	yes
`PO`	reference	yes	→ PurchaseOrders
`AmendmentType`	select	yes	QtyRevision, PriceRevision, NeedByReschedule, LineAdd, LineRemove, Cancellation
`Reason`	text	yes
`RequestedBy`	reference	yes	→ Users
`RequestedAt`	date	yes
`DeltaAmount`	formula	yes	fx: SUM(POAmendmentLines.NewLineTotal − POAmendmentLines.OldLineTotal)
`ApprovedBy`	reference		→ Users; final approver
`ApprovedAt`	date
`AppliedRevision`	number		The PurchaseOrders.Revision this amendment produced
`Status`	select	yes	Draft, PendingApproval, Approved, Applied, Rejected, Cancelled
`SupplierAcknowledged`	toggle
`BaseRevision`	number	yes	Current PurchaseOrders.Revision when drafted; mismatch on application requires rebase and new approval
`BeforeTotal`	currency	yes	Frozen current PO total at BaseRevision
`ProposedTotal`	formula	yes	fx: BeforeTotal + DeltaAmount
`CumulativeIncreaseAfter`	formula	yes	fx: PO.CumulativeIncrease + SUM(MAX(POAmendmentLines.NewLineTotal − POAmendmentLines.OldLineTotal, 0))
`RoutingAmount`	formula	yes	fx: MAX(ProposedTotal, PO.OriginalApprovedTotal + CumulativeIncreaseAfter)
`SourceRevision`	number	yes	Draft amendment content revision; frozen at PendingApproval
`ContentDigest`	text		Exact proposed complete PO scope, before/after lines and terms
`SpendApproval`	reference		→ SpendApprovals (new complete proposed PO decision, usable only for this PO)
`AppliedEvent`	reference		→ ProcurementEvents (idempotent amendment application)
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`GrossIncrease`	formula	yes	fx: SUM(MAX(POAmendmentLines.NewLineTotal − POAmendmentLines.OldLineTotal, 0)); offsetting decreases never hide an increase or added line

POAmendmentLinesPer-line before and after on an amendment. Line item of POAmendments.line item

Field	Type	Required	Details
`Amendment`	reference	yes	→ POAmendments
`POLine`	reference		→ POLineItems (null for LineAdd type)
`ChangeType`	select	yes	QtyChange, PriceChange, DateChange, AddLine, RemoveLine
`OldQty`	number		Frozen base quantity; 0 for AddLine
`NewQty`	number		Proposed approved quantity; never below current accepted quantity; 0 only for wholly unfulfilled removal
`OldUnitPrice`	currency		Frozen base price; 0 for AddLine
`NewUnitPrice`	currency		Required for added and remaining lines; 0 for full removal
`OldNeedByDate`	date
`NewNeedByDate`	date		Required for every added line; proposed promise for date changes
`OldLineTotal`	formula		fx: OldQty × OldUnitPrice
`NewLineTotal`	formula		fx: NewQty × NewUnitPrice
`Notes`	text
`Item`	reference		→ Items (optional for added free-text lines)
`ItemDescription`	text		Required for AddLine; full proposed line description
`UOM`	text		Required for AddLine and preserved for existing lines
`Category`	reference		→ Categories (required for AddLine; frozen existing category otherwise)
`GLAccount`	text		Proposed expense account, required for added lines
`ProjectCode`	text		Proposed project scope
`ContractRate`	reference		→ ContractRates (proposed matched active rate)
`CreatedPOLine`	reference		→ POLineItems (set once when AddLine is applied)
`LineNumber`	number	yes	Stable amendment line identity

ReceiptsPhysical arrival or service acceptance against a PO. Supplier ASN is untrusted advance evidence until an authorised receiver verifies it. A Posted receipt is immutable; correction is a linked reversal followed, if needed, by a replacement. HistoricalBaseline receipts retain evidence but never repeat quantity or outbound effects.transaction

Field	Type	Required	Details
`ReceiptNumber`	text	yes
`PO`	reference	yes	→ PurchaseOrders
`Supplier`	reference	yes	→ Suppliers
`ReceiptDate`	date	yes
`ReceivedBy`	reference	yes	→ Users
`ReceivingLocation`	reference	yes	→ Locations
`PackingSlipNumber`	text
`BOLNumber`	text		Bill of lading
`CarrierName`	text
`Source`	select	yes	WMS, DockEntry, DeskReceipt, SupplierASN
`Status`	select	yes	Draft, Received, Inspected, Posted, Disputed, Returned; unresolved inspection or Blocked supplier holds Disputed. A replacement is a separate receipt, never a relabelled rejected arrival
`Notes`	text
`EventType`	select	yes	Delivery, Reversal
`ReversesReceipt`	reference		→ Receipts (required for Reversal; exact original accepted quantities, no duplicate return/correction)
`PostedEvent`	reference		→ ProcurementEvents (one local posting event)
`PostedAt`	datetime		Required once posted
`InspectionEvidence`	attachment		Inspection, desk acceptance or quarantine support
`PORevision`	number	yes	Issued order revision inspected against
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`SourceRevision`	number	yes	Increasing source revision; identical replay is a no-op and conflicting payload for the same revision is rejected

ReceiptLineItemsPer-line received quantity against a PO line. The grain accounts payable reads for the three-way match and the scorecard reads for on-time and quality. Line item of Receipts.line item

Field	Type	Required	Details
`Receipt`	reference	yes	→ Receipts
`POLine`	reference	yes	→ POLineItems
`Item`	reference		→ Items
`ItemDescription`	text	yes
`QtyOrdered`	number	yes	Snapshot from POLine at receipt
`QtyReceived`	number	yes	Nonnegative gross physical arrival quantity; on a Reversal, positive magnitude of original arrival being reversed
`QtyAccepted`	number		Nonnegative accepted physical quantity; required before posting; QtyAccepted + QtyRejected = QtyReceived
`QtyRejected`	number		Nonnegative rejected physical quantity; does not satisfy PO quantity
`RejectReason`	select		Damaged, WrongItem, ShortShip, OverShip, QualityFail, Late, Other
`LotNumber`	text
`SerialNumber`	text
`ExcludeFromPerformance`	toggle		Procurement Manager decision with reason; exclusions retained and counted, never silently drop adverse results
`ExclusionReason`	text		Required when ExcludeFromPerformance
`Status`	select	yes	Received, Inspected, Accepted, Rejected, Returned
`PromiseDateSnapshot`	date	yes	OriginalNeedByDate from the PO line at first issue; preserved through reschedule
`UnitPriceSnapshot`	currency	yes	Approved PO unit price at this receipt revision, used for received value
`ExclusionApprovedBy`	reference		→ Users (Procurement Manager)
`ExclusionApprovedAt`	datetime		Required when ExcludeFromPerformance
`ReversesLine`	reference		→ ReceiptLineItems (required on reversal; exact original line)
`QualityDefectQty`	number	yes	Subset of QtyRejected due to quality defects, bounded from 0 to QtyRejected; late arrival alone contributes 0

SupplierReturnsControlled return of rejected arrivals or previously accepted goods, with original line, disposition and quantity evidence. Only shipped returns of previously accepted goods reduce PO accepted fulfilment; returning already rejected goods has no second quantity effect.transaction

Field	Type	Required	Details
`ReturnNumber`	text	yes
`Receipt`	reference	yes	→ Receipts
`ReceiptLine`	reference	yes	→ ReceiptLineItems
`PO`	reference	yes	→ PurchaseOrders
`Supplier`	reference	yes	→ Suppliers
`Item`	reference		→ Items
`QtyReturned`	number	yes	Positive quantity no more than the source line available accepted or rejected balance, after prior returns and corrections
`Reason`	select	yes	Damaged, WrongItem, OverShip, QualityFail, Other
`RMANumber`	text		Supplier's return authorisation
`RaisedBy`	reference	yes	→ Users
`RaisedAt`	date	yes
`ShippedDate`	date
`CreditExpected`	currency		Expected USD credit recorded for AP review; not automatically a credit posting or reduction of PO commitment
`Status`	select	yes	Draft, Authorised, Shipped, CreditExpected, Closed
`ReturnsAcceptedQty`	toggle	yes	True only when returning previously accepted goods; determines accepted fulfilment decrement
`Disposition`	select	yes	Replacement, Credit; Credit still needs an approved PO quantity reduction to remove the replacement obligation
`PostedEvent`	reference		→ ProcurementEvents (once-only shipped return effect)
`AuthorisedBy`	reference		→ Users (Procurement Manager or independent Receiving Clerk)
`AuthorisedAt`	datetime		Required before Shipped
`ReversesReturn`	reference		→ SupplierReturns (correction of a prior shipped return; compensating event, never delete history)
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)
`SourceRevision`	number	yes	Increasing source revision; identical replay is a no-op and conflicting payload for the same revision is rejected

MatchExceptionsA mismatch returned by accounts payable when the supplier's invoice disagrees with the order or the receipt. The Buyer's worklist for resolving it on the procurement side.transaction

Field	Type	Required	Details
`ExceptionNumber`	text	yes
`PO`	reference	yes	→ PurchaseOrders
`POLine`	reference		→ POLineItems
`Receipt`	reference		→ Receipts
`Supplier`	reference	yes	→ Suppliers
`InvoiceReference`	text	yes	Supplier invoice number as held by accounts payable
`ExceptionType`	select	yes	PriceVariance, QtyOverReceipt, NoReceipt, NoPO, Other
`InvoiceAmount`	currency	yes
`OrderAmount`	currency
`ReceivedAmount`	currency
`RaisedAt`	date	yes
`Owner`	reference	yes	→ Users (the PO's Buyer)
`Resolution`	select		Amendment, CorrectingReceipt, ReInvoice, Accepted, Return
`ResolvedAt`	date
`Status`	select	yes	Open, InProgress, Resolved
`InboundEvent`	reference		→ ProcurementEvents (deduplicated AP mismatch or resolution event)
`ResolutionEvidence`	attachment		Required before Resolved; procurement acceptance cannot bypass AP payment authority

BlanketReleasesCall-offs against a MasterAgreements umbrella. Each release draws down the agreement's TotalCommit and generates a PurchaseOrders row priced at the agreement's rates.transaction

Field	Type	Required	Details
`ReleaseNumber`	text	yes
`MasterAgreement`	reference	yes	→ MasterAgreements
`Supplier`	reference	yes	→ Suppliers
`ReleaseDate`	date	yes
`ReleaseValue`	formula	yes	fx: SUM(BlanketReleaseLines.LineTotal); initial release value only, not current agreement consumption
`ScheduleDate`	date	yes	Requested delivery
`GeneratedPO`	reference		→ PurchaseOrders
`RequestedBy`	reference	yes	→ Users
`Status`	select	yes	Draft, Released, Received, Closed, Cancelled
`Notes`	text
`Department`	reference	yes	→ Departments (must be within approved agreement scope)
`CostCenter`	reference	yes	→ CostCenters
`CurrentCommitment`	formula	yes	fx: GeneratedPO.CurrentCommitment when generated, otherwise 0; agreement uses CommitmentAllocations
`SourceRevision`	number	yes	Draft version; immutable after Released
`ReleaseEvent`	reference		→ ProcurementEvents (one generated PO and one initial reservation)
`SpendApproval`	reference		→ SpendApprovals (approved source agreement authority)
`SourceSystem`	text	yes	Origin namespace; local for native records
`SourceRecordID`	text	yes	Stable source identity; unique with SourceSystem
`ImportMode`	select	yes	Live, HistoricalBaseline; baseline records activate only through an approved migration batch
`MigrationBatch`	reference		→ MigrationBatches (required for HistoricalBaseline)

BlanketReleaseLinesThe items called off on a release, each priced at a contract rate under the agreement. A line with no rate under the agreement is refused. Line item of BlanketReleases.line item

Field	Type	Required	Details
`Release`	reference	yes	→ BlanketReleases
`LineNumber`	number	yes
`Item`	reference	yes	→ Items
`Qty`	number	yes
`UOM`	text	yes
`ContractRate`	reference	yes	→ ContractRates; must belong to the release's MasterAgreement
`UnitPrice`	currency	yes	From the ContractRate
`LineTotal`	formula	yes	fx: Qty × UnitPrice
`NeedByDate`	date
`Category`	reference	yes	→ Categories (approved rate item category snapshot)
`GeneratedPOLine`	reference		→ POLineItems (one generated line per release line)
`GLAccount`	text	yes	Expense account
`ProjectCode`	text		Optional project scope

ExpeditingThe expediting worklist: open PO lines that are past NeedByDate or inside the warning window. Written daily by the expediting-reminder workflow.transaction

Field	Type	Required	Details
`ExpediteNumber`	text	yes
`PO`	reference	yes	→ PurchaseOrders
`POLine`	reference		→ POLineItems
`Supplier`	reference	yes	→ Suppliers
`OriginalNeedByDate`	date	yes
`RevisedPromiseDate`	date		Supplier proposal only until approved reschedule; never rewrites the original delivery-performance baseline
`DaysOverdue`	formula		fx: MAX(today − OriginalNeedByDate, 0); original delivery commitment remains visible
`FlaggedAt`	date	yes
`Severity`	select	yes	Warning, Late, Critical
`Owner`	reference	yes	→ Users (Buyer)
`LastContactedAt`	date
`Notes`	text
`Status`	select	yes	Open, InContact, Promised, Resolved, Cancelled
`QtyOutstanding`	number	yes	Current POLine.QtyOpen, refreshed after each accepted receipt, correction, return or amendment
`ResolvedAt`	datetime		Only when QtyOpen = 0; partial delivery leaves the case active
`ClosureReason`	text		Required for Resolved or Cancelled
`Successor`	reference		→ Expediting (replacement case after an approved reschedule of remaining quantity)

SupplierPerformancePeriod scorecard per supplier: on-time delivery, quality, price competitiveness. Computed from receipts and expediting at period end, published by the Procurement Manager, and read by BidComparisonScores and the supplier's portal seat.transaction

Field	Type	Required	Details
`ScorecardNumber`	text	yes
`Supplier`	reference	yes	→ Suppliers
`Period`	text	yes	YYYY-MM or YYYY-Q#
`POCount`	number	yes
`LinesReceived`	number	yes	Count of eligible completed PO lines with FulfilledAt in the period; partial arrivals do not inflate delivery count
`ExcludedLines`	number		ReceiptLineItems with ExcludeFromPerformance set
`OnTimeDeliveryPct`	number	yes	0–100: completed eligible PO lines with FulfilledAt <= OriginalNeedByDate divided by LinesReceived; 50 marked NoHistory when denominator is 0
`QualityScore`	number	yes	0–100: 100 × (1 − QualityRejectedQty / QualitySampleQty); 50 marked NoHistory when QualitySampleQty = 0. Rejected Late reason alone is delivery performance, not a quality defect
`PriceCompetitivenessScore`	number	yes	0–100 from documented comparable contract or RFQ benchmarks; 50 marked NoHistory when no comparable observations
`TotalSpend`	currency	yes	Net accepted USD value in period using ReceiptLineItems.UnitPriceSnapshot, less accepted returns/corrections; gross rejected arrivals excluded
`OverallScore`	formula	yes	fx: (OnTimeDeliveryPct + QualityScore + PriceCompetitivenessScore) / 3; displayed only with Coverage indicating which components use neutral NoHistory values
`ComputedAt`	date	yes
`Status`	select	yes	Draft, Published
`QualitySampleQty`	number	yes	Net eligible physically inspected quantity; corrections net out originals and units must share a reviewed comparable basis
`QualityRejectedQty`	number	yes	Quality-defective quantity in sample, excluding lateness-only rejection and double-counted returns
`Coverage`	text	yes	Observed or NoHistory for delivery, quality and price, with sample sizes and unit-basis limitations
`CalculationEvidence`	attachment	yes	Frozen source IDs, exclusions, quantity basis and comparable price benchmarks
`PublishedBy`	reference		→ Users (Procurement Manager)
`PublishedAt`	datetime		Required for Published; published scorecards immutable, corrections create a new revision

SpendApprovalsVersioned authority request and frozen decision for a complete source revision. Document lifecycle may progress independently. Submitted content and approved decisions cannot be overwritten; invalidation stops future use but does not erase existing commitments. Reused authority and Buyer-limit policy are explicit decision types, never a fabricated new human signature.transaction

Field	Type	Required	Details
`ApprovalNumber`	text	yes	Unique authority request/revision
`DocumentType`	select	yes	Requisition, PurchaseOrder, Amendment, MasterAgreement
`Requisition`	reference		→ PurchaseRequisitions
`PurchaseOrder`	reference		→ PurchaseOrders
`Amendment`	reference		→ POAmendments
`MasterAgreement`	reference		→ MasterAgreements
`SourceRevision`	number	yes	Frozen source revision; exactly one document reference required by DocumentType
`ContentDigest`	text	yes	Canonical header, line scope, pricing, routing dimensions, dates and terms
`DecisionType`	select	yes	Matrix, InheritedAuthority, BuyerLimit, MigrationBaseline
`PriorAuthority`	reference		→ SpendApprovals (approved source reused or superseded)
`RoutingAmount`	currency	yes	USD full-document routing amount; amendment uses its cumulative RoutingAmount
`ApprovedAmount`	currency	yes	USD reviewed source total; 0 while pending
`TolerancePct`	decimal	yes	Explicit reviewer-approved nonnegative tolerance, default 0; no unrecorded extra authority
`ApprovedMaximum`	currency	yes	USD maximum including explicitly approved tolerance; lines reconcile to this cap
`DecisionBy`	reference		→ Users (final actual signer or inherited signer; decision type distinguishes automation)
`DecisionAt`	datetime		Required for final decision
`PolicyVersion`	text	yes	Approval matrix versions or authorised Buyer-limit/migration policy
`RFQRequired`	boolean	yes	True if any applicable rule requires competition; inherited orders retain the condition
`ValidThrough`	date		Latest permitted new commitment date; agreement authority cannot outlive EndDate
`Status`	select	yes	Pending, Approved, Rejected, Invalidated, Superseded
`InvalidationReason`	longtext		Required for Invalidated or Superseded; retained commitments are not deleted
`Evidence`	attachment		Signed agreement, decision packet, or reviewed migration authority evidence

SpendApprovalLinesImmutable scope and approved allowance within a SpendApprovals decision. Separate lines retain routing dimensions and source identities. Parent and line ceilings are both enforced; changing supplier, item, category, quantity, scope or value outside this packet requires a new decision. Line item of SpendApprovals.line item

Field	Type	Required	Details
`SpendApproval`	reference	yes	→ SpendApprovals
`LineNumber`	number	yes	Stable snapshot line number
`Department`	reference		→ Departments (null only for explicitly approved cross-department agreement scope)
`CostCenter`	reference		→ CostCenters (null only for approved agreement scope)
`Category`	reference		→ Categories (null only for explicitly approved agreement-wide scope)
`Supplier`	reference		→ Suppliers (required for PO, amendment and agreement; optional sourcing-neutral requisition)
`Item`	reference		→ Items
`ItemDescription`	text	yes	Frozen item/service specification or explicit agreement scope
`UOM`	text		Required when quantity is bounded
`ApprovedQty`	decimal		Nonnegative quantity cap; null only for amount-based agreement scope
`ApprovedAmount`	currency	yes	USD reviewed line value
`ApprovedMaximum`	currency	yes	USD line cap inclusive of explicitly allocated tolerance; line caps sum to parent cap
`RequisitionLine`	reference		→ RequisitionLines
`POLine`	reference		→ POLineItems
`AmendmentLine`	reference		→ POAmendmentLines
`ConsumedAmount`	currency	yes	Sum of posted AuthorityAmountDelta allocations against this source line
`ConsumedQty`	decimal	yes	Sum of posted AuthorityQtyDelta allocations against this source line
`SpentScopeDigest`	text	yes	Frozen detailed scope including GLAccount, ProjectCode, dates and terms omitted from compact columns

CommitmentAllocationsImmutable signed effects of a business event on a PO line and its funding authority. AmountDelta measures actual order commitment; AuthorityAmountDelta separately measures use or release of the linked approval allowance, preventing a new approval packet from duplicating agreement spend. Reversals are compensating Posted rows referencing the original.transaction

Field	Type	Required	Details
`AllocationNumber`	text	yes	Unique event + PO line + source approval line + allocation leg
`Event`	reference	yes	→ ProcurementEvents
`PurchaseOrder`	reference	yes	→ PurchaseOrders
`POLine`	reference	yes	→ POLineItems
`SpendApprovalLine`	reference	yes	→ SpendApprovalLines
`MasterAgreement`	reference		→ MasterAgreements (required for every agreement-backed actual commitment effect)
`BlanketRelease`	reference		→ BlanketReleases
`Amendment`	reference		→ POAmendments
`AmountDelta`	currency	yes	Signed USD change to actual PO commitment; 0 for pure authority transfer; each order change counted once across its allocation legs
`QtyDelta`	decimal	yes	Signed ordered-quantity change; 0 for pure authority transfer
`AuthorityAmountDelta`	currency	yes	Signed USD consumption of this approval line; initial reservation or increase positive, unused release negative
`AuthorityQtyDelta`	decimal	yes	Signed quantity consumption of this approval line
`ReversesAllocation`	reference		→ CommitmentAllocations (compensating leg; cannot exceed the unreversed original)
`PostedAt`	datetime	yes	Atomic local reservation/application timestamp
`Status`	select	yes	Posted; immutable entries remain Posted when compensated, so sums include both legs

ProcurementEventsDurable once-only business event and migration provenance. The unique source event key and payload digest separate a replay from a conflicting update. Local quantity, approval and commitment effects commit atomically with Applied; outbound delivery has its own retry state.transaction

Field	Type	Required	Details
`EventKey`	text	yes	Unique SourceSystem + SourceRecordID + SourceRevision + EventType
`SourceSystem`	text	yes	Origin namespace
`SourceRecordID`	text	yes	Stable source record identity
`SourceRevision`	number	yes	Frozen source version
`EventType`	text	yes	Stable business type such as Conversion, POApproval, AmendmentApplied, ReceiptPosted, ReturnShipped, ReceiptReversed, SupplierStatusChanged, APMatchResolved or BaselineActivated
`PayloadDigest`	text	yes	Same key/digest returns the prior result; same key/different digest rejects as conflict
`PurchaseOrder`	reference		→ PurchaseOrders
`Receipt`	reference		→ Receipts
`SupplierReturn`	reference		→ SupplierReturns
`MigrationBatch`	reference		→ MigrationBatches
`ImportMode`	select	yes	Live, HistoricalBaseline
`Actor`	reference	yes	→ Users (actual user or configured restricted integration identity)
`OccurredAt`	datetime	yes	Original business occurrence timestamp
`Status`	select	yes	Staged, Applied, Rejected
`AppliedAt`	datetime		Set only after local effects succeed atomically
`ResultReference`	text		Stable resulting record/revision identity for retries
`Evidence`	attachment		Frozen approval, supplier status, migration or correction support

IntegrationDeliveriesPer-event destination outbox for an explicitly configured connection. Retrying transport resends the same revision and idempotency key; it never repeats a local business effect. External acknowledgement and reconciliation are required before claiming delivery.transaction

Field	Type	Required	Details
`Event`	reference	yes	→ ProcurementEvents (Applied event)
`Destination`	select	yes	AccountsPayable, Inventory, Warehouse, Supplier, Budgeting
`DeliveryKey`	text	yes	Unique Event.EventKey + Destination
`PayloadDigest`	text	yes	Frozen outbound payload; correction requires a new event/revision
`Status`	select	yes	Pending, Sending, Acknowledged, Failed, Suppressed
`Attempts`	number	yes	Retry count; no second local posting
`LastAttemptAt`	datetime		Transport time
`AcknowledgedAt`	datetime		Required for Acknowledged
`ExternalReference`	text		Destination receipt/mirror identity and accepted source revision
`LastError`	longtext		Actionable failure or suppression reason
`ReconciledBy`	reference		→ Users (Admin or Controller for controlled reconciliation)

MigrationBatchesReviewed cutover batches for master data, authority, current commitments and accepted-quantity baselines. Import first stages stable IDs, then resolves cyclic references and reconciles totals before activation. Historical records are evidence, not live events.transaction

Field	Type	Required	Details
`BatchNumber`	text	yes	Unique migration batch
`SourceSystem`	text	yes	Origin namespace
`CutoffAt`	datetime	yes	Boundary separating historical baseline from live events
`ImportPolicy`	text	yes	Versioned mapping, source keys, cutover and outbound suppression rules
`PreparedBy`	reference	yes	→ Users (Admin)
`ReviewedBy`	reference		→ Users (Controller or Procurement Manager other than PreparedBy)
`ReviewedAt`	datetime		Required before activation
`SourceRowCount`	number	yes	Expected staged rows
`ReconciledRowCount`	number	yes	Accepted mapped rows; differences explicitly explained in evidence
`ExpectedCommitment`	currency	yes	USD current order commitments at cutoff, including fulfilled retained consumption
`ExpectedAcceptedQty`	decimal	yes	Quantity control total only for a documented common UOM; evidence reconciles each PO line/UOM separately
`ReconciliationEvidence`	attachment	yes	Source IDs, duplicate/conflict checks, authority packets, agreement totals and per-line accepted quantities
`Status`	select	yes	Staged, Validated, Approved, Activated, Rejected
`ActivatedAt`	datetime		Set once by BaselineActivated event; activation and baseline effects are atomic

ERP•AI workspace

Start now Procurement

Create your ERP.AI account and get started with Proto.

Start now Download agent

Previous · reference 2 of 6Reports and dashboards Next · reference 4 of 6Integrations

Procurement

Modules

Procurement

Processes

Procurement

Industries

Procurement

Reference

Procurement

Data model

How the model is organised

Master data

Requests and authority

Sourcing

Orders and changes

Receiving and exceptions

Performance

Replay and migration

Keys and references

Migration order

Tables

Start now Procurement

Procurement

Modules

Procurement

Processes

Procurement

Industries

Procurement

Reference

Data model

How the model is organised

Master data

Requests and authority

Sourcing

Orders and changes

Receiving and exceptions

Performance

Replay and migration

Keys and references

Migration order

Tables

Start now Procurement

Your Privacy, Your Choice

Manage Your Cookie Preferences