How to Understand Planning Model and Planning Version and Copy in SAP APO

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

We cover both Planning Models and Planning Versions.
We cover the version copy process in APO.
One can copy changes to the active version from the inactive version.

Introduction to Planning Models and Planning Versions

This article covers creating copies of the active version for various purposes. A common reason for creating a planning version is to do the following:

Run a constrained plan as unconstrained.
Have a version that is changed somehow — allowing a comparison between the live environment and the planning version — sometimes called a simulation version.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

When Starting with APO

When starting with APO, it is important to set your Model and Planning Version. The Model is a container for the version; it is one of the basic master data items in the Planning Version. The planning version is used for all types of planning and is a way of controlling and segmenting models. You can find this below.

The planning version and model are both easy to create.

It is desirable to create both, so you do not interfere with the active version or model or other people’s models and versions.

After the Model Has Been Created

Once the model and version have been created, you can now perform many planning activities. The planning model requires and allows that product and locations to be added to that version. However, products and locations need to be created.

Enhancements in planning versions for 5.0 include comparing results between different planning versions and the ability to incorporate key figures from additional planning versions automatically.

Planning Versions and Simulation

Planning systems typically have a standard ability to duplicate a supply chain planning model and its transaction data. This means that the planning system can have multiple “versions.” These versions may often be only slight variations of one another. However, in a planning system, a slight variation of input can make huge differences in the planning output. In technical terms, a version is a separate schema, which resides on the same database. Therefore, the schema is copied, and pointing is used to control the schema, but it is on the same server, the same database, and communicates with the same processor. One reason for this is that it maximizes using the resources (for instance, a simulation version can be processed when the live version is not being processed). But also, it is easiest to perform a version copy from the same database. This is shown in the graphic below.

More resources are required when one uses a duplicate version. It means more data, and the version copy itself takes processing resources and must be scheduled for light periods of system use.

Some Common Reasons for Using Different Versions

Planning systems can only have one “live” version – that is, one version, which interacts with the ERP system; however, Common reasons for copying a version are the same as using planning systems in general.

They include the following:

To Perform Simulation – which I define as making a master data or configuration change and testing the planning output for possibly rolling the change into the live system. Simulation is a bit of a lost art – with few companies that can perform a simulation with much in the way of standards – a topic covered in this article.
For S&OP Planning
For Rough Cut Capacity Planning

When a constraint-based method is used in SNP, a major reason for a version is to constrain differently between them. Of the different APO modules, SNP is the most intensive user of simulation versions.

Version Copy In APO

The version copy is the most important part of the process. The version copy allows the company to leverage all of the hard work in setting up the version to make a perfectly pristine copy of all of the configuration, master data – and, if desired, the transaction data. When the transaction data is included, the version can be referred to as a snapshot in time. It should be remembered that the inactive version cannot communicate with the ERP system, so whatever is brought over regarding the transaction is all the transaction data the version will ever have.

As time passes, the version copy becomes less and less current. However, new version copies can be performed to bring the offline version up to date.

This is transaction /SAPAPO/VERCOP.

The copy is mostly from the active version or 000 to an inactive version such as 001, 002, etc. But there are two exceptions.

It is possible, of course, to copy from an inactive version to another. This would be done if some changes had been made to an inactive version and the first inactive version needed to be kept as is, and more changes made to another version.
Master, data can be copied from an inactive version to an active version. The reason for doing this is described in the following section.

In this screen’s scope area, one can decide to bring in just a portion of the overall model. This, of course, can reduce the size of the version copy. But it is also more work. A version copy essentially creates a new version. But it can also be deleted, which is done with the transaction /N/SAPAPO/MVM. That way, old versions that are not being used can be deleted to reduce the database’s size.

Copying Back Changes to the Active Version from the Inactive Version

A nice feature of version management in APO is copying master data from the inactive version to the active version. This is a major time-saving function. This is because changes made to master data in the inactive version – say due to simulation, can be directly copied over to the active version. This is both an issue of reducing the effort required but it also provides a quality control benefit. This is because it is unnecessary to check all the changed areas in the inactive version and ensure that the exact changes are also made in the active version.

Introduction to Simulation Versions

The standard explanation of how to merge versions in APO is critiqued in this article. Then the simulation is discussed more broadly within the APO suite.

Technical Details of Setting up Simulation in APO

APO has several transactions for managing versions. Versions are essentially duplicate databases that are used to provide multiple sets of data to the application layer. Copying a planning version is /N/SAPAPO/VERMER. Versions are merged with transaction /N/SAPAPO/VERME. Deleting a version is /N/SAPAPO/VERMER. Merging the inactive (simulation) planning version with the active (production) version is the textbook way according to SAP to migrate changes from the simulation to the production version. However, I can’t entirely agree with this. Several things have to happen before you merge a simulation version with the active version.

First of all, the CIF or Core Interface must be paused. If a CIF model were to move data to the APO system during a simulation merge, it would lead to serious problems for at least the active version.
The planners cannot have plans that overlap.
You must select the key figures you want to copy between the versions.
You can, but do not have to copy the entire version. You can copy just combinations of products/locations.
Any procedure that was run on the simulation version would need to be run on the active version to update the transaction data in the simulation version.

However, just because the active version can be merged with the inactive (simulation) version does not mean that it is good to do so. Another way of moving the results is to copy the master data changes applied from the inactive version to the active version. This is performed with the MASSD transaction. Most of the things tested in a different version concerning supply chain planning are fields on the Location Product Master and lead times. These things are easily changed with MASSD.

Using Simulation in APO

The functionality and reliability of simulation in APO are greatly misrepresented to companies. Other consultants will make comments about the simulation version on projects that I often have a hard time getting behind these comments because I have had numerous problems getting a simulation to work properly.

The simulation requires 100% confidence in the system you are simulating, and I don’t have anywhere near that using APO for simulation. I have found several occasions where the simulation is simply incorrect. I think that there are many instances where companies are relying upon simulation results from SAP and thinking the differences are due to the tested master data changes, when in fact, they are working with a contaminated simulation. What goes undiscussed in so many articles on SAP is that other vendors already have great simulation capabilities.

MCA Solutions and PlanetTogether have excellent ad hock simulation capabilities that are far easier to use than anything SAP offers. Both require no separate set of versions to perform a basic simulation. When master data changes are necessary, each easily allows the connection to copies of duplicate SQL databases. I compare PP/DS simulation capabilities vs. PP/DS in this article.

ToolsGroup also has a data administration panel that allows different segments or categories of different SQL databases to be mixed and matched. So lead times from one model can be combined with order information from another model. Their interface for this is easy to use and does not require knowledge of SQL. While with APO, only consulting resources or super users can actually set up a simulation, in many other applications, users can set up their own simulations. That is how far behind other vendors SAP is in this area. And being behind like this is costing companies a great deal in both the extra hours that must be paid for to setup simulations in APO, in worse and oftentimes contaminated results, and in an inability to progress the business because APO clients end up with such limited simulation capabilities.

Simulation with APO in Practice

For me, the only real safe APO simulation is a system copy to a new box or in the active version. Simulation can be performed in the active version if the change is made to the master data necessary, and then a planning run is performed when users are not likely to be using the system. After the run is complete and the results are cataloged, the change data must be changed back to its original state, and any procedure that affects planning results be rerun. This has the advantage of using the actual production data, and because system copies between different boxes are such a problem with SAP, it provides the most realistic simulation available. It should be understood that I do not recommend doing this because I think it is a best practice. Clearly, making changes to your production system is dangerous and must be performed very carefully. However, with the limited and unsatisfactory results from inactive versions in APO, sometimes, it is the best way. I do not find it necessary to experiment in the production version in any of the other applications that I work with, exclusive to SAP APO.

External Optimizers for Simulation

Also, I try to perform simulations in external tools that simulate APO’s cost optimization or even ERP’s MRP. My experiences with the lack of usability or transparency of performing simulation in APO have led me to use a series of external applications to perform the simulation. I find this far faster and more effective and have additional design benefits for my clients. Simulation in APO Generally

Generally, there is too much focus on the technical aspects of simulation in APO, a system with many limitations with simulation. I have yet to see a company that uses APO simulation consistently, which benefits from it. Also, even if the technical simulation in APO is correct, I have an issue with how most companies document the simulation results. I describe the necessary documentation for simulation here.

However, while many companies want fast results from simulation, few are willing to invest the time to perform proper simulations, document the simulations, and then socialize the simulations to a broader group. Even with better simulation capability within the application, extensive and clear documentation and a system for holding this information are necessary to benefit from the simulation. Secondly, simulation should not only be performed post-go live but should be part of the design stage. Simulation has the dual benefit of providing feedback for the business and showing what functionality in the application can be relied upon.

Go to top

Conclusion

This article described both the background of versions and version copy and how version copy works in APO. Of the numerous simulation capabilities I have reviewed, APO’s is on the lower end of the spectrum, both regarding their technology and usability. Although it is nice that APO supports parallel processing as copying versions are resource-intensive. APO version management is easily outdone by MCA Solutions SPO (now Servigistics), ToolsGroup, and PlanetTogether. And those are just the vendors that I can think of off the top of my head. PlanetTogether’s version management is completely integrated into the application, and versions can be easily created and deleted.