Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
cancel
Showing results for 
Search instead for 
Did you mean: 
Domnic
Product and Topic Expert
Product and Topic Expert

Using SAP Integrated Business Planning as a Supplier on the SAP Business Networks


 

Suppliers make a significant contribution in Supply chain processes. SAP Business Networks facilitate exchanging of forecast requirements and commitments for these using interfaces graphically as well as programmatically. Standard interfaces can be leveraged to integrate Supply chain planning solutions such as SAP Integrated Business Planning.

In this blog, I like to explain how a Supplier can use SAP Integrated Business Planning to automatically download forecast requirements from his customer who can be a Buyer on the SAP Business Networks. For this document exchange we use SAP Cloud Integration as a middleware.


Figure 1. An example process that can be used by a Supplier to exchange Forecasts and Commits

Usually, the process starts from the Buyer’s actions. He would create a Demand Plan and have a forecast which needs to be fulfilled by his Supplier. As an illustration, imagine the Buyer is a Bicycle manufacturer. He plans to produce 1000 pcs of a specific mountain bike over the next 3 months before summer. For this, he outsources certain parts of the Bicycle from a few of his suppliers. Some could be the wheel fork, brakes, gear assembly, etc. Imagine he has a favorite supplier who is a very trustworthy business partner over the decades – suppling gear assemblies for different bicycle configurations. We call him Supplier A.

The Buyer creates a demand plan for his bicycles and sees that he likes to order 1000 pcs of a specific gear assembly from Supplier A. The Buyer would like to use SAP Business Networks as a platform to exchange his requirement details as well receive commitments, electronically from his favorite supplier A. This specific supplier uses SAP IBP as his planning tool. He likes to get his requirements from customers directly into his SAP IBP instance and work with the data.

In our above scenario, the Buyer would send a Demand Forecast as a supply chain plan to the SAP Business Networks. There are few blogs and documentation about how this can be done from SAP IBP directly (if a Buyer would use it). In the SAP Business Networks this data would be received as a Product Activity Message. There must be an active supplier enablement done as a pre-requisite on the Business Network configuration pages between the Buyer and the Supplier A.

Once this data is available on the SAP Business Networks, it is immediately available to the Supplier’s inbox. This data can be downloaded using the get pending request REST API provided by the SAP Business Networks. I am using the SAP Cloud Integration as a middleware to automate this process.

 

Get Buyer’s forecast.


Before the Supplier A could download this data, he needs a place in his planning area to store this data. In SAP IBP all time relevant planning details are stored as Key Figures. These are all organized in a planning area. Supplier A would need to create a key figure to store this data – I called it BUYERFORECAST. This is a key figure which is based out of 4 main attributes also called as root attributes.


Figure 2. an Example Key figure definition for storing Buyer Forecast in IBP


 

The root attributes considered here are customer ID (who is actually the Buyer on the SAP Business Networks), a location ID to which products needs to be shipped and then we have the Product ID which is the gear assembly the Buyer wants to order from Supplier A. There can be many more attributes which can be relevant for the supplier. They can be added as required.

Supplier A can download the Product Activity message using a sequence of steps. First is to get an internal pending queue ID. This ID can be requested via a REST API with a cXML payload that specifies the Buyer Ariba Network ID and the last used time stamp. If there are documents pending to be downloaded, the API would respond with a pending queue ID. This ID is then later used to download the actual Product Activity documents. Thes document can contain the Buyer part ID which would be known by the supplier, A deliver location, time details when this part needs to be delivered and the forecast quantity from the Buyer for this specific part. The forecast quantity would be the actual value that goes into the BUYERFORECAST key figure in SAP IBP along with the Product ID, Location ID and the time stamp.

The iFlow shown below makes a call to get the pending queue. With the queue ID, it would then download 5 documents which are related to forecast. The Number of documents that needs to be downloaded can be set in the queue id request. The request to download the queue would contain the queue ID. The response would be a Multi-part-MIME document which has 5 documents in cXML format, separated by the message de-limiter. Each of these documents are then processed individually in the iFlow. They can be converted to JSON formats using very simple transformations.


Figure 3: iFlow to pull Product Activity message and store in SAP IBP using OData APIs


The Product IDs and location ids can be mapped to Supplier A#s product relevant details. A JSON which follows the API definitions of SAP IBP’s OData interface for writing Key figure data can be created in one of the steps in this iFlow.  Calling the OData APIs would then store the data in a staging table in SAP IBP. After burn procedures can be triggered to process the data, after all the details are written to the staging tables. A Separate API can be used or the last message can include the ”DoCommit” flag to trigger the after burn.

Update Supplier commit.


Once the data is in IBP, the planner at Supplier A can view the data using Excel in a planning view. He has the possibility to either agree on the schedule and quantity or he has the possibility to adapt the forecast requirement based on availability. In either case, the Supplier would have to inform the Buyer about the commitments. I choose to store this data in a separate key figure called BUYERCOMMIT. The root attributes can be the same as the BUYERFORECAST key figure. This way, the supplier has the chance to see what was requested and what was committed.

We use SAP IBP’s OData interface to read data this key figure data from IBP. This data is transformed to cXML structure and then posted to the SAP Business Networks as a Product Replenishment message. The iFlow below is a screen shot that does this process.


Figure 4: iFlow to read key figures from SAP IBP and post them as Product Replenishment message


These iFlows can be scheduled via a timer on the SAP Cloud Integration suite. It is also possible to call them via REST end points provided the sender of these flows are using HTTPS adapter. In that case one would need the oAuth credentials from the sub-account in BTP.

The flexibility of SAP IBP allows a Supplier to define his own Key figures which can be used to store forecast data. Such forecast data can be generated by a planning system on the Buyer’s side. Using SAP Cloud Integration, it is possible to transform different payload types and message types into standard interfaces which are available on SAP Cloud offerings such as SAP IBP and the SAP Business Networks. Here I have given an idea where a supplier can leverage SAP IBP to automatically download forecast data from his buyer as well as send his commitments. The integration content used in this example is available for download as a sample community content: API Hub Doc, Github Sample repo

 

Domnic Savio Benedict

Product Expert, SAP Integration Business Planning