Projects:CrossChannel/Functional Specification

Contents 1 My Project - Functional Specifications 1.1 Introduction 1.1.1 Relation with eHUB project 1.2 Scope 1.3 Cross Channel scenarios 1.3.1 Central Broker 1.3.2 Diversity and Rules 1.3.3 References 1.4 Design Considerations 1.4.1 Assumptions 1.4.2 Dependencies 1.4.3 Constraints 1.5 Glossary 1.6 Functional Requirements 1.6.1 User roles & profiles 1.6.2 Business process definition 1.6.3 User stories 1.6.4 Functional requirements based on business processes 1.7 Open Discussion Items 1.8 Closed Discussion Items

My Project - Functional Specifications

This is a draft document, a preliminary set of thoughts to outline the functionality and facilitate the discussion.

Introduction

Openbravo provides today all the building blocks to support a multi-channel operation but it requires a relevant implementation effort. The solution can be better generalized, integrated and completed to make it much easier to implement. There are two main areas within this theme:

• Define and implement a general interface, the so called eHUB, to all front-end channels (including WebPOS, eCommerce, …) and
• Extend Openbravo OMS for out-of-the-box support to configurable cross-channel scenarios, such as Click&Collect, Click&Deliver, Pick&Deliver and others.

The purpose of this project is to allow out-of-the-box support to configurable cross-channel scenarios. The order-scenarios can include all defined channels and as such represent a cross-channel scenario. The configuration of these order-scenarios include:

• Sequence of execution of order-steps;
• Conditions for the execution of the steps;
• Defaulted data-values, over-writable or not, visible for end-user or not.

Relation with eHUB project

The “Configurable cross-channel scenarios” project defines the steps, conditions and content of the order scenario, while the "eHUB" project defines how this is communicated to the relevant channel. The documents that describe the functional and technical requirements for this are found here: eHUB Functional Specification and eHUB Technical specifications.

This document describes the functional requirements for the configurable cross-channel order scenarios.

Scope

We limit the scope (for now) to those channels inside a scenario, that all belong to organizations of the same legal entity. Hence, a scenario where the order is placed in an organization belonging to entity A and delivered from a warehouse that belongs to organization in legal entity B is not part of this project. The mentioned case will be treated in the Advanced Order Scenarios project. Drop-Shipments and Trans-Shipments, if executed within the same legal entity, are part of the scope of this project.

• The definition of an order scenario is a predetermined sequence of order-steps, conditions under which these steps can be executed and default data-values that must be provided to the execution of the operations that can be over-writable by the user (or not) and visible to the end-user (or not).
• As example, it may define if a picklist has to be generated for a specific order. And if so, from which warehouse it must be picked. It also may define if that picklist can be generated only after a prepayment of x% or if it can be generated if the inventory is available, etcetera’s.

The cross-channel scenario is (pre)defined on the highest organization level, inheritable and configurable on subsequent levels.

Cross Channel scenarios

When considering the functionalities for a Cross-Channel platform, we need to recognize that each organization -even within a group- might have specific rules to govern their business. A few examples of the diversity in the scenarios that Openbravo should support:

• The franchiser within a corporation might decide not to accept payment-on-delivery while the "owned stores" are obliged to follow corporate policy and accept that. Thus, in the case of the franchiser, the scenario "Click&Deliver" behaves slightly different because the payment step needs to be completed and comes before the delivery step.
• The franchisers might demand a pre-payment on a Click&Deliver for VIP-customers in the internal loyalty system where the own stores do not. Thus, the franchiser includes a prepayment step where the owned store doesn't.
• A customer might get an additional discount if (s)he selects the scenario Click&Carry and picks-up the goods from a specific warehouse. Thus, the channel is a relevant data-element in the rules that determine the discount.

These examples above serve to deduce the factors that have influence on Cross-Channel scenarios. The first two examples influence the (sequence of the) steps while the third example influences the behavior or outcome of a specific step. Without the intention to be complete, the factors that influence in cross-channel scenarios include:

• Organization;
• Warehouse within the organization;
• The channel itself might determine a different discount;
• Customer type, member of loyalty program;
• Product, Product group;
• Date, date-range;
• Payment method, Pre-payment amount;

As result of this unforeseeable diversity, the Cross-Channel scenarios should be configurable -or better put constructable-. This construction would define the scenario by: a) concatenate the relevant business steps; b) add rules and parameters to each step with optionally default parameters.

Central Broker

In order to determine, for each order, if and when the next step can be executed there will be a central broker that governs the execution of the order-scenario. This broker is triggered by order-related activities in the database (such as payment received; shipment confirmed; ...) and determines if the next order-step can be executed by evaluating the conditions for the next step. If a next step is to be executed, the broker triggers the relevant step while providing the default data-values for that step.

Diversity and Rules

So now that we have recognized the need for constructing the cross-channel scenarios on the level of organization, let's extract all the potential building blocks ("steps") that together form a order-process. Once identified these steps, we can construct the scenarios from them.

Having said this, a "Pick&Carry" scenario has fewer steps than a "Click&Deliver", so lets picture first the most extensive cross-channel scenario and also the least extensive scenario, for the sake of the example excluding third-party deliveries as you can have with drop-shipments or trans-shipments.

The below images show the most-extensive and the least-extensive order scenario, excluding third-party shipments (Drop-Shipments and Trans-Shipments). The steps are not necesarily in the same sequence: For instance a pre-payment could be required in order to make a reservation and/or appointment.

Subsequently, the increasing personalization that SMAC is enforcing upon society, creates the necesity to allow that each step in the order-process is/can be governed by RULES. Examples of personalized situations are:

• A reservation might have an expiry date, defaulted to today + x and maxed to today + y. But a VIP-customer or specific product could allow for a longer reservation perdiod;
• A pre-payment might not be required for customers that have a loyalty-program membership;
• If a pre-payment is required, then there should be rules to calculate the relevant amount to prepay;
• Shipping options have different urgency and prices. Given the geography, not all options might be eligible;
• Picking not necesarily is done from the default store. This can depend on the product definition, the available inventory or it can depend on the geographic location of the customer;
• Products can also be stored (and owned) by an external supplier. In this case:
  • the order (after pre-payment?) must be transferred to the external supplier;
  • The ship-to address can be directly to the customer (DROP-SHIPMENT)
  • The ship-to address can be to the store (TRANS-SHIPMENT), in order to be picked up and possibly be joined with other goods from other warehouses / suppliers.

• • Order Scenario "Click&Deliver"
    • 00 Offer Reservation
      • 00.01 Condition (pre): Retrieve customer loyalty status
      • 00.02 Data-element:Store, Value:Pamplona, Visible:yes, Overwritable:no,
      • 10.02 Data-element:Expiry-date, value:Today+1(shop-calendar), Visible:yes, Overwritable:yes.
      • 00.03 Condition (post): Create reservation
    • 10 Offer Appointment
      • 10.01 Condition (pre): Retrieve reservation (must exist)
      • 10.02 Data-element:Appointment-date, value:Expiry-date+1, Visible:yes, Overwritable:yes.
      • 10.02 Condition (post): Create appointment (quotation?)
      • 10.03 Condition (post): Send email to Store-manager
    • -> Now just a inventory reservation and appointment exist, inactive until next activity or expiry-date.
    • 20 Offer Shipping options
      • 20.01 Condition (pre): Retrieve appointment
      • 20.02 Data-element:Shipping_Service, value:Express;72h;5 business days, Visible:yes, Overwritable:yes.
      • 20.03 Data-element:Ship-From, value:Pamplona_Whse, Visible:yes, Overwritable:yes.
      • 20.04 Condition (post): Create order
    • -> Now the order exists.
    • 30 Prepayment
      • 30.01 Condition (pre): Retrieve order (must exist)
      • 30.02 Condition (pre): Calculate pre-payment amount
    • 40 Picking
      • 40.01 Condition (pre): Pre-payment is completed
      • 40.02 Condition (post): Execute picklist
    • 50 Shipping
      • 50.01 Condition (pre): Picklist is confirmed (goods are in outbound)
      • 50.02 Condition (post): Confirm Delivery note (produces goods-issue)
      • 50.03 Data-element:Printer, value:whse, Visible:yes, Overwritable:yes.
      • 50.04 Condition (post): Print invoice hardcopy
      • 50.05 Condition (post): Send invoice by email

References

Design Considerations

Assumptions

Dependencies

Constraints

Glossary

Functional Requirements

User roles & profiles

Business process definition

User stories

Functional requirements based on business processes

Open Discussion Items

Closed Discussion Items