APO SPP Manual Adjustment of Demand History – Do’s & Dont’s
I Request SCN to allow me to dedicate this document for my Good Friend Vijay Varadharajan.
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.
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.
- 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.
- 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.
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 (1st Change) – 133 (2nd 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