I Request SCN to allow me to dedicate this document for my Good Friend Vijay Varadharajan.

Overview

This document helps the forecaster’s / Supply chain analyst to follow the precautions while manipulating the data with the Manual Adjustment of Demand History screen in SAP so that inconsistencies within the system could be prevented.

Transaction - /n/sapapo/sppdmdh.

Do’s

When you’re updating the histories in any of the below highlighted Key Figures (Any changeable Key Figures), Please adhere to the steps explained below.

Step  1

• Select the KeyFigure Line and then click on “Change” button
• Enter the value into the respective bucket where you want to change the figures.
• Once done click on the “Save” button, in the series as explained in the above screen shot
• The below confirmation will pop on successfully saving the entries.

Step 2.

• If you like to work on different part you can stay with the transaction and you can work without leaving the transaction by following the step 1.
• If you like to work on the same part then you must leave the transaction and wait for a minute so that the data what you’ve edited previously will get updated into the system respectively (Need a minute for Daemon to Update the data into DEMCRT).
• Still if you want to update the same Product-Location-Bucket without leaving the transaction. Make sure you wait for a minute and refresh the screen until you see the changed numbers reflecting in “Demand: Final History”, if you see the values updated into Final History then proceed with further changing.

CAUTION- Please leave the transaction and come back again after a minute if you want to edit the historical values for the same Part, same Location and same time bucket combination.

In our example, the user tried to edit the history from 25 (refer above screen shot) to some other value for the same Part, same Location and same time bucket.

System warns the user as the data for particular Location-Product is been locked ( i.e Daemon still in progress of updating the data from DEMCRT to the Multiproviders), since the user just edited and saved the value for the same combination within a minute ago for which the system trying to update the new value across the system.

When system shows the above warning message, it strongly suggests you to hold the changes for the particular part and it wants you to try after sometime (May be after 1 min), it’s advisable to leave the transaction and come back again for the next change after a minute.

Don’t’s

Here’s an example where the user violated the STEP 2 which leads to inconsistencies in the system for a particular part’s Historical values.

In the Time Bucket M.06.2011, the original history was 143. User changed the history to 15 first time and then tried to change the value again. Now the system warns the user with below warning message as the previous change was not yet updated into the system completely.

User violated the system warning and changed the history to 10 in Time Bucket M.06.2011 within a minute and without leaving the transaction.

However, Doing so the system will show you the message as the data got saved successfully as given in the below screen shot.

As a result of the above violation, Negative values in the demand Histories created in the system.

143 – Initial demand History.

First change – 15 (143 – 15 = 128), so -128 from 143 of original demand history for the product-location-M.06.2011 combination has been captured by Daemons but not yet updated into the system.

Second Change – 10 (143 – 10 = 133), so -133 from 143 of original demand history for the product-location-M.06.2011 combination has been accumulated by Daemons to its previous value and yet to be updated into the system.

Here is how the system will update the Histories finally.

143 (original Dem History) – 128 (1^st Change) – 133 (2^nd change)

143 – 261 = -118

As a result, when you try to view the Part’s forecasting information in Forecast UI for the Product-location combination system will throw out an error saying “Inconsistent Historical Data” as given below.

CAUSE - As for the reason!! It is a consequence of the deamon updating 9ADEMCRT records to 9ADEMMUL with a frequency of one minute. The locprod is locked as long as data is saved to 9ADEMCRT. (Technically it is not possible to lock it further.) And then if you change demand during the intermediate time between deamon runs, demand is calculated how much to be adjusted.

Solution: Running Stocking Realignment may resolve this kind of inconsistencies

NOTE– There could have been NEW notes released by SAP to overcome this issue, But am not sure.

Check these Notes as well.

1836600 - Inconsistent historical data of orders with rejection reason

1673288– Negative Forecast is calculated

1. Access sequence created: ZDUA and Condition table used SAPIBD01 and Fields in condition table SAPIBD01 and Field Ship From is selected as optional so that we can use this same access sequence from other Source.

Configuration : SPRO-> SCM Basis-> Pack -> Packaging Specification-> Determination of Packaging Specifications-> Define Access Sequences

2. Condition type used is ZDUA

3. Determination procedure used is ZSPP_D.

4. ZSPP_DRP_ROUNDING is the rounding profile defined and Rounding profile Configuration in DRP.

SPRO-> Advanced Planning and Optimization -> Supply Chain Planning -> Service Parts Planning (SPP) -> Basic Settings -> Define Rounding Profile

5. Setting of Z_DRP service profile which is used for DRP. ZSPP_DRP_ROUNDING is rounding profile assigned.

SPRO-> Advanced Planning and Optimization -> Supply Chain Planning -> Service Parts Planning (SPP)->Distribution Requirements Planning (DRP) ->Define Service Profile for DRP

6. Pack spec ZSPP_0048 maintained for supplier XXX and Target qty 75 at level SPP rounding

Transaction /SCWM/PACKSPEC

7. Testing pack spec  in simulation mode using transaction /SAPAPO/AC12

Forecast Planning service takes long time due to huge entries in change history table entries in the time series.

Forecast Planning services: SPP: Forecast Service -  SPP_FCS_SERVICE, SPP: Forecast Disaggregation Service -  SPP_FCST_DISAGGREGATION, SPP: Forecast Service (StdDev.) - SPP_FCS_SERVICE_MSE, SPP: Forecast Approval -  SPP_FCST_RELEASE.

Below Changed history tables in time series data area have Millions of records.

It leads to poor performance in the forecast planning service.

/SCA/TK1SPM  -  Key Figures of Time Series Data Area 1SPM

/SCA/TS1SPM - Status Values of Time Series Data Area 1SPM

/SCA/TN1SPM - Notes for Time Series Data Area 1SPM

/SCA/KT1SPM  - Key Figure History for Time Series Data Area 1SPM

/SCA/ST1SPM  - Status History for Time Series Data Area 1SPM

/SCA/IS1SPM  - Internal Status of Time Series Data Area 1SPM

Delete all change History for times series data area which will improve performance.

You can use below reports to delete time series change history entries.

Report /SCA/TSDM_TS_HIST_DELETE - Delete time series change history

Report /SCA/TSDM_TS_HIST_DELETE_ALL - Delete All Time Series Change History Entries

This is document is helpful to Create Live Cache Backup in HANA.

Scenario 1:  APO on HANA database.

Scenario 2: APO on SQL/Oracle database(other than HANA).

Please follow the below steps to create LiveCache backup in HANA:

Step1: Replication Model by using Transaction /SAPAPO/REPL_MOD_VIE.

Click on 'New Entries' button

Give name for  Replication Model ID and Description.

Choose Planning Book, Data View, Planning Version, Secondary Database Connection and Selection ID is optional.

Select check box for Delta Replication Relevant Model and Delta Replication Executable.

Scenario 1: Select 'DEFAULT' as Secondary Database Connection and this is standard database connection.

Scenario 2: Select Secondary Database connection HD4 which is created by using Transaction DBCO.

Add Key Figures

Step2: Activate Replication Model by using /SAPAPO/REPL_MOD_MNG.

Replication model relevant tables/views will be created in HANA.

Step 3: Check tables/views in HANA which is relevant to replication model.

Step4: Replication of Planning Data to HANA by using Transaction /SAPAPO/REPL and this is full data load.

Step 5: Check full data load in HANA. Demand Plan calculation view under Replication Model.

Can view data in Chart also.

Step 6: Delta Replication of Planning Data to HANA by using Transaction /SAPAPO/REPL_DELTA.

Step 7: Can check delta change in HANA.

Step 8: Create Delta Job by using program /SAPAPO/REPL_REPLICATION_DELTA with periodic.

This Delta job will take care backup in HANA based on periodic intervals.