# E-commerce Order Management — for your agent

E-commerce order management for channel intake, stock allocation, split fulfilment, returns and controlled refund handoffs.

## Application

- Catalogue identity: `e-commerce-order-management` (not a workspace app ID).
- Website: [E-commerce Order Management](https://www.erp.ai/e-commerce-order-management/).
- Who uses it: order desks and fulfilment teams who promise dates and keep them
- Application family: Orders.

## Connect and inspect the workspace

1. Read the [ERP.AI platform reference](https://www.erp.ai/skill.md) for current authentication and API documentation.

2. Sign in to [ERP.AI](https://apps.erp.ai) and select the user's intended organization and application. A user can manage their personal API key at [API keys](https://apps.erp.ai/apps?settings=api-keys). Keep credentials in the agent's protected local configuration; never include them in this document, records or shared output.

3. Authenticate documented requests to `https://apps.erp.ai` with `Authorization: Bearer <API_KEY>`. Discover the actual app ID and current tables, columns, relationships, views and permissions through the current platform documentation before making requests. Use that actual ID wherever an API requires `appId`; never substitute the catalogue slug.

4. Match the records and workflow below to the live schema. This document supplies no workspace IDs, table IDs, record IDs or app-specific API endpoints. Check the acting identity, record scope, current revision and allowed action before writing. Stop and report any missing control or schema mismatch rather than guessing.

5. Follow the approval and operating rules below. Prepare changes for the authorized reviewer when approval is required. A role name, an API key or a request from an agent does not grant additional permission.


Current public skill manifest: [skills.json](https://apps.erp.ai/api/skills.json). Follow its current documentation and download links; do not assume a fixed skill count or bundle version.

## Discover accessible applications

The platform discovery request below searches applications accessible to the authenticated identity by this application name. Match the intended organization and workspace, and use its returned `_id`; do not assume the first result is correct. Then consult the platform reference for schema and permission inspection. The key is a local environment variable; no credential is supplied here.

```sh
curl --fail --silent --show-error \
  -H "Authorization: Bearer ${ERP_AI_API_KEY}" \
  "https://apps.erp.ai/v1/app-builder/app?q=E-commerce%20Order%20Management&pageSize=5"
```

## Capabilities

- Available to promise
- Backorders
- Order promising
- RMA
- Partial shipments
- Order approval
- Multi-channel intake
- Split shipments
- Substitutions
- Order status

## Modules

- **Orders**: Multi-channel capture and status
- **Allocation**: Available to promise and priority
- **Fulfilment**: Pick, pack, ship and split
- **Returns**: RMA, inspection and credit
- **Pricing**: Lists, contracts and discounts
- **Reports**: Fill rate, backorders and cycle time

## Workflow and approval points

1. Capture
2. Validate — human approval required.
3. Allocate
4. Ship
5. Close

## Detailed operating process

### 1. Capture channel order

Integration Operator configures authenticated IntakeEvents and stable channel identifiers. Apply each new source order and its lines atomically. A repeat with the same event identity and payload is a no-op; a changed payload with the same identity becomes Conflict. A newer order revision enters Draft; older events cannot overwrite current commercial state.

### 2. Validate commercial snapshot

Order Desk resolves missing SKU mappings, quantity units, currency, address and price/tax evidence. Unknown payment state, configured payment risk or price exceptions keep a HoldReason. Submit the frozen OrderReviews: Status: Draft → PendingReview on Orders. Machine validation may pass an in-policy order directly to Ready only when all configured checks are evidenced.

### 3. Approve order exceptions

Order Manager independently approves or rejects the submitted OrderReviews at the current Orders.Revision. The decision covers the stated reason and values. Any later material change supersedes affected decisions. Only a complete set of approved required reviews clears the associated hold and permits Status: PendingReview → Ready; self-approval and role substitution are denied.

### 4. Reserve available stock

Inventory Planner allocates Ready demand using the latest accepted InventorySnapshots and the configured stock authority. Conditional writes lock or compare the authority version and reserve quantities atomically across affected balances. A repeated CommandKey returns the same Reservations. Stale or conflicting stock requires refresh; no forced negative availability is allowed.

### 5. Resolve uncovered demand

Inventory Planner records Backorders for uncovered quantities and proposes an alternative location or evidence-backed date. Order Desk records customer agreement in PromiseHistory. A substitution requires explicit CustomerConsent and independent Order Manager approval of the exact SubstitutionRequests revision and current order revision before changing lines. Unconfirmed ExpectedDate remains an estimate and does not silently change PromisedDate.

### 6. Release warehouse work

Fulfilment Operator receives Fulfilments funded by current Reservations at the assigned location. Splits preserve order-line identity and the sum of all assigned quantities. Send a stable IntegrationMessages command and retain the external acknowledgement: Status: Released → Accepted. Unknown transport outcome requires reconciliation before another effect is sent.

### 7. Confirm partial dispatch

Fulfilment Operator confirms packed quantities and shipment allocations. Dispatch atomically consumes only those reservations and increments shipped quantities once per stable shipment identity. Remaining demand stays open: Orders move to PartFulfilled or Fulfilled from derived quantities. Each consumed reservation portion creates its own Pending ReservationMovements record and reduces RemainingQuantity atomically. The movement remains withheld from availability until its exact dispatch quantity is reflected in an acknowledged stock snapshot; other partial dispatches keep their independent pending state. Carrier tracking updates delivery milestones separately.

### 8. Review order changes

Order Desk submits ChangeRequests bound to current scope. Order Manager approves a different requester’s request after checking shipped, packed and externally accepted work. Cancellations after warehouse acceptance enter AwaitingWarehouse and retain stock until a confirmed cancellation outcome. A refusal or dispatch race blocks local cancellation. Price, address or promise changes invalidate the affected approval and delivery snapshots before re-release.

### 9. Authorise and inspect return

Order Desk requests ReturnAuthorizations against shipped quantities. Order Manager approves eligibility or a documented exception independently against the frozen ReturnAuthorizations revision and its line quantities; any subsequent scope change invalidates that decision. Returns Inspector records partial ReturnInspections, condition and disposition with a unique receipt key. Restock follows accepted inspection at the recorded ReceivingLocation and a ReturnStockAdjustment IntegrationMessages command. Its inspection, location, signed quantity and immutable key must match the acknowledged authority movement and InventorySnapshots record; quarantine remains unavailable. A correction retains the original message and creates a linked reversal of that exact effect, with any new disposition sent as a separate command. Corrections append records and reverse attributable effects without overwriting evidence.

### 10. Approve refund request

Order Desk prepares RefundRequests linked to capture identity and the line, shipping and tax allocation. Finance Reviewer approves another requester’s frozen revision only within verified captured value less succeeded, sending, unknown and approved refund commitments. Disputes and mismatched currency hold the request. Goods receipt does not itself approve a refund, and approval does not establish payment success.

### 11. Reconcile external outcomes

Integration Operator dispatches an approved immutable refund command under the configured Finance Reviewer authority and original IdempotencyKey. Provider timeout produces Unknown, not failure or a fresh refund key. Finance Reviewer reconciles verified PaymentEvents and the provider object before releasing reserved refund capacity. CreditExport remains a pending accounting handoff until that system acknowledges it; no local record claims a ledger posting.

### 12. Close reconciled order

Order Desk closes an order only after all line quantities are shipped or validly cancelled, open warehouse cancellations and commercial requests are resolved, returns have final disposition and financial handoffs reconcile. Integration Operator runs ReconciliationRuns across channels. Closing does not delete source events, promise history or decisions; later authorised returns reopen the operational case with traceable history.

## Roles and permissions

### Order Desk

Owns customer requests, source corrections and evidence of customer agreement.

- Manage Draft Orders and OrderLines within assigned Channels

- View stock and fulfilment status

- Submit OrderReviews and ChangeRequests

- Apply current approved ChangeRequests only through the controlled transition

- Request ReturnAuthorizations and RefundRequests

- Record PromiseHistory customer responses

- Propose SubstitutionRequests

- Cannot approve own requests or send refunds

### Order Manager

Decides order risk, price exceptions and customer-facing amendments.

- View scoped Orders and OrderReviews

- Approve or reject OrderReviews for another requester at the current revision

- Approve ChangeRequests and ReturnAuthorizations within policy

- Approve consented SubstitutionRequests

- Maintain active PriceRules under change review

- Cannot approve own requests or override stock invariants

- Cannot approve or send RefundRequests

### Inventory Planner

Allocates stock and manages uncovered demand.

- View Products Locations and accepted InventorySnapshots

- Create or release Reservations through the stock authority

- Prepare Draft Fulfilments and FulfilmentLines within current reservations

- Manage Backorders and supply evidence

- Propose PromiseHistory

- View scoped Orders and Fulfilments

- Cannot fabricate stock snapshots or force negative availability

- Cannot approve commercial exceptions

### Fulfilment Operator

Confirms warehouse work and shipment evidence for assigned locations.

- View scoped Fulfilments and FulfilmentLines

- Release eligible Draft Fulfilments within current reserved quantities

- Confirm picking and packing within reserved quantities

- Record Shipments and evidence

- Process warehouse cancellation acknowledgements

- View delivery-address snapshots for assigned work

- Cannot change order prices or payment state

- Cannot ship cancelled or unreserved quantities

### Returns Inspector

Receives returned goods and records their condition.

- View approved ReturnAuthorizations and ReturnLines

- Create ReturnInspections with receipt evidence only at authorised ReceivingLocation

- Propose correction inspections with traceable history

- Confirm restock or quarantine disposition

- Cannot approve return exceptions or refunds

- Cannot mark goods sellable before accepted inspection

### Finance Reviewer

Approves bounded refund instructions and reconciles financial outcomes.

- View Orders PaymentEvents and return evidence

- Approve or reject RefundRequests for another requester at the exact revision

- Review payment and credit reconciliation exceptions

- Authorise configured refund dispatch only after required approval

- Export approved credit handoffs

- Cannot alter verified PaymentEvents or approve own requests

- Cannot treat a pending provider call as settled money

### Integration Operator

Maintains mappings and resolves transport and reconciliation failures.

- Manage test Channels and authorised connector configuration

- View redacted IntakeEvents and IntegrationMessages

- Dispatch only authorised immutable messages and retry them with their original CommandKey

- Run ReconciliationRuns and record external evidence

- Quarantine conflicting source events

- Cannot approve business exceptions or edit captured amounts

- Cannot store credentials in business records

### Admin

Maintains identities, scoped grants and reviewed configuration changes.

- Manage Users and role assignments

- Configure channel and location scope

- Audit records and decision history

- Manage configuration versions and retention policy

- Cannot implicitly approve business decisions

- Cannot erase applied events or amend audit history

- Business actions require an explicitly assigned business role and all independence checks

## Operating constraints

### Invariants and integration boundaries

- **Quantities:** for each OrderLines record, OrderedQuantity equals CancelledQuantity plus ShippedQuantity plus OpenQuantity. All terms are nonnegative. Remaining reservation balances and unshipped, uncancelled warehouse assignments cannot exceed open demand; a shipment cannot exceed packed, reserved quantities. Return commitments cannot exceed previously shipped quantities less other live return commitments. Cancelled requests and rejected returns release only their own capacity.
- **Availability:** eligible stock equals current OnHand less Unavailable, ExternalCommitted, all Reservations.RemainingQuantity and all Pending ReservationMovements quantities. The stock mapping must exclude OMS reservations from ExternalCommitted to avoid double subtraction. Each dispatch creates a uniquely keyed ReservationMovements record per reservation portion; it atomically reduces RemainingQuantity, increases DispatchedQuantity and increments shipped demand. Original reservation Quantity always equals RemainingQuantity plus DispatchedQuantity plus ReleasedQuantity. A confirmed release reduces only RemainingQuantity and increases ReleasedQuantity. A stock acknowledgement changes only the matching movement from Pending to Reflected after its full quantity and stable identity are reflected in authoritative stock. A partial shipment never marks the unshipped reservation balance consumed, and later acknowledgements may arrive in any order. A delayed or incomplete acknowledgement conservatively withholds availability. Unconfirmed inbound supply is excluded. If the authority cannot reserve atomically across all writers, stop automatic promising and surface a review requirement.
- **Concurrency:** enforce uniqueness and quantity checks inside server transactions or the authoritative reservation service. Snapshot reads and hidden buttons are insufficient. Concurrent revisions, competing reservations, duplicate shipments and refunds must either return the same result or reject the stale operation without a partial side effect.
- **Decisions:** bind approvals to record revision, reason, amount, line quantities and identity of the requester. Material changes invalidate affected approval. Different roles on one user do not satisfy independence. Admin cannot bypass these rules through direct API writes.
- **Money:** use one declared currency precision and deterministic rounding policy for each order. Allocate discounts, tax and shipping consistently across partial refunds; the sum cannot exceed the original refundable components. Refund capacity includes approved, sending and unknown attempts until a verified failure or rejection releases it. Charge disputes hold further refund action for review. Prices, taxes and captured amounts remain source snapshots; this app does not calculate legal tax obligations or post a general ledger by itself.
- **Effects:** persist external commands before dispatch. Retry unchanged arguments under the same stable key and account scope. Timeouts require status lookup or reconciliation before retrying with a new identity. Deduplicate provider event IDs and reconcile current provider object state when events arrive out of order; a later delivery timestamp is not proof of a newer business state.
- **Return stock effects:** every restock or correction is an immutable ReturnStockAdjustment message with the originating inspection, receiving location, signed quantity and stable effect identity. Acknowledgement must prove that exact movement is reflected in the linked stock snapshot. Unacknowledged restock never adds local sellable stock. A correction references the original acknowledged message, cannot reverse more than its unreversed quantity and retains an unknown reversal outcome until reconciled. Its separate replacement disposition cannot be treated as completed merely because reversal was requested.
- **Audit and access:** all rows have server-generated stable IDs, tenant scope, revision and created/updated timestamps. Cross-tenant references are rejected. Enforce channel, location, field and action scope on server reads, writes, exports and agent calls. Store payment references only, redact secrets and limit access to delivery addresses. Applied events, decisions and financial receipts are append-only; corrections link to the original. Retention and privacy policies are implementation inputs.
- **Examples and sources:** the Shopify fulfilment-order model and Stripe event/idempotency contracts informed integration acceptance tests; they do not certify an available connector. Other providers require their own verified adapter contract and permissions.

## Records and fields

### Users

People and service identities with explicit location and channel scope.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| Name | text | Yes | Display name |
| Email | text | Yes | Unique identity |
| Role | select | Yes | Order Desk, Order Manager, Inventory Planner, Fulfilment Operator, Returns Inspector, Finance Reviewer, Integration Operator, Admin |
| Scope | longtext | Yes | Allowed channel and location identifiers; deny by default |
| Active | boolean | Yes | Inactive identities cannot act |

### Channels

A storefront, marketplace account or manually entered sales channel.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| ChannelCode | text | Yes | Unique within the workspace |
| Name | text | Yes | Customer-facing channel |
| ExternalAccountID | text | No | Identity at the source; unique with connector type |
| ConnectorType | text | Yes | Configured adapter, or Manual |
| Currency | text | Yes | Default ISO currency; reject unsupported order currencies |
| IntakeMode | select | Yes | Disabled, Test, Active |
| StockAuthority | text | Yes | Named inventory system and reservation protocol |
| StaleAfterMinutes | number | Yes | Configured maximum stock age; no universal default |
| TimeZone | text | Yes | IANA timezone for cutoffs |
| RulesVersion | number | Yes | Increment when mappings or approval policy change |
| SourceMappings | longtext | Yes | Versioned external SKU to Products and units, currency and account mappings; ambiguous mappings block intake |

### Customers

Channel customers associated with orders without storing payment credentials.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| CustomerNumber | text | Yes | Unique internal identity |
| Channel | reference | Yes | → Channels |
| ExternalCustomerID | text | Yes | Unique with Channel; guest identity remains order-specific |
| Name | text | Yes | Customer or organisation name |
| Email | text | No | Contact address |
| ConsentReference | text | No | Applicable communication consent evidence |
| Status | select | Yes | Active, Restricted, Archived |

### Products

Sellable SKU variants and the units accepted at intake.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| SKU | text | Yes | Unique internal SKU; variants remain distinct |
| Name | text | Yes | Product name |
| Unit | text | Yes | Base sales unit |
| QuantityScale | number | Yes | Allowed decimal places; no implicit unit conversion |
| TaxCategory | text | Yes | Code interpreted by the configured tax authority |
| ReturnPolicyCode | text | Yes | Versioned eligibility policy reference |
| Status | select | Yes | Active, Discontinued, Blocked |

### Locations

Stockholding or third-party fulfilment locations.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| LocationCode | text | Yes | Unique warehouse identifier |
| Name | text | Yes | Warehouse or partner name |
| TimeZone | text | Yes | Local cutoff interpretation |
| DispatchCutoff | text | Yes | Configured working calendar and cutoff policy |
| Authority | select | Yes | Local, WarehouseSystem, ThirdParty |
| Status | select | Yes | Active, Suspended, Closed |

### InventorySnapshots

Versioned stock observations; imported balances never constitute a reservation by themselves.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| SnapshotNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Accepted, Superseded, Stale, Rejected |
| ObservedAt | datetime | Yes | Recorded by the server |
| Product | reference | Yes | → Products |
| Location | reference | Yes | → Locations |
| SourceRevision | text | Yes | Monotonic source revision or verified authoritative read token |
| OnHand | decimal | Yes | Physical quantity in the base unit; accepting a newer snapshot supersedes the former current snapshot for this SKU and location |
| Unavailable | decimal | Yes | Damaged, quarantined or otherwise unsellable quantity |
| ExternalCommitted | decimal | Yes | Commitments outside this OMS; must exclude its own tracked reservations |
| AcknowledgedDispatches | longtext | Yes | Stable dispatch identities reflected in this snapshot |
| ReceivedAt | datetime | Yes | Local receipt time |
| ValidationNotes | longtext | No | Rejected mapping, stale revision or quantity discrepancy |
| AcknowledgedStockAdjustments | longtext | No | Stable return disposition or reversal movement identities and exact signed quantities reflected in this snapshot |

### PriceRules

Effective-dated agreed prices or discounts used for an order snapshot.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| RuleCode | text | Yes | Unique rule version |
| Channel | reference | Yes | → Channels |
| Product | reference | Yes | → Products |
| Customer | reference | No | → Customers. Optional customer contract |
| Currency | text | Yes | Currency required for the price |
| UnitPrice | decimal | Yes | Nonnegative price in currency precision |
| DiscountLimit | decimal | Yes | Maximum permitted discount amount per base unit |
| StartDate | date | Yes | First applicable business date |
| EndDate | date | No | Last applicable business date |
| Status | select | Yes | Draft, Active, Retired |
| Priority | number | Yes | Configured precedence; equal-priority overlaps are rejected |

### Orders

An immutable source identity with a revisioned commercial and delivery snapshot.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| OrderNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Draft, PendingReview, Ready, PartFulfilled, Fulfilled, Cancelled, Closed |
| CreatedAt | datetime | Yes | Recorded by the server |
| Channel | reference | Yes | → Channels |
| ExternalOrderID | text | Yes | Unique with Channel; manual orders use a generated stable key |
| Customer | reference | Yes | → Customers |
| Owner | reference | Yes | → Users. Order Desk owner |
| SourceRevision | text | Yes | Upstream order version; timestamps alone are insufficient |
| Revision | number | Yes | Increment for changes to quantities, prices, address or promise |
| AddressSnapshot | longtext | Yes | Frozen delivery address and contact details for this revision |
| Currency | text | Yes | Single ISO currency for the order |
| MerchandiseAmount | decimal | Yes | Sum of accepted line net amounts |
| ShippingAmount | decimal | Yes | Source shipping charge |
| TaxAmount | decimal | Yes | Source tax amount with tax calculation reference |
| TotalAmount | decimal | Yes | Merchandise plus shipping plus tax; explicit rounding rule |
| TaxReference | text | Yes | Authority and calculation version |
| PaymentState | select | Yes | Unknown, Authorised, Captured, PartRefunded, Refunded, Disputed |
| HoldReason | longtext | No | Blocks release while nonempty |
| RequestedDate | date | No | Customer requested delivery date |
| PromisedDate | date | No | Current agreed delivery date, not an unconfirmed ETA |

### OrderLines

Accepted demand and price snapshots for each source line.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| Order | reference | Yes | → Orders |
| ExternalLineID | text | Yes | Unique within Order |
| Product | reference | Yes | → Products |
| OrderedQuantity | decimal | Yes | Positive base-unit quantity |
| CancelledQuantity | decimal | Yes | Derived from effective cancellation decisions |
| ShippedQuantity | decimal | Yes | Derived from confirmed shipment allocations |
| OpenQuantity | decimal | Yes | Ordered minus Cancelled minus Shipped; never negative |
| UnitPrice | decimal | Yes | Frozen price |
| DiscountAmount | decimal | Yes | Frozen line discount |
| TaxAmount | decimal | Yes | Frozen line tax |
| NetAmount | decimal | Yes | Rounded merchandise amount after discount |
| PriceRule | reference | No | → PriceRules. Rule applied when priced |
| PriceEvidence | text | Yes | Source price or override decision reference |
| Status | select | Yes | Open, PartShipped, Shipped, Cancelled |

### IntakeEvents

Authenticated source deliveries with durable duplicate detection and recoverable processing.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| IntakeNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Received, Applied, Duplicate, Conflict, Rejected |
| ReceivedAt | datetime | Yes | Recorded by the server |
| Channel | reference | Yes | → Channels |
| ExternalEventID | text | Yes | Unique with Channel |
| ExternalOrderID | text | Yes | Source order identity |
| PayloadHash | text | Yes | Canonical payload digest; same event ID with changed content is a conflict |
| SourceRevision | text | Yes | Order revision when supplied |
| Order | reference | No | → Orders. Resolved canonical order |
| FailureReason | longtext | No | Validation, mapping or signature failure |
| AppliedAt | datetime | No | Set atomically with canonical changes |

### OrderReviews

Independent decisions against a frozen order revision and reason.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| ReviewNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Submitted, Approved, Rejected, Superseded |
| CreatedAt | datetime | Yes | Recorded by the server |
| Order | reference | Yes | → Orders |
| OrderRevision | number | Yes | Exact revision requiring approval |
| Reason | select | Yes | PaymentRisk, PriceOverride, AddressChange, PolicyException |
| RequestedBy | reference | Yes | → Users |
| AssignedReviewer | reference | Yes | → Users |
| DecidedBy | reference | No | → Users. Must differ from RequestedBy |
| DecisionAt | datetime | No | Server time |
| Evidence | longtext | Yes | Reason, checks and decision; immutable after decision |

### Reservations

Exclusive quantities held for an order line at a location.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| ReservationNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Active, PartConsumed, Consumed, Released, Expired |
| CreatedAt | datetime | Yes | Recorded by the server |
| OrderLine | reference | Yes | → OrderLines |
| Location | reference | Yes | → Locations |
| Quantity | decimal | Yes | Original reserved quantity; equals RemainingQuantity plus DispatchedQuantity plus ReleasedQuantity |
| RemainingQuantity | decimal | Yes | Unconsumed exclusive balance; derived atomically and never negative |
| DispatchedQuantity | decimal | Yes | Cumulative quantity consumed by unique ReservationMovements |
| ReleasedQuantity | decimal | Yes | Cumulative unused quantity released after authority confirmation |
| CommandKey | text | Yes | Unique allocation command identity |
| Snapshot | reference | Yes | → InventorySnapshots. Stock version used for conditional reservation |
| AuthorityToken | text | Yes | Reservation receipt from the stock authority, or local transaction ID |
| ExpiresAt | datetime | No | Lease expiry before fulfilment release |

### Backorders

Unallocated demand with an accountable owner and explicit supply uncertainty.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| BackorderNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Open, Offered, Resolved, Cancelled |
| CreatedAt | datetime | Yes | Recorded by the server |
| OrderLine | reference | Yes | → OrderLines |
| Quantity | decimal | Yes | Current uncovered quantity; derived without duplicating reservations |
| Owner | reference | Yes | → Users. Inventory Planner |
| SupplyEvidence | longtext | Yes | Supplier or warehouse evidence; predictions labelled unconfirmed |
| ExpectedDate | date | No | Unconfirmed replenishment estimate |
| ReviewDate | date | Yes | Next action date |
| Resolution | select | Yes | AwaitingSupply, AlternativeLocation, Substitution, CustomerCancellation |

### Fulfilments

A warehouse work request for one order and location; acceptance and cancellation remain separate outcomes.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| FulfilmentNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Draft, Released, Accepted, Picking, Packed, Dispatched, CancelRequested, Cancelled |
| CreatedAt | datetime | Yes | Recorded by the server |
| Order | reference | Yes | → Orders |
| Location | reference | Yes | → Locations |
| Owner | reference | Yes | → Users. Assigned Fulfilment Operator |
| ExternalRequestID | text | No | Stable warehouse work identity |
| PlannedStart | datetime | Yes | Start of planned warehouse slot |
| PlannedEnd | datetime | Yes | End of planned warehouse slot |
| AcknowledgedAt | datetime | No | Warehouse accepted request time |
| CancellationReason | longtext | No | Requested reason; does not establish cancellation |

### FulfilmentLines

The quantity of each reservation handed to a warehouse work request.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| Fulfilment | reference | Yes | → Fulfilments |
| OrderLine | reference | Yes | → OrderLines |
| Reservation | reference | Yes | → Reservations |
| Quantity | decimal | Yes | Positive; summed unshipped and uncancelled assignments cannot exceed reservation RemainingQuantity |
| PackedQuantity | decimal | Yes | Confirmed packed quantity |
| ShippedQuantity | decimal | Yes | Confirmed shipped quantity; cannot exceed packed quantity |
| Status | select | Yes | Assigned, Picked, Packed, Shipped, Cancelled |

### Shipments

A package or dispatch confirmation, with its allocated line quantities retained.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| ShipmentNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Prepared, Dispatched, InTransit, Delivered, Exception, Voided |
| CreatedAt | datetime | Yes | Recorded by the server |
| Fulfilment | reference | Yes | → Fulfilments |
| ExternalShipmentID | text | Yes | Unique with the fulfilment provider |
| LineQuantities | longtext | Yes | Immutable validated mapping of FulfilmentLines IDs to shipped quantities |
| Carrier | text | No | Configured delivery provider |
| TrackingNumber | text | No | Carrier tracking identity |
| DispatchedAt | datetime | No | Confirmed handoff time |
| DeliveredAt | datetime | No | Provider-confirmed delivery time |
| Evidence | attachment | No | Dispatch or delivery receipt |
| CostAmount | decimal | No | Actual configured carrier charge, never inferred as zero |
| CostCurrency | text | No | Currency of the recorded charge |

### ShipmentEvents

Append-only tracking observations without using arrival order as business order.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| TrackingEventNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Received, Applied, Duplicate, Rejected |
| ReceivedAt | datetime | Yes | Recorded by the server |
| Shipment | reference | Yes | → Shipments |
| ExternalEventID | text | Yes | Unique with provider |
| Milestone | select | Yes | Prepared, Collected, InTransit, Delivered, DeliveryException, Returned |
| OccurredAt | datetime | Yes | Provider observation time |
| SourceRevision | text | Yes | Source version or reconciliation reference |
| Evidence | longtext | Yes | Raw status reference and normalised result |

### ReturnAuthorizations

Permission to receive specific previously shipped goods.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| RMANumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Requested, Approved, Rejected, Receiving, Inspected, Closed |
| CreatedAt | datetime | Yes | Recorded by the server |
| Order | reference | Yes | → Orders |
| RequestedBy | reference | Yes | → Users |
| ApprovedBy | reference | No | → Users. Order Manager independent from requester |
| Reason | select | Yes | Damaged, IncorrectItem, Unwanted, DeliveryFailure, Other |
| PolicyVersion | text | Yes | Eligibility and return-window version |
| Evidence | longtext | Yes | Customer request and exception decision |
| ExpectedDate | date | No | Expected receipt date |
| Revision | number | Yes | Increment for any proposed scope or evidence change |
| ApprovedRevision | number | No | Must equal Revision before action; changes supersede approval |
| DecisionAt | datetime | No | Server decision time |

### ReturnLines

Authorised return quantities against original shipped order lines.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| ReturnAuthorization | reference | Yes | → ReturnAuthorizations |
| OrderLine | reference | Yes | → OrderLines |
| AuthorisedQuantity | decimal | Yes | Cannot exceed shipped less other nonrejected return commitments |
| ReceivedQuantity | decimal | Yes | Cumulative evidenced receipt |
| AcceptedQuantity | decimal | Yes | Quantity accepted after inspection |
| Disposition | select | Yes | AwaitingInspection, Restock, Quarantine, Repair, Scrap, ReturnToCustomer |
| Status | select | Yes | Expected, PartReceived, Received, Inspected, Closed |

### ReturnInspections

An inspection receipt for a return line; disposition does not itself issue a refund.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| InspectionNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Draft, Confirmed, Corrected |
| InspectedAt | datetime | Yes | Recorded by the server |
| ReturnLine | reference | Yes | → ReturnLines |
| ReceivingLocation | reference | Yes | → Locations. Actual receiving location; server-scoped to the inspector |
| Inspector | reference | Yes | → Users |
| ReceiptKey | text | Yes | Unique receipt-and-inspection command identity |
| Quantity | decimal | Yes | Positive inspected receipt quantity |
| Condition | select | Yes | Resellable, Damaged, Incomplete, WrongItem |
| Disposition | select | Yes | Restock, Quarantine, Repair, Scrap, ReturnToCustomer |
| Evidence | attachment | No | Inspection evidence |
| Corrects | reference | No | → ReturnInspections. Correction points to prior inspection without overwriting it |

### RefundRequests

A revision-bound request for payment-provider action; money moves only on provider confirmation.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| RefundNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Draft, Submitted, Approved, Sending, Unknown, Succeeded, Failed, Rejected, Superseded |
| CreatedAt | datetime | Yes | Recorded by the server |
| Order | reference | Yes | → Orders |
| ReturnAuthorization | reference | No | → ReturnAuthorizations. Optional when refund relates to cancellation or goodwill |
| Revision | number | Yes | Refund scope version |
| OrderRevision | number | Yes | Order scope being refunded |
| Amount | decimal | Yes | Positive refund in order currency; bounded by refundable captured amount |
| Currency | text | Yes | Must match the capture currency |
| Allocation | longtext | Yes | Line, tax and shipping portions with rounding reconciliation |
| CaptureReference | text | Yes | Provider capture identity, required before submission |
| RequestedBy | reference | Yes | → Users |
| ApprovedBy | reference | No | → Users. Finance Reviewer independent of RequestedBy |
| ApprovedRevision | number | No | Must equal Revision before sending |
| DecisionEvidence | longtext | Yes | Reason and approval or rejection evidence |
| IdempotencyKey | text | Yes | Stable provider key for this immutable attempt |
| ProviderRefundID | text | No | Confirmed external identity |
| ResultAt | datetime | No | Verified terminal provider result time |
| DecisionAt | datetime | No | Server approval or rejection time |

### PaymentEvents

Verified payment-provider observations; authorisation is never counted as captured cash.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| PaymentEventNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Verified, Duplicate, Rejected |
| ReceivedAt | datetime | Yes | Recorded by the server |
| Order | reference | Yes | → Orders |
| ProviderEventID | text | Yes | Unique with provider account |
| ProviderObjectID | text | Yes | Capture, refund or dispute identity |
| EventType | select | Yes | Authorised, Captured, Refunded, Voided, Failed, Disputed |
| Amount | decimal | Yes | Amount in provider currency |
| Currency | text | Yes | Must match mapped order/capture |
| OccurredAt | datetime | Yes | Provider event time, not an ordering guarantee |
| Evidence | longtext | Yes | Verified object state and source version |

### IntegrationMessages

Durable outbox and inbound acknowledgements for each external effect.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| MessageNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Pending, Sending, Acknowledged, Retryable, Unknown, Failed |
| CreatedAt | datetime | Yes | Recorded by the server |
| Channel | reference | Yes | → Channels |
| Order | reference | No | → Orders. When this message concerns an order |
| Purpose | select | Yes | OrderImport, StockRead, ReserveStock, ReleaseStock, FulfilmentRequest, CancelFulfilment, ShipmentUpdate, Refund, CreditExport, ReturnStockAdjustment |
| CommandKey | text | Yes | Unique immutable effect identity |
| PayloadHash | text | Yes | Binds retries to unchanged arguments |
| ExternalReference | text | No | Provider request or receipt identity |
| AttemptCount | number | Yes | Increment on each transport attempt |
| NextAttemptAt | datetime | No | Backoff schedule |
| LastError | longtext | No | Redacted result without secrets |
| Inspection | reference | No | → ReturnInspections. Required for ReturnStockAdjustment |
| Location | reference | No | → Locations. Required receiving location for ReturnStockAdjustment |
| QuantityDelta | decimal | No | Signed base-unit stock change for ReturnStockAdjustment; positive only after accepted Restock inspection |
| ReversesMessage | reference | No | → IntegrationMessages. For a correction, identifies the exact prior acknowledged stock adjustment being reversed |
| AcknowledgedSnapshot | reference | No | → InventorySnapshots. For ReturnStockAdjustment, proves matching movement identity, location and signed quantity are reflected |

### ChangeRequests

Proposed cancellations or post-approval commercial changes.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| ChangeNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Submitted, Approved, AwaitingWarehouse, Applied, Rejected, Superseded |
| CreatedAt | datetime | Yes | Recorded by the server |
| Order | reference | Yes | → Orders |
| OrderLine | reference | No | → OrderLines. Required for a line quantity cancellation |
| OrderRevision | number | Yes | Revision reviewed |
| ChangeType | select | Yes | CancelQuantity, ChangeAddress, ChangePrice, ChangePromise |
| ProposedChange | longtext | Yes | Frozen before/after values and business reason |
| RequestedBy | reference | Yes | → Users |
| ApprovedBy | reference | No | → Users. Independent Order Manager |
| Quantity | decimal | No | Positive cancellation quantity where applicable |
| ExternalOutcome | text | No | Warehouse cancellation receipt or reason for refusal |
| Revision | number | Yes | Increment for any proposed scope or evidence change |
| ApprovedRevision | number | No | Must equal Revision before action; changes supersede approval |
| DecisionAt | datetime | No | Server decision time |

### PromiseHistory

Immutable customer-promise revisions and the evidence supporting each change.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| PromiseNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Proposed, Accepted, Rejected, Superseded |
| CreatedAt | datetime | Yes | Recorded by the server |
| Order | reference | Yes | → Orders |
| OrderRevision | number | Yes | Revision of the promise decision |
| PreviousDate | date | No | Prior commitment |
| ProposedDate | date | Yes | New date offered |
| OriginalPromisedDate | date | No | First accepted commitment; immutable for performance reports |
| SupplyEvidence | longtext | Yes | Reservation, warehouse calendar and delivery assumption |
| CustomerResponse | longtext | No | Recorded agreement or rejection |
| Owner | reference | Yes | → Users. Order Desk owner |
| AcceptedAt | datetime | No | Customer agreement evidence time |

### SubstitutionRequests

A proposed alternative SKU with explicit customer consent and commercial review.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| SubstitutionNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Proposed, PendingReview, Approved, Rejected, Applied |
| CreatedAt | datetime | Yes | Recorded by the server |
| OrderLine | reference | Yes | → OrderLines |
| AlternativeProduct | reference | Yes | → Products |
| Quantity | decimal | Yes | Base quantity with documented unit conversion if necessary |
| OrderRevision | number | Yes | Revision to which the proposal applies |
| PriceDifference | decimal | Yes | Signed difference in order currency |
| CustomerConsent | longtext | Yes | Required evidence for the actual replacement |
| RequestedBy | reference | Yes | → Users |
| ApprovedBy | reference | No | → Users. Independent Order Manager |
| ReplacementLineID | text | No | New order line identity after controlled amendment |
| Revision | number | Yes | Increment for any proposed scope or evidence change |
| ApprovedRevision | number | No | Must equal Revision before action; changes supersede approval |
| DecisionAt | datetime | No | Server decision time |

### ReconciliationRuns

Recorded comparisons of source orders, stock, warehouse outcomes and payment objects.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| ReconciliationNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Queued, Running, Exception, Resolved |
| StartedAt | datetime | Yes | Recorded by the server |
| Channel | reference | Yes | → Channels |
| Scope | select | Yes | Orders, Stock, Shipments, Payments, Credits |
| WindowStart | datetime | Yes | Source interval being compared |
| WindowEnd | datetime | Yes | End of source interval |
| SourceCursor | text | Yes | Stable provider export or API cursor |
| MismatchCount | number | Yes | Unresolved differences |
| Evidence | attachment | No | Redacted comparison and resolution receipt |
| Owner | reference | Yes | → Users. Assigned Integration Operator |
| EndedAt | datetime | No | Completion time |

### ReservationMovements

One independently acknowledged stock debit for each reservation consumed by a dispatch.

| Field | Type | Required | Definition |
| --- | --- | --- | --- |
| MovementNumber | text | Yes | Unique, immutable business number |
| Status | select | Yes | Pending, Reflected |
| CreatedAt | datetime | Yes | Recorded by the server |
| Reservation | reference | Yes | → Reservations |
| Shipment | reference | Yes | → Shipments |
| Quantity | decimal | Yes | Positive dispatched quantity in the base unit; never exceeds reservation RemainingQuantity before consumption |
| CommandKey | text | Yes | Unique with reservation and shipment; unchanged retries return this movement |
| DispatchIdentity | text | Yes | Stable identity sent to the stock authority for this exact quantity |
| AcknowledgedSnapshot | reference | No | → InventorySnapshots. Only a snapshot proving this exact movement is reflected |
| ReflectedAt | datetime | No | Set once after verified authority acknowledgement |

## Relationships

- ReturnInspections → IntegrationMessages (one-to-many): Link restock and correction effects to their receiving location and authority acknowledgement.
- Reservations → ReservationMovements (one-to-many): Track each consumed partial quantity and its stock acknowledgement independently.
- Shipments → ReservationMovements (one-to-many): Retain stable stock debits for each dispatched reservation portion.
- Channels → Orders (one-to-many): Preserve channel and external-order uniqueness.
- Orders → OrderLines (one-to-many): Retain line identities and quantities through amendments.
- Orders → OrderReviews (one-to-many): Keep independent decisions bound to the reviewed revision.
- Products → InventorySnapshots (one-to-many): Identify exact SKU and base-unit stock.
- Locations → Reservations (one-to-many): Prevent allocation across the wrong warehouse.
- OrderLines → Reservations (one-to-many): Split held quantities without exceeding open demand.
- OrderLines → Backorders (one-to-many): Expose the uncovered balance.
- Orders → Fulfilments (one-to-many): Separate warehouse work for each location.
- Fulfilments → FulfilmentLines (one-to-many): Retain the reservation funding each work quantity.
- Fulfilments → Shipments (one-to-many): Allow partial dispatches without closing remaining work.
- Shipments → ShipmentEvents (one-to-many): Reconcile tracking observations independently of receipt order.
- Orders → ReturnAuthorizations (one-to-many): Anchor return eligibility in the original order.
- ReturnAuthorizations → ReturnLines (one-to-many): Constrain return commitments to shipped quantities.
- ReturnLines → ReturnInspections (one-to-many): Record partial receipts and correction history.
- Orders → RefundRequests (one-to-many): Keep payment requests separate from physical returns.
- Orders → PaymentEvents (one-to-many): Reconcile verified capture and refund objects.
- Orders → ChangeRequests (one-to-many): Require approval for revisioned commercial changes.
- Orders → PromiseHistory (one-to-many): Preserve original and revised customer commitments.
- OrderLines → SubstitutionRequests (one-to-many): Link the old item and proposed replacement.
- Channels → ReconciliationRuns (one-to-many): Compare each source under its own identity and rules.
- Orders → IntegrationMessages (one-to-many): Track every external effect and acknowledgement.

## Views

### Open Orders

Source: Orders

Filter: Status IN ('PendingReview', 'Ready', 'PartFulfilled')

Roles: Order Desk, Order Manager, Inventory Planner

Columns: OrderNumber, Channel, Customer, Status, PromisedDate, HoldReason

### My Customer Follow-ups

Source: Orders

Filter: Owner = current user

Roles: Order Desk

Columns: OrderNumber, Customer, Status, RequestedDate, PromisedDate, Owner

### Order Approval Inbox

Source: OrderReviews

Filter: Status = 'Submitted'

Roles: Order Manager

Columns: ReviewNumber, Order, OrderRevision, Reason, RequestedBy, AssignedReviewer, Status, CreatedAt

### Intake Exceptions

Source: IntakeEvents

Filter: Status IN ('Conflict', 'Rejected')

Roles: Integration Operator, Order Desk

Columns: IntakeNumber, Channel, ExternalOrderID, Status, FailureReason, ReceivedAt

### Current Stock

Source: InventorySnapshots

Filter: Status = 'Accepted'

Roles: Inventory Planner

Columns: SnapshotNumber, Product, Location, OnHand, Unavailable, ExternalCommitted, ObservedAt

### Allocation Queue

Source: Backorders

Filter: Status IN ('Open', 'Offered')

Roles: Inventory Planner, Order Desk

Columns: BackorderNumber, OrderLine, Quantity, Resolution, ReviewDate, Owner

### Warehouse Schedule

Source: Fulfilments

Filter: Status IN ('Released', 'Accepted', 'Picking', 'Packed')

Roles: Fulfilment Operator, Inventory Planner

Columns: FulfilmentNumber, Location, Owner, PlannedStart, PlannedEnd, Status

### Fulfilment Board

Source: Fulfilments

Filter: Status IN ('Released', 'Accepted', 'Picking', 'Packed', 'CancelRequested')

Roles: Fulfilment Operator

Columns: FulfilmentNumber, Order, Location, Status, Owner

### Shipment Tracking

Source: Shipments

Filter: Status IN ('Dispatched', 'InTransit', 'Delivered', 'Exception')

Roles: Fulfilment Operator, Order Desk

Columns: ShipmentNumber, Fulfilment, Carrier, TrackingNumber, DispatchedAt, Status

### Return Receiving

Source: ReturnAuthorizations

Filter: Status IN ('Approved', 'Receiving')

Roles: Returns Inspector, Order Desk

Columns: RMANumber, Order, Reason, ExpectedDate, Status

### Return Inspection Queue

Source: ReturnLines

Filter: Status IN ('PartReceived', 'Received')

Roles: Returns Inspector

Columns: ReturnAuthorization, OrderLine, ReceivedQuantity, AcceptedQuantity, Disposition, Status

### Refund Approval Inbox

Source: RefundRequests

Filter: Status = 'Submitted'

Roles: Finance Reviewer

Columns: RefundNumber, Order, Amount, Currency, RequestedBy, Revision, Status, CreatedAt

### Refund Reconciliation

Source: RefundRequests

Filter: Status IN ('Sending', 'Unknown', 'Failed')

Roles: Finance Reviewer, Integration Operator

Columns: RefundNumber, Order, Amount, ProviderRefundID, Status, ResultAt

### Commercial Change Inbox

Source: ChangeRequests

Filter: Status = 'Submitted'

Roles: Order Manager

Columns: ChangeNumber, Order, ChangeType, OrderRevision, RequestedBy, Status, CreatedAt

### Connection Recovery

Source: IntegrationMessages

Filter: Status IN ('Retryable', 'Unknown', 'Failed')

Roles: Integration Operator

Columns: MessageNumber, Channel, Purpose, CommandKey, AttemptCount, Status, NextAttemptAt

### Active Price Rules

Source: PriceRules

Filter: Status = 'Active'

Roles: Order Manager

Columns: RuleCode, Channel, Product, Customer, Currency, UnitPrice, StartDate, EndDate, Status

### Order Closure Queue

Source: Orders

Filter: Status IN ('Fulfilled', 'Cancelled')

Roles: Order Desk

Columns: OrderNumber, Channel, Customer, Status, CreatedAt

### Reconciliation Exceptions

Source: ReconciliationRuns

Filter: Status = 'Exception'

Roles: Integration Operator, Finance Reviewer

Columns: ReconciliationNumber, Channel, Scope, WindowStart, WindowEnd, MismatchCount, Status

## Reports

- **Order Fill Rate** (hierarchical): Compare accepted units with shipped units by order cohort, channel and SKU; show cancellations separately and never silently remove unmet demand.
- **Backorder Age** (flat): Show uncovered quantities, first unresolved date, next review date and supply evidence by owner.
- **Promise Reliability** (hierarchical): Compare first accepted promise and latest agreed promise with evidenced delivery; retain revised commitments and exclude unconfirmed tracking outcomes from on-time claims.
- **Split Shipment Cost** (flat): Show dispatch count and recorded carrier charges per order when a configured cost source supplies them; missing costs remain unknown.
- **Order Cycle Time** (hierarchical): Measure source acceptance to release, dispatch and delivery separately, with holds and unresolved stages visible.
- **Return Reasons and Disposition** (hierarchical): Compare authorised, received and inspected quantities by SKU, reason and condition without equating returns to refunds.
- **Refund Exposure** (flat): Show approved, in-flight, unknown and confirmed refunds against verified captured amounts in each currency.
- **Price Exceptions** (flat): Show discount and price overrides with requester, independent reviewer and frozen order revision.
- **Channel Reconciliation** (flat): Show missing orders, conflicting identities and unresolved external acknowledgements by channel and reconciliation window.
- **Stock Commitment Reconciliation** (flat): Compare active reservations and pending dispatch debits to authority snapshots, highlighting stale stock and unacknowledged movements.

## Working with this application

### What it helps with

- **Order Desk's assistant.** Explain held orders, prepare a customer follow-up and draft a bounded change or return request with its source evidence.
- **Inventory Planner's assistant.** Identify uncovered demand, stale snapshots and possible location alternatives without treating unconfirmed stock as available.
- **Fulfilment Operator's assistant.** Summarise assigned work and shipment exceptions, preserving the exact packed and shipped quantities.
- **Returns Inspector's assistant.** Prepare inspection records from supplied evidence and highlight missing condition or disposition information.
- **Finance Reviewer's assistant.** Assemble refund evidence and reconcile provider references while leaving the independent financial decision with the authorised person.
- **Integration Operator's assistant.** Investigate conflicting events, compare source cursors and prepare safe retries under their original command identities.

### What it cannot do alone

The assistant cannot approve its requester's own commercial exception or refund, invent stock or provider evidence, assume customer consent, or treat a timeout as a failed payment. It cannot expand its permissions or treat a credit export as a confirmed accounting posting. Product substitutions, commercial exceptions and refunds retain their specified human decisions.

### Example requests

```text
Show my held orders and the evidence needed to release each one.
Prepare a backorder follow-up without changing the customer promise.
Explain which quantities remain open after this order's split shipments.
Draft a return request for these shipped lines; do not approve it.
Reconcile this unknown refund against its existing provider reference.
```

## Detailed application guides

- [Orders](https://www.erp.ai/e-commerce-order-management/modules/orders) — Order intake with channel identity, commercial checks, approvals and traceable amendments.
- [Allocation](https://www.erp.ai/e-commerce-order-management/modules/allocation) — Available-to-promise, reservations and backorder resolution grounded in stock authority.
- [Fulfilment](https://www.erp.ai/e-commerce-order-management/modules/fulfilment) — Warehouse release, split shipments, tracking and cancellation acknowledgement.
- [Returns](https://www.erp.ai/e-commerce-order-management/modules/returns) — Return authorisation, inspection, disposition and independently approved refunds.
- [Pricing](https://www.erp.ai/e-commerce-order-management/modules/pricing) — Price snapshots, customer agreements, discount exceptions and refund allocations.
- [Reports](https://www.erp.ai/e-commerce-order-management/modules/reports) — Order, stock, delivery and refund reporting with explicit unresolved outcomes.
- [Order intake and approval](https://www.erp.ai/e-commerce-order-management/processes/order-intake) — Capture, duplicate checks and independent commercial approval before release.
- [Allocation and backorders](https://www.erp.ai/e-commerce-order-management/processes/allocation-and-backorders) — Reservation, uncovered demand, customer promises and consented substitutions.
- [Split fulfilment and tracking](https://www.erp.ai/e-commerce-order-management/processes/split-fulfilment) — Location-specific warehouse work with partial shipment and tracking reconciliation.
- [Order changes and cancellation](https://www.erp.ai/e-commerce-order-management/processes/order-changes) — Revision-bound changes that respect accepted warehouse work and customer commitments.
- [Returns and refunds](https://www.erp.ai/e-commerce-order-management/processes/returns-and-refunds) — Independent return, inspection and refund decisions with provider reconciliation.
- [Direct-to-consumer brands](https://www.erp.ai/e-commerce-order-management/industries/direct-to-consumer) — Order operations for product brands balancing promotions, promises and customer returns.
- [Marketplace sellers](https://www.erp.ai/e-commerce-order-management/industries/marketplace-sellers) — Channel-aware orders with duplicate protection, stock authority and payment reconciliation.
- [Multi-warehouse retailers](https://www.erp.ai/e-commerce-order-management/industries/multi-warehouse-retail) — Stock allocation and partial fulfilment across owned and partner warehouses.
- [Roles and permissions](https://www.erp.ai/e-commerce-order-management/roles) — Channel, location and action scopes with independent commercial and refund decisions.
- [Reports and analytics](https://www.erp.ai/e-commerce-order-management/reports) — Reporting definitions for order coverage, promises, returns and unresolved money movements.
- [Data model](https://www.erp.ai/e-commerce-order-management/data-model) — Order, stock, warehouse and financial records with explicit identity and quantity rules.
- [Integrations](https://www.erp.ai/e-commerce-order-management/integrations) — Adapters with explicit source authority, permissions, retries and reconciliation requirements.
- [Implementation](https://www.erp.ai/e-commerce-order-management/implementation) — Rollout from source mappings and control tests to reconciled channel activation.
- [Your order operations assistant](https://www.erp.ai/e-commerce-order-management/agent) — Proto assistance for order exceptions, stock investigation and controlled configuration.
- [Pricing](https://www.erp.ai/e-commerce-order-management/pricing) — No per-user fees. Pay for automation as you use it, with implementation priced separately.
- [Frequently asked questions](https://www.erp.ai/e-commerce-order-management/faq) — Answers about the order lifecycle, approvals, integrations and rollout.
- [Get started](https://www.erp.ai/e-commerce-order-management/get-started) — Configure the order-management scope with your channels, stock authority and team.