View source | Discuss this page | Page history | Printable version   





OmniChannel, CrossChannel or MultiChannel: Different names for the same concept that covers customer-oriented commercial operations like sales and after-sales services such as returns, warranties or repairs, that imply the possible use of multiple channels, to the discretion of the customer and in a seamless and effortless way.

Channel: The identification of a source from where sales orders are obtained or previous sales is serviced, so called customer-contact-points. Examples are:

Channel versus Organization: The current organization structure will only alter in the sense that the customer-contact-points inside the organizations will be tagged with a Channel, and that this channel plays a role in the definition of the behavior. An organization can have 1 or multiple (sales) channels, but a sales channel is not defined by the type of access or device: You can have several WebPOS in your store but consider the mobile WebPOS in your store a different sales channel than the fixed POS that you have at the checkout desks. And all mobile WebPOS can belong to the same channel, regardless in which organization they physically are. Likewise, you can have a single website as your online presence but consider the domestic access as a different channel from access from abroad. Of course you also can have multiple websites and consider each of them a different channel, or group them into 1 or more channels.

Notes for Technical Design:

  1. Each access or device that can create an order (Website, WebPOS, Self-checkout, ...) must be tagged with the Channel to which it belongs. This 'tag' is communicated to the OMS and Channel Manager that determines / personalizes the options as defined in the Channel Definition window.
  2. A website can bundle multiple channels. These channels can be linked also to the same or to different organizations.
    1. Case 1: Apart from the physical stores (organizations), there is another organization to handle online orders and shipping logistics. This organization has its own assortment with its own price list, that can match or not with other stores' assortment and price list. In case of 'Buy Online + Pickup In-Store', this store is used merely as a Warehouse. In Spain, there are several companies that implements this way of operating: MediaMarkt, Fnac, El Corte Ingles (La tienda en casa), ...
    2. Case 2: Each physical store (organization), besides of its traditional channels (WebPOS, Self-checkout, ...) implements also an option to allow buy there directly from a website. This website could be shared among all or several organizations, but depending on some factors (IP, customer physical address, ...), the assortment and price list displayed will be the one of the target organization. This target organization usually is the store closer to the user location. E.g: Most of physical supermarkets' assorment and price list varies depending on the location of the supermarket. When the user reaches the online ecommerce platform, the first data is requested to introduce is his current location. Using this location, the system will be able to determine which is the organization that is going to handle the order and, therefore, load the proper assortment and price list. In this case there is no ad-hoc organization created to handle the online orders. The order is directly managed at accounting and logistic level by the target organization applying its own delivery schedule, delivery methods, ... In Spain, there are several companies that implements this way of operation for their online supermarket: Alcampo, Eroski, ...
    3. Case 3: If for instance access from a local IP is considered a different channel than access from a foreign IP. The website therefor should include certain logic to determine the Channel that is communicated to the Channel Manager and OMS.
  3. The philosofy behind the callcenter or kiosk is exactly the same as the website. E.g: It could happen that there was an organization that was exclusively to take phone orders, or it could happen that the customer calls directly to the store that is going to serve the order.
Multiple organizations accept orders from various channels and want to give a personalized service. The challenge is to manage this.

Channel Differentiation Tools

The concept of Channel serves the demanding customer and thus serves the retailer. It allows for better business intelligence and differentiation tools that allows personalized customer services. Examples of differentiation tools are:

And with multiple channels and various differentiation tools there is a need for control.

Channel Control

With this potential proliferation of channels it becomes crucial that the various differentiation tools are visible and controllable from a central point. Take for instance discounts as a differentiation tool:

  1. A retailer might want to stimulate the sales from the online store and increases discounts in that channel;
  2. Next, marketing starts a campaign for a certain product range for all channeles;
  3. and thirdly all stores discount their products after the X-mas event.

If these discounts would be effectuated through different systems, there would be a big chance of them getting out of control with the direct effect of losing margins and increasing costs for internal control.

With some effort you can connect to Openbravo a few websites, a set of kiosks, self-service POS and normal POS. The challenge is however, to see in a central place how these channels behave in terms of payments, distribution, discounts and loyalty.

Only if all channels and differentiation tools are controlled from a central point, the retailer will be able to compare or adjust discounts between channels.

First-, Second- and Third-Level functionalities

From the definition above, it is clear that there are several levels of functionality, where a next-level would require the prvious level(s):

The First-Level functionality is the ability to accept and serve orders for different channels and control from a central point how these channels should behave. The first-level functionality is directly related to manage the primary differentation tools:

  1. Channel Definition window;
  2. Channel Devices (tab);
    1. Channel tag in each POS;
    2. Magento tagged with (multiple) Channel;
  3. Channel Payment rules (tab);
  4. Channel Distribution rules (tab);
  5. Channel Manager.
    1. Magento connector adapted to Channel Manager;
    2. POS adapted to Channel Manager.
The flow in (modern) triangular trade.

The Second-Level functionality is the ability to personalize the service via the different channels. The second-level functionality is related to manage the differentiation tools that enhance the user-experience:

  1. Channel Discounts rules (tab);
  2. Channel Loyalty rules (tab);

The Third-Level functionality is the ability to manage trianguler order scenarios, where the exposed products are not -and will never be- actually in stock of the seller but will always be shipped from a non-disclosed supplier, internal or external. It is relevant to repeat here that these scenarios should be seemless and effortless as the definition of OmniChannel requires.

  1. Triangulation and European Union VAT rules
  2. Definition of Triangulation. The scenario would typically be:
    1. BUYER buys from SELLER (order-pair 1), SELLER invoices BUYER;
    2. SELLER buys from SUPPLIER (order-pair-2), SUPPLIER invoices SELLER;
    3. SUPPLIER ships to BUYER and informs SELLER.


The initial scope of Openbravo OmniChannel project is focussed on the First-Level functionalities, described above. As such the scope includes:

Channel Manager

The Channel Manager is the central software component that brokers between requests from the various channels and the configuration as defined in the Channel Definition window.

The typical execution of the Channel Manager is as follows:

  1. A Channel sends a request for options to the Channel Manager. This request can be anonymous or named. These options are grouped as:
    1. Payment options,
    2. Delivery options,
    3. Discount definitions,
    4. Loyalty definitions,
    5. Assortment definitions.
  2. The Channel Manager reads the configuration as defined in the Channel Definition window and returns the possible values for each group to the Channel;
  3. The Channel exposes the received values to the user/operator;
  4. The Channel returns to the Channel Manager the chosen values.
  5. The chosen values are checked with the Channel Definition for additional values that are relevant for the OMS, e.g. "Carrier=DHL" can be a value that is a result of chosing the delivery option "24hrs @ Home".

Channel Definition window

Each order that is received by the central OMS (Order Management System) should register from which channel it was received. This is of importance for the order entry and handling but also important input for Business Intelligence.

What facilities -in terms of the Differentiation Tools- are given to each of the channel is defined in the Channel Definirion window, see below simplified mockups.


The Channel Definition window with the tabs from where the differentiation tools can be managed and First-Level and Second-Level functionalities clearly indicated.

Primary Scenarios

The configuration of the OmniChannel scenarios has the sole purpose to provide the order-creation process with the correct input since each order can -will- be different and personalized to the customer' requirements.

It is this configuration that determines -and provides as input- the first-phase order-components that are needed for the payment and delivery: How and when must be paid? and ┬┐How and when must be delivered? This configuration provides the following concepts to the Central OMS: Payment moment/method/amount, Scheduled Delivery Date, the Terms and Carrier, the Ship-From and -To, and whether or not an additional product of type "Service-Transport" has to be added to the order and what the costs of that service is, if any.

The following OmniChannel scenarios are considered:

BODAH - Buy Online + Deliver At Home

The typical interaction between customer, system and warehouse in the BODAH scenario.

The most well-known and widely used omnichannel scenario. Concerning the flexibility of the options that the channel may offer, this scenario implies the following:

Delivery Options: The Channel offers that the customer may specify (part of) the delivery by choosing:

Note that the concepts of Terms, Ship-From, Carrier, costs (if-any) are either not shown to the customer or are implicit in the chosen option.


Variable Show Edit Value
Ship-From No No Central DC
Conditions Action (atomic rules that can be assigned to a situation) Terms Carrier
Ship-To Yes Yes Show * from Customer-Address Allow to create new Address (Parent=Customer, Type=Ship-To)
No Show * from Stores Do not allow to create a new Address
Service Yes No 24h Add Product to order "Transport 24h" (price 24 US$) DDP Fedex
Set Delivery Date = *NOW* + 24h - shipping LeadTime DDP Fedex
72h Add Product to order "Transport 72h" (price 8 US$) DDP Fedex
Set Delivery Date = *NOW* + 72h - shipping LeadTime DDP Fedex
Std. Business delivery - Free Set Delivery Date = *NOW* DDP Mailorder

Payment Options: The Channel offers that the customer may specify (part of) the payment rules as defined in the Payment Differentiation tab:


Differentiation Conditions
Payment Customer-Level Product Category DateRange
Moment Method Amount
Gold On-Order (Pre-Payment) NA NA
Gold On-Issue (Delivery) NA NA
Gold On-Invoice (Post-Payment) Customer Credit Remainder
Silver On-Order (Pre-Payment) Bank Card 20% uprounded M10
Silver On-Issue (Delivery) NA NA
Silver On-Invoice (Post-Payment) Bank Card Remainder
On-Order (Pre-Payment) Bank Card 100%
On-Issue (Delivery) NA NA
On-Invoice (Post-Payment) NA NA

BOPIS - Buy Online + Pickup In-Store

The typical interaction between customer, system and warehouse in the BOPIS is identical to BODAH and the differences are driven from configuration and customer-election.

This scenario implies that the front-end (online channel) offers specific payment rules (moment + method + amount) and that the customer may specify part of the delivery rules (moment). As such, the process is identical to the BODAH-flow and differences driven by configuration and customer-election.

The sole difference between this channel and BOP@H is that the delivery address was set (by the customer) to a near shop. Payments can still be pre-payment only, on pickup or invoiced after because this does not interfere or relate to the logistical flow but to the financial flow.

Delivery Options: The Channel offers that the customer may specify (part of) the delivery by choosing:

Note that the concepts of Terms, Ship-From, Carrier, costs (if-any) are either not shown to the customer or are implicit in the chosen option.

Buy @ Call-Centre (through WebPOS UI) + Pickup In-Store

This scenario is not very different from the BOPIS scenario with regards to the processing. It is however different from the interface POV: Here the POS is not in a store but in a call center.

This brings two main differences:

  1. The UI of the POS should be capable of accepting all channel-related definitons from the Channel window, starting with the definition of the Channel to which it belongs (device).
  2. The Order-Type that is created by the WebPOS in this scenario is not the "POS order but the "Standard Order" because the "goods-issue transaction" (shipment) is not immediate but on a later moment or date. By definition, a Standard Order can not be an anonymous order and further needs a Ship-To address (as defined in the Channel window for this channel) and the Pick-up date (=Scheduled Delivery Date). The WebPOS UI should ask for these values.

Return to Different Store

A return to the same store (As-Is functionality) as where the product was purchased results in a new order with a negative goods-issue (shipment) and negative payment.

  1. Goods Transactions: The negative lines are linked to the corresponding positive lines of the delivery note of the original order.
  2. Payment: The payment is not related to the original order but just to the new (negative) order.

Return to Different Store: Franchise vs Consignment

A store can be owned or it can be a franchise. The difference between these two types of stores typically would be the owndership of the inventory: A frachise would purchase the stock from the mother-company and subsequently own it. However, a franchise is much more than just owning stock and it happens in many different industries that a franchise does not own the stock but has all inventory in consignment. Hence, the discussion about franchise vs owned store is the wrong discussion, the relevant difference is who owns the stock:

  1. Customer buys online (owned store/inventory) and returns to another physical store (franchise store with owned inventory).
  2. Customer buys in a physical store or kiosk or call-center (franchise store with owned inventory) and returns to the online channel (owned store/inventory).
  3. Customer buys online (owned store) and returns to a physical store (franchised/consignment inventory).

Note: Change of ownership is a condition in the Channel definition for Returns!

In the case of a return with a change of ownership, the transaction from the POV of the receiving shop is somehow a purchase of the product from the customer that returns for the commercial price. As this is not good business for the franchiser, the next /fair) step would be to return the product to the central organization for the same commercial price and this can be done with a standard SO/PO pair.

Use cases


With that, it will also be controlled which channel may execute returns, and under which conditions:

  1. Technical aspect: The link to the positive lines of the original delivery note would require that this initial order is accessible.
  2. Functional aspect "Return Acceptance":
    1. Product: Can all products / product categories be returned?
    2. State: If the product is returnable, is it returnable regardless the state/reason/value in which the product is?
      1. Inventory state: Is the product acceptable as return if "Damaged"?
      2. Reason of Return: (not working, was received in bad state,
      3. Value: Is a 5 cent product accepted as return? What is the threshold for this (receiving) channel?
  3. Functional aspect "Return Processing", in case the return is accepted:
    1. Should the receiving company just store and resell or return to central company?
    2. Does the original organization and receiving organization belong to the same legal entity? E.g.: Franchise organizations.

Placeholder for Relevant Concepts

Secondary Scenarios

Buy @ Kiosk + Pickup In-Store

Buy @ Call-Centre + Deliver At Home

Retrieved from ""

This page has been accessed 3,616 times. This page was last modified on 19 February 2018, at 11:25. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.