Getting Sales Orders into SAP IBP for Demand
In order to create a forecast in IBP, you need a meaningful sales history. In all sample planning areas and showcases, this is just one key figure: "Sales History". The first go-to approach for generating this key figure is BW: sales reporting requirements need historic sales data as well, so you might take the same for creating a forecasting sales history. However, there are companies that are not using BW. Or there are companies using BW, but have plenty of non-technical reasons why connecting it to IBP is somewhere between impossible and highly unlikely. Additionally, in S/4-HANA the reporting strategy from SAP is: you don't need a BW if you want to report on operative data from S/4-HANA. So in consequence, there must be a way to generate a sales history directly from S/4 data.
Having a monthly sales history key figure on material/location or material/location/customer level is nice, but you might want more: Future business requirements might require modifying the sales history to generate different customers, locations or materials. In IBP terms, this is called "Realignment". IBP is quite powerful when it comes to these capabilities, so you might want additional attributes in your data that allow you to retroactively change your history data from the perspective of future business models, such as customer countries, regions, additonal org elements, routes, hierarchies, classifications - whatever. Usually, that data is on the level of each individual sales order. So it might actually make sense to copy all individual sales orders into IBP, so you can use the data from old sales orders to perform future realignments directly inside IBP. In a second step, this data is then aggregated and placed in the infamous "Sales History" key figure on the actual planning level relevant for forecasting.
The data model
In S/4-HANA (as in all SAP releases before), a sales order has three levels:
- Schedule Lines
There are different quantities that might be interesting for planning purposes:
- Requested Quantity
- Confirmed Quantity
- Delivered Quantity
- Invoiced Quantity
And there are several dates that are usually more or less helpful - depending on how the sales process for a company or the industry actually works:
- Order creation date
- Delivery date (when the customer receives the goods)
- Material availability date (when the goods are ready to be shipped)
- Goods-Issue date
- Invoicing date
Dates and quantities are on the level of the individual schedule line, so we need a data model that is on that level. Remember that in a HANA database, it is no longer required to normalize the data model as it was common when relational databases were invented, therefore, the repeated header and item data can go into the same IBP master data type as the rest. The "attribute as key figure" feature allows us, to nicely make key figures from order quantities at one or multiple dates as present in our data.
But there is an important issue: which key fields should this master data type for sales orders have? Sales order, item and schedule line number are natural candidates, but there is a technical constraint here: if you want to use "attributes as key figures", an attribute that is key field of its own master data type - such as material number (PRDID) or location number (LOCID) - can not be a non-key field of another planning level. In IBP releases before 2211, this was resolved by having a different number of key fields in the master data type and its connected planning level. Since 2211, this is no longer possible. Therefore, only two alternatives exist:
- You make key fields of separate master data types (usually PRDID, CUSTID and LOCID) key fields in the sales order data type as well. This has consequences if a sales order changes during its lifetime: once someone changes e.g. the plant in the sales order, the entry in the master data table doubles: one for the old plant and one for the new plant. The interface to S/4 must therefore recognize such changes and put the quantities on the old record to 0.
- You name the key fields of separate master data types differently in the sales order (e.g. ORD_PRDID, ORD_CUSTID, ORD_LOCID). In order to get the key figures onto the right levels to be able to copy them to their correct counterparts, an additional planning level, an attribute transformation for each key attribute and a set of additional order key figures is required here.
Both approaches are possible and require considerable effort. As we will see later, the choice of mechanism is heavily dependent on the technology used to extract sales orders from S/4-HANA. Currently, not all mechanisms are capable of providing all data required to detect changes correctly.
Extracting the data
Data transfer between S/4-HANA and IBP for Demand is implemented as ETL (Extract-Transform-Load) process using the CI-DS (Cloud Integration for Data Services) tool. CI-DS can use several methods of extracting data from S/4:
- Read the database directly
- Use a BW extractor via the ODQ framework
- Use an individually generated ABAP program that can contain user-defined code to implement any method of data extraction.
Reading the database directly for sales orders might become complicated because of the huge amount of sales order data usually present in a productive S/4-system - even if we could use a CDS-view containing the different involved tables that would contain all required fields in one step. Therefore, a mechanism that would allow us to transfer only changes would be helpful. Fortunately, SAP offers now two generations of extractors that do exactly that - albeit with different levels of comfort:
The classical extractor for sales order data on schedule line level is named
2LIS_11_VASCL. You can activate and control it using transaction LBWE and initialize its data with transaction OLI7BW. This extractor contains all fields from header, item and schedule line levels that would under normal circumstances be required in IBP. In case, fields are missing, these can easily be added in two ways: already during posting of the statistics data through a user-exit in function module '
MCV_STATISTICS_ORDER or through a BADI that is called during the extraction process. For consistency and performance reasons, it is advisable to use the first method, although the process for adding additional user-defined partner functions is a little bit more complex due to a missing parameter inside the user exit.
In case additional quantities at different stages of the sales process are required (e.g. open orders and deliveries), an additional extractor
2LIS_11_V_SC is available that will provide these quantities on top. It makes sense, however, to send the data from this extractor directly into key figures. The biggest advantage of the classical extractor are its simple extensibility and its full delta capabilities including before- and after-images. This means, that for every change of a sales order, the situation before and after the change is transferred, thereby making it possible to use the data model with the extended set of master data key fields.
With S/4-HANA comes a new extractor technology: CDS-Extractors. Built upon CDS-views, these extractors add basic delta capabilities on top, however, before- and after-images are not supported. The CDS-Extractor for sales order schedule lines is named
C_SALESDOCUMENTSCHEDLINEDEX_1 and is available since S/4 HANA 2021. To make this extractor visible for CI-DS, you need to create a separate datastore setting the field "Context" to "ABAP_CDS". Usage of a CDS-extractor requires you, however, to implement the attribute transfomation indicated before, otherwise changed key fields will not be reflected correctly in your data.
As we have seen, the structure and layout of our IBP planning levels and master data types is dependent on the capabilties of the extractor technology used to extract the data from S/4. Of course, making the argument that it may be easier to get the data from BW only shifts the decision which extractor to use over to other people, but it doesn't get rid of the problem in general.
I expect further development from SAP in this area and I assume, that in a not too distant future, this article may get updated and another method for getting your sales orders into IBP can be introduced.