Introduction
Orders
Introduction to Orders'Orders' is a broad subject within the context of EVA. We'll show you what EVA brings out-of-the-box and afterwards we'll lay out all facets of order flows. Once you've gone through this page, we're sure you'll have a basic understanding of what an order is, what it can be, what stages it goes through and how you can interact with it.
Available flows
EVA features all the order flows you'd expect in Unified Commerce out-of-the-box. We'll give you a quick overview of what these flows are along with some of the main considerations. You can of course check out all flows in detail in their respective docs pages.
| Flow | Description | Considerations |
|---|---|---|
| BOPIS/C&C | Buy Online, Pick-up In Store AKA Click & Collect Customers can order (and pay) products online and select a store of their choosing as pick-up location. Product availability is visible per store. | - Moment of payment is configurable: during the order placement or at pick-up. - These orders can also be fulfilled by warehouse |
| SFS | Ship from Store Our Order orchestration can route orders to be fulfilled by stores. | - Store fulfillment on location - Store fulfillment relieves pressure on warehouses - Store fulfilment leads to measurable, faster delivery |
| Warehouse fulfillment (or see Orchestration | Orders are routed to be fulfilled by a warehouse. | |
| EA | Endless Aisle Create delivery orders from within the store, to be fulfilled by either a warehouse or another store. | |
| Reservation | Reservations in store Reserve stock in another store. | |
| Interstore | Interstore transactions Transfer stock store-to-store with the initiative at the side of the sending store. |
Stages of an order flow
Creation
For starters, the actual order has to be created. Most of the time, this is just the process of assigning an identifier or OrderID to the order. As soon as the order has an ID, it is known within EVA as an actual order, albeit an empty one.
Basket building
Now, let's make a general division between 'orders' and 'baskets', where a basket is an order that's not yet 'placed'. The order being a basket is the second step of the order process. We can put products in the basket, apply discounts or attach a customer. After any of these steps, the order will remain a basket. After your basket is complete, it's time to place the order, effectively raising the basket to be an order. When doing this, we check whether the order has all information that's necessary. We check whether the order is 'ready to become an actual, full-fledged order'.
After the order is placed there's several steps we go through, which usually follow each other up in a specific order.
Payment
When the order has all necessary information, payment can be performed. Based on the order information, EVA can check what payment methods are available. After payment is complete, the order will be marked as being paid.
Shipment
After an order is paid, it's generally time to ship the order. Shipment is again a very broad term; when a customer buys something over-the-counter we speak of a shipment, but if a customer orders something that needs to be sent out by a warehouse across the country, we still talk about shipment. What we need to remember is that 'shipment' refers to the products effectively ending up in the customer's hands.
As soon as an order is shipped out we consider it to be 'shipped'. From that point onwards, it's the courier's responsibility.
Invoicing
The minute an order is both paid for and shipped, we generate an invoice. The transaction has seen both it's goods shipped out and payment made, so the invoice can be made.
Examples
We will give you some examples of order flows now, we'll start with a nice and easy example.
Basic over-the-counter transaction
A customer walks in to your store and strats looking for the items they want. When they've got their literal basket filled, they go over to the store counter. Here, an employee starts scanning the items.
| As soon as the very first item has been scanned, the order is known in EVA.
The counter employee finishes up scanning all items in the basket and heads into checkout. They can freely move into checkout, since over the counter transactions do not require customer data by default. The customer pays with cash.
| When the order is paid, we assume it is immediately shipped as well, since this is a carry out order.
Now, we can print a receipt and/or mail the invoice to the customer (which would require an e-mail eddress to be provided).
| The order is now marked as completed.
E-commerce order
Now, for a more complicated example. For this example's complexity, we will assume the webshop operates on a third party e-commerce system, and that the order will be fulfilled from an external warehouse.
A customer lands on your webshop and starts adding some stuff to their basket. This order is not yet known in EVA, as these operations happen in a third-party e-com system. The customer wraps up their basket, heads into checkout, adds their personal and address information and makes a payment. Now, when the order is paid, it is time to ship the order, but EVA is not yet aware of the order's existence. To resolve this, we push the entirety of the order into EVA using one simple webservice.
| This order 'push' will include all data, including the payment, so EVA can immediately determine the order's status and that it is ready for shipment.
Now, EVA will determine which fulfillment will be most beneficial for this certain order through order orchestration. In this specific case, let's assume the outcome is warehouse fulfillment through an external warehouse. Becauase we landed on this result, EVA will export the order (much like the webshop exported the order to EVA) to the appropriate warehouse's system.
| This export, will again contain all data.
Now, the warehouse can get cracking on fulfilling the order, making sure to update EVA through their system as they proceed.
| Example of these updates are 'shipment created' or 'shipment shipped'.
As soon as EVA knows the order to be shipped, we will generate an invoice, send it to the customer, and mark the order as completed.
Determining your order type
You can determine what kind of order type(s) an order has via its properties.
You can check this in for example a GetOrder call by filtering on the Properties property. The value it contains is an enum value. We can check exactly what enum values correspond with what order type by calling GetEnumValues:
If an order is both a pickup order (1) and created by an employee (2), the order's Properties value will be set to 3.
If an order is returned (65536), which is imported from Watchtower (2048) and is a duplicate (16), the order will say: Properties: 67600.
We're currently making a tool for you to use on our docs pages to easily decipher enum values into their smaller parts, but in the meantime: you can use nifty tools such as this one created by one of our awesome devs: factorize.