Tuesday, June 1, 2010

Note 425825 - Consistency checks, /sapapo/om17, /sapapo/cif_deltareport

Summary

Symptom

Scope of functions of the consistency checks, /sapapo/om17 and /sapapo/cif_deltareport (/SAPAPO/CCR)

Other terms

Internal consistency, external consistency, comparison, compare, consistency check, CIF Compare & Reconcile Deltareport, refresh
/SAPAPO/TS_LCM_CONS_CHECK, /SAPAPO/TS_LCM_CONS_CHECK_ALL
/SAPAPO/TS_LCM_REORG

Solution

Internal consistency refers to the consistency between the liveCache data and the APO database.
External consistency refers to the consistency between the APO system and one or more dedicated R/3 Systems.
Before you check the external consistency and set it up again, if necessary, make sure that the internal consistency of the APO system is guaranteed.

In addition to the information contained in this note, you should refer to the document "Data Consistency between SAP R/3 and SAP APO 3.0/3.1".
This document was created as part of "SAP Best Practices for Solution Management mySAP SCM" and contains extensive information on the relevant consistency checks.
You can find the path for this document in note 572003.


----------------------------------------------------------------
Internal consistency checks
----------------------------------------------------------------

Internal consistency check - transaction /SAPAPO/OM17

Internal consistency refers to the consistency between the liveCache data and the APO database.
Inconsistencies may occur if the APO database data or the liveCache data can no longer be completely restored due to system crashes and inappropriate backup strategies.Since there is currently no logging for Demand Planning data, inconsistencies can still occur in this area following a recovery.To check the external consistency between the APO database and the liveCache and to set it up again, if necessary, use transaction /SAPAPO/OM17.

The following data is checked in particular:

  • Pegging areas, stocks, campaigns and planning versions are checked.
  • Master data:This data is saved redundantly in the APO database and in the liveCache, this means that data which is only on the APO DB, can be generated in the liveCache.If data still only exists in the liveCache, you can select this for deletion.
  • No resources are checked.The 'Resources' option is provided in older versions of the /SAPAPO/OM17 report, but you should avoid using this option as the results are inadequate.The results are not satisfactory.
Internal consistency check for resources - transaction /SAPAPO/REST02


(also in the initial screen of the resource maintenance under the menu Tools/liveCache check)
You can select different options on the selection screen of the report.

  • Check existence in the LC - liveCache check
    Only checks which resources do not exist in the liveCache and displays a list of these resources.
  • Save non-exist. res. LC - liveCache save
    This option checks the resources and creates missing resources in the liveCache.Resources, for which a backup is not possible in the liveCache, are assigned a red traffic light and a corresponding error message in the list of results.
  • Save selected res. LC - liveCache save
    This option saves all the resources in the liveCache that meet the selection conditions.
    A list with yellow traffic lights is displayed for those resources where there are differences between the database and the liveCache.The differences are highlighted.
    Resources, which could not be saved in the liveCache, are displayed with a red traffic light.Corresponding error texts are displayed in the list of results for these resources.

In the list of results, resources can be selected and saved in the liveCache.You can also navigate into the resource maintenance by selecting resources and the "Change resources" function.You can also display the time stream in the liveCache by clicking on the time stream GUID (times in UTC) and you can display the bucket vector in the liveCache by clicking on the green traffic light in the "Bucket vector" column.

Consistency checks for product allocations


To date, there is no consistency check for product allocations within transaction /SAPAPO/OM17 - the check tool is available in the menu tree for product allocations "Global ATP - Environment - Product Allocations - Repairs".
In the product allocation, the incoming order quantities can be directly updated in the liveCache during a direct connection to the planning area.Using the tool in the liveCache, you can reconcile the data with the product allocation assignment on the database.The tool allows you to check and then correct the data.

/SAPAPO/ATPQ_CHKUSG -Check product allocation assignment
Product allocation assignment without complete incoming order quantity
Product allocation assignment without order item
Product allocation assignment without allocation group

Inconsistent temporary quantity assignments after the LC recovery


Previously, there was neither a consistency check nor a repair option within transaction /SAPAPO/OM17 for inconsistent and incorrect temporary quantity assignments that may occur after an LC crash and a subsequent LC recovery.
These inconsistencies only occur for APO Release 3.0 if you are using a liveCache lower than Version 7.4. As of LC Version 7.4, the LC itself performs the correct data recovery.You can use the /SAPAPO/REBUILD_TQA report to eliminate the inconsistencies after an LC recovery for APO 3.0. This report deletes incorrect temporary quantity assignments and creates missing quantity assignments.
However, it is not possible to use the report to correct all inconsistencies automatically and you must perform this manually in some cases. For a detailed description of the procedure, see note 435827.

Demand Planning consistency check


The /SAPAPO/TS_LCM_CONS_CHECK_ALL report checks all existing time series networks of the Demand Planning.Any inconsistencies are displayed for each planning area and version without the option of being able to delete these.
The /SAPAPO/TS_LCM_CONS_CHECK report performs the same checks as the /SAPAPO/TS_LCM_CONS_CHECK_ALL report, but only for one planning area to be selected in each case and also for each planning version (if desired).You can also activate the 'repair' option.Any inconsistencies are then automatically eliminated during the run.If you select the 'Repair' option, no other processes may be active for the selected planning area and the selected planning version. To make sure that this is the case, you can set an optional lock after implementing note 543304 or as of Support Package 22. If you cannot set the optional block, execution of the report is terminated for this version and a list of system users who have already set a change lock for the planning version is displayed.

The following is checked:

  • Storage buckets profile in the liveCache:
    With the storage buckets profile the system checks, in addition to the existence, whether the start times of the time buckets and the weighting factors are correct.The system runs its checks on the basis of the settings of the planning area's storage buckets profile (cf. transaction /SAPAPO/TR32).Any inconsistencies here cannot be repaired.However, this case only occurs very rarely (for example, if the fiscal year variant has been subsequently changed).The inconsistencies can only be eliminated by creating (initializing) the time series again.
  • Time series
    With the time series, the system checks whether the corresponding liveCache anchors, and in turn all corresponding time series for these anchors, exist in the liveCache for all characteristics combinations in accordance with the planning object structure (DB).Missing anchors or time series are created.
    However, these time series are created with initial information.Therefore, if data is lost during a liveCache crash, this data must be produced again (for example, by restarting a planning run, reloading historical data from an InfoCube).
  • DP relationships
    With the DP relationships, the check starts from the planning object structure and the related aggregates to ascertain whether all the relationships exist. The check also verifies whether unnecessary relationships exist. Missing relationships are created and unnecessary relationships deleted.
    Provided the data still exists in the corresponding planning object structure, the DP relationships can be completely created again (except for firming information).If the time series of the planning object structure were created again with initial values in the case of a liveCache crash, this (initial) information is also copied to the DP relationships.When the time series of the planning object structure (see above) are recovered, the DP relationships are automatically adjusted.
  • DP-BOM relationships (only as of APO 3.0 Support Package 19/APO 3.1 Support Package 03 or note 458666)
    With the DP-BOM relationships, the system checks, on the basis of the existing characteristic combinations and the master data, whether all relationships exist in the liveCache between the dependent characteristic combinations.(Characteristic combinations are dependent if they show the same PPM and the same user-defined characteristics).The system also checks whether the BOM coefficients of the PPMs agree with the coefficients in the liveCache.The check for the DP BOM relationships assumes that all characteristic combinations exist.Missing BOM relationships are created and changed BOM coefficients are adjusted.


The report /SAPAPO/TS_LCM_REORG (supplied with note 542946 or Support Package 22) determines all liveCache time series and period patterns from a selected planning version that do not have any 'liveCache anchors', independently of planning areas.These objects do not have any reference to the application data and are therefore not inconsistent as such, but simply unnecessary objects which result in increased liveCache memory consumption.For this reason, you should only have to run the report approx.
If you have selected the 'Repair' option, any unnecessary time series and period patterns are deleted.
When you run the report /SAPAPO/TS_LCM_REORG, no other processes for a planning area (applies only to planning areas with key figures based on liveCache time series) should be allowed to run with the same planning version, since this would result in liveCache objects that are still required by the other parallel process being recognized as unnecessary (and then possibly deleted).For this reason, we recommend that you always run the report with the option 'Lock planning version'.In this case, all planning areas that use the planning version to be checked are locked for the relevant version.If you cannot activate the lock, report execution is interrupted and a list of system users is displayed, showing users who have already set a change lock for the planning version.

Supply Network Planning using time series

If time series are used in the Supply Network Planning in a SNP planning area, the /SAPAPO/TS_LCM_CONS_CHECK report can also be used to check this time series network and to eliminate inconsistencies if required.The report is used in exactly the same way as for Demand Planning.In addition you have the option to check and correct the SNP master data.
However, the /SAPAPO/TS_LCM_CONS_CHECK_ALL report is not available for SNP planning areas.
As of Support Package 17, and to a greater extent as of Support Package 19, the consistency can also be checked for SNP data stored in the time series. For more information, see notes 446360 and 441398.
If time series are used in the Supply Network Planning in an SNP planning area, you can also use the report /SAPAPO/TS_LCM_REORG.The report is used in exactly the same way as for Demand Planning.

TP/VS consistency check:Report /SAPAPO/VS_CONS_CHECK (transaction /SAPAPO/VSCC)


You can check the following data by making a selection on the initial screen:

  • APO master data relevant for TP/VS, such as vehicle resources, transportation lanes, locations
  • Customizing and optimization profiles
  • R/3 OLTP and APO TP/VS integration and carrier selection settings
  • Consistency between liveCache and TP/VS anchor tables (orders and transport requests)


Consistency means that a transport exists in the anchor tables for each transport in the liveCache, and vice versa.If inconsistencies are found, some of them can be repaired using the transaction.The relevant transports are deallocated (no entry in the anchor tables) or published/unpublished in the liveCache (the statuses are different in the liveCache and anchor tables).Inconsistent entries in the anchor tables are deleted.

Transaction /SAPAPO/VSCC was developed primarily to recognize possible inconsistencies.If an inconsistency is displayed and if it cannot be eliminated by forward navigation, open a problem message.

Consistency check for scheduling agreements

The /SAPAPO/PWB_KILL_INCO report corrects scheduling agreements and releases if they meet the following inconsistency criteria:

  • There is a different number of input and output nodes, but neither number is 0.
  • Orders that do not have any inputs but whose material is maintained in the vendor location and that are contained in a planning version.These orders would cause terminations in the future.
  • Orders whose quantity fields are different in the source and target.
  • The accumulated numbers of goods receipt and goods issue in the liveCache must agree with those in the database.
  • Cross-check with the set process:the order GUID in ordmap refers to the incorrect request type.Objects exist, even though the process makes no provision for them.
  • There are still APO scheduling agreement schedule lines even though the scheduling agreement in R/3 is already flagged as an OLTP scheduling agreement
  • There are still APO scheduling agreement schedule lines even though the scheduling agreement in R/3 is already flagged as an OLTP scheduling agreement
  • Neither a delivery nor a goods issue exists on the database, but they are allocated in the liveCache


Since the data is deleted and created again in the liveCache, you should proceed very carefully.You should only use the check if you notice inconsistencies or following a liveCache crash.In the first case, you should only consider this specific scheduling agreement and in the second case, all scheduling agreements should be checked.

Consistency check for operations

In the database table of /SAPAPO/OPR operations, operations may exist which have no orders in the liveCache or no orders for a simulation version or orders for deleted simulation versions or no external operation number.These operations place an unnecessary burden on the database table and may cause poor system performance.

To delete operations, which are no longer required, from the database, you should schedule the Z_CHECK_CONSISTENCY_OPERATIONS report on a weekly basis.
To create the above report, follow the instructions in note 458854.


----------------------------------------------------------------
External consistency checks ------------------------------

External consistency check CIF Compare/Reconcile function

External consistency refers to the consistency between the APO system and one or more dedicated R/3 Systems.
Inconsistencies may occur if at least one of the systems crashes and cannot be fully recovered again.In the same way, inconsistently deleting CIF queues or unwanted user settings can cause inconsistencies.

You can use transaction /SAPAPO/CCR to execute the CIF Compare/Reconcile function. Note:In APO 3.0, Version 3 is available after the downgrade using note 459402;you can only start the Compare/Reconcile function, Version 3, in APO 3.0 by executing the /SAPAPO/CIF_DELTAREPORT3 report.
/SAPAPO/CCR only checks the data of the active planning version (planning version 000) since R/3 data is only integrated through CIF with this planning version.
You do not need to check the external consistency after a complete recovery of the liveCache and/or of the APO-DB.

In particular, the following data of the active planning version 000 is checked:

  • Only transaction data is checked.
  • Only existence is checked in Version 2:A check is only performed on production and planned orders at header level, purchase orders, purchase requisitions and sales orders at schedule line level to see if they exist.The quantity is also checked but only for stocks.
  • In addition to the existence check, important quantities and dates are compared in Version 3. The level of detail distinguishes itself here with different compared transaction data.
  • If inconsistencies are found between the systems, these are not cleared automatically.You must select one or several of the objects in question on the detailed screen and initiate the transfer of the object in the required direction (APO, R/3) by selecting the corresponding button.

Header Data



Release Status:Released for Customer
Released on:30.05.2003 14:41:28
Master Language:German
Priority:Recommendations/additional info
Category:Consulting
Primary Component:SCM-TEC In Case of LiveCache Problems: Please use SCM-APO-LCA
Secondary Components:SCM-APO-MD-RE Resource

Affected Releases

Software
Component
Release
From
Release
To
Release
And
subsequent
SAP_APPL
46C
46C
46C

SAP_APO
30
30A
30A

SCM
400
400
400

SCM
410
410
410

SCM
500
500
500

Related Notes




744896 - Initialization/consistency check of an SNP planning area

676128 - Product allocations: Product allocation assignment check

669287 - Superfluous time series for SNP planning areas

634440 - /SAPAPO/OM_ORDKEY_ORDMAP_CHECK improvement

603593 - Deleting from check programs

572003 - SCM operating concept

542946 - Error message time series/period pattern does not exist

500843 - Composite SAP note for COM and SAP liveCache 7.2 or higher

458854 - Reorganizing the operation table

435827 - Recovery of temporary quantity assignments in the liveCache

434647 - Point-in-time recovery in an SAP system group

434645 - Point-in-time recovery: What must I be aware of?

No comments: