Supply chain planning as a source of information for SAP Business Warehouse

[former_member209790]

This document explains the aspects of Supply chain management (SCM) and how it serves as a source of information for SAP Business Warehouse (SAP BW).

Supply chain planning (SCP) is the component of supply chain management (SCM) involved with predicting future requirements to balance supply and demand.

Anticipating the customer demand over a period of time, evaluation of existing resources to verify where they stand with respect to the projected demand, analyzing the gap between the projected demand and available resources and planning steps to address the gap so that the demand can be met are all the core functions of Supply chain planning.

There are 3 main areas of planning involved in Supply chain planning:

1. Demand Planning: Product demand forecast is performed over a period of time which drives the sales forecast and other supply chain operations planning.
2. Inventory Planning: Planning the inventory and material stocks to meet the forecast demand.
3. Production Planning: Manufacturing of products to meet the projected demand and the raw materials needed to achieve this plan.

Demand Planning

Aimed at forecasting the demand for products.

SAP Advanced Planner and Optimizer (SAP APO) supports this business function which serves as a data source for SAP BW as well.

The actual data from SAP BW is passed on to SAP APO as historical information to assist accurate planning. The planning functions are configured within SAP APO to produce the forecast data. The forecast data is then brought into SAP BW to be compared with the actual data from SAP ECC.SAP APO can be setup as a source system to SAP BW and vice versa.

The planning information can be extracted to BW using standard data source 0APO_DP_FORECAST_01 which is a delta capable data source. The DSO Planned Sales Quantity (0APO_DS05) is used to stage this data into Info cube overall sales planning (0APO_C07) for reporting.

Production Planning

Aimed at planning the right quantity with the right schedule to meet the projected demand.

When a production order is created various operations and activities are planned for that order. Upon execution of the production order the quantities and the actual timelines are captured as a part of transaction data. This actual execution data is then compared with the planned production data to measure the variance.

Inventory Planning

Inventory management deals with the complete flow of material right from the procurement for raw material to the final delivery of the finished good.

2LIS_03_BX - Stock initialization for Inventory management data source provides the initial snapshot of the stock which can be used as a base to calculate the inventory.

The initialization of this data source is done via Tcode MCNB after which the data can be transferred into BW via an initialization info package.

2LIS_03_BF – Goods movements from Inventory management data source captures material movements on the basis of table MSEG. The data is captured at the material document and document item level of granularity for different movement types. The extraction is also dependent on the process keys that are used to identify each record.

2LIS_03_UM – Stock revaluations data source is used to update the correct values of revaluated inventory from SAP OLTP to SAP BW. It updates only the stock values not the stock quantities.

The data from all three data sources are consolidated in the Info cube Material Movements 0IC_C03.It contains stock initialization data load from 2LIS_03_BX and then regular delta loads from 2LIS_03_BF and 2LIS_03_UM.

Inventory Reporting

Inventory management with non-cumulative key figures

Suited if the reporting requirement is to report the historical stock balances on a daily level.

The query-runtime is excellent. To reduce the data volume in the fact table, it is better to use the non-cumulative key figures.

One of the most important aspects of inventory data model in SAP BW is the concept of non-cumulative key figures. Unlike sales or procurement related reporting which is done for a period of time the inventory reporting is done for a point of time. So we cannot simply aggregate values for reporting. In inventory the data is stored as an inflow or outflow and the inventory is calculated at runtime by adding or subtracting the inflow or outflow values from the initial stock.

The Non-cumulative cube 0IC_C03 is loaded from PSA for Stock movements. Daily stock balances are not stored in cube but calculated at runtime.

0RECORDTP For Inventory management with non-cumulative key figures

Technically, only non-cumulative changes (movements) and the stock referring to a certain point in time (so called reference points or markers) are stored in the fact tables. In order to distinguish between this two kinds of values the technical info object 0RECORDTP (part of the package dimension) was introduced.

For movements we have 0RECORDTP=0, for the reference points 0RECORDTP is always equal to 1 and the time reference characteristic is set to 'infinity' (e.g. 0CALDAY = 31.12.9999).

In case the cube is totally compressed and you are only interested in the current stock values of a certain material, the query can only read the marker and hasn't to carry out calculations using the inflow and outflow.

By default the transaction LISTCUBE only reads data records where 0RECORDTP=0! Hence, if you want to get the reference points displayed you need to restrict this info object explicitly to 1 (or interval [0, 1]).

Inventory management with Snapshots

The reporting requirement is to report the historical stock balance on a monthly level of all materials.

The Snapshot loads data for every key figure and granularity of the Info Cube. This can end in a very high data volume and batch process time. The movements are not stored in the Info Providers. Due to the high amount of movements the query-runtime is bad. A retrace of one special stock is not possible.

In snapshot model we have to perform aggregation in DSO based on key and then move the summarized data to cube. Also, once a month we have to calculate stock balance and copy it as opening balance for new month. Monthly stock balances are stored in cube.

Both of these models can be implemented in parallel.