Hello Friends,
It's quite normal for a planning cycle to take several iterations or rounds until you come up with the final plan data. The requirements are often to track the changes made in each iteration and to lock previous iterations against change.
Typical Approach
The most frequently used data model for planning applications uses some kind of version characteristic to implement these requirements. Version 101 for "Budget Round 1", Version 102 for "Budget Round 2", Version 103 for "Budget Round 3" etc. At the start of each round you copy the data of the previous version. Then you add the previous version to a data slice to protect it against further changes. So far so good. However, this approach has a few disadvantages:
- High data volume: there's a full set of data per version
- A lot of redundant data: there are only few records that have actually changed from one round to the other
- In flexible locking: you can lock only complete versions and every user has to be "in the same round"
Suggested Solution
With a small change to the data model you can avoid all of these issues and get better performance at the same time. Instead of using just "Version" (0VERSION), we introduce another characteristic to the data model called "Planning Round" (ZROUND). Planning Round is simply a counter (numc 2) with the following values: 00 - Initial Entry, 01 - 1st Round, 02 - 2nd Round, 03 - 3rd Round, etc. Planning Round is not included in any of the planning/aggregation levels. It will be automatically deriverd using a characteristic relationship. Version is the source field and Planning Round is the target field of the relationship. Once a round is completed you increase the planning round number. You can also use a data slice to lock each planning round separately.
This has the effect, that the system stored only the delta changes for each round! The data of previous rounds is not touched at all and each round contains relatively little data (assuming no mass changes).
If you do not include Planning Round in your queries, they will show the final plan values. If you drill-down by Planning Round, the query will show the details on how the plan values have changed in the course of the rounds.
Example
Here's a simple example. You start by entering the initial amount for your budget:
Custom table:
Plan data:
The system derived planning round as follows:
Once the round is complete, we increase the counter (In addition you can lock ZROUND = 00 in a data slice):
Custom table:
Now we make a change to some of our plan data:
The system determines the delta automatically and planning round is derived again:
So now we have two records:
I think you get the picture. If there is no change, then there are no additional records stored. This reduces the data volume significantly - especially if planning is done manually.
Characteristic Relationship
There are some alternatives for implementing the characteristic relationship. First, you could keep it simple and add Planning Round as an attribute to Version. In this case don't forget to perform an attribute change run once you updated the attribute. Second option is to use a mini DataStore Object which contains Version and Planning Round. You can update it via file upload or by using the API function module RSDRI_OSDO_MODIFY. The final option is to implement the derivation logic in ABAP and base it on a custom table. Here you have the most flexibility and could for example build the derivation based on user ID and make it time-dependent.
Best,
Marc Bernard
@marcfbe
