Projects:EHub/Functional Specification

Contents 1 My Project - Functional Specifications 1.1 Introduction 1.1.1 Relation with eHUB project 1.2 Definition 1.3 Scope 1.3.1 Dependencies 1.3.2 Constraints 1.3.3 User roles & profiles 1.4 Use Cases Studies 1.4.1 Integration with a Stand-Alone E-Commerce 1.4.2 Integration with a MarketPlace 1.4.2.1 Variants 1.4.3 Integration with a Call Center or a Customer Support System 1.4.4 Integration with a Shopping Mall 1.4.5 Integration with an ERP 1.5 Solution Design 1.5.1 Glossary 1.5.2 Window Design: Configuration of Services 1.5.3 Window Design: Configuration of Channels 1.5.4 Process Design: Order Processing 1.5.5 Process Design: Product Listing/Synchronization 1.5.6 Process Design: Customer Synchronization 1.5.7 Process Design: Master Data Listings 1.6 Design Considerations 1.6.1 Assumptions 1.7 Integration Plan Structure 1.8 Open Discussion Items 1.9 Closed Discussion Items 2 References

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 (POS including WebPOS, eCommerce, …) and
• Extend Openbravo OMS for out-of-the-box support to common cross-channel scenarios, such as Click&Collect, Click&Deliver, Pick&Deliver and others.

The purpose of this project is to define and implement a general interface and with that facilitate the connection with multiple sales channels, multiple payment methods and multiple fullfilment channels, while in parallel guarantee the consistency of the communication, both on functional and on technical level, with the Openbravo Order Management System (OMS).

Relation with eHUB project

The "eHUB" project defines how the communication with the relevant channel is structured, while the “Configurable cross-channel scenarios” project define the steps, conditions and content of the order scenario. The document that describe the functional requirements for this is found here: Cross Channel Functional Specification

This document is to describe the functional requirements for the general interface mentioned here.

Definition

The eHUB is the software component that interacts between front-end channels and the central Openbravo Order Management System (OMS) by the means of services. Part of this eHUB is the standardization, structure and mapping of these services.

The definition of a channel in this project is “a type of end-point that requests information from and sends information to the central Openbravo OMS, via the eHUB". The structure of these requests are defined in the channel definition as part of the eHUB.

• Example: the WebPOS is a channel (probably the first and most complex). The WebPOS terminals communicate with the OMS according to the structure as defined for this channel. Magento is another channel and Prestashop is a third (Even though both are eCommerce, there will be differences between various eCommerce solutions so for Openbravo they are different channels). The channel is defined on the highest level, not related to any organization.

As logical extention to this, and as separate projects, we foresee to adapt the existing connectors with the e-Commerce solution leaders (Magento, Prestashop and others) to the new standard interface and to facilitate the Openbravo partners to base their development of future connectors on this eHub. With this approach of a general interface from the sales channels with the central OMS, we will enforce consistency in the operation with all different e-commerce solutions, both on functional and on technical level, and allow quicker and easier development for new e-commerce solutions.

Scope

When talking about cross-channel scenarios, 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 (drop-shipment) is part of the Advanced Order Scenarios project.

The eHUB is seen as a pool of services available to Sales Channels to process Cross Channel Scenarios. Each channel will declare, in its definition, its capacities to handle -or not- specific steps of the sales process. This will have consequences in the behavior of the eHUB, for example pushing events.

• Control of Data:
  • By definition of the eHUB, the channels are in control of the services that they want to use. Practically that means that the eHUB will respond to requests from channels and not enforce rules over them, for instance:
    • Enforcement of a Price/Discount Policy. Channels are free to pull from the master data, or to subscribe to push events. But upon reception of an order, no control will be made over price, unless the channel is configured to accept the pricing from the Openbravo OMS.
    • To generalize on the point above, the eHUB should not even check for an order consistency. (for instance that the sum of lines amount matches the total amount). The reason for this is that the channel is responsible for the amount displayed to the User (in a point of Sales, in a Shopping Cart) and the OMS should faithfully record operations.
  • In order to limit the data-inconsistency risk related to that principle, the eHUB could optionally include an Order Calculation function that would help the channel to double check the content of a cart, by for example auto-applying discounts.

• Control of Order Scenario
  • The control of data above applies as long as the channel respects the general rules within the ERP, mainly the defined cross-channel order-scenarios. For instance:
    • A Picking and shipping step would not start if the defined conditions, such as a (pre)payment, are not met.
    • The eHUB would never deliver data not accessible to a channel's organization per the Openbravo security Model.
    • Channels will have to respect the minimal contract available in the Services they use (Mandatory information etc.).

As a result, the eHUB should be flexible enough to allow the implementation of any Cross-Channel Scenario.

Dependencies

Constraints

User roles & profiles

Use Cases Studies

Integration with a Stand-Alone E-Commerce

Describes the Interactions to integrate with a Self-Operated Platform such as a Magento Deployment, where the organization is in charge of the full delivery chain.

Integration with a MarketPlace

Describes the integration with a MarketPlace ( example T-Mall in China, Amazon, eBay in the rest of the world )

Variants

Stock reservation for the Market Place The Market Place owns Stock Deliveries orchestrated by the Market Place or not

Integration with a Call Center or a Customer Support System

Describes the interactions in the case where orders and customer data has to be accessed, edited and created through a Call Center. (And in particular when the software supporting the call center is not Openbravo)

Integration with a Shopping Mall

Describes the interactions in the case of using a third Party POS System

Integration with an ERP

Describes the case when orders are coming from an ERP.

Solution Design

Glossary

Window Design: Configuration of Services

Before defining a channel and the interactions/services that it allows/uses and how these are mapped, the services themselves must be defined.

Within these services we include:

• Master data:
  • Present and allow to update full customer account data, add ship-to addresses, payment methods;
  • Expose product data, product search;
  • Expose price, discount and promotion data;
  • Tax applicable;
  • Expose store and warehouse information, address, open (or not) for public;
• Dynamic and Transactional data:
  • Present inventory data of pre-selected warehouses;
  • Accept and Process an order at any stage of its lifecycle (Draft / booked / shipped / paid).
  • Expose a list of orders according to the stage of their lifecycle.
  • Accept and Process modifications to an order.
• Other Services
  • Execute an Order calculation by submitting order lines and receiving the calculation of discounts to apply, Total amounts, taxes.
  • Merging customers : ask that two accounts are merged into one, including all their past transactions.

Most of these services have to be available in two versions : a PULL option allows the Channel to actively retrieve the data while a PUSH option will let the eHUB actively communicate information to the Channel.

In the case where a service is implemented as PUSH, the related configuration will include more details such as the endpoint to use, the authorization supported, etc..

Additionally to Services the other important function of the eHUB is to allow Declaration of a Sales Channels.

Window Design: Configuration of Channels

Once the service are defined, we can define the channel(s) and within them the service and how they are used. The channel configuration allows for each service to define whether the channel uses the standard service, or a custom service overriding the default one. The configuration of the channel will then offer additional fields (/Subtabs ...) to provide the necessary configuration.

The configuration is described in the listing below. When no type is defined, we understand the configuration as a checkbox.

• Customer Listing
  • No Customer Listing
  • PULL (Default) 'Means that the Channel will use Openbravo's Services to download Customer data'
  • PUSH
    • Connector Implementation ( Drop Down menu allowing to select an implementation of a customer connector).
    • Event Source (Business Event or background Process).

• Customer Creation/update
  • No Edition
  • PUSH (Default) 'Means that the Channel will use Openbravo's Services to create/update Customer data'
  • PULL
    • Connector Implementation.
    • background process

• Product Listing
  • No Product Listing
  • PULL (Default)
  • PUSH
    • Connector Implementation
    • Event Source (Business Event / Background Process )
    • Receive Product Updates
    • Receive Price Updates
    • Receive Tax Updates

• Promotion Listing
  • No Promotion Listing
  • PULL
  • PUSH
    • Connector Implementation
    • Event Source (Business Event / Background Process)

• Store Listing
  • No Store Listing
  • PULL (Default)
  • PUSH
    • Connector Implementation
    • Process Scheduler

• Is a Store ( In this case all other Checkboxes gets checked)
• Is a Pick-up Point
• Is a Payment Point
• Accepts Order

• Process Deliveries

• Accepts Returns
• Accepts Cross-Organization Returns

• Stock Vision
  • No Stock Synchronization
  • PULL (Default)
  • PUSH
    • Connector Implementation
    • Process Scheduler

• Orders
  • PUSH (Default)
    • Connector ( Adaptor) implementation
  • PULL
    • Connector Implementation
    • Process Scheduler
  • Automatically Book Order
  • Automatically Create Shipments
  • Automatically Process Shipments
  • Automatically Process Invoices
  • Automatically Process Payments
  • Hooks
    • On Order Create
    • On order pre-book
    • On Order post-book
    • On Shipment Creation
    • On Shipment Complete (pre)
    • On Shipment Complete (post)
    • On Invoice Complete (pre)
    • On Invoice Complete (post)
    • On Payment Complete (pre)
    • On Payment Complete (post)

• Returns
  • Same settings as orders.

Note : Keeping all configuration at their defaults should be a workable configuration

Process Design: Order Processing

Process Design: Product Listing/Synchronization

Process Design: Customer Synchronization

Process Design: Master Data Listings

Design Considerations

Assumptions

• it should be possible to send the same information (ticket etc.) multiple times, the eHUB should handle this gracefully, for example by ignoring duplicate messages
• information should never get lost
• if the eHUB receives incorrect/inconsistent information from a client then it should either reject the message, letting the client handle the error, or store the message in the eHUB with the error, so it can be solved/corrected in the eHUB.

Integration Plan Structure

Open Discussion Items

Closed Discussion Items

References

• [1] POSLog (ARTS) Industry standard - One data container for all channels.
• File:EHub-LCWD ARTS POSLog Technical Specification Vol 00 Narrative 20150203.pdf POSLog (ARTS) - Technical Specification

Category: Projects ERP