Understanding Business Integration Settings

In our analysis of business configurations, we identify three key elements, particularly in the application set-up. This may represent a shift, as we transition from SAP S/4HANA or ECC's customizing screens, baddies, and bappies, to a simplified cloud-based system, making use of both UI and APIs. You'll note these changes when we explore the OMF application.

Subsequent sessions will delve into the system structure, backends, and integration points based on your queries. We will specifically discuss integration patterns as they've caught your attention.

We will further discuss business configuration set-up which involves defining the market (which could be a sales channel), setting up distinct rules for managing inbound orders, and confirming your fulfillment strategy. The market ties to a sales area, requiring traditional data such as a sales org, distribution channel, etc.

You will come across rules regarding order management integration or strategies for order division for physical items and subscription products. In conclusion, configuring your market, defining the rules, and fulfillment strategy are the main focuses of the configuration process.

We're examining the integration settings of an internal system used by our services and implementation group for testing purposes. While some options may appear enabled or disabled due to this testing context, our focus will be on discussing the full range of available options.

The first step in our integration settings is to decide whether to enable the SAP subscription billing system. Following that, we examine if we're to integrate with SAP Event Mesh, a process that involves a simple 'yes' or 'no' decision but also includes some definitions. Similarly, decisions must be made about enabling areas such as Order Management Sourcing and Availability.

You'll notice in these integration options that there are three aspects you can easily define and configure. Those new to industry cloud solutions may find this different from other SAP applications, specifically the back-end systems of SAP S/4HANA ECC. This constitutes a shift in paradigm, but one that provides a unique and effective approach to configuration.

Moving on to market configuration. We earlier noted that there are seven fields to configure here: general information, sales area, orchestration, delivery options, sourcing, transfer hold and one-time customer.

Identifying the market begins with defining the market ID. The ID we used internally may look like a serial sales area distribution channel, or possibly a division. However, you have the liberty to choose any market ID that fits your naming convention internally.

Next, we define the marketplace, which could mean a US market, an Amazon marketplace, or any other sales channel or market area. The important part is that the name you choose should have a mapping back to your sales area as defined in your ERP or SAP S/4HANA system.

Then we provide vital information like our sales area. Note that this is not open text - we have to ensure precise alignment with the systems we're integrating with, particularly with a key fulfillment core like SAP S/4HANA ECC. For example, if we're including our sales organization, distribution channel, and division, those values must match what is defined in our sales area within the SAP S/4HANA.

We also set different orchestration rules and IDs, which can be decided based on item type, site type and key mappings.

Continuing with our market configuration, we have the ability to define various delivery options such as standard delivery, express delivery, overnight shipping etc.

If we choose to enable integration with a sourcing and availability engine like SAP Order Management for sourcing and availability, a unique strategy ID can be inputted here. This ID corresponds to the sourcing strategy created in SAP Order Management for sourcing and availability, which considers parameters like availability, cost, warehouse capacity etc.

We also have the provision to enable a 'transfer hold', whereby you can set a defined period during which an order stays in this hold area before being dispatched into order orchestration and the fulfillment system.

Lastly, we have the 'one-time customers' field where you input the relevant customer ID.

From a user interface perspective, and as you can see, setting up configuration and defining strategies is quite straightforward, with the ability to make it as simple or complex as you want.

We recommend updating business configurations through the application UI, or alternatively, through an API call.

Following an industry cloud solutions approach, we adopt the agility of a CI-CD model (continuous integration and continuous development). This means we have a faster release cycle that doesn’t adhere to the traditional on-prem model of version releases every six months. For instance, new features may be released every two to four weeks.

Regarding delivery options, you can add elementary options as shown. It's as simple as adding different IDs and descriptions.

Next, we have the order activities, divided into standard activities and system activities.

Standard activities are pre-delivered within the application and include statuses such as 'ready for pickup', 'delivered', 'picking started', 'fulfillment', 'rejected', 'shipped' and 'picked'.

System activities, on the other hand, are automatically orchestrated in OMF between the OrderStatuses API and the OrderActivities API. In configuring any activity, you define the activity name, description, and decide if it would be enabled, published, or displayed in the activities list in the application.

While these standard activities are readily available, the system also allows for the creation of new or custom activities. These can be connected to various integration points within other upstream or downstream processes or applications.

We then move on to our orchestration settings where we establish our fulfillment channels. After defining your market and relevant rules, everything is mapped back to this fulfillment channel.

You create an ID for each channel. For instance, you might have a main channel, a physical channel for physical inventory products, and a subscription channel. Each of these channels has associated rules.

An orchestration rule ID is set up, specifying the path for item type - in this case, physical items. This would belong to the physical channel. As we proceed with the demo, the application of mappings will be evident.

We also have the provision for a default rule that is either specific to a channel or applicable to all markets. If it was for every single market, we would set the default rule for it as 'yes'.