Customer Order

Theme Concepts

This theme encompasses the subject areas that represent the creation, fulfillment, shipment and settlement of "customer orders".

There are a variety of order processing scenarios supported in the ARTS Data Model and POSLOG V6.0 XML schemas.  The scenarios support different customer order, fulfillment, delivery, payment and settlement processing steps.  A retailer may have to support several different scenarios at the same time.  For example a department store may have to support in-store sales (the usual retail scenario), food service sales (for an in-store restaurant), customer order sales (for kiosk, ecommerce and in-store catalog ordering) and other variations.

The following steps make up a customer order process.  

•Browse/shop - Order - Browsing and placing items in a physical or electronic shopping cart - order creation;

•Ordering - Customer Order - Deciding to order all or selected items placed into a physical or electronic shopping cart - order placement;

•Fulfillment - The preparation of make to order items, picking and packing of stock items and/or or providing services;

•Delivery/Shipment - The transfer of merchandise items (or performance of services) to a carrier or directly to the customer;

•Payment - The pre-authorization of tender for a Customer order, the partial pre-payment of a customer order, the full pre-payment of a customer order and/or the payment in full of a customer order; and

•Settlement - The point where a Customer Order, Taxes, Payment and other transaction components are recognized for financial reporting purposes and assigned the appropriate debit and credit dispositions for correctly posting to a retail financial journal (generally the sales journal).  A Settlement process is completed through the transition of a customer order or part of a customer order to a retail transaction.

The order of the steps varies by scenario.  In some scenarios like an in-store customer self-service purchase, the fulfillment step is implied when they take an item from a shelf and place it into their shopping cart.  Some steps, like payment, may occur at several points during the customer order process.  For example a customer may pay a deposit for the purchase of an item and upon delivery pay the balance.  Retailers will implement different variations of these processing steps based on their particular policies and procedures.

Understanding ARTS Order Processing Concepts

Orders Stage

In POSLOG 6.0, the order process is reflected in three kinds of transactions.  The Order transaction represents a customer's accumulation of items that they are potentially going to purchase.  This concept of an Order is typically associated with a shopping cart.  As customer browse on a web site or in a bricks and mortar store they may freely add items to and take items out of their Order (or shopping cart).  So the Order is a temporary container used to aggregate the items a customer accumulates with the intent to purchase.  Orders as a discrete step in the overall customer order process do not generate financial transactions or unit control transactions.  They are basically a scratchpad work area customers use to pick and choose the items they will finally commit to purchase.

The ARTS ODM V7.0/7.1 does not treat customer orders as transactions.  A CustomerOrder is a document that describes a request by a customer to purchase merchandise and/or service items from a retailer on agreed terms and conditions (price, delivery, payments schedule, cancellation policy, etc.).  A customer order and its line item components are created and updated through CustomerOrderControlTransaction and CustomerOrderControlTransactionLineItem entities.

Through using CustomerOrderState, CustomerOrderStateAssignment, CustomerOrderLineItemState and CustomerOrderLineItemStateAssignment, ARTS ODM maintains an up to date status for orders along with a history of status changes.  The history supports retailer analysis of customer ordering behavior.

Customer Order Stage

A Customer Order transaction represents a commitment on the part of a customer to purchase one or more items in an Order.  That customer commitment may or may not be followed by a Payment process during which a customer pre-authorizes the retailer to charge their credit/debit card account upon shipment of the items in their order OR authorizes a charge to prepay or partially pay for the order.  For mail order, ecommerce and similar deferred delivery scenarios, the payment process generally follows this pattern.  For an in-store, self-service retail scenario, the payment step occurs near the end of the order transaction and is captured using a RetailTransaction.

The ARTS ODM V7.0/7.1 directly represents the concept of a customer order in the CustomerOrder, CustomerOrderLineItem and related subtypes.

Fulfillment Stage

The fulfillment of an order is the retailer's picking and packing merchandise or provision of services to meet the customer's needs.  Fulfillment can be a complex process involving a number of parties including retailer suppliers for direct shipment to the customer.  A given customer order may be satisfied through several fulfillment actions. For example an order for 5 items from Amazon may be fulfilled as two separate fulfillment actions.  Fulfillment may involve inventory back orders, transfers and other secondary transactions used to secure the items required to complete a customer order.

Order fulfillment may require the reconstitution of a CustomerOrder and CustomerOrderProductLineItem entities.  This reconstitution may involve the splitting of CustomerOrderProductLineItem entities items into separate entities to record picking and packing, vendor direct and other fulfillment tactics.  This refactoring is accomplished through a CustomerOrderProductAssignment join entity which allows a single order line item to be split across many CustomerOrderProductGroup entities.  This mechanism enables a retailer to maintain a linkage between a CustomerOrder and multiple fulfillment and subsequent shipment/deliveries.

The ARTS ODM V7.0/7.1 uses the combination of the CustomerOrderProductGroup and the CustomerOrderProductAssignment (with appropriate type code attributes) to represent a pick/pack fulfillment that represents a carton or other container packed with picked items that will be subsequently shipped to a customer.  Note that this only applies to tangible items, since services are not "picked and packed".

Delivery/Shipment Stage

Delivery or shipment is the step where the items or services purchased by the customers are transferred from the retailer directly to the customer or a third party carrier.  It represents the point in time when a retailer may invoice a customer and/or trigger a Payment which has the effect of turning a pre-authorized debit/credit charge into an actual funds transfer charge.  For in-store, self-service scenarios, the delivery step is implicit in the customer's taking physical possession of their items when they have placed them in the shopping cart and paid for them at the checkout counter.

In the ARTS ODM V7.0/7.1 a CustomerOrderProductGroup and its CustomerOrderProductAssignment children represent a packing slip and container which make up a delivery.  In the Data Model these are represented as a RetailTransactionShipment and RetailTransactionShipmentLineItem.  This information is the line item detail basis for generating an invoice and/or RetailTransaction for subsequent settlement.

Payment Stage

The payment step may occur at the end of a customer order process as part of the settlement (which is the case for a typical in-store, self-service scenario) or several times (in the case of an ecommerce order which involves a pre-authorization at Customer Order placement with a follow up funds transfer upon shipment/delivery of the product).  The payment step, because it may involve the actual transfer of funds from a customer to the retailer triggers financial transactions required to record the receipt of a deposit or prepayment and the credit to a liability account (since the retailer has collected money that has not yet been earned).  Pre-authorization payments are represented by CustomerOrdertenderPreAuthorization entities and deposits/prepayments are represented by the CustomerOrderPaymentLineItem entity type.  For in-store, self service retail order processing scenarios, the Payment is built into the RetailTransaction and treated as a TenderLineItem.  As with Customer Order, Fulfillment and Delivery, it is an implicit step compressed into the point of sale retail transaction.

Settlement Stage

The settlement step is the point where the customer takes possession of the items and/or receives the service and pays for them.  A Settlement is instantiated as a RetailTransaction in the ARTS Data Model.  At settlement several key things happen:

•Retailers recognize revenue from the delivered items or services.  Revenue recognition means they may credit sales revenue;

•Retailers accept tender in exchange for the goods/services delivered.  Tender, as used here means that the sales revenue credits (plus any additional fees and taxes) are offset by a debit to an asset account.  An asset account may be cash, accounts receivable, voucher, etc.; and

•Stock ledger unit control and financial accounts are updated to reflect the outflow of merchandise.

Settlement actions are triggered by delivery/shipments and so, there may be several settlements associated with a Customer Order.

As already discussed, for an in-store, customer self-service scenario the fulfillment and delivery steps are implicitly executed as customers pick items, place them is a physical shopping cart and roll on to the checkout counter where settlement occurs in the guise of a RetailTransaction.

Retail Business Sector Variations

ARTS supports a wide variety of different retail business models.  Each retail business model involves modifying the customer order steps either by reordering their execution, making some explicit and some implicit, repeating them.

In-store, Self Service Scenario (Traditional Bricks & Mortar Retail)

The In-store, Self-Service scenario typically compresses the order -> customer order -> payment -> fulfillment -> deliver/shipment -> settlement steps into a retail transaction.  It is the simplest scenario because it does not require the creation and management of customer order and customer order line item states and reconstitution  discussed earlier.

Food Service/Restaurant/Make to Order Scenario

Retail businesses include restaurants and similar enterprises that prepare the items they serve and sell from multiple inputs. Within the food service/restaurant retail segment, there are multiple alternative process sequences for completing customer orders.  These include a fast food scenario, a sit-down service restaurant and a delivery service scenario.  These three represent the major baseline process flows covered here.  There are many extensions and variations retailers may add to distinguish their service.

The Fast Food Scenario consists of an order -> pay -> prepare (fulfill) -> serve (deliver) -> settle sequence of processes.  This reflects the typical scenario where the customer places an order, pays for the order and subsequently is served at the counter or a pickup window.

The sit-down service restaurant scenario consists of an order -> prepare(fulfill) -> serve(deliver) -> payment -> settle sequence of processes.  Here there are some variations around how an order payment is held pending the final incorporation of a tip to settle and close the transaction.

The delivery service scenario may vary in how payments are processed but follows the following flow.  The deliver customer order consists of an order -> payment ->prepare (fulfill) -> deliver -> settle sequence of steps.  This is a sub-scenario where the customer pays for the item at order submission time.  An alternative is where a customer pays for the food at the time it is delivered.  In this scenario the settlement of the order happens after the delivery person has returned with the payment tender and turned it into the retailer.

The ARTS ODM V7.0/7.1 supports these scenarios where a retail application has the logic to generalize food service/restaurant customer orders in a way that fits with its treatment of customer orders (as discussed earlier).  It provides a food service-specific retail transaction view (see the Food Service & Hospitality theme).  But it does not provide the explicit food service/restaurant order processing model objects reflected in POSLOG 6.0.  This is a gap that will be addressed in future Data Model Versions.

Ecommerce/Catalog Retail Scenario

This scenario involves a separation between the point in time a Customer Order is placed and the point in time when a Customer Order is delivered for prepackaged, prepared items.  The order channel may be in-store, the web, a kiosk, catalog, telephone, etc.  This scenario represents the "classic" treatment of a customer order as illustrated in the following diagram

Figure 64 - ARTS Notational Ecommerce/Catalog Customer Order Process

The notion of a customer order lifecycle applies to in-store purchases as well as web and catalog purchases.  The difference is that the in-store process treats the browsing, shopping, order, pick and pack and ship activities as unobserved behaviors performed by the customer as they walk the store.  The term "unobserved" means that the retailer does not track, monitor and manage the customer's activities explicitly.  Accordingly, the steps are in fact being executed by the customer but are not recorded in most scenarios.  Note that this is going to change with the advent of video analytics.  ARTS ODM 7.0/7.1 provides entities to support ordering, picking and packing, shipping and settlement.  Future releases of the ARTS data model will support browsing and selecting with the addition of a web shopping subject area and video analytics subject area.

Customer Order Process Actions

Browsing (Part of Ordering)

Browsing involves customers navigating through a store or web site to examine different items.  They may check prices, read product reviews, pick the product up and look at it, etc.  Browsing, in a web environment, can be explicitly tracked, monitored and measured.  Browsing in a bricks and mortar environment is typically not observed and measured to the same degree.  With improving video analytics it is increasingly practical to consider tracking customer browsing actions.  ARTS ODM 7.0/7.1 will be extended in the future to provide the entities and relationships needed to capture, classify, count and analyze customer browsing behavior.  Additionally, in future releases of the data model, browsing actions will be further decomposed (i.e. checking prices, reading product review, etc.) will be explicitly modeled.  This will be feasible with the increasing customer use of mobile devices to assist shopping in stores.

Selecting (Part of Ordering)

Selecting involves the customer choosing a product, putting it in a real or electronic shopping cart and moving to the next item or to checkout.  Selecting is important because it reflects a customer decision point.  Like browsing, in a web environment every customer action can be captured, classified and analyzed.  In a bricks and mortar store customer activity is typically not observed to the same level of granularity.  However with video analytics it is becoming more practical to capture customer item selecting behavior.

Customer Ordering (Commitment to Purchase by Placement of Customer Order)

Ordering involves a customer making a formal request to purchase an item.  On the web this occurs when a customer checks out a shopping cart (or part of a shopping cart's content).  In a bricks and mortar store this occurs when the customer takes their shopping cart of merchandise to the checkout stand.

Pre-authorization/Prepayment

Customers may pre-authorize a retailer to charge their debit/credit card account once a shipment is made against their order.  Alternatively, customers may pay a deposit or prepay for the order.  In the former case since no funds are transferred there is no financial impact on the retailer.  In the latter case, a prepayment or deposit is money received and must be financially recognized as a liability pending shipment of the product and subsequent settlement.  At the time of settlement, the retailer may recognize the income and as a credit and offset the liability with a debit because the deposit or prepayment is now earned income.

Picking & Packing (Fulfillment)

Picking and packing includes taking retail selling units out of cases (inventory units), physically retrieving items from inventory and putting them into one or more containers (packing) documenting what items are picked on a packing slip, sealing the package and forwarding it to shipping.  Picking and packing is the point where a customer order and its line items may be refactored into different packages and shipments (see Logical 02315 - Retail Transaction - Customer Order View for details on this issue).  For bricks and mortar stores purchases that do not involve an explicit order step, customers are doing their own picking and packing as they add items that are already broken into retail selling units to their carts.

Shipping

Shipping involves physically transferring item packages from the retailer's facility to a carrier and subsequent transport and delivery to the consumer.  In a bricks and mortar environment this step is executed implicitly by the customer when they take the items with them.

Settlement

Settlement involves paying for items and is the point where a retailer formally recognizes sales revenue.  In ARTS a customer order settlement is always represented as a RetailTransaction.

Vendor Direct Fulfillment

Customer orders may be fulfilled directly by a retailer's supplier.  In this scenario, the customer orders the goods from the retailer, the retailer places an order with the supplier and the supplier ships the product to the customer directly.  This is a common variation of the notational customer order process.  Retailers often refer to this as drop shipping.

Customer Order Cancellations

Customers may submit orders and, prior to entering the picking and packing process may cancel those orders.  The business rules specifying the rules around when customers may cancel orders are defined by the retailer.

Customer Returns

Customer returns may happen when customers decide not to keep an item they have purchased, received and paid for.  Returns, unlike cancellations require a settlement step (a return RetailTransaction).  This credits the customer's account (i.e. credit debit card account or retailer account) and debits the retailers return contra account.  Customer returns are typically tied into a vendor return process (reverse logistics) where the retailer forwards customer returns back to its vendors.   This is standard practice for large retailers.