Order

First-Pass Node Dossier

This page is an evidence-backed node dossier generated from the domain hierarchy and node questionnaire.

What It Is

Order is the primary commercial aggregate for draft carts, confirmed orders, addresses, totals, ownership, shipping lines, payments, returns, risks, and post-purchase visibility.

Parent hierarchy:

• Order Lifecycle
• Order Authoring And Review
• Order

Primary implementation paths:

• packages/framework/src/Models/Order.php
• packages/framework/src/Http/Controllers/Api/Admin/OrdersController.php
• packages/framework/src/Http/Controllers/Api/Storefront/OrdersController.php
• packages/framework/src/Actions/Order
• packages/admin/src/Livewire/Admin/Order

What Users Can Do With It

Direct capabilities

Operators can:

• create, show, update, and delete orders through the admin API
• calculate, confirm, cancel, duplicate, and fulfill orders
• apply shipping lines or shipping services across items
• send invoice emails, preview emails, and download PDFs
• upload or download quote PDFs
• refund selected items or refund and cancel an order

Customers can:

• view order history and order details
• update limited order fields such as note, email, references, and addresses while allowed
• download fulfillment invoices when available

Indirect capabilities

Other workflows also use Order:

• ERP synchronization
• shipping selection and recalculation
• fulfillment-request creation and tracking
• order-return creation and refund recovery
• abandoned-cart detection when cart = true

Things users cannot do directly

This pass did not find a separate packaged admin page for returns or risks inside the order detail UI. Those workflows are exposed through API surfaces and host-app operations tooling, while the packaged admin order page focuses on review, items, shipping, financial details, and comments.

Where It Is Managed

Channel	Role	Notes
Admin orders list and order page	Direct	Main packaged operator review surface
Admin API	Direct	Broad lifecycle and adjustment actions
Storefront my-account orders	Direct read/update	Shopper history and detail access
Storefront cart	Parent-owned	Same aggregate before confirmation
ERP sync	Indirect	External system synchronization

Sources:

• packages/admin/routes/web.php
• packages/admin/resources/views/components/order/page-content.blade.php
• packages/framework/src/Http/Controllers/Api/Admin/OrdersController.php
• packages/framework/src/Http/Controllers/Api/Storefront/OrdersController.php
• packages/framework/src/Actions/ErpBridge/Order

Channel-Level Field Coverage

Admin create flow

Creating an order validates and can set:

• customer_id
• shipping_address_id
• billing_address_id
• optional product_inventory_location_id
• project_number
• reference_number
• email
• currency
• gift
• gift_message
• cart
• sales_channel

Source:

• packages/framework/src/Actions/Order/CreateOrder.php

Admin and storefront update flow

The shared update action supports fields such as:

• note
• internal_note
• tags
• email
• currency
• tax_exempt
• taxes_included
• gift_message
• gift
• reference_number
• project_number
• hold_until_date
• custom_tax_rates
• owned_by_user_id
• deposit_amount
• external_status
• cart
• external_id

Sources:

• packages/framework/src/Actions/Order/UpdateOrder.php
• packages/framework/src/Http/Controllers/Api/Storefront/OrdersController.php

Admin show surface

The admin order show flow can include:

• items and item locations
• shipping lines
• customer and addresses
• tax lines and discount lines
• comments
• returns
• payments and refunds
• fulfillment request items
• risks
• fulfillments
• shipments
• flags

Source:

• packages/framework/src/Actions/Order/Requests/Admin/Show.php

Configuration And Data Model

Key model characteristics:

• soft-deletable
• UUID-based
• ERP-syncable
• searchable
• action-request aware
• flag-aware
• notification-aware

Important relationships:

• items()
• payments()
• shippingLines()
• shipments()
• returns()
• risks()
• fulfillmentRequests()
• fulfillments()

Source:

• packages/framework/src/Models/Order.php

Relationships

Order is the hub record for:

• OrderItem
• OrderShippingLine
• OrderPayment
• OrderReturn
• OrderRisk
• shipment and fulfillment coordination

Practical dependents:

• admin order review
• storefront order history
• refunds and returns
• shipping and fulfillment domains

Folded Supporting Records

This first pass documents several thin supporting records inside Order rather than as standalone pages:

• OrderRisk
  • nested risk records used for manual or payment-driven review concerns
• OrderDiscountLine
  • order-level discount adjustments exposed through financial review
• OrderTaxLine
  • calculated tax detail reviewed on the order rather than managed as its own workflow
• OrderRefund
  • downstream payment-settlement records related to returns and refund actions

OrderRisk is intentionally folded here because the shared package exposes nested API CRUD but no packaged standalone Livewire review page, and operators encounter it as part of the broader order review surface rather than as an independent workflow.

Rules And Downstream Effects

Update side effects

Updating an order can:

• reset addresses and custom tax rates when the customer changes
• convert a draft cart into a non-cart order when ownership changes
• clear cart notifications during that conversion
• trigger post-update events

Source:

• packages/framework/src/Actions/Order/UpdateOrder.php

Confirmation side effects

Confirming an order:

• sets processed_at
• moves status to open
• logs order activity
• dispatches OrderConfirmed
• sends confirmation email
• recalculates allocated stock for product items

Source:

• packages/framework/src/Actions/Order/MarkAsConfirmed.php

Cancellation side effects

Cancelling an order:

• sets cancelled_at
• logs order activity
• recalculates allocated stock
• dispatches OrderCancelled

Source:

• packages/framework/src/Actions/Order/CancelOrder.php

Risk and notification review

Order review pulls together two different risk surfaces:

• stored OrderRisk records created under the order
• payment-gateway risk fields on related order payments

Those are related review signals, but they are not the same thing as cart notifications or checkout blockers.

Sources:

• packages/framework/src/Models/OrderRisk.php
• packages/framework/src/Http/Controllers/Api/Admin/OrderRisksController.php
• packages/framework/src/Models/OrderPayment.php

Integrations And Automation

ERP bridge

Orders are a major ERP sync surface in the shared package.

Source:

• packages/framework/src/Actions/ErpBridge/Order

PDF and email outputs

Orders can generate or send:

• order PDFs
• consolidated invoice PDFs
• invoice emails
• quote PDFs

Sources:

• packages/framework/src/Http/Controllers/Api/Admin/OrdersController.php
• packages/framework/src/Actions/Order/GeneratePDF.php
• packages/framework/src/Actions/Order/GenerateConsolidatedInvoicePDF.php
• packages/framework/src/Actions/Order/SendInvoiceByEmail.php

Refund workflows

Orders support refund and refund-plus-cancel flows through admin actions.

Sources:

• packages/framework/src/Http/Controllers/Api/Admin/OrdersController.php
• packages/framework/src/Actions/OrderRefund/RefundSelectedItems.php
• packages/framework/src/Actions/OrderRefund/RefundAndCancelOrder.php

Where It Appears To End Users

Order appears across both operator and shopper flows.

Operators see it in:

• admin order list
• admin order detail
• confirm and cancel actions

Shoppers see it in:

• my-account order history
• my-account order detail
• invoice download flows tied to fulfillments

Current Documentation Takeaways

1. Order is the central commercial aggregate across cart, confirmed order, recovery, and tracking phases.
2. The packaged admin UI is strong for order review, but returns and some recovery workflows remain more API and host-app driven.
3. Thin supporting records such as OrderRisk, discount lines, and refund records are best understood as parts of order review rather than first-pass standalone documentation targets.
4. Customer-facing visibility is real, but it is scoped to order history, detail, and invoice retrieval rather than full operational editing.

Open Questions

• This first pass did not audit every action reachable from host-specific admin extensions, only the shared package controllers, Livewire pages, and major framework actions.