Overview

Order management is the workhorse of any e-commerce operation. Ability to transition orders through fulfilment stages, take payments, send email notifications and process returns and refunds are essential for provision of satisfactory service to customers.

The platform offers two tools in the customer service section: Orders for order management and Payments for quick access to all payments. Access to data displayed in these panels is fully managed by data federation so only authorised users see the data.

Order panel allows easy access to customer orders and provides simple action buttons to progress the order. Order flows are fully automatic and depend on the order contents (i.e. what items have been ordered? is there multiple delivery involved? what fulfilment centres will be used?) and payment method (i.e. what features payment gateway supports?).

Order state machine manages all order flows and supports the following functionality:

online card payments in "pre-paid" mode (AUTH_CAPTURE)
online card payments in "authorisation first then payment on delivery" mode (AUTH then CAPTURE on shipment)
per delivery payments (separate CAPTURE for each shipped delivery in multi delivery orders) and per order payments (single CAPTURE for full order amount) support
offline payments in "pre-paid" mode (e.g. payment via telephone call, payment via bank transfer)
offline payments in "payment on delivery" mode (e.g. payment to courier)
refund processing (i.e. returns)
SaaS order approval (shop admin is able to pre-approve legitimate orders)
SaaS blocking orders exceeding specific amount or blocking orders for specific customers
as well as manual override for payments.

As order passes through various fulfilment stages the state machines manages inventory and email notifications to customers and call centre operatives (see order state machine section below for more details).

A typical flow would be:

an order is placed on the frontend by a customer
state machine sends out email notifications and order enters an "awaiting allocation" state, payment is either authorised (AUTH) or captured (AUTH_CAPTURE) depending on payment method
cron job runs and checks all "awaiting allocation" orders that need inventory reservation. At this stage both backorder and preorder items are accounted for. In case of backorder items email notification for of out of stock items is sent to alert about orders placed that require stock replenishment. In case of pre-order items the reservation of inventory is postponed until the release date
next stage is "stock allocated", which means that the inventory is reserved and order can be progressed further
following order states are "packing", "ready for shipment" are designed for inventory management. For example for larger companies with large fulfilment centre operations these transitions could be done by fulfilment centre operatives whilst they assemble the order and prepare it for shipment
next stage is "shipped", if this is for a previously authorised only order (AUTH) then capture (CAPTURE) instruction is issued at this point.
last stage of the delivery is "completed", which can be used by third party delivery tracking systems (e.g. singed for with delivery notification)
when all deliveries within given order are "completed" the order is deemed "completed" as well

Each transition described above is configured with appropriate email notification triggers, so that the business users and the customers are fully aware of the order status. In enterprise edition SaaS all email notifications can be suppressed or customised to use alternative mailing list, so that specific notifications are sent to interested parties as opposed to a generic account.

Order management

Order management encompasses funds capture, inventory management and email notifications, which are fully managed by order state machine (OSM). At each step of order flow business user is presented with simple choices how to proceed with the order such as "Approve order", "Cancel order", "Ship delivery", "Process refund" etc. which are provided by OSM. Reader is advised to review "OSM" section below which explains in detail some of the flows and an "end to end example" section which shows in detail what happens to a typical customer order from order placement stage all the way through to its completion.

Order search

Order search result table provides vital information about the order such as its current status and payment method, total amount and amount of funds actually captured as well as available action button for the overall order when order line is selected (usually "Pre-Approve", "Approve", "Cancel" or "Return" actions).

When order is "in progress" state it usually means that the delivery flow had been initiated and business user needs to look at the order details (by selecting order line from the result and clicking edit button) to proceed with next stages such as processing specific deliveries of the order.

Order search filter provides many special searches including selection of specific order statuses when performing a search. Be sure that you use the correct combination of statuses to get all results that you need. Filter help provides several pre-sets to toggle between most common combinations of the statuses. Additionally special keys can be used to search by specific field (e.g. @ can be used to search within shipping and invoice address fields to search by location). Business users are highly advised to study all possible options to make the most of their searches.

Order overview

Overview tab lists full details of the order such as information about the customer, shipping and billing addresses, order status and payment status in the top section. Lower section of the tab is concerned with providing specific details about the deliveries and items contained within those deliveries, giving full picture of prices, taxes, discounts and promotions as well as estimated and actual delivery times and delivery tracking information.

OSM manages each delivery separately therefore by selecting delivery number link business user with be presented with available actions specific to that delivery. This is because different deliveries may have different flows. For example "preorder" items delivery would be held off until the preordered items reach the release date (i.e. available from date), "electronic" delivery would not require "packing" and would be progressed straight to "shipment completed" due to the nature of the electronic delivery and so on.

Additional Information

This tab provides additional information, which may help the call centre operative when there is a problem with an order. It lists the shop code for which the order is placed and customer's IP address from which the order was placed, internal order GUID and full details of the promotion codes that were applied to given order.

B2B SaaS

SaaS B2B aims to provide additional information about the features specific to B2B flows. This includes order pre-approval information and business user who authorised the order as well as information captured via B2B additions in the checkout, such as customer reference and various IDs to associate the order within B2B fulfilment process.

Additionally this tab contains another table with items contained within the order which show B2B related details such as item costs, invoice numbers and additional item details that are usually provided by third party systems where the orders are exported to.

Payments

Payments tab shows all payment related transactions for given order, regardless of whether they were successful or not. This provides full history of what happened to the order in terms of payment, so that problems could be easily tracked. The platform also automatically determined the actual amount captured for any given order from the transaction history, so that outstanding amount is clearly seen at all stages of the order processing.

Audit and Export

The platform has a built in order export API where each shop can be configured using custom attributes to enable various exporters (including custom implementations) to run at specific order export states. These states are different to the order status and are only used to define milestones when a certain order export should happen. Out of the box the following states are set:

Transition	State	Notes
Payment (both online and offline) is confirmed for the order. This is the initial payment confirmation transition.	INITPAID	Used as the initial order export hook. Exporters can use this state in order to export newly created paid order.
A delivery has been set to a "shipment completed" state	DELIVERY	Could be used by exporters to notify third party systems of the completed delivery. Note that this may not necessarily indicate that all deliveries are shipped
Full order cancellation	CANCELLED	May be used to notify fulfilment systems of the cancellation. Cancellation indicates orders that have not yet been shipped
Full order return	RETURNED	May be used to notify fulfilment systems of the return of the items that were shipped previously.

Exporter job runs on a cron (recurring interval) that checks for order exporters configured for given order's shop and which are bound to order eligibility state. Custom exporter can set own export eligibility states thus providing a chain or exports if needed. In other words exporter A can be bound to INITPAID and configured to set eligibility to A_COMPLETED when is finishes. Then exporter B can be bound to A_COMPLETED. Thus in the first export cycle if order is in INITPAID - A is triggered, which sets A_COMPLETED eligibility state when it finished. In the second cycle order is in A_COMPLETED state, then B is triggered. This technique can be used to chain any number of exporter that enhance/export the order. During each export cycle audit information is recorded to ensure that detailed information of what happened to the order is maintained.

Below is an example of typical production system with three exporters A, B and C firing at various states and also audit information for integrated third party delivery despatch notification, which is marked as delivery update A and B.

Audit trail and notes 3.7.0+

Order management has records of a detailed transitions trail that an order goes through during its fulfilment cycle, which captures the initial state and target state, which could be used for forensic analysis. This is especially beneficial when fulfilment cycle is fully automated using plugins that directly interact with external system to automatically progress the order. Audit trail provides a full picture of what happened and when.

Manually performed transition performed using the order transition buttons in Admin (see Order state machine section below) will record user ID, audit message and optionally client facing messages in addition to the default audit trail information. Within order transition confirmation prompt additional input fields will allow to add audit notes for internal use and also client facing notes if they are applicable.

Client facing notes could be used in themes to enhance frontend experience. For example an additional section in order history where this information is shown. It is also could be used within email templates to personalise the experience, such as providing a detailed reason why and order is cancelled or additional information useful to the customer about their order.

It is also possible to leave audit messages on the order at any time during fulfilment to improve internal communication between departments in your company and aid fulfilment process.

Order state machine (OSM)

In terms of business operation order state machine (OSM) acts as a black box that simply works.

When customer places an order it enters OSM with "pending" state and OSM takes control over it from that point onwards.

Depending on the payment method selected (i.e. features supported by payment gateway) OSM determines the applicable flow with which to proceed. Each flow defines several milestones which require business user's action for the customer order to transition to next phase. For example if the order is set with offline payment OSM will perform inventory reservation and put the order into "Awaiting payment" state and send notification to call centre via email, at which point the orders section will display "Approve" and "Cancel" available actions for this order. When "Approve" button is clicked the business user is advised to take the payment from customer (e.g. payment over the phone) or verify that payment occurred (e.g. bank transfer). This action by business user will transition order into "in progress" state and send approval notification to call centre at which point OSM will start delivery flow for each delivery within the order.

The flows themselves do not specifically require business user's action as in a "business user is a person" but rather a person or a system who would act on authority to progress the order. For example OSM provides and action button to mark delivery as "shipment completed", however it is possible to create a say third party integration with delivery tracking system that would send notifications which would trigger this transition upon successful delivery. Such integration would remove the need for clicking the button "in person" and would allow this part of the flow to be fully automatic. Other third party integrations can be used for other milestones to make the flow completely automatic if necessary.

Each order transition within OSM will either affect payment, inventory or order state providing notifications at each stage.

Below are depictions of the most common order flow scenarios.

Offline pre-paid mode

Offline pre-paid mode assumes that the order is paid in full off-line (e.g. by phone) prior it is passed to the fulfilment team.

In SaaS there is also an option for "Pre-approve" the order. This is an additional configuration that puts the order in "require approval" state, which could be triggered at shop level for all customers or can be set at the customer level. If the order is put to this state then an email is sent to the shop administrator advising them that the order needs to be pre-approved.