This Wiki page is to provide necessary information about forecast consumption in APO system. Some basic concepts, customizing settings and system logic is explained.
Topics included in this page:
- Basic Concepts of Consumption
Explain basic concepts about forecast consumption.
- Customizing Settings
List necessary customizing settings and relevancy.
- Forecast Consumption in Product View
View consumption result in product view, Element tab vs. Forecast tab, Overview tab vs. Detail tab.
- Technical Points of Forecast Consumption
Check this part if you want to know how to debug and trouble shooting of forecast consumption.
<Basic Concepts of Consumption>
What is consumption
- Planned independent requirements are created.
- Customer requirements come in, which consume planned independent requirements according to the requirement strategy and consumption settings (consumption mode and consumption periods).
- Procurement happens against the requirements.
- Goods Issue (GI) is made for customer requirements. Customer requirements disappear and withdrawal quantities are logged.
** The famous picture
Dates in Consumption
- Date of Planned Independent Requirement -> Available Date / Period
Use forecast's available date (or period) to calculate on which date the forecast is available for consumption.
- Date of Customer Requirement -> Available (Requirement) Date (Not delivery date)
Use customer requirement's available date (e.g. sales requirement's available date) to calculated which date's forecast to be consumed.
Delivery date or other dates in sales order's schedule line are not used / considered in consumption logic.
Quantities in Consumption
- Quantities of Planned Independent Requirement–Planned Quantity : The original forecast amount for which the forecast was created.–Assigned / Allocated Quantity : The quantity in the forecast that has been consumed by other order categories.
This quantity is not stored, it is calculated at runtime.–Open (Planned) Quantity : The planned quantity that has not been assigned or withdrawn from stock.–Withdrawal Quantity : The quantity that has produced / procured and for which a goods issue has been posted in ECC.
- Quantities of Customer Requirement
Requirement Quantity (Not confirmed quantity)
- If no consumption periods have been maintained, only those forecasts are consumed that lie in the same planning period as the availability date of the customer requirements.
- The assignment of customer requirements to planned independent requirements is carried out dynamically. This means that if requirements are rescheduled, the assignment is deleted and redefined.
Consumption Mode and Consumption Period
Consumption Mode and Consumption Period is defined in Product Master (T-code: /SAPAPO/MAT1), "Demand" tab, "Requirement Strategy" sub tab.
They can be CIFed from ECC system and can also be set/changed in APO system.
Controls the direction on the time axis in which the system consumes the forecast.
- Backward consumption
- Sales orders consume forecasted quantities that lie before the requirements date.
- Backward/forward consumption
- Sales orders consume forecasted quantities that lie before the requirements date. If the actual demand is not satisfied, the sale orders then consume forecasted quantities that lie after the requirements date in order to satisfy the remaining demand.
- Forward consumption
- Sales orders consume forecasted quantities that lie after the requirements date.
- Weekly or monthly consumption
- Sales orders consume forecasted quantities that lie in the week or month of the requirements date. The system does not consider forecasted quantities in other periods.
- User-defined consumption
- Sales orders consume forecasted quantities according to your own consumption logic implemented via the Business Add-In (BAdI) /SAPAPO/DM_BADI_CSP.
** Monthly Consumption, Weekly Consumption, User-defined Consumption is valid as of SCM 7.01.
Defines the consumption period (in calendar days) for backward / forward consumption, based on consumption mode defined.
In backward consumption, sales orders, dependent requirements or material reservations consume forecasted demand that lies within the consumption period and before the requirements date.
In forward consumption, sales orders, dependent requirements or material reservations consume forecasted demand that lies within the consumption period after the requirements date.
** The consumption period is in calendar days not workdays. Since SNP and PP/DS can use different calendars, it is not possible to define a calendar for use with consumption. This may lead to unexpected results.
Defines how production quantities are planned in APO, and how forecast is consumed by other orders.
Requirement Strategy Definition
- CategoryDefines the forecast's order category which could be assigned / consumed. Notice that the category specified here must with "FORECAST" type defined in customizing setting of ATP categories (t-code: /SAPAPO/ATPC03).
- PIR SegmentSpecifies to which segment the system assigns the planned independent requirements.
- Assignment ModeSpecify to which segment the system assigns the customer requirement. Determines how customer requirements consume the PIRs and whether final assembly is accounted for.
- Category GroupDefines which categories (of customer requirement) consume the PIRs.
** Category group is defined in t-code /SAPAPO/SNPCG. The setting "Quantity Type" is not taken into account in consumption scenario. "Pegging relevant quantity" is always used in consumption calculation.
** We do not support the scenario where "Delivery (ATP category BR) consumes forecast". Delivery is normally considered as other type of process than customer requirement. Please do not include BR in the category group. Even when delivery is created, forecast should be still consumed by the sales order.
- Planning Version Defines valid version.
Requirement Strategy Assignment to Product / Location
(T-code /SAPAPO/MAT1 )
Assign the requirement strategy to location product master, "Demand" tab, "Requirement Strategy" sub tab, "Proposed Strategy" field so that forecast consumption can take place.
** Requirement Strategy in product master can be CIFed from ECC system (mapping rule as below), and can be set / changed in APO system.
Strategy ECC APO Remarks Make-to-stock 10 10 Planning with final assembly 40 20 Planning without final assembly 50 30 Planning without final assembly for configuration materials 50 35 From SCM 7.0 Planning with planning product 60 40
SAP Supported Requirement Strategy
Not all combinations of PIR Segment / Assignment Mode is supported by SAP. Always check below chart when you set up a consumption scenario.
Here only the combinations with green color are supported by SAP.
Combinations with yellow color may work sometimes, but SAP does not guarantee that it works every time and SAP does not provide support to them.
Requirement Class (ECC) and Check Mode (APO)
Except for the above settings, "Allocation Indicator" setting in requirement class at ECC side is also very important.
- The Requirement Class is transferred to APO with the sales order, and saved in liveCache as "order status".
- In APO, the Requirement Class has to be defined as Check Mode (same identifier).
- In the definition of the Requirement Class, the assignment mode (alias allocation indicator) and the Requirements reduction indicator is maintained.
(* Requirement Reduction indicator is necessary for strategy 10 if you want reduction to happen for strategy 10.)
- The APO Check Mode’s assignment mode and the Requirement Class allocation indicator should be the same for consistency of the systems behavior.
- The assignment mode of the Check Mode found by reference of the Requirement Class has to be the same as the assignment mode of the APO strategy. Otherwise, this sales order does not consume.
- The check mode’s assignment mode is stored with the sales order data in LiveCache and is the basis for all the future consumption recalculations with this sales order. Therefore, changes on R/3 side on strategy or requirement class do not affect the APO-data. Deletion and re-issue of the sales order is needed.
Common Customizing Issues for Consumption not Happening
Allocation Indicator or Requirement Class
In many incidents where "consumption does not happen" issue was reported, a common reason is allocation indicator of the requirement class in ECC is not set correctly, or the allocation indicator is not transferred to APO correctly. So if all other settings are OK, but consumption still does not happen, you can go to product view (t-code /SAPAPO/RRP3), load the product/location. Then you enter GT_IO in the command field, press enter, you'll be led to the page displaying order data in liveCache.
Only those customer requirements with correct order status can consume forecasts. e.g. if you're using strategy 20, order status of the sales order (category BM) must be "1", so that it can consume forecasts.
Strategy of Forecast Orders
Another possible reason for "consumption does not happen" issue may be forecast orders does not have correct strategy. This may happen that you assigned requirement strategy to the location product master after the forecasts were created. e.g. you release forecasts when requirement strategy is blank. In this case the forecasts do not have any strategy assigned. Then you assigned strategy 20 to the location product master, and expect the customer requirements can consume the forecasts created before, but it is not possible. You'll have to re-release the forecasts to make consumption happen. To check whether a forecast order has strategy assigned, you can follow the above steps, and check "Strategy" field. e.g. in the above scenario, only when forecasts are assigned strategy 20 could consumption happen.
Missing/Incorrect Setting of Check Mode (t-code: /SAPAPO/ATPC06)
Check mode is maintain in product master, "ATP" tab. In order to have consumption happen, corresponding entry must be maintained in /sapapo/atpc06, with correct assignment mode (the same as requirement strategy).
<Forecast Consumption in Product View>
Forecast orders on Element tab
Forecast orders are displayed in product view (T-code: /SAPAPO/RRP3). When you see a forecast order in Element tab of product view, the quantity of it is the quantity after consumption, which means you will not know it's original forecast quantity here. If the forecast is completely consumed by customer requirements and zero quantity orders are not to be displayed according to product view, you even cannot see the existence of the forecast order.
By using command GT_IO in product view, you can see some quantities of the forecast orders:
- Total Quantity: This is the original forecast quantity when the forecast order is planned / released
- Receipt/Requirement Quantity: This is the quantity after consumption, which is the quantity displayed in 'Element' tab
- Original Quantity: Reduction / Withdrawal Quantity
In Element tab, you only see the "Receipt/Requirement Quantity" of the orders.
Forecast Orders on Forecast tab
Forecast tab is the place where forecast orders and consumption situation are well displayed. This is the same as in T-code: /SAPAPO/DMP1.
There're several columns in this tab.
- Period (From Date / To Date): The validity of the forecasts. (Forecast order can be valid for a period, not only valid for one day.)
- Panned Quantity: This is the original planned quantity (Total Quantity) of the forecast orders.
- Withdrawal Quantity: The reduction / withdrawal quantity due to goods issue. When no withdrawal quantity exists, this column is hidden.
- Allocated Quantity: The quantity calculated by Planned quantity subtracts Remaining planned quantity and subtracts Withdrawal quantity. This quantity is not stored anywhere, instead it's always calculated on time.
- Remaining Planned Quantity: The quantity after consumption, which corresponds to Receipt / Requirement Quantity in Element tab
Forecast tab is separated into two tabs: Overview and Detail
- Overview tab
Overview tab displays forecast consumption in periodic bases. It sums up the customer requirement quantities (allocated quantity) and reduction / withdrawal quantities in the whole period and displays them as single (summed) value.
- Detail tab
Detail tab displays forecast consumption in order bases. It displays each order details, e.g. which customer requirement consumes which forecast.
** Notice that, if a customer requirement is not displayed in this tab, it will not consume forecast. A customer requirement is not displayed here means it is not read for consumption. You can refer to "Common customizing problems for consumption not happening" part in this page.
Difference between Element tab and Forecast tab
A common issue about forecast consumption is the difference between Element tab and Forecast tab. The difference can be quantity difference between Element tab and Forecast tab for the same forecast order.
* First make sure that you're using the same time zone in Element tab and Forecast tab.
- Time Zone of Element Tab
Controlled by Menu -> Settings -> Time Zone
- Time Zone of Forecast Tab
First check if "Local Time Zone" is set in /sapapo/MVM, [SNP] area.
If yes -> Location's local time zone
If no -> UTC time zone
Technical difference between the two tabs
To understand this, we must understand how consumption is saved and displayed.
1) When sales order / delivery / PGI is created/done in ECC, the transactional data will flow to APO which triggers consumption. The consumption calculation will be done after the transactional data is saved. The calculated result (consumption result) will then be saved to liveCache.
2) When you open product view, in Element tab, it just reads the data saved in liveCache. So you can imagine when the consumption situation in Element tab is incorrect, it means the consumption is not calculated correctly or not saved to liveCache correctly when the transactional data came into APO, which is a process happened before already. ** That's why it is not possible for SAP support team to investigate the existing incorrect situation in Element tab.
3) Different from Element tab, whenever you open the Overview or Detail tab of Forecast tab, consumption will be triggered to calculate consumption situation based on current transactional data in liveCache, which means consumption will be recalculated freshly. So the result may be different from Element tab if the consumption is not calculated correctly or saved correctly when transactional data came into APO, though we expect it to be the same.
** Notice that the result here in Forecast tab is only for display. It is not saved to liveCache.
If the consumption situation in Forecast tab is not correct, we can just check the forecast calculation by directly switching to the tabs of "Forecast" tab.
if the consumption situation in Element tab is not correct, we can use report /SAPAPO/CSP_CORRECT_FCST to trigger forecast calculation and save, to make the result consistent with Forecast tab. This report does the same thing as when we switch to Forecast tab, just adding an additional step to save the result to liveCache.
Difference between Overview tab and Detail tab
There may also occur situation that Overview tab and Detail tab do not match. This normally indicates a problem in forecast consumption logic. Normally the difference happens because certain customer requirement(s) consumes different forecast, e.g. an sales order consumes forecast in period N in Overview tab while it consumes forecast in period N+1 in Detail tab. When this situation happens process as following.
- Check whether ATP time series is used for the planning version in model and version management (T-code: /SAPAPO/MVM, field "CBF Time Series Update").
- If yes:
1) Check if ATP time series has "local time zone" setting activated for "ATP Buckets" in customizing setting "Maintain Global Settings for Availability Check".
** If ATP buckets are with "Local Time Zone", in model and version management, SNP settings, "Local Time Zone" is also necessary to keep consistency.
2) Go to ATP time series (T-code: /SAPAPO/AC05), check whether the customer requirement is in the correct period as in the Detail tab.
Also try below reports to update ATP time series. ( ** Notes regarding the below reports may also necessary to be applied. )
- Apply most recent SAP notes regarding this topic (notes belongs to component SCM-APO-FCS-CSP, key words "Overview" and "Detail"), for example:
- 2101304 Forecast consumption not correct in Overview sub-tab (5)
- 2099028 Forecast consumption not correct in Details sub-tab
- 2067726 Forecast consumption not correct in Overview sub-tab (4)
- 2039068 Forecast consumption not correct in Overview sub-tab (3)
- 2030110 Wrong consumption in 'Overview' tab when descriptive characteristics are used
- 2026354 Forecast consumption not correct in Overview sub-tab (2)
- 1937622 Forecast consumption not correct in Overview sub-tab
- 1848271 Wrong consumption situation in Product View Forecast tab (3)
- 1793574 Wrong consumption situation in Product View Forecast tab (2)
- 1598321 Wrong consumption situation in Product View forecast tabs
- However when Daylight Saving Time (DST) is used, it's possible that difference between Overview tab and Detail tab cannot be eliminated.
For detailed explanation about this, please refer to child page Forecast consumption with Daylight Saving Time (DST) .
- If the above does not solve the situation, you may consider raising a ticket to SAP support team.
<Technical Points of Forecast Consumption>
Settings at ERP side
To debug forecast consumption (as well as forecast reduction), we'll need to debug how the incoming transactional data from ECC is processed in APO, so we must stop the incoming queue first. To do this, go to transaction CFC2 in ECC system, create an entry for the user id which processes the transactional data, and set [Q D R] respectively for the 3 columns.
** In T-code: CFC1, it is suggested to set as queues are processed in APO system (Inbound Queue).
- Inbound queue: Queues are stopped in APO system as inbound queue, in transaction SMQ2
- Outbound queue: Queues are stopped in ECC system as outbound queue, in transaction SMQ1
Create / Change Transactional Data and Check Stopped Queue in APO system
Take Sales Order for example. In ECC system, t-code VA01/VA02, create/change a sales order (in case of change, must be requirement relevant change). On saving, sales order will be CIFed to APO, and the queue will be stopped in T-code: SMQ2 for debugging. So if you check SMQ2, you'll find below queue. Here CFSLS indicates it's a queue of sales document, and document number follows (in the sample, sales order number is 35763).
Go inside the queue, and find out the FM to process it. (Here the FM is /SAPAPO/CIF_SL_DOC_INBOUND.)
Then pushbutton to start debugging the queue.
Breakpoints for Queue Processing
- Set breakpoint at /SAPAPO/DM_MERGE_WHEN_LAST. Notice that this is only called once when all created/changed items are collected.
- Then in FM /SAPAPO/DM_ALLOCATION_SAV_PEGS, consumption is called in background task.
- When stops here in debugger, go to debugger settings (Shift+F1), tick below setting, and press F8 to finish the process.
Debug Transactional RFC call
- In T-code: SM58, find the recorded RFC.
- Select the item, go to menu ‘Edit’ -> ‘Debug LUW’, we reach famous FM '/SAPAPO/DM_ALLOCATION_RP'
Function module /SAPAPO/DM_ALLOCATION_SI: consumption simulation (when displays consumption in ‘Forecast’ tabs.
- Function module /SAPAPO/DM_ALLOCATION_RP: real-time consumption (when customer requirement comes or forecast release)
- Function module /SAPAPO/DM_ALLOCATION_SD: consumption call from ATP (during ATP processes)
Deep into FM /SAPAPO/DM_ALLOCATION_RP
- Read forecast orders with GET_APO_ORDER(_CHAR)
- FM '/SAPAPO/OM_PEGID_SELECT_ORDERS' – Read forecast orders from liveCache
BADI /SAPAPO/DM_BADI_CSP method ‘MODIFY_DATA’.
- Evaluate PEGID customer order with GET_PEGID_FROM_MAT_REQ
- Read customer orders with GET_APO_ORDER_REQ_SUM
Consulting note about ATP time series - Note 1383155
- FORM get_requirements_matrix to get dependent demand.
- FORM GET_CROSS_LOC_ORDER_REQ – Cross Location Forecast Consumption (as of SCM 7.01) ?
- Perform consumption with CONSUMPTION_ORDERS
FORM QUOTA_QTY_PERIOD_CALC_FCS * consumption in customer order period
(* Return value ‘cf_rest’. If it’s not zero, then go on to consume in the past and future.)
FORM PRPLN_DISTRIBUTE_NEAREST_FCS * consumption in past and future
- Check if forecast orders was changed with GET_CHANGED_ORDER
- Change forecast orders in liveCache with CHANGE_APO_ORDER
Display of consumption balance
- Transaction code: /SAPAPO/RRP3 and /SAPAPO/DMP1
- Package /SAPAPO/DEMAND_PLANNING and Function Group /SAPAPO/DM_ALLOC_DISPLAY
- Important FM /SAPAPO/DM_ALLOCATION_SI
Online Help of forecast consumption in APO system.
2147386 - General reasons for sales order not consuming forecasts