Well, let’s first see the mystery – you have the below content in the planning book currently which you have downloaded to a file:
In the mean time let’s assume you have changed the prod1 value to 60, thus making the total 120.
Ideally, you download the file to make some changes and then to upload. Let’s assume you didn’t change anything for this example (for easy understanding) and start uploading the values from the file to the planning book. You expect the values in Figure1 to get updated in the planning book. But with what you end up is something like below:
This is the mystery I subjected, and yes – you will understand this and will be able to resolve this in a short time 🙂 .
The fact is: the behavior is correct – the note 1404581 explains this – and let me put the note explanation in simple way. The sequence how the behavior goes as per the note is:
- The total value is first compared between the file and the planning book, and in case of any discrepancy – the value of the file updates the internal table which finally updates the values to the database for the ‘Total’ value.
- Considering the new ‘Total’ value, the internal dis-aggregation to the product level (considering our example) happens as per the current situation of the planning book (and of course considering the calculation type of the key-figure: but don’t get it here, and understand this as ‘pro-rata’ for now for easy understanding). These dis-aggregated values are stored in temporary internal tables but not in the database.
- The comparison now happens for the detailed level between the file and the current planning book values. The values are as well updated to this internal table.
Once these three activities are completed, the internal table is finally committed and the values are updated in the data base. It is this sequence which creates the confusion for the consultants. Let’s understand this pictorially:
Point 1,2: File has 100 as total value while planning book as 120. So, the change happens from 120 to 100. Since the total is now changed, the dis-aggregation to the detailed level happens considering the new value of 100 as per the previous dis-aggregated situation.
Current situation of planning book says Prod1 = 60, and Prod2 = 60.
File says Prod1 = 40 and Prod2 = 60.
So, the value changes for Prod1. This change occurs still in the internal calculation. And this means, the total value is also impacted. Below picture says it:
And it is these values which get committed finally, creating a confusion for the guys who do the file upload to a planning book.
A point to note: File upload always happen to the key-figures which are not read-only. Any read-only key-figure will not be impacted by the file upload. By default, the ‘Total’ in the data view is always in edit mode. But with macro functions, you can make it read-only.
Let’s assume we made it read-only in the above situation. But yet, during the file upload, the ‘Total’ is considered and changed. This is SAP bug. The fix for this is the note 1975441 which makes sure that the key-figures which are read-only are not considered during the upload.
If you can just try to understand the above scenario in case the ‘total’ is not considered during the upload, all goes well and file upload happens as per the expectation. In fact, what is not understood is the reason why SAP has given us the option of overwriting only ‘Total’ and ‘Aggregated level’ during the upload of the file but not ‘Detailed level’ – in case they had given this option, the workaround we would have asked our DP planners who regularly upload files is to simply select the ‘Detailed level’ radio button during the upload.
By the way, in case you are not able to understand what ‘Aggregated Level’ means – it’s just that the point 3 doesn’t happen 😉 .