Managing orders
Order Settings
In March 2014, Commerce 1.9 was released that included a number of feature enhancements involving order workflow on the administrative side. Below is a rundown of the various settings and how they affect the new features.
- Apply pricing rules - A new local action for orders that, when clicked, will run the pricing rules for that particular order.
- Simulate checkout completion - A new local action for orders that, when clicked, will invoke the checkout completion events in rules.
- Shopping cart refresh - These settings let you control how often the shopping cart orders are refreshed, a task that can impact speed at the cost of flexibility.
Apply pricing rules
A new local action for orders that, when clicked, will run the pricing rules for that particular order.
When you click the "Apply pricing rules" button, a few things will happen:
- All product prices will be reset and recalculated using the product pricing rules defined on this site.
- Non-product line items may or may not be updated depending on the type.
- Custom prices entered on the edit form will be lost.
Simulate checkout completion
A new local action for orders that, when clicked, will invoke the checkout completion events in rules.
When you click the "Simulate checkout" button, a few things will happen:
- The normal checkout completion process will be invoked on this order.
- This may involve order status updates and e-mail notifications.
Shopping cart refresh
Shopping cart orders comprise orders in shopping cart and some checkout related order statuses. These settings let you control how the shopping cart orders are refreshed, the process during which product prices are recalculated, to improve site performance in the case of excessive refreshes on sites with less dynamic pricing needs.
Refresh mode
- Refresh a shopping cart regardless of who it belongs to.
This was the default setting pre Commerce 1.9. This has a performance impact but enables extremely dynamic pricing (assuming the pricing changes between each page request). - Only refresh a shopping cart if it belongs to the current user.
This is the new default and allows for dynamic pricing but prohibits the performance impact when the user viewing the information (presumably an administrator) views the cart, which enhances the speed for the administrator and limits the number of possible problems with dynamic pricing that relies on "current user" instead of "order owner." - Only refresh a shopping cart if it is the current user's active shopping cart.
This setting further preserves pricing on older carts that are not currently the active cart.
Refresh frequency
To further enhance the performance impact, we set a reasonable lifespan for calculated prices. If your pricing depends on up-to-the-second changes, then this setting can be set to zero so that it will always be calculated. Its likely the majority of use cases could have a large number of seconds here. Shopping carts will only be refreshed if more than the specified number of seconds have passed since they were last refreshed.
Note that, by default, we always recalculate on /cart and /checkout but you can turn off that setting here as well.
Displaying All Orders
Views is the easy way to display all orders, including orders that are cart orders, etc. You can just edit the existing administrative view of orders and expose the filter, etc.
There is even a default view to change your Admin Orders view into a Views Bulk Operations view with all this functionality in Commerce VBO Views
Implementing an automated order workflow
The Drupal Commerce shopping cart and checkout systems handle advancing an order from the Shopping cart status through the various Checkout: #### statuses and finally to the Pending order status. While the Order module defines additional order statuses for Canceled, Processing, and Completed orders, it does not implement any rules specifically to place orders into these statuses. The only way orders will get to these statuses out of the box is if an administrator were to move the order to that status from its edit form.
When you build your store, it is up to you to implement your automated order workflow beyond what the shopping cart and checkout systems provide. You can do this via direct module integration or Rules configurations that interact with various events, such as moving an order that has been paid in full to the Processing status for fulfillment or directly to Completed if fulfillment is automated (e.g. in the case of a digital commerce site).
The primary thing to keep in mind is that an order may complete the checkout process without having been paid in full. This means any automated workflow steps that result in the fulfillment of the order should use the When an order is first paid in full event or hook_commerce_payment_order_paid_in_full() instead of the checkout completion event / hook. This is primarily the case when a site integrates a payment gateway that supports delayed payment (e.g. PayPal eCheck payments) or performs authorization only transactions during checkout that are meant to be captured later.
You do not have to use all the order statuses provided by default, and you can create your own either through code or a contributed module like Commerce Customer Order Statues.
For more information, refer to the related checkout documentation.