Outlining the Functional Requirements

These solutions offer modular services that are native to other SAP applications and systems, such as SAP S/4HANA, which is your backend system. This is what we refer to as a composable suite, where you can select needed applications or services. However, it's not necessary to have SAP S/4HANA as your backend system, as it's possible to use non-SAP systems, as long as they adhere to API structures.

These various applications work together within the Composable Suite to form business processes united by various interfaces, inheriting microservices so they can communicate and integrate with multiple third-party systems. Our backend systems use the SAP S/4HANA to capture orders for standard SD processes, as well as to collect product data and subscription products for SAP subscription billing.

Systems communicate through the BTP Integration Suite, which includes our Cloud Integration, allowing us to simplify the data integration, with often little configuration needed beyond updating different endpoints. We require master data, customer data, and sales orders, which come from SAP S/4HANA or third-party systems, and can be integrated with a commerce system.

We see orders coming into SAP Order Management foundation validated against the master data from our backend system. Once in SAP Order Management foundation, we collect data, orchestrate it by sourcing information, split orders based on physical products or assortments, and send them back to third-party consumers via the SAP Event Mesh. We can also use the Event Mesh to send updates to e-commerce systems and notifications to customers.

SAP Order Management foundation also provides business configuration applications, enabling you to see all inbound orders, their statuses, and all header and item level details. We also offer standard content and analytics capabilities that provide specific reporting capabilities.

Remember, all of this can be made accessible to non-SAP systems, with the Integration Suite streamlining and simplifying all system communication via API's.

Now, if you have any questions, don't hesitate to ask. Some specifics will be addressed later in upcoming slides or can be answered in follow-up sessions. This overview should provide a clear understanding of how various systems within the SAP architecture can integrate and communicate with each other to form a complete business process.

• In-Store - Brick and Mortar retail location
• Commerce - Where you are selling your products on your website
• Market Place - Where you sell your products on a 3rd party site (Amazon)
• We have our different order capture systems
  • POS for In-Store transactions
  • Commerce Platforms to take online orders
    • Phones, tablets, PC's/Laptops

Data is exchanged between the order capture system to the backend system

• We do this with SAP Integration Suite
  • Convert data from one format to another (JSON to XML)
  • Map data from one field to another
  • Apply any calculation logic
• Send data from the source to the format needed by the receiving system

• On the far right side we have our product master data, transactional data (sales orders) coming from S/4H
• On the bottom we get our Business Partner data vis MDI from S/4H
• We have subscription products, price rates and subscription orders coming from SAP Subscription Billing
• This will ensure we can do proper MD validations on inbound orders coming from the sales channels

• View All Orders
• Business Configuration
  • Integration Settings
  • Business Configuration

• SAP Analytics Cloud
• Standard Content to access SAP Order Management foundation and have predelivered stories, dashboards

Automatic change data event service to send updates to downstream systems

Moving forward, we will be discussing the end-to-end process in the SAP system. Utilizing the consumer journey, we will sequentially examine the necessary events, systems, and results that support this journey.

An example of this is the SAP Commerce's process of capturing a customer's order. The customer finds an item, adds it to the basket and a price is provided.

Omnichannel Pricing and Promotions, another cloud solution, supports this journey by determining the appropriate promotions and pricing for that customer and communicates this back to them. This ensures the right price at the right time for the customer.

Before completing the purchase, the product's availability within our supply chain is checked and the best storage strategies based on availability and cost are utilised.

When they decide to make the purchase, the customer logs in and address validation from third-party business services are used. Several third-party services are integrated from this point, such as Master Data Management (MDM) to create and distribute business partners.

After payment is made and authorized, the order is processed through the SAP Order Management Framework which centralizes all order-related information.

By validating the availability of products and selecting the best delivery options, we can ensure the order is fulfilled efficiently. The order can be divided based on physical and subscription products and routed accordingly.

Finally, once the purchase order is put through, the SAP system takes over with the sales order generation, sending logistics information to the warehouse and transportation services to ensure smooth and accurate delivery to the customer.

Throughout this process, updates are made in the OMF, available via standard APIs or published through Event Mesh.

Ultimately, this end-to-end process is about ensuring a smooth, efficient and accurate customer journey, from request to delivery. Each stage of the journey is supported by different solutions, integrated and coordinated to achieve the best outcome.

Moving forward, we will explore the requirements for master and transactional data. We have two potential product classifications; physical products and subscription billing products.

Physical products, which include tangible items purchasable on an e-commerce platform, require details such as name, language, product type, category, group, price, and pricing groups. Utilizing the seamless integration, we can support these requirements and cater to both generic and variant items, such as sell sets and displays.

In contrast, subscription billing products are more service-oriented, for example, a music subscription app or any other app providing service rather than physical goods. This classification aligns with service materials or subscription products.

To integrate these, we match it with customer or business partner data, including customer IDs. Additionally, we need transactional data, particularly sales orders for these procedures.

Physical products and Retail Products

• Name
• Language
• Product Type, Product Category, Product Group, UOM, AUOM, Pricing Group
• Generic/Variants
• Sales Sets
• Displays

Subscription (Billing) Products

• Digital Service
• App

Customer / Business Partner

Personal

At a high level, we receive orders in SAP Order Management foundation and process them in SAP S/4HANA to generate sales orders and related documents. Their updates must then be fed back to SAP Order Management foundation to keep our order activities up-to-date. As we delve into the details, we'll explore the backend systems and SAP S/4HANA integration points.

The key components here include product data and sales orders data and their specific transmission methods through SAP S/4HANA. We can transfer standard product information like product data, language, product type, and more, from SAP S/4HANA using iDoc. Two relevant examples are Matmas and Artmas, the latter being particularly relevant for retail public master data.

Sales order updates are sent via a SOAP API from SAP S/4HANA to cloud integration, and further forwarded to SAP Order Management foundation. Regarding new inbound commerce, it originates from commerce to SAP Order Management foundation and is transmitted via an HTTP call to the iFlow. Whenever communication needs to occur from an industry cloud solution to an on-prem or backend system, it must pass through Cloud Connector to expose the sales order service externally.

In brief, iDoc here refers to Matmas or Artmas, and we have standard iFlows for the sales order API which is also known as the A2A API.

• Material - MATMAS
• Article - Retail: ARTMAS
• Attributes: Product type, product category, product group, UOM's, pricing group
• Exclusions: Variant Config

A2A SOAP API

In this section, we'll delve into the functionality of customer business partner integration points. Here, you'll learn that business partners from SAP S/4HANA are relayed through the Data Replication Framework (DRF), a component of MDG that, despite its age, is still vital in transmitting data. Keep in mind that business partner data is communicated via a SOAP API and subsequently integrated into the SAP MBA Master Data Ingestion service, available on SAP BTP.

Following this, the customer data from our business partners is forwarded to SAP Order Management foundation - an indispensable step for order processing which requires accurately validated customer data. This process also involves key mappings, which align your customer IDs in SAP S/4HANA with data originating from your commerce system. This is an essential function to ensure data consistency and accuracy across different platforms.

In this section, we will discuss the integration points of SAP subscription billing. From SAP SAP Order Management foundation, we retrieve data from SAP subscription services via APIs. We call these points from the SAP Order Management foundation to obtain product data, which we then use in the product flow, extracted from subscription billing.

There are three crucial data points from SAP subscription billing:

1. Subscription Products: These can be akin to services like music subscriptions.
2. Pricing and Rate Plans: These could vary, for example, a monthly rate versus an annual subscription.
3. Updates to Subscription Orders: This information needs to be available in the SAP Order Management foundation for order activities.

In terms of master data requirements, we require information about the product, customer, or business partner. We also need transaction rates like sales orders. Once we have this information in the SAP Order Management foundation, we can process customer orders from the sales channel. Actions may include receiving the original order request from third-party systems or e-commerce platforms, thereby enabling the creation of a central order in OMS.

In the workflow of an order, we initiate with an inbound order received at SAP Order Management foundation. Paramount is the integrity check like duplicates verification to eliminate repeated orders. Additionally, key mapping is conducted to align customer IDs between your e-commerce and backend systems. Concurrently, any network glitches are handled either through auto or manual relicensing.

Another significant aspect is the order hold policy, which can be exercised if you want to keep the order on standby for a certain period. A typical example is the order cancellation policy prevalent in the APJ region like certain Asian countries where an order can be put on hold for 30 minutes.

Payment authorization includes consumers' remorse or cancellation period, granting customers about 30 minutes to revoke the order. An order can also be modified while in process. This allows for adding, updating, or deleting items, which is generally conducted via APIs.

If for any reason an order needs to be canceled, it can be done from a centralized repository or application. This overview outlines the entire order process for better understanding and effective management.

• Duplicate Order Check
• Key Mappings (for example Customer ID)
• Retrigger

• Add Items
• Update Items
• Update Quantities
• Delete Items

• Hold Order for specified duration
• For example: Order Cancellation Policy

Moving onto sourcing and availability, this refers to the processes set in motion when a customer adds an item to their cart. The main goal is to determine the most efficient means of fulfilling the order to ensure a great customer experience. For instance, deciding if the customer will buy online and pick up in store, or get it delivered to their home.

While SAP Order Management foundation doesn't handle sourcing and availability directly, it does accommodate it if connected with a third-party sourcing tool. You might already have this functionality through your e-commerce or OMS platform, or through integrated order management.

Sourcing decisions are influenced by factors like availability, DC or store capacity, varying costs, or delivery times. From our conversation with Biagio, we understand that through the configuration of different sourcing strategies, we can cater to any combination of these factors. Upon receiving an order, SAP Order Management foundation sends a request to either third-party sourcing or OMSA to identify the most optimal fulfillment method, and this information is then relayed back to OMS, which executes further downstream processing as per the chosen orchestration process.

We can establish a single order or split various orders based on certain criteria. We also have the capability to implement rules for splitting orders as needed.

Let's assume you're selling two types of physical items, say shoes and clothes. You would need to formulate unique fulfillment strategies for each.

For instance, when dealing with shoes, you might have a dedicated distribution center (DC) and hence, a separate fulfillment plan. This implies that for every shoe order, the fulfillment is enacted by warehouse one. This also involves the creation of the corresponding sales document.

Similarly, for apparel or other assortments, you might operate from another DC, meaning items can be fulfilled from warehouse two, necessitating the generation of a unique sales document. Thus, the type of product can determine warehouse operations and sales documentation practices.

When we receive sales orders, we initiate our standard integration procedure. This process includes several key steps. Firstly, we create the sales order in the ERP system. Next, we generate an outbound delivery document which is forwarded to the Warehouse Management System. This document serves as a pick ticket for warehouse associates. They then collect the ordered items from the storage area and prepare them for dispatch at the designated dock. Once ready for shipping, a notification is sent to the shipping carriers for pick-up and delivery to the customer. This entire workflow is all facilitated through well-defined integration points across various systems and services.

To smoothly coordinate various activities and updates, we aim to integrate all systems using Order Management foundation. This approach eliminates the complexities associated with multiple systems handling similar tasks and ensures a streamlined exchange of information.

A variety of standard order activities, such as creating, picking, shipping, tracking, and delivering can be harmonized this way. For instance, we can directly send status updates to SAP Order Management foundation, offering a consolidated view of the order statuses.

Additionally, it's viable to incorporate a payment authorization system for real-time payment status updates. Similarly, we can gather shipment and delivery status data from carriers directly.

Next, all accumulated data is forwarded to the SAP Order Management foundation. As the central hub, the SAP Order Management foundation offers versatile ways to interact and retrieve order-related data. Coupled with creating and publishing events through Event Mesh, this system enables integration with various consumers like email or SMS systems or other service test systems.

This sort of alignment enriches the information available, strengthening our capacity to update and offer enhanced upstream services.