Ordermodel is one of the key models in Spree. It provides a central place around which to collect information about a customer order - including line items, adjustments, payments, addresses, return authorizations, and shipments.
Orders have the following attributes:
number: The unique identifier for this order. It begins with the letter R and ends in a 9-digit number. This number is shown to the users, and can be used to find the order by calling
item_total: The sum of all the line items for this order.
adjustment_total: The sum of all adjustments on this order.
total: The result of the sum of the
payment_total: The total value of all finalized payments.
shipment_total: The total value of all shipments' costs.
additional_tax_total: The sum of all shipments' and line items'
included_tax_total: The sum of all shipments' and line items'
promo_total: The sum of all shipments', line items' and promotions'
state: The current state of the order. To read more about the states an order goes through, read The Order State Machine section of this guide.
user_id: The ID for the corresponding user record for this order. Stored only if the order is placed by a signed-in user.
completed_at: The timestamp of when the order was completed.
bill_address_id: The ID for the related
Addressobject with billing address information.
ship_address_id: The ID for the related
Addressobject with shipping address information.
shipping_method_id: The ID for the related
created_by_id: The ID of object that created this order.
shipment_state: The current shipment state of the order. It takes into account all shipments. Described below in Order Shipment states section.
payment_state: The current payment state of the order. It takes into account all payments. Described below in Order Payment states section.
special_instructions: Any special instructions for the store to do with this order. Will only appear if
Spree::Config[:shipping_instructions]is set to
currency: The currency for this order. Determined by the
Store#default_currencycurrency in which this order was created
last_ip_address: The last IP address used to update this order in the frontend.
channel: The channel specified when importing orders from other stores. e.g. amazon.
item_count: The total value of line items' quantity.
approver_id: The ID of user that approved this order.
confirmation_delivered: Boolean value indicating that confirmation email was delivered.
token: The token stored corresponding to token stored in cookies. In older Spree versions this attribute was called
canceler_id: The ID of user that canceled this order.
store_id: The ID of
Storein which this order was created.
Some methods you may find useful:
outstanding_balance: The outstanding balance for the order, calculated by taking the
display_item_total: A "pretty" version of
display_adjustment_total: Same as above, except for
display_total: Same as above, except for
display_outstanding_balance: Same as above, except for
Orders flow through a state machine, beginning at a
cartstate and ending up at a
completestate. The intermediary states can be configured using the Checkout Flow API.
The default states are as follows:
cart- initial state
address- Cart moved to Checkout
delivery- buyer has added Shipping and Billing addresses
payment- buyer selected delivery option
confirm- buyer added payment option (if required)
complete- order was placed
paymentstate will only be triggered if
confirmstate will only be triggered if
completestate can only be reached in one of two ways:
- 1.No payment is required on the order.
- 2.Payment is required on the order, and at least the order total has been received as payment.
Assuming that an order meets the criteria for the next state, you will be able to transition it to the next state by calling
nexton that object. If this returns
false, then the order does not meet the criteria. To work out why it cannot transition, check the result of an
Alongside the global Order state there's also
shipment_statecolumn which indicates the state of all shipments. Order can have multiple shipments.
shipped- all Shipments are in the
partial- at least one Shipment has a state of
shippedand there is another Shipment with a state other than
shippedor there are InventoryUnits associated with the order that have a state of
soldbut are not associated with a Shipment
ready- all Shipments are in the
backorder- there is backordered inventory associated with an order
pending- all Shipments are in the
Alongside the global Order state there's also
payment_statecolumn which indicates the state of all payments. Order can have multiple payments.
payment_totalis equal to
payment_totalis less than
payment_totalis greater than
failed- most recent payment is in the
void- order is canceled and
Line items are used to keep track of items within the context of an order. These records provide a link between orders, and Variants.
When a variant is added to an order, the price of that item is tracked along with the line item to preserve that data. If the variant's price were to change, then the line item would still have a record of the price at the time of ordering.
An order can link to two
Addressobjects. The shipping address indicates where the order's product(s) should be shipped to. This address is used to determine which shipping methods are available for an order.
The billing address indicates where the user who's paying for the order is located. This can alter the tax rate for the order, which in turn can change how much the final order total can be.
Adjustments are used to affect an order's final cost, either by decreasing it (Promotions) or by increasing it (Shipping, Taxes).
Payment records are used to track payment information about an order. For more information, please read the Payments guide.
An order can have many
ReturnAuthorizationobjects. These records keeps track of which items have been authorized for return and how the user will be compensated -- either via exchanging the item(s) or a reimbursement.
If you change any aspect of an
Orderobject within code and you wish to update the order's totals -- including associated adjustments and shipments -- call the
update_with_updater!method on that object, which calls out to the
For example, if you create or modify an existing payment for the order which would change the order's
payment_stateto a different value, calling
update_with_updater!will cause the
payment_stateto be recalculated for that order.
Another example is if a
LineItemwithin the order had its price changed. Calling
update_with_updater!will cause the totals for the order to be updated, the adjustments for the order to be recalculated, and then a final total to be established.