Skip to end of metadata
Go to start of metadata

Purpose

 This page collects information and questions-answers about the usage of version copy.

Overview

SAP Help link about Version Copy

  • Transaction: /SAPAPO/VERCOP

       It triggers: /SAPAPO/VERSION_COPY_PAR or /SAPAPO/VERSION_COPY_RESTR reports (can be run from T-Code: SE38) depending on SCM_BASIS version and activated business functions

  • Create the parallel processing profile for Version Copy: under SPRO - IMG - SCM Basis - Master Data - Model and Version MAnagement or in transaction SM30 view /SAPAPO/MVMPROF

Program in detail: FM /SAPAPO/MVM_VERS_DEL_COPY_PAR.
FM: /SAPAPO/MVM_VERS_DEL_PAR (Deletion of object during version copy)
FM: /SAPAPO/DM_COPY_VERS_DEP_BASIC (Serial copy of MD)
FM: /SAPAPO/MVM_VERS_COPY_MAS_PAR (Parallel copy of MD)

/Information: Main part of the code moved to FM /SAPAPO/VERSION_COPY_INTERNAL due to 2GB size limit on report./

Version copy programs (/SAPAPO/VERSION_COPY_PAR or /SAPAPO/VERSION_COPY_RESTR) are proceeding with 2 main parts:

  • 1st part deletes the  target version content however the version entry in /SAPAPO/APO01 table remains due to version-attached functions are existing.
  • 2nd part copies the content from the source version to the target version based on the selection criteria or variant defined in the report's user interface
    (refer to SAP Note 519014 - Handling Planning Version Management)

This is the standard behavior of the program.

General information:

1.  Memory usage:

Large amount of data causes dumps due to running out of memory / reaching the maximum lock entries during verion copy.
Solution:
move time series copy into a separate step using transaction /SAPAPO/TSCOPY or report /SAPAPO/RTSCOPY. See SAP Note: 429422 - SAP APO System Requirements for multiple Planning Versions.

In case of larger /SAPAPO/PEGKEY table scenarios the memory dump can be avoided with the following correction notes/KBA documents:

2089982 - Planning version copy copies too large amount of data
2077645 - Copying all transaction data of source version
1899803 - Unintentional copying of stocks
1865990 - Unable to prevent the copying of stocks
2405784 - Resource Shortage in /SAPAPO/VERCOP

2. Obsolete data

DUMP occurs during deleting a planning version with keywords like: CONNE_IMPORT_WRONG_OBJECT_TYPE, CONNE_IMPORT_WRONG_FIELD_LENG, CX_SY_IMPORT_MISMATCH_ERROR, /SAPAPO/RMSNPOPT, SCM-APO-SNP
Solution: 781817  - Deleting a planning version

3. Performance

You experience a relatively long runtime for the Version Copy Job:
Solution: It is always recommended to use version copy reports in the background due to the standard relatively extended runtime. You can set up and use parallel processing profiles for the //version_copy_par program. Please see note: 916921 - MVM: Customizing planning version copy parallelisation. Please also separate Time Series copy from the version copy job using transaction /SAPAPO/TSCOPY or report /SAPAPO/RTSCOPY. 429422 - SAP APO System Requirements for multiple Planning Versions.

The profile name is stored in database table: /SAPAPO/MVMPROF and the servers are maintained in RZ12 trasnaction.

The following SAP note can also be relevant: 2371417 - Version copy: Long runtime selecting /SAPAPO/V_TRPROD

1994795 - Version Copy takes very long time
2315127
- Performance improvement for material profile selection during version copy
2315640 - Performance improvement in matlsim_delete_processing
2116547 - Long runtime when deleting operations
2032784 - Version copy: Performance issue with PDS
2422846 - Performance Improvement - /SAPAPO/VERSION_COPY_PAR – SELECTs in LOOP

4. Parallel running programs:

You experience unexpected errors during version copy, or version deletion programs (/SAPAPO/VERSION_COPY_PAR, /SAPAPO/VERSION_COPY_RESTR,  /SAPAPO/VERSION_DELETE_LC_DB):
Solution:

  • Make sure that no other main jobs are running parallel with the Version Copy (Eg. CIF, According to note 1228423, make sure that there are no concurrent CIF activities running at the time of version copy.) Please mind: 2203392 - Planning Version Copy fails due to simultaneously running other reports
  • Please also revise the schedule of frequently scheduled liveCache-reorganization reports in SM37, starting with /SAPAPO/OM*. Otherwise these reports can cross over and cause random failures of the copy or deletion of the planning version in the liveCache.

In case of DUMPs: 2183509 - Job /SAPAPO/VERSION_DELETE_LC_DB runtime error DBIF_RSQL_SQL_ERROR [APPLICATION DEADLOCK]

If you are using parallel processing profiles:

customizing transaction SPRO:
==> Advanced Planning and Optimization
 ==> Master Data
  ==> Model and Version Management
   ==> Create Parallel Processing Profile for Planning Version Copy
Set the flag  "No Order Serialization" as 'X'.
If the performance allows it then the Parallel processing can be switched off completely as well, in order to test the behavior with a single server process.

You can use report /SAPAPO/DM_PEGKEY_REORG and transaction /SAPAPO/OM17 prior the version copy job to remove inconsistencies.

Useful error log transactions for troubleshooting: ST22 , SLG1, SM37, /N/SAPAPO/OM11, SE91 (message nr. search)

And for system monitoring: SM12, SM13, SM66, SM21

5 /SAPAPO/MVM transaction, version - related flags

After upgrading your SCM_BASIS (to 7.13) you experience that the Flag such as: ''CBF Time Series Update'' under ATP tab (/SAPAPO/ATP_VPL_UPDATE) is flagged in the /N/SAPAPO/MVM transaction for the planning version (000), although it was initial before the system upgrade. It can happen that a flag is not visible, but the database table /SAPAPO/APO01 contains the entry.

Solution:  check the /SAPAPO/APO01 database table to make sure that this is an inconsistency. Check the Flag /SAPAPO/ATP_VPL_UPDATE if its set. It only appears in the UI (//MVM). The relevant setting is in the database.
You can sort this problem out by switching to change mode and saving the Planning Version without any changes in the //MVM transaction. This will sync up the database with the UI. This flag can be otherwise switched on and off with Report (SE38): /SAPAPO/OM_ATP_REBUILD_TS

6. Latest released notes

A DUMP occurs during parallel version copy using: /SAPAPO/VERSION_COPY_RESTR

Category               Installation Errors
Runtime Errors         DBIF_DSQL2_SQL_ERROR
Except.                CX_SY_NATIVE_SQL_ERROR

Function Module affected is: /SAPAPO/OM_PVC_WORKER

At line: EXECUTE PROCEDURE PVC_WORKER

Solution: Please implement correction note: 2121317 - PVC_WORKER dump during parallel version copy''.

Other notes:
2246607 - Short Dump during version copy
2244391 - Shortdump while performing version copy
2042688 - Version Copy dumps due to memory consumption
2030439 - Version copy not deleting all PEGKEY-s
2336274 - Order existence check error in /SAPAPO/SCC_TL1

7. Live Cache

LiveCache version and SCM version matrix: You can check the actual LiveCache installation parameters at /N/SAPAPO/OM13 transaction.

Make sure to use an up-to-date LiveCache-Build with the proper version of LCA-SCM system combination, in transaction /N/SAPAPO/OM13.
KBA:
2074841 - Matrix of liveCache Versions for SCM 7.00 and 7.01
2074842 - Matrix of liveCache Versions for SCM 7.02 and Later.
2074843 - Version Matrix for HANA integrated liveCaches and ).

 LiveCache error codes. If Transaction /SAPAPO/OM11 log or other pop-up messages during transactions reveal a LCA error code during error analysis you can check the explanation for your troubleshooting tasks in the following useful transaction: /N/SAPAPO/OM10. You can as well have a look on /SAPAPO/OM13 to analyse LiveCache setup parameters.

If the LCA release, that is installed in the system has been withdrawn or not matching the SCM_BASIS release, then various SHORT DUMPs can occur in the system such as:

Category Installation Errors
Runtime Errors DBIF_DSQL2_SQL_ERROR
Except. CX_SY_NATIVE_SQL_ERROR

Responsible Statement looks like:
EXECUTE PROCEDURE "APS_PEG_CAT_GET_ORDERS" ( or EXECUTE PROCEDURE "APS_ORDER_GET_DATA" (    etc...   EXECUTE PROCEDURE "APS*

Function Module looks like:
/SAPAPO/OM_PEG_CAT_GET_ORDERS or /SAPAPO/OM_ORDER_GET_DATA  etc... /SAPAPO/OM*

 

 8. APO Planning Version's table: /SAPAPO/APO01 -> SIMID = VRSIOID.

9. Version Copy Programs

  • /SAPAPO/VERSION_COPY_RESTR is a reorganized version copy program. 2077617 - FAQs for copying the transaction data in the planning version copy (available from 7.02) Please mind SAP Note 1963447 - Performance problem in /SAPAPO/VERSION_COPY_RESTR.
    Please see the details of business function SCM_APO_VERSION_SIM

There is a main difference between /SAPAPO/VERSION_COPY_PAR and /SAPAPO/VERSION_COPY_RESTR   from Master Data copy point of view. As it is written in note 2077617 the /SAPAPO/VERSION_COPY_PAR copies ALL master data in case you select the option: Copy Master and Transactional Data. If you use /SAPAPO/VERSION_COPY_PAR with Copy Master Data only option, then the selection is respected and only the selected location-products are copied.

/SAPAPO/VERSION_COPY_RESTR has however a re-organized User Interface, therefore it is able to distinguish and copy the master data only from the selection regardless of only Master Data or Master Data together with transactional data is copied.

Here is a preview of the UI difference, click on image for large size:

  • /SAPAPO/MVM_COPY_MODEL_VER_BCK - This report is capable of copying existing Versions on existing Models to a new different model’s new version. It does a full scope copy. It acts as a backup program.

10. VersioID

  • VRSIO conversion routine (input-output conversion): /SAPAPO/VRSIOID domain and data element (main DB table /SAPAPO/APO01) has a conversion logic. This means eg. when you enter the Plannig Version name (/SAPAPO/VRSIOEX) in the UI for a transaction, the program will refer to the /SAPAPO/VRSIOID immediately with the help of the conversion routine.
    Such a logic is used eg. with DPRID and DPREX fields in /sapapo/snp01 table.

11. Product Split Copy with Version Copy

  • Product Split database tables: /sapapo/t445pvhd and /sapapo/t445pvdt
  • These database tables are deleted / re-written in /SAPAPO/VERSION_COPY_INTERNAL
    • To copy the relevant entries for a product-location, at least one location must be declared in the selection criteria on the /SAPAPO/VERSION_COPY_PAR or /SAPAPO/VERSION_COPY_RESTR screen. If there is a full scope of product location master data copy taken place, wildcard * usage is necessary. See SAP Note:1661727

12. Planning version copy message : /SAPAPO/MVM099

  • In general the planning version cannot be copied back to the active version: In PP/DS the situation in version 000 is very dynamic (there are always new sales orders being entered, planned orders being converted into production orders, etc), such that many times if we were to adopt results of an inactive planning version this would only make the active version outdated.

  • Generally, if a planner has found a good planning run setup (by comparing results from different planning versions), they can execute planning in version 000 with the "best" settings to get similar results.

  • (As a remark: In SNP some parts of a version can be merged 000 version with /SAPAPO/VERMER tranaction).

     

Related Content

Related Documents

Related SAP Notes/KBAs

Note 1569428 Short dump during planning version copy
Consulting note 519014 Handling Planning Version Management
Consulting note 123150 Performance: SNP master data queue processing

1928130 - APO Upgrade 7.0: Missing Extra Attributes in tx /SAPAPO/MAT1
1569428 - Short dump during planning version copy
2203392 - Planning Version Copy fails due to simultaneously running other reports
2058389 - Dump "SYSTEM_CANCELED" and error "/SAPAPO/TSM 205" during version copy


  • No labels