Fulfilment Policy

What It Models

A fulfilment policy supplies the delivery conditions used when a sale is placed. Administrators can scope it to a product, an ordering profile or the workspace default. Obligations retain a copy so later administration does not silently alter an existing sale.

Identity and Attributes

A policy has a stable record identity, one scope and a version. Financial eligibility can use full payment, a threshold, a deposit, immediate billing or no financial condition. Approval, application readiness, reversal response, bank-debit timing and parent-line behavior qualify that condition.

Relationships

One policy can supply many frozen obligation gates. Selection prefers an active product policy, then an active ordering-profile policy, then the workspace default, before using the built-in fallback.

Invariants

Scope uniqueness and valid stored policies protect selection. Replacements check the version read and refuse locked records. Policy application preserves existing approval and readiness safeguards while changing only eligible pending records.

How It Is Stored and Shared

Fulfillment owns policy storage and resolution. Preparation contributes application requirements, and the register stores the resulting gate. The registration declares no custom-field capability for these records.

Open Design Questions

Large policy applications need a reliable continuation design: repeating the current request can keep inspecting the same first page.