Internal and External Consistency

Internal and external consistency for SAP APO (3.x) / mySAP SCM (4.
x)
Best Practice for Solution Management
Version Date: April 2004 This document refers to the data consistency between SAP R/3 and SAP APO 3.0 / 3.1, SAP SCM 4.0 / 4.1 and within SAP APO 3.0 / 3.1, SAP SCM 4.0 / 4.1. The newest version of this Best Practice can always be obtained through the SAP Solution Manager.
Contents
Applicability, Goals and Requirements ..................................................................................... 2 Preliminary Information ............................................................................................................ 3 Procedure ........................................................................................................................... 5 Consistency Checks...................................................................................................... 5 Checks for Internal Consistency ................................................................................... 7 External Consistency Checks ..................................................................................... 18 The Consistency Check Process ................................................................................ 26 Executing the Consistency Check............................................................................... 27 Further Information................................................................................................................. 34
Internal and external consistency for SAP APO
Applicability, Goals and Requirements

Goal of Using this Document
The aim of this document is to ensure consistency between SAP APO and your OLTP system, and consistency between the SAP DB and liveCache within your SAP APO system. This document describes the necessary tools and measures. It supports you during the development and implementation of a consistency-oriented interface and system management concept by: Suggesting procedures and sequences for consistency checks according to the business processes that you want to map with your SAP APO system. Giving operation and performance notes for individual consistency checks Listing the areas of responsibility for monitoring and executing consistency checks.
Alternative Practices
You can also book an on-site Solution Management Optimization (SMO) service known as SAP Interface Management service, whereby SAP experts support you in drawing up a data consistency concept.
Staff and Skill Requirements

To implement this Best Practice, you require the following teams: Application Management Team The Application Management Team should create the SCM / APO business process management concept specified in this Best Practice. This team combines experts from several areas of your company: Business department Solution support organization (for example, the IT department and the Help Desk) Implementation project team Execution Teams The execution teams are the following groups, which are taken together from your Solution Support Organization: The Business Process Champion for each business process Application Support Development Support Program Scheduling Management Software Monitoring Team System Monitoring Team More information about roles and responsibilities of these teams can be found in the super ordinate Best Practice General Business Process Management, which you can obtain through the SAP Solution Manager.
2004 SAP AG
Necessary or Useful Training Courses: BC355 APO System Administration SCM210 APO Integration TTW060 SAP APO Technical Administration BC555 liveCache Administration for APO Systems
Preliminary Information
This Best Practice is based on the most common integration scenario for setting up a mySAP Supply Chain Management (mySAP SCM) solution using SAP Advanced Planner and Optimizer (APO). The main components of an SAP SCM system landscape are summarized in the following table and shown schematically in the subsequent illustration. SAP APO System The SAP Advanced Planner and Optimizer system facilitates the strategic, tactical, and operational planning processes. APO consists of several software components: a relational database system (RDBMS) as in any SAP R/3 System, called APO DB; an SAP R/3 Basis; the APO application programs; a separate, very fast object-oriented SAP DB database called liveCache; and a number of programs that execute the optimization algorithms, called optimizers. These components can run on the same or on different servers. OLTP System The Online Transaction Processing system covers functionality for sales and distribution, material and inventory management, controlling, shop floor control, logistic execution, and so on. An Online Analysis Processing system, such as SAP Business Information Warehouse (BW), provides accumulated historical data as a basis for future extrapolation purposes in APO Demand Planning.
OLAP System
2004 SAP AG
OLTP System
SAP R/3 Plug-In RDBMS
SAP APO System
OLAP System
live Cache
RDBMS RDBMS
OLTP System
SAP R/3 Plug-In RDBMS
SAP AG
The various strategies for using SAP R/3 and APO in combination are called integration scenarios. The SAP APO system is connected to one or more SAP R/3 OLTP systems via the APO Core Interface (CIF), which transfers all relevant data between them. The CIF uses queued remote function calls (qRFCs) to ensure the desired sequence and transactional security of data transmissions. For information about solution management for APO CIF, see the respective Best Practice document. You may also use other OLTP systems than SAP R/3. These systems cannot use the CIF for a connection to the APO system, but SAP provides BAPIs (Business Application Programming Interfaces) for programming data supply between third party systems and APO. This scenario is not covered in this document. The SAP APO is the planning component of mySAP SCM. SAP APO is used to make strategic, tactical, and operational decisions and supports you in performing the following planning activities: Demand Planning (DP) Supply Network Planning (SNP) Production Planning (PP) Detailed Scheduling (DS) Deployment Transport Load Builder (TLB) Transport Planning and Vehicle Scheduling (TP/VS) Global Available-to-Promise (gATP)
SAP APO is primarily a planning tool, although some industry specific execution functions are available (such as production backflush for repetitive manufacturing). In standard business scenarios, execution functions such as confirmations, goods receipt, purchasing, and so on are performed in the SAP R/3 OLTP system, which contains all functionality for (among 2004 SAP AG
many others) Material Management MM, Sales and Distribution SD, Production Order Processing PPSFC, Logistics Execution LES, and Controlling CO.
Procedure
Consistency Checks
Overview
Implementing an SAP APO system in your system landscape increases the demand on your interface management and system administration due to the following technical requirements: The data required for planning is held in the liveCache database, which is based on main memory. This data is also stored in the SAP DB. For example, this happens in liveCache 7.2 when a checkpoint is written. The consistency of the information shared by these two storage media is called internal consistency. Implementing SAP APO in your system landscape increases the data exchange between the systems. In particular, a close connection is created between the SAP R/3 systems and SAP APO. Correct, current data is a prerequisite for successful planning activities in SAP APO. This data is exchanged between SAP APO and the dedicated SAP R/3 systems. It is therefore essential that the data in SAP APO and the connected SAP R/3 systems remains consistent. This type of consistency is known as external consistency.
Causes of Inconsistency
There is inconsistency between the systems if one or more of the following has occurred: Incomplete recovery in one of the systems in the system group Incomplete recovery of liveCache or APO DB Manual change to data in SAP R/3 or SAP APO Program errors
Incorrect intervention in the CIF interface, for example deletion of orders without transfer to APO SAP provides standard tools for checking internal and external consistency. How you use the tools depends largely on the solution you have implemented with SAP APO. The basic procedure recommended by SAP is first to establish internal consistency within SAP APO and then to check the external consistency between one SAP APO system and one dedicated SAP R/3 System. As of SAP SCM 4.0 and SAP R/3 Plug-In 2003.1 SAP recommends running CIF Postprocessing after completion of internal and before starting external consistency checks. If more than one SAP R/3 System is connected to an SAP APO system, you must use the corresponding tool for each of these SAP R/3 Systems and the SAP APO system.
2004 SAP AG
The following tables show the tools with relation to the SAP APO applications used. Table 1: Tools for checking internal consistency
Check Tool PP/DS ATP DP SNP TP/VS VMI BOP CTM
Consistency Check for resources /SAPAPO/REST021 As of SAP SCM 4.0 report /SAPAPO/CRES_CAPACITY_LENGTHEN should be used for extending of time streams TP/VS Checks SAPAPO/VSCC1 Temporary quantity assignments /SAPAPO/REBUILD_TQA1 Consistency check for DP and SNP /SAPAPO/TS_LCM_CONS_CHECK Consistency check for schedule line agreements and scheduling agreement confirmations1 /SAPAPO/PWB_KILL_INCO Orders1 Z_CHECK_CONSISTENCY_ORDERS Order operations1 Z_CHECK_CONSISTENCY_OPERATIONS Product allocations TA /SAPAPO/ATPQ_CHKUSG n-handling for CTP rep. /SAPAPO/DMOPR_REORG_CTP Model and version management TA /SAPAPO/MVM
X X X X X X X X X
X X X X X X X X
X X
X X X
X X
Table 2: Tools for checking external consistency

Check Tool PP/D S ATP DP SNP CTM TP/VS VMI BOP
/SAPAPO/CIF_DELTAREPORT3 /SAPAPO/CIF_DELTAREPORT2 (only up to SAP APO 3.0 including SP 19) RCIFORDER_RESERVATIONS_COMPARE /SAPAPO/SDRQCR21 /SAPAPO/VSCC Schedule line agreements and scheduling agreement confirmations /SAPAPO/PWB_KILL_INCO Configuration /SAPAPO/RCUIB_DELETE_CFG RCUIB_SEND_CONFIGURATION IPPE R/3 APO Report IPPECIF_EKG_COMPARE Runtime Objects Report /SAPAPO/CURTO_ORDER_EXPLODE
X X X X X
X X
X X
X X
X X
X X
X X
X X
Check is included in new transaction /SAPAPO/OM17 for APO 3.1 and SCM 4.0 / 4.1
2004 SAP AG
If you are using SAP APO 3.1 or SAP SCM 4.0 /4.1, most of the consistency checks in tables 1 and 2 are available in transaction /SAPAPO/OM17. See also the documentation for this transaction in SAP Service Marketplace.
Checks for Internal Consistency

Backorder Elimination in Capable-to-Promise
The Capable-to-Promise (CTP) process is based on the use of ATP (Available-to-Promise) and PP/DS (Production Planning & Detailed Scheduling) functions. In the CTP process, components and capacities are visibly reserved for parallel transactions during sales order creation. This occurs before the sales order is saved. If the sales order is not saved, the reservation of the components and capacities must be taken back. This means that the procurement elements that were created temporarily must be deleted again. If you terminate the sales order transaction in a controlled fashion, that is, using the corresponding menu options or buttons, the system calls an ABAP function that deletes the orders that are to be deleted in liveCache and in the database. If, however, you end the transaction with /n, the system activates the task handler, which takes control of the data in liveCache. The task handler ensures that the order data is deleted from liveCache. However, it cannot prevent some order data remaining in the database. This remaining data is simply descriptive data that it is not relevant for planning. You can eliminate the backlog using report /SAPAPO/DMOPR_REORG_CTP. For more information on running the report, see SAP Notes 413127 (for SAP APO 3.0) and 426563.
Prerequisites
A prerequisite for using the check report is that you use the CTP scenario.
Process
You can plan report /SAPAPO/DMOPR_REORG_CTP to run regularly (for example, weekly) in the background. You cannot and must not define variants. Parallel processing is not necessary as the runtime is not critical.
Result
The program run deletes the reservations of components and capacities. A results list is not created there is no need to process or work through the results.
Internal Consistency Check for Setup Matrices

As of SAP APO 3.1, you can execute the consistency check for setup matrices using transaction /SAPAPO/OM17. In this case, see the documentation on transaction OM17. In SAP APO 3.0, program Z_MATRIX_CONSISTENCY_CHECK is available through SAP Note 589136. This program makes the same checks as transaction /SAPAPO/OM17 in higher releases. Program Z_MATRIX_CONSISTENCY_CHECK checks the consistency of the data in liveCache and the database. There is an option to generate the inconsistent setup matrices in liveCache. You can do this using program /SAPAPO/MATRIX_TO_LC_SEND. Normally, this occurs when you save the setup matrices in Customizing. However, if a connection error occurs, the transfer must be repeated.
Prerequisites
As well as the case described above (connection error to liveCache), we also recommend running the report before each consistency check for resources.
2004 SAP AG
Process
Report /SAPAPO/MATRIX_TO_LC_SEND does need to not run in parallel processing, as the runtime is not critical. You can run other activities in the system.
Result
You can view the results list in the application log (transaction SLG1). Note that this log is not stored under the user name. You can find it under the object APO and sub-object PPDS.
Internal Consistency Check for Resources

As of SAP APO 3.1 you can run this consistency check report using the central transaction /SAPAPO/OM17. For more information on this, see the documentation on transaction OM17. The internal consistency check for resources checks that the relevant data exists in liveCache and compares the data. (Transaction /SAPAPO/REST02 also, from the initial screen of resource maintenance in menu Tools -> liveCache Check) You can select various options on the selection screen of the report.
Check existence in LC LiveCache check: Checks which resources do not exist in liveCache and produces a list of these resources. Save non-existent resource LC LiveCache save: Checks the resources and generates missing resources in liveCache. The system displays a red traffic light for resources that cannot be saved in liveCache and issues a corresponding error message in the results list.
Save selected resource LC liveCache save: Saves all the resources to liveCache that meet the selection criteria. The system displays a list with yellow traffic lights for those resources for which there is a difference between the database and liveCache. The differences are highlighted in color. The system shows a red traffic light for the resources that could not be saved to liveCache. Corresponding error messages are display in the results list for these resources. You can select resources from the results list and save them to liveCache. You can also navigate to resource maintenance by selecting resources and choosing Change resource. You can also display the time stream in liveCache (times in UTC) by clicking on the time stream GUID and you can display the bucket vector by clicking on the green traffic light in the Bucket Vector column.
Goal and Prerequisites

We recommend using transaction /SAPAPO/REST02 in two cases: After liveCache recovery: First, however, you must run program SAPAPO/MATRIX_TO_LC_SEND, since there are dependencies between the resources and the setup matrices. Missing setup matrices are saved to liveCache. You should then execute transaction /SAPAPO/REST02 so that the resource data can be transferred consistently from the SAP APO database to liveCache. You should execute transaction /SAPAPO/REST02 at regular intervals so that the time streams used in resources are extended. These time streams are not extended automatically in the system: This only occurs if you plan transaction /SAPAPO/REST02 at regular intervals.
Technical System Prerequisites

None.
Process
In the case of recovery, you should execute report SAPAPO/MATRIX_TO_LC_SEND first, which transfers the setup matrices back to liveCache consistently. You can then execute the resource check either directly from the resource maintenance menu by selecting Tools -> liveCache Check, or in the background. The processing method you use depends on the number of resources to be checked.
2004 SAP AG
Performance
The runtime of the check is correlated positively with the number of resources to be checked and the length of the time streams used. This means that an exact value cannot be determined for the runtime. As a general rule, a value of between 2 and 4 resources can be taken, for which checks and repairs can be executed for each second of runtime.
Internal Consistency Check for Temporary Quantity Assignments

The following is only relevant for SAP APO 3.0 with a liveCache version lower than 7.4 Some of the data of the temporary quantity assignments cannot be produced consistently after a recovery, despite a successful checkpoint. Some quantity assignments that have already been released exist again, and temporary quantity assignments are missing. Therefore, you MUST run report /SAPAPO/REBUILD_TQA after every recovery. The report deletes quantity assignments that are no longer required and generates missing quantity assignments. If the report is not available (it is delivered with SAP APO 3.0 support package 21), you can implement it using SAP Note 504133.

Achieving consistency in the temporary quantity assignments after a recovery. IMPORTANT: You MUST run the report after a recovery. The report must never be run during normal operation of the SAP APO system because temporary quantity assignments which are still in use would be deleted. A prerequisite is that you have service pack 21 for SAP APO 3.0 and implement report /SAPAPO/REBUILD_TQA according to SAP Note 504133.
Use
You can execute the consistency check by running report /SAPAPO/REBUILD_TQA. Once you have started the program, choose Execute and confirm the security check. The runtime can be several minutes depending on the data volume.
Verification/Subsequent Processing
If you use backorder processing, you must first delete and then re-execute the backorder processing that was executed AFTER the time stamp of the imported liveCache checkpoint and that has the status buffer or update. This reconstructs the missing persistent quantity assignments. You can determine the time stamp of the imported liveCache checkpoint using transaction /SAPAPO/OM11. If you use ALE third-party order processing in connection with product allocation or checks against forecasting: In this special case, it is not possible to construct all of the corresponding persistent quantity assignments automatically, therefore you have to recheck all the orders that were created and saved in the sales system (SAP R/3 A) but have not yet been transferred to the delivery system (R/3 B) and updated there. You can determine the corresponding orders using table APODELTA in the sales system (R/3 A). Call transaction SE16 and enter APODELTA. Select table content (F7) and Execute (F8). The system then lists all order items (DOC_NUMBER and ITEM_NUMBER) that are saved in the sales system but that have not yet been created in the delivery system. If these order items have executed a product allocation or a check against forecasting in SAP APO, you have to check these items again (transaction VA02) and save them. This reconstructs the missing persistent quantity assignments.
2004 SAP AG
10
If you create orders in a CRM system with product allocation or checks against forecasting, using persistent quantity assignment: In this special case, it is not possible to construct all the corresponding persistent quantity assignments automatically, therefore you have to recheck all the orders that were created and saved in the CRM system but have not yet been transferred to the connected SAP R/3 system and updated there.
For details on the procedure, see SAP Note 435827.
Internal Consistency Check for Procurement Scheduling Agreements

You can run this consistency check report using the central transaction /SAPAPO/OM17. For more information on this, see the documentation on transaction OM17. You can use report /SAPAPO/PWB_KILL_INCO to re-establish consistency of the scheduling agreements. You can make the consistency check either using the central transaction /SAPAPO/OM17 (SAP APO 3.1) or with enhanced possibilities by using transaction SE38 directly. Report /SAPAPO/PWB_KILL_INCO corrects scheduling agreements and releases and confirmations (only available in APO 3.1 and above) if they fulfill the following inconsistency criteria:
The number of input and output nodes is different but not 0. Orders that have no input but that have materials maintained in the vendor location and are contained in a planning version. These orders could lead to errors in the future. Orders, which have different quantities before they have been consumed in the source and target locations. The cumulated quantity of goods receipt and goods issue in liveCache must correspond to the database. Cross check with the set process: The order GUID Ordmap relates to the wrong order type. They exist but are not defined in the process. There are still OLTP scheduling agreement schedule lines although the scheduling agreement in SAP R/3 is already flagged as an SAP APO scheduling agreement. There are still APO scheduling agreement schedule lines although the scheduling agreement in SAP R/3 is already flagged as an OLTP scheduling agreement.
Neither an outbound delivery nor a goods issue exists in the database but they are allocated in liveCache Since the data in liveCache is deleted and recreated, you must proceed with the utmost caution. You should only use the check if inconsistencies have been noted or if liveCache crashes. In the first case, you should focus on one scheduling agreement and in the second case you should check all of the scheduling agreements.

The restoration of consistency between the scheduling agreements following a liveCache recovery. A consistency check as part of a regular maintenance cycle.
First implement SAP Note 414908. While the report is running, you must not process any planning runs, goods receipts, shipping notifications, and so on, that affect the scheduling agreements.
2004 SAP AG
11
Use
In the case of a recovery:
Execute the report in test mode first. This does not change the operational data in any way: It lists all the inconsistent orders that are found. Afterwards, it is possible to correct the inconsistent orders.
In live operation
Normally, you would not expect any inconsistencies in live operation mode. We therefore recommend that you run the report only in test mode.
Runtime/Performance
The runtimes for the report are not critical. You can run the check in parallel. To do this, use suitable selection criteria when creating variants for mass processing.
Internal Consistency Check for In-House Production Orders

In-house production orders can exist in liveCache that do not have any operations in the database table for the operations /SAPAPO/OPR. This leads to planning problems. You can use report Z_CHECK_CONSISTENCY_ORDERS to determine in-house production orders from SAP APO liveCache for which there are no operations in the database table /SAPAPO/OPR. These orders are displayed in a list alongside the output product. Using this information, you can analyze the cause of the inconsistencies (for example incorrect PPM maintenance). To rectify inconsistencies, you should plan report Z_CHECK_CONSISTENCY_ORDERS to run weekly. If this report is not already in your system, you can implement it using the instructions in SAP Note 539199.

To use this correction report, you must be using in-house production orders in PP/DS. This means that you should not need to use this report in any applications other than PP/DS and CTP. This report identifies inconsistent in-house production orders from liveCache. You should run the report following a recovery and, where applicable, at regularly weekly intervals. You should not run the report if you execute multi-user planning. We recommend that you run the report at a time when the system workload is at a minimum (for example at night or during maintenance periods). It is possible to run other consistency checks or repair reports at the same time.
Internal Consistency Check for Operations

You can run this consistency check report using the central transaction /SAPAPO/OM17. For more information on this, see the documentation on transaction OM17. The database table for operations, /SAPAPO/OPR, may contain operations that do not have any orders in liveCache, do not have any operations for a simulation version, or do not have an external operation number. These operations are an unnecessary load on the database table and can lead to poor system performance in some cases.
2004 SAP AG
12

Before you execute the consistency check, you must implement report Z_CHECK_CONSISTENCY_OPERATIONS from SAP Note 458854. This report deletes unnecessary operations from the database. This improves system performance and reduces the load on the database.
Use
Redundant information is deleted from liveCache and the database. We recommend that you run this report weekly.
In test mode (UPDATE flag not set), the system simply issues a log of possible inconsistencies. Depending on the results, you can start the report again with the UPDATE flag set. The superfluous data records are deleted from table /SAPAPO/OPR. No further activities are required.
Internal Consistency Check for Product Allocations

You can also run this consistency check in SAP APO 3.1 using the central transaction /SAPAPO/OM17. For more information on this, see the documentation on transaction OM17. In product allocation, the incoming order quantities are updated directly in liveCache through a direct connection to the planning area. Using transaction /SAPAPO/ATPQ_CHKUSG, you can compare the data in liveCache with the product allocation in the database. If a direct connection is not available, both the time series and the product allocation assignment are in the database and can also be compared with this tool. The transaction allows you to check the data and then correct it. The following checks are possible: Product allocation without (corresponding) incoming order quantity You can copy the total product allocation quantity of the orders to the incoming order quantity in the product allocation group. You should do this if you have: Copied the planning data from the OLTP system to SAP APO using transaction QTSA, overwriting the incoming order quantity in the process. Transferred data from a planning area to a product allocation group, overwriting the incoming order quantity in the process. Changed the incoming order quantity in the planning area (using the direct connection to the planning area) Used the direct connection to the planning area following a liveCache crash.
Incoming order quantity without product allocation If there is an incoming order quantity in a time series that can no longer be traced back to a product allocation (the product allocation is no longer available), you can delete the incoming order quantity with this tool. Product allocation without an existing order item In rare cases, a sales order is deleted and the product allocation remains nonetheless. You can delete this product allocation and, in doing so, reduce the incoming order quantity accordingly.
2004 SAP AG
13
Product allocation without existing product allocation group You find individual assignments without characteristics combinations if the characteristic combination has been deleted. You can also delete individual assignments here. This function does not influence the incoming order quantity. For more details on the individual options of the correction transaction, see the documentation on transaction /SAPAPO/ATPQ_CHKUSG (left mouse click in the SAP Easy Access menu).
Transaction /SAPAPO/ATPQ_CHKUSG is a repair tool that you can use primarily in the rampup phase to check and correct your product allocation data. For example, if you change the definition of the product allocation group or take over the data from other systems (for example, from an R/3 System or via the DP from other systems) for the transportation allocation, this tool enables you to bring together the product allocation data with the already available product allocation to a consistent status. You can also use transaction /SAPAPO/ATPQ_KCGRP_U regularly. This transaction executes the same activities as /SAPAPO/ATPQ_CHKUSG with the check for product allocation assignment without incoming order quantity. The product allocation is compared with the incoming order quantity. If the quantities are different, the system adjusts the incoming order quantity automatically for all affected time series. SAP recommends the use of the repair tools in the ramp-up phase. During the production operation of your system, you can schedule these tools for monitoring your data consistency on a weekly or monthly basis. Note that for a large number of characteristic combinations and a large volume of customer orders, the repair tools require a longer runtime.

This tool establishes consistency between the product allocation assignment of the orders and the incoming order quantity in the product allocation time series (it does not matter whether the time series are used with or without a direct connection to the planning area). After a recovery, the product allocations have to be recreated in the planning area. You must then reactivate the CIF integration model. You cannot execute the transaction until after the order data has been transferred to SAP APO. In operational mode, you can execute the transaction without any particular prerequisites. Note, however, that you must not run a consistency check on the corresponding planning area (/SAPAPO/TS_LCM_COMS_CHK) at the same time.
Use
The repair of inconsistencies with transaction /SAPAPO/ATPQ_CHKUSG is intended only for interactive processing, where you use the result list to choose the time series for which a repair is to be performed. Additionally, you can schedule transaction /SAPAPO/ATPQ_KCGRP_U as a background job, by creating a batch input file for this transaction and letting this batch input file run in the background.
2004 SAP AG
14
Consistency Check for Transportation Planning / Vehicle Scheduling (TP/VS)

You can start this consistency check report using the central transaction /SAPAPO/OM17. For more information on this, see the documentation on transaction OM17. You can check the following data by selecting it on the initial screen of transaction /SAPAPO/VSCC: SAP APO master data that is relevant for TP/VS, for example vehicle resources, transportation lanes, and locations Customizing and optimization profiles SAP R/3 OLTP and SAP APO TP/VS integration and transportation service provider selection settings Consistency between liveCache and TP/VS anchor tables (orders and transfer orders)
Consistency means that for each planned order in liveCache, a transfer order exists in the anchor table and vice versa. If the system finds inconsistencies, they can be repaired to a certain extent using transaction /SAPAPO/VSCC. The corresponding orders are no longer planned (no entry in the anchor tables) or published/unpublished in liveCache (status different in liveCache and anchor tables). The system deletes the inconsistent entries in the anchor tables. Transaction /SAPAPO/VSCC is primarily designed to recognize any inconsistencies. If inconsistencies are displayed and you cannot rectify the inconsistency by navigating forward, open a problem message.

Since transaction /SAPAPO/VSCC checks both the internal and external consistency of transportation planning data, all other consistency checks for external consistency must previously have been executed using /SAPAPO/CIF_DELTAREPORT3, and the relevant data must have been made consistent. This means that the consistency check for transportation planning should be the last check to be executed.
Use
The consistency check for TP/VS can be scheduled daily. As well as running report /SAPAPO/VS_CONS_CHECK online, you can also schedule it with corresponding variants. We are not aware of any performance bottlenecks. You should therefore check the runtime for a consistency check in the productive environment first. It is possible to perform checks in parallel by creating an individual variant for each data object type for background processing. This means that you can run a check for Customizing, master data, relatedrelated objects, and so on.
You process the results using the list produced at the end of the check. You can branch to the corresponding transaction to process the data by clicking on the traffic lights of the individual check results. You can then work through the inconsistencies. If you run the check in the background, you can display the results using the application log (transaction SLG1). Depending on the error priority, you may have to run a new check for the corresponding data object type or rectify the inconsistency directly based on the error message.
2004 SAP AG
15
Internal Consistency Check for SAP APO Models and Versions

You can use central transaction /SAPAPO/OM17 to perform this consistency check. For more information on this, see the documentation on transaction OM17. The model consistency check checks that the master data assigned to a model or work area is complete and that it can be used as a model in SAP APO without inconsistencies. It provides you with important information about the current status of the master data and whether it is suitable for SAP APO planning functions. IMPORTANT: The model consistency check makes logical checks only and does not make any technical checks (such as checking liveCache consistency). You have to run the model consistency check when maintaining master data or after activating the integration models (master data transfer).

The consistency check results in an overview of the completeness or incompleteness of the master data objects within the model concerned. Inconsistencies can be corrected from the log. A prerequisite for using the consistency check is that check profiles exist. You define the scope of the check within the check profile. This means that you specify within the check profile which master data objects are to be involved in the check.
Use
You use online transaction /SAPAPO/CONSCHK to start the model consistency checker. You can also run the check in background processing from the initial screen. Furthermore, you can use transaction SM36 to create a background-processing job and run it in cycles. It is possible to perform checks in parallel by creating a variant for each master data object for background processing.
A log file is issued after you have run transaction /SAPAPO/CONSCHK interactively. You can navigate to corresponding maintenance transactions directly from this log file. This enables you to process the inconsistencies. During background processing, the log file is written to the database and can be processed subsequently using transaction /SAPAPO/CONSSHOW. This subsequent processing is no different to that of the online consistency check.
Internal Consistency Check for Demand Planning, SNP Time Series and SNP Master Data
Report /SAPAPO/TS_LCM_CONS_CHECK_ALL checks all the existing time series networks of Demand Planning. Inconsistencies are displayed for each planning area and version but they cannot be repaired. Report /SAPAPO/TS_LCM_CONS_CHECK makes the same checks as report /SAPAPO/TS_LCM_CONS_CHECK_ALL but only for a selected planning area and, if required, for each planning version. You can activate the 'Repair' option here.
2004 SAP AG
16

This report is used to keep planning areas consistent in SNP and DP. The following consistency checks are made:
Storage buckets profile in liveCache: The system first checks that storage bucket profile exists and then checks that the start dates of the time buckets and the weighting factors are correct. The storage buckets profile settings of the planning area are checked (see transaction /SAPAPO/TR32). Inconsistencies cannot be repaired here. However, inconsistencies here are very rare (an example would be if the fiscal year variant were subsequently changed). Inconsistencies can only be repaired by recreating (initializing) time series. Planning data cannot be restored if you do this. Key figure descriptions in LiveCache (SCM4.0/4.1): The system checks whether the descriptions for the used key figures in the planning area exit and are correctly created in the liveCache. Using the repair option, inconsistencies in the key figure descriptions can be repaired. Time series: The system checks all the characteristic combinations into the planning object structure (database) to see whether the associated liveCache anchor and all associated time series exist in liveCache. Missing anchors or time series are created. These time series are created with an INITIAL status. If data is lost during a liveCache crash, it has to be restored (by restarting a planning run, by reloading historical data from an Info Cube, or by some other action) DP relationships: Here, the system checks the planning object structure and associated aggregates to see that all the relationships exist. It also checks whether there are any redundant relationships. Missing relationships are created; redundant ones are deleted. If the data still exists in the associated planning object structure, DP relationships can be completely restored (with the exception of fixing information). If time series of the planning object structure were recreated with initial values after a liveCache crash, this initial information is also adopted into the DP relationships. When restoring time series of the planning object structure (see above), the DP relationships are adjusted automatically. DP BOM relationships (as of SCM 4.X or APO 3.0, support package 19 (extended form 25)/APO 3.1 support package 03 (extended form 17) or SAP Note 458666 (extended form 636465)): The system checks the existing characteristic combinations and master data to see whether all the relationships between dependent characteristic combinations exist in liveCache. (Characteristic combinations are dependent if they have the same PPM and the same free characteristics.) The system also checks whether the BOM coefficients of the PPMs are consistent with the coefficients in liveCache. A prerequisite for checking the DP BOM relationships is that all characteristic combinations exist. Missing BOM relationships are created, changed BOM coefficients are adjusted.
If time series are used in an SNP planning area in Supply Network Planning, the /SAPAPO/TS_LCM_CONS_CHECK report can also be used to check this time series network and repair inconsistencies, if required. This report is used in the same way here as it is in Demand Planning. It is also possible for the SNP master data to be checked and corrected. However, report /SAPAPO/TS_LCM_CONS_CHECK_ALL cannot be used for SNP planning areas. As of Support Package 17, and in extended form as of Support Package 19, you can also check the consistency of SNP data that is stored in time series. For more details, see SAP Notes 446360 and 441398.
2004 SAP AG
17
If time series are used in an SNP planning area in Supply Network Planning, the report /SAPAPO/TS_LCM_REORG_SNP can also be used. This report is used in a similar way to the report /SAPAPO/TS_LCM_REORG in Demand Planning. For more details, see SAP Note 669287.
Use
The consistency check using report /SAPAPO/TS_LCM_CONS_CHECK can be run independently of other activities in SAP APO. Multiple planning areas or versions can be processed in parallel. To do this, you might have to create several variants for report /SAPAPO/TS_LCM_CONS_CHECK. However, if the Repair option is set, any inconsistencies within the chosen planning area and planning version are repaired. If it is set, no other processes are allowed to be active for the chosen planning area. To ensure this, a corresponding locking logic has been provided in SAP Note 543304 and Support Package 22. You should run report /SAPAPO/TS_LCM_CONS_CHECK regularly in check mode (daily, for instance). You do not have to restrict other system activities here. Before performing planning runs in the background, you should run the /SAPAPO/TS_LCM_CONS_CHECK report in repair mode. No activities with data changes should take place in time series in the version for the planning area. This means that no other activities are allowed to take place within the planning area, version, and time series combination to be checked. CIF changes to orders do not cause problems. It is also possible to plan in a different planning area of the same version. The type and number of inconsistencies are the decisive factor in implementing the repair mode. If a check mode does not find any errors, you do not have to run the procedure for preventing concurrent system activities or repair mode. If there are a large number of inconsistencies, repair mode might have to be used more often than described above to reduce errors in day-to-day planning.
Depending on the processing mode, the report provides a list of all the inconsistencies in the version and the planning area. If repair mode is active, inconsistencies are repaired automatically. However, this does not apply to the storage buckets profile in liveCache. Any storage bucket profile inconsistencies cannot be repaired. However, inconsistencies here are very rare (an example would be if the fiscal year variant were subsequently changed). Inconsistencies can only be repaired by recreating (initializing) time series. Inconsistent master data/PPM cant be repaired, too. This has to be done manually or by reactivating or deleting the PPM from the relevant models.
2004 SAP AG
18
External Consistency Checks

As mentioned previously, you should usually schedule the tools for checking and restoring external data consistency after those for checking and restoring internal data consistency. Different tools are available depending on the application being used.
External Consistency Checks Using CIF Postprocessing

As of SAP SAP SCM 4.0 and SAP R/3 Plug-In 2003.1, CIF error handling can be used for the change transfer of transaction data. It ensures that all queue entries are processed during the data transfer. Faulty objects no longer lead to queue blocks; instead, they are logged in postprocessing records. You can then call these postprocessing records in CIF postprocessing, rectify the errors, and retransfer the objects to the relevant target system. The original sequence of transfers is retained for this. CIF error handling offers you the following options: The logging of faulty transfers in postprocessing records A program for postprocessing the faulty transfers A jump to the application log The postprocessing of faulty transfers by new transfers to the target system. A message issued to the person who triggered the faulty transfer (for example, through an order change) using SAP Office Mail (Express)
See also: Restrictions for CIF error handling that are outlined in SAP Note 602484. You can find release information about earlier SAP R/3 Plug-In releases in the SAP Service Marketplace under R3-Plug-In -> Media Center.
External Consistency Checks Using CIF_ Deltareport3

Report CIF_DELTAREPORT3 can be used to check the external consistency of the majority of transaction data used in APO (such as production orders, planned orders, sales orders, stocks, and so on). It makes the following data checks:
It only checks transaction data It checks that the data exists. It then compares, for example, important quantities and times. The level of detail varies between the different transaction data compared. The quantity is also checked for stocks.

Report /SAPAPO/CIF_DELTAREPORT3 ensures that the data transferred using the Core Interface (CIF) is or remains consistent between SAP R/3 and SAP APO. If inconsistencies between the systems are detected, you can also use this tool to repair them. This report corrects problems quickly and easily. In the majority of cases, CIF can be used to resend the missing data. However, you need to completely understand the CIF model and integration between SAP APO and SAP R/3. This includes knowledge about master and transaction data in the relevant SAP R/3 and SAP APO systems. If inconsistencies occur between the systems, it is always advisable to analyze the causes of the error, to be able to rule out software errors, for instance. Knowledge of ABAP is also useful to be able to perform on-site error analyses. 2004 SAP AG
19
Depending on the system settings in SAP APO, changes to transaction data are only listed and are not transferred synchronously to SAP R/3. This results in these changes being identified as inconsistencies, although they are not. Therefore, it is necessary to set a change pointer when the data is transferred from SAP APO to SAP R/3 before running /SAPAPO/CIF_DELTAREPORT3. You use transaction /SAPAPO/C5 to do this.
Technical System Prerequisites

SAP APO Support Package 19 PI.2001.1 with the associated note prerequisites. See SAP Note 458164.
Use
To start the report in SAP APO 3.0, you use transaction SE38, program name /SAPAPO/CIF_DELTAREPORT3. As of APO 3.1, you can use transaction /SAPAPO/CCR. Online processing: Required entry fields are the Partner System field and at least 1 object type that you want to be checked.
Important Notes
Making fewer restrictions when selecting data and choosing a large variety of object types will cause the runtime of the transaction to be longer. If the quantity of data you have chosen is too large, there is the possibility that a short dump (TIME_OUT) will occur. In this instance, you have to run the report in background processing or reduce the quantity of data.
You should start the compare/reconcile report only if there is a small data load in the Core Interface. For instance, you could do this during the night, when no planning runs that would generate CIF-relevant documents are taking place. Otherwise, the report could display false inconsistencies due to parallel processing. You can use SAP Note 496779 or SAP APO 3.0A to prevent this from happening. You should not start the compare/reconcile report during initial data transfer or a delta compare/reconcile.
Background Processing
Before you can start a background processing run, you have to create suitable variants for program /SAPAPO/CIF_DELTAREPORT3. Note the following when doing this: Compare/reconcile reports can be run in parallel. Create multiple variants for report /SAPAPO/CIF_DELTAREPORT3 (see above). When defining the variants, note that the selected object types cannot overlap. To ensure this, you can assign a dedicated variant to each object type (sales order, production order, purchase requisition, and so on).
You should start the compare/reconcile report only if there is a small data load in the Core Interface. For instance, you could do this during the night, when no planning runs that would generate CIF-relevant documents are taking place. Otherwise, the report could display false inconsistencies due to parallel processing. See SAP Note 496779 from SAP APO 3.0A Support Package 21. You should not start the compare/reconcile report during initial data transfer or a delta compare/reconcile.
Online Processing
Once the compare/reconcile is complete, an output screen appears, displaying an overview of the results. This is done separately according to documents (orders) and stocks. A line is displayed for every object type selected on the screen for comparing, showing the following information: Total: The number of SAP R/3 objects that have been selected for comparison
2004 SAP AG
20
Error: The total number of errors found All other columns: Distribution of errors to individual error areas
A tab page displaying detailed lists of the individual faulty orders or stocks is displayed for every object type that is shown to have errors in the results overview. In the case of orders, there could be additional tab page on every tab page for an incorrect object type listing the orders for each error area. If required, execute a reconcile.
Choose a tab page showing a detailed list of incorrect objects and select the lines you wish to reconcile (to make multiple selections, hold down the CTRL button at the same time). Choose the appropriate button (e,g. Send to APO) to start the reconcile. In the dialog box that appears, confirm that you have initiated the Send.
The current state of the data is read from the database. Depending on the transaction, the data is transferred asynchronously using the standard CIF interface of the object type. A selection icon/deletion icon appears beside the selected lines in the Sent/Action column indicating that the Send has been initiated for the relevant objects. An object that has a selection icon/deletion icon cannot be processed, even if it is reselected for this purpose.
Background Processing
Up to SAP APO 3.1 the spool list is the result of the compare function in background mode. To view the spool list for a job that ended without errors, choose your job in the job overview (transaction SM37), choose Spool, choose your spool list from the spool list overview, and choose Display (F6). As of APO Support Package 7, you also have access to all detailed lists of the faulty objects. To view these, see the spool list beside the summary results overview of the comparison for documents and stocks. As of SAP SCM 4.0 the results of the comparison can be saved in background processing. Then they can be loaded at a later point in time and processed afterwards. The upload does not take as much time as a complete program run. Therefore, you can save a considerable amount of time.
Compare/Reconcile Report Performance

In general, the consistency compare/reconcile of /SAPAPO/CIF_DELTAREPORT3 has four stages. Stage 1: It evaluates the integration models to be checked. The runtime of this stage is linearly related to the size of the integration model. Stage 2: Due to performance reasons, it selects the data parallel from R/3 and APO. We cannot provide a blanket statement about performance for this stage. The runtime is determined by the relationship between filter objects and the data objects to be checked. We cannot provide a general recommendation. For more detailed information, see SAP Note 439438. Stage 3: It checks that the data exists in APO. After the integration models are evaluated and the corresponding data is read from SAP R/3, SAP APO is checked to see that the corresponding data exists here. The runtime is linearly related to the size of the integration model. Stage 4: It checks whether the APO data does NOT exist in the SAP R/3 system. If you have a large integration model, this step will have a shorter runtime.
2004 SAP AG
21
For more information, see SAP Notes 439438 and 451446. To optimize the runtime, change the block size of the filter object. We cannot provide a general recommendation for the block size of the filter object since the ideal setting is always based on the relationship between the filter objects and the data objects to be checked.
Important notes:
Correction of Incorrect Sales Order Requirements

CIF_DELTAREPORT3 cannot repair all inconsistencies in the sales order area.

In such cases the report /sapapo/sdrqcr21 corrects incorrect sales order requirements in R/3 and APO. These inconsistencies can occur due to program errors or by deleting queue entries. If you use backorder processing (BOP), you can use this report to check the consistency of SD order tables (/SAPAPO/posmapn, /SAPAPO/ordadm_i, /SAPAPO/schedlin). BOP relies on these tables being consistent. CIF_DELTAREPORT3 does not include these checks. The report is delivered in the standard version as of the following releases: R/3: APO: R/3 plug-in 2002.2 APO 3.0A Support Package 22 APO 3.10 Support Package11 SCM 4.0
To ensure a proper run of the report, implement SAP Note 444641 and all related notes and prerequisites.
Functions
Order and delivery requirements are first gathered in APO and R/3.When requirements are determined in the R/3 System, reorganization may be executed in line with the functions of the R/3 report sdrqcr21 (table VBBE). The requirements are then compared at field level (MBDAT, open quantity, confirmed quantity, plan quantity, plant, etc.) and the corresponding create/update/delete events sent. If the option to test SD order tables is selected, the system checks that these exist and are consistent. If the report is executed in test mode, neither the table VBBE in the R/3 System with the selectable result of the reorganization is updated, nor are any events sent. If the report is not executed in test mode, the VBBE table may be updated with the result of the reorganization. In addition, events for creating, updating and deleting between SAP APO and SAP R/3 are sent according to the inconsistencies found.
Both the output of the result and the processing of the events can be controlled using different parameters. Caution: if this report is not executed in test mode, this must only be run at a time when no change is made to sales and distribution documents in the system. The report does not change any data directly in APO. Instead, it sends corresponding events from the R/3 System to APO for correction (create/ update/ delete). To ensure that these events can be created, sent and processed correctly and, consequently, the inconsistencies can be eliminated also, implement the list of notes given in SAP Note 444641.
2004 SAP AG
22
Basically, for performance reasons, you need to check the consistency of SD job tables and to clean up entries for closed requirements. Use the /sapapo/sdorder_del APO report for this. However, here you must first implement the most current version with all notes from composite SAP Note 553476 as this has been completely revised. For more details, see the report documentation and the F1 help for the individual entry and selection parameters as soon as the report is available in your APO system.
External Consistency Check for Production Order Items

/SAPAPO/CIF_DELTAREPORT3 is used to check the cross-system consistency of order reservations for production and process orders. The delta report in SAP APO (/SAPAPO/CIF_DELTAREPORT3) only provides a comparison at the order header and main item level.

For SAP APO 3.0 / 3.1you can use report RCIFORDER_RESERVATIONS_COMPARE to compare and, if necessary, reconcile order reservations for production and process orders on a cross-system basis. All production and process orders (that is, all orders that have not been technically completed, have been deleted, or are marked for deletion) are selected according to the selection criteria in SAP R/3. For this, orders are only considered if their end products are contained in an active integration model for production orders for the target system specified. All orders reservations relevant to SAP APO are selected in SAP R/3 and the order reservations themselves are selected in SAP APO for all orders that meet these criteria. Then, the order reservations of the two systems are compared. Order reservations are only compared if the orders exist in both systems. If inconsistencies exist at the order level, these can only be found in SAP APO by using /SAPAPO/CIF_DELTAREPORT3. We recommend that you run /SAPAPO/CIF_DELTAREPORT3 before starting the comparison of order reservations because this enables you to rectify inconsistencies at the order level before the comparison. The comparison can determine the following, cross-system inconsistencies: Reservations in the SAP R/3 order (with quantity still relevant to MRP) that do not exist in the SAP APO order are listed under the category Missing in APO. Reservations in the SAP APO order that do not exist in the SAP R/3 order are listed under the category Missing in R/3. Differences in material or plant in the order reservations are listed under the category Difference in Material/Plant. Differences in the quantity relevant to MRP are listed under the category Difference in Quantity.
Note that a comparison is not made for co-products and by-products.
Use
Report RCIFORDER_RESERVATIONS_COMPARE can be started in dialog mode using transaction SE38 or in background processing if you create a suitable variant and background job. If parallel activities in the system lead to inconsistencies being displayed that do not actually exist, you can execute an iterative comparison that compares again the orders that were identified as inconsistent. This significantly reduces the possibility of an inconsistency being displayed that does not actually exist. Note that this function cannot be executed selectively (only for selected orders). The iteration is executed for all orders that are identified as inconsistent. You are also recommended to check in the corresponding CIF queues to see if the orders concerned are currently in a queue.
2004 SAP AG
23
If you are working in dialog mode, all orders with inconsistencies for order reservations are displayed after the comparison. To receive detailed information about the inconsistencies, you can use the Display Faulty Reservations for Order function to display all inconsistencies along with the relevant error category Note that this function displays the details for the order on which the cursor is currently placed. To rectify the inconsistencies, the report enables you to retransfer the orders from SAP R/3 to SAP APO. This adjusts the orders in SAP APO to the current status of the SAP R/3 orders. Once you have done this, the orders should no longer display any inconsistencies. The block size on the initial selection screen is used to define the number of orders that are transferred in each LUW when data is reconciled from SAP R/3 to SAP APO. This function is executed for all orders that you have marked in the dialog. After the reconciliation, you should again execute an iterative comparison to repeat the comparison for orders that were identified as inconsistent. This enables you to check whether the orders have been transferred correctly. Note that this function cannot be executed selectively (only for selected orders). The iteration is executed for all orders that are identified as inconsistent. You are also recommended to check in the corresponding CIF queues to see if the (faulty) orders concerned are currently in a queue. You can also check this using the delta report in SAP APO. After a comparison in the background, the inconsistencies that were found are logged in detail for each order in the spool list. Under print options, you should select a report width of at least 140 columns to ensure that you receive all information about the inconsistent reservations in the spool list. If the comparison is executed using Reconcile Errors Automatically, the inconsistencies that are found are reconciled using an automatic retransfer of the orders from SAP R/3 to SAP APO. Only use this option if you have made extensive tests in dialog mode. See also SAP Notes 542805 and 538111. Important: As of SAP SCM 4.0 the functions of report RCIFORDER_RESERVATIONS_COMPARE are contained in /SAPAPO/CIF_DELTAREPORT3, which means that report RCIFORDER_RESERVATIONS_COMPARE is no longer necessary.
External Consistency Check for TP/VS

You use transaction /SAPAPO/VSCC to ensure external data consistency for the application Transportation Planning and Vehicle Scheduling. Since transaction /SAPAPO/VSCC checks both the internal and external consistency of transportation planning data, all other consistency checks for external consistency must previously have been executed using /SAPAPO/CIF_DELTAREPORT3, and the relevant data must have been made consistent. This means that the consistency check for transportation planning should be the last check to be executed. For more details about using the report, see the Internal Data Consistency section.
2004 SAP AG
24
External Consistency Check for Faulty Configurations

Program errors, faulty transfers, or transfers that have been terminated can lead to inconsistent data statuses for configurations in SAP APO. Possible errors could be terminations during the transfer of configurations for example, when changing sales orders or when deleting orders. There is currently no consistency check for configurations. The only possibility to restore data consistency is to delete the configurations using report /SAPAPO/RCUIB_DELETE_CFG (this report is available as of SAP APO 3.0 Support Package 19 (SAPKY30A19) and as of SAP APO 3.1 Support Package 3 (SAPKY31003); it can also be installed using SAP Note 457988). You should only do this if this configuration is no longer used. Then, the configurations can be retransferred from SAP R/3 to SAP APO using report RCUIB_SEND_CONFIGURATION. This function is the same as an initial data transfer and any existing configurations in SAP APO are overwritten. The report only transfers configurations. It does not transfer configured sales orders, and so on.

Prerequisites for a successful transfer:
Master data exists in SAP APO (characteristics, products, and so on) Configured objects exist in SAP APO. This means that the sales orders exist in SAP APO, only the configuration is faulty or missing.
Use
It is not currently possible to determine data inconsistencies for configurations. However, report /SAPAPO/RCUIB_DELETE_CFG requires an exact specification of the configuration to be deleted. For this reason, it is not possible to recommend a regular procedure for avoiding inconsistencies. The tool can only be used to rectify inconsistencies that have already been identified.
After the configuration(s) have been deleted, they have to be retransferred from SAP R/3. To do this, use report RCUIB_SEND_CONFIGURATION.
External Consistency Check for Integrated Product and Process Engineering (iPPE)
If an iPPE model is transferred to SAP APO, this model can be compared between SAP R/3 and SAP APO using the report IPPECIF_EKG_COMPARE. You start the comparison tool by calling this report via SE38 in SAP R/3. Enter the production versions to be compared and the relevant SAP APO system. You then receive an overview of all inconsistencies in the iPPE model between SAP R/3 and SAP APO.

The aim of this report is to ensure data consistency between SAP R/3 and SAP APO for iPPE.
Use
The comparison tool can be used online or in the background. It is possible to parallelize the process by creating suitable variants. For example, it is possible to process different plants in parallel.
2004 SAP AG
25
External Consistency Check for PP/DS runtime objects

As of SAP SCM 4.1 and PI 2004.1 R/3 master data can be compared with the corresponding PPDS runtime objects in APO. With report /SAPAPO/CURTO_ORDER_EXPLODE data can be compared or if necessary transferred again.
The following options are available:
1.
Comparison of the change date
On the basis of the last change in R/3 it can be checked, if the data still have been transferred to APO or not. The following results are possible: inconsistent master data exist
The results are listed and can be transferred again, compared again or a protocol can be displayed. When starting a new transfer, the existing PPDS runtime objects are overwritten. Objects without errors get a green status. When starting a new comparison, they are no longer compared. no inconsistent master data exist
You are directly routed to the application log.
2.
Comparison of the results of the master data explosion
A manufacturing order is simulated on R/3 and on APO side to compare the consistency of the master data on both sides. Here you can get a detailed list of inconsistent data. The R/3 and APO master data explosion result including operations, phases, input- and output products and relationships are listed next to each other in a tree. It is now possible to transfer again.
Comparison in the background For background processing it can be determined, if PP/DS runtime objects should be transferred automatically, when inconsistent data have been detected or if just a protocol should be written.
Prerequisites This report just compares APO relevant data like routing/recipe, production version, work center, components. On R/3 side, relevant data for creating a manufacturing order have to exist. An active integration model for the PP/DS runtime object has to exist as well.
Restrictions Using customer exits or BAdIs, to modify the results of master data explosion it is necessary to adapt them, when for the comparison your modifications should be taken in account.
2004 SAP AG
26
The Consistency Check Process

Measures before the Check
Before executing an external consistency check, you have to ensure that SAP APO is consistent internally. The procedure and the number of checks needed depend on the applications that you want to use in your SAP APO system. Therefore, the steps for each individual application are described below, along with detailed explanations. The general procedure, which is independent of a specific version, is as follows:
Lock the Users

For some stages of a consistency check between liveCache and the APO database, there are not allowed to be any active processes in the SAP APO system (this depends on the object being checked). Therefore, all users apart from administrators should be locked. The descriptions of the individual check programs specify whether a lock is required for that specific program. For all SAP APO release levels, you can use transaction /SA PAPO/OM17 and the option Lock/Unlock Users to activate the lock.
Check and End System Activities

Within transaction /SAPAPO/OM17, choose the option Overview of Active Users/Tasks/Jobs. Users who are already logged on have to leave the system and scheduled background jobs must be stopped for the duration of the consistency check. Messages can be sent to the users affected. Active tasks and jobs must be terminated or you have to wait until they have finished.
Lock CIF Queues

Depending on the object to be checked, it may also be necessary to stop CIF queues so that data transfers are not made from the OLTP system(s) for the duration of the consistency check. If you are using INBOUND queues, you can stop the transfer by using report RSTRFCI1. If you are using OUTBOUND queues, you have to use transaction SMQ1 and program RSTRFCQ1 in the relevant OLTP system(s) to stop the transfer.
Select the Objects to be Checked and the Scope of the Check

For more details, see the relevant sections.
Execute the Consistency Check

Results Overview and Rectifying the Inconsistencies

Unlock the CIF Queues

After the consistency checks or once you have restored internal data consistency, you can restart the CIF queues. If you are using inbound queues, use report RSTRFCQ3. If you are using outbound queues, you have to restart the queues using transaction SMQ1 and program RSTRFCQ3. Release the background jobs that you stopped earlier.
2004 SAP AG
27
Executing the Consistency Check

There is a difference between the consistency check in SA P APO 3.0 and SAP APO 3.1 For SAP APO 3.1, the consistency check can mostly be made using the redesigned transaction /SAPAPO/OM17. For detailed documentation about this new transaction, see SAP Service Marketplace - Solution Details Cross Industry Solutions - My SAP Supply Chain Management MySAP SCM Technology Consistency Checks SAP APO 3.1 OM17. If differences exist for the procedure between SAP APO 3.0 and SAP APO 3.1, this is indicated in the relevant sections.
Consistency Check for PP/DS

1. Check Procedure/Restoration of Internal Consistency.
Sequence Object for Consistency Check 0 Setup matrices Check Tool Check Frequency Exists in New OM17 ? Parallel Processing N
/SAPAPO/MATRIX_TO_LC_SEND See note 589136 APO 3.1: Tcode /SAPAPO/OM17
Once a day if Y needed
Resources
APO 3.0: Transaction /SAPAPO/REST02 APO 3.1, SCM 4.0 / 4.1: Transaction /SAPAPO/OM17
Pegging Areas
Tcode /SAPAPO/OM17
If needed Y once per day If needed once per month After initial data load or class changes within R/3 Only if errors occur N
Pegging Areas make-to-order scenario CDP classes
APO 3.0/3.1: /SAPAPO/PEGKEY_REORG SAP SCM 4.0 / 4.1: /SAPAPO/DM_PEGKEY_REORG APO 3.1 note 597248
Procurement Scheduling Agreements
APO 3.0 report /SAPAPO/PWB_KILL_INCO APO 3.1: Transaction /SAPAPO/OM17
2004 SAP AG
28
Sequence Object for Consistency Check 3
Check Tool
Check Frequency
Exists in New OM17 ? Y
Parallel Processing N
Order operations APO 3.0 report Z_CHECK_CONSISTENCY_OPERATIONS APO 3.1: Transaction /SAPAPO/OM17
458854
Please see the following notes for additional modification reports if needed: 458854 Reorganizing the operation table 539199 Make-to-order production orders for APO 3.0 und 3.1 574976 Inconsistencies with order status/operation status for APO 3.0 und 3.1
3 4
Campaigns Handling for CTP
APO 3.1: Tcode /SAPAPO/OM17 /SAPAPO/DMOPR_REORG_CTP
If needed Y once per day If needed (e.g. CTP used) once per week (depends on volume) N
N N
Models & versions
APO 3.0 / 3.1, SCM 4.0 / 4.1: report /SAPAPO/CONSCHK
2. Check Procedure/Restoration of External Consistency

Sequence Object for Consistency Check Configuration Check Tool Check Freque ncy Exists in New OM17 (APO3.1) N Parallel Processing
/SAPAPO/RCUIB_DELETE_CFG RCUIB_SEND_CONFIGURATION
CDP classes
APO 3.1 SAP Note 597394
After N initial data load or class changes within R/3 Once a day if needed N
Planned orders Production orders Sales orders Purchase requisitions Purchase orders Confirmations Stocks
Report /SAPAPO/CIF_DELTAREPORT3
2004 SAP AG
29
Sequence
Object for Consistency Check Sales Order requirements
Check Tool
Check Freque ncy
Exists in New OM17 (APO3.1)
Parallel Processing
/SAPAPO/SDRQCR21 see note 444641
After N Deltarep ort3 if needed After delta report 3 After Deltatransfer of iPPE data, if needed. N
Production orders
Report RCIFORDER_RESERVATIONS_COMPARE Report IPPECIF_EKG_COMPARE
iPPE
PP/DS runtime object
Report SAPAPO/CURTO_ORDER_EXPLODE
Consistency Checks for SNP, CTM and VMI

Check Procedure/Restoration of Internal Consistency
The following sequence of internal consistency checks is recommended for SNP:
Sequence Object for Consistency Check 1 Resources Check Tool Check Exists in Frequen New OM17 cy (APO3.1) Once a day if needed Once a day if needed Y Parallel Processing Y
APO 3.0: Transaction /SAPAPO/REST02 APO 3.1, SCM 4.0 / 4.1: Transaction /SAPAPO/OM17
Time series objects
APO 3.0 / 3.1, SCM 4.0 / 4.1 Report: /SAPAPO/TS_LCM_CONS_CHECK /SAPAPO/TS_LCM_CONS_CHECK_ALL /SAPAPO/TS_LCM_REORG_SNP
Limited Y
Order operations (only for CTM)
APO 3.0 report Z_CHECK_CONSISTENCY_OPERATIONS APO 3.1, SCM 4.0 / 4.1: Transaction /SAPAPO/OM17
Models & versions
Once a day if needed
2004 SAP AG
30
Check Procedure/Restoration of External Consistency

Sequence Object for Consistency Check 1 Planned orders Production orders Sales orders Purchase requisitions Purchase orders Confirmations Stocks 2 Sales Order requirements /SAPAPO/SDRQCR21 see note 444641 After Deltareport3 if needed N N Check Tool Check Frequency Once a day if needed Exists in New OM17 (APO3.1) N Parallel Processing Y
Report /SAPAPO/CIF_DELTAREPORT3
Check Procedure/Restoration of Internal Consistency for DP

Sequence Object for consistency Check 1 Time series objects Check Tool Check Freq. Once a day if needed Exists in new OM17 (APO3.1) Y Parallel Processing N
APO 3.0 / 3.1, SCM 4.0 / 4.1 Report: /SAPAPO/TS_LCM_CONS_CHECK /SAPAPO/TS_LCM_CONS_CHECK_ALL
Consistency Checks for ATP

Product availability check: This type of availability check is carried out on the basis of the ATP quantity (Available-to-Promise). The ATP quantity is calculated from stock, planned receipts (production orders, purchase orders, planned orders, and so on), and planned requirements (sales orders, deliveries, reservations, and so on). Depending on the operation, this type of availability check makes dynamic checks with or without the check horizon, taking into account stocks and planned goods movements. A consistency check is made as follows for this scenario:
Sequence Object for Consistency Check 1 Temporary quantity assignments Handling for CTP Check Tool Check Frequency Exists in New OM17 (APO3.1) Parallel Processing Y
APO 3.0 transaction /SAPAPO/REBUILD_TQA APO 3.0 / 3.1, SCM 4.0 / 4.1: report /SAPAPO/DMOPR_REORG_CTP
After liveCache N recovery Once a day if needed N
Models & versions
Limited Y
2004 SAP AG
31
Check Procedure/Restoration of External Consistency

Sequenc e Object for Consistency Check Check Tool Check Frequency Exists in Parallel New Processing OM17 (APO3.1 ) N N
Configuration
APO 3.0 / 3.1, SCM 4.0 / 4.1: /SAPAPO/RCUIB_DELETE_CFG RCUIB_SEND_CONFIGURATION
Schedule line agreements Planned orders Production orders Sales orders Purchase requisitions Purchase orders Confirmations Stocks
APO 3.0 / 3.1, SCM 4.0 / 4.1: /SAPAPO/PWB_KILL_INCO APO 3.0 / 3.1, SCM 4.0 / 4.1: Report /SAPAPO/CIF_DELTAREPORT3 Once a day if needed
Sales Order requirements
APO 3.0 / 3.1, SCM 4.0 / 4.1: /SAPAPO/SDRQCR21 see note 444641
After Deltareport 3 if needed
Production orders
APO 3.0 / 3.1, SCM 4.0 / 4.1: Report
RCIFORDER_RESERVATIONS_COM DELTAREP PARE

ORT3 6 iPPE APO 3.0 / 3.1, SCM 4.0 / 4.1: Report IPPECIF_EKG_COMPARE
After N /SAPAPO/C IF_
After Y Deltatransfe r of iPPE data, if needed.
Internal Consistency Checks for Backorder Processing

Sequence Object for Consistency Check 1 Temporary quantity assignments Time series objects Check Tool Check Frequency Directly after liveCache recovery Once a day if needed Exists in New Parallel OM17 Processing (APO3.1) N Y
APO 3.0 transaction /SAPAPO/REBUILD_TQA APO 3.0 / 3.1, SCM 4.0 / 4.1: report /SAPAPO/TS_LCM_CONS_CHECK /SAPAPO/TS_LCM_CONS_CHECK_ALL
Limited Y
Product allocations
APO 3.0 / 3.1, SCM 4.0 / 4.1: transaction /SAPAPO/ATPQ_CHKUSG
2004 SAP AG
32
Sequence Object for Consistency Check 4 Models & versions
Check Tool
Check Frequency Once a day if needed
Exists in New Parallel OM17 Processing (APO3.1) Y Y
External Consistency Checks for Backorder Processing

Sequence Object for Consistency Check Check Tool Monitor Exists in Frequenc New y OM17 (APO3.1) Y Parallel Processing
Configuration
APO 3.0 / 3.1, SCM 4.0 / 4.1: /SAPAPO/RCUIB_DELETE_CFG RCUIB_SEND_CONFIGURATION
Schedule line agreements Planned orders Production orders Sales orders Purchase requisitions Purchase orders Confirmations Stocks
APO 3.0 / 3.1, SCM 4.0 / 4.1: /SAPAPO/PWB_KILL_INCO APO 3.0 / 3.1, SCM 4.0 / 4.1: Once a day if Report /SAPAPO/CIF_DELTAREPORT3 needed
Production orders
APO 3.0 / 3.1, SCM 4.0 / 4.1: Report
After delta N report 3
RCIFORDER_RESERVATIONS_CO MPARE
5 Sales Order requirements APO 3.0 / 3.1, SCM 4.0 / 4.1: /SAPAPO/SDRQCR21 see note 444641 6 iPPE APO 3.0 / 3.1, SCM 4.0 / 4.1: Report IPPECIF_EKG_COMPARE After Deltarepo rt3 if needed N N
After Y Deltatrans -fer of iPPE data, if needed.
Internal Consistency Checks for Product Allocation

After a recovery, the product allocations have to be recreated in the planning area. In contrast to the usual procedure, the CIF integration model must be activated AFTER the product allocations have been made. Transaction /SAPAPO/ATPQ_CHKUSG can only be executed after the order data has been transferred to SAP APO. Transaction /SAPAPO/ATPQ_ALERT must then also be executed to identify any shortfalls that may exist.
2004 SAP AG
33
Sequence Object for Consistency Check 1 Time series objects
Check Tool
Monitor Exists in Frequency New OM17 (APO3.1) Once a day N if needed
Parallel Processing Limited Y
APO 3.0 / 3.1, SCM 4.0 / 4.1: report /SAPAPO/TS_LCM_CONS_CHECK /SAPAPO/TS_LCM_CONS_CHECK_ALL
Product allocations Product allocations
APO 3.0 / 3.1, SCM 4.0 / 4.1: transaction /SAPAPO/ATPQ_CHKUSG APO 3.0 / 3.1, SCM 4.0 / 4.1: TA /SAPAPO/ATPQ_ALERT
After step 2 N
Consistency Checks for TP/VS

Sequence Object for Consistency Check 1 TP/VS checks Check Tool Monitor Exists in Frequency New OM17 (APO3.1) Once a day if needed Parallel Processing
APO 3.0: Transaction /SAPAPO/VSCC APO 3.1: Transaction /SAPAPO/OM17
Models & versions
2004 SAP AG
34
Further Information
Troubleshooting
If the information contained in this Best Practice did not produce the desired results, check whether the following SAP Notes provide a solution to your problem: 602484 597248 589136 574976 543304 539199 538111 504133 458854 458666 451446 446360 444641 441398 439438 425825 414908 410696 407708 399709 397840 397533 397362 391780 391408 389193 387236 387201 Restrictions CIF error handling/postprocessing Report for the consistency check of CDP master data II Consistency check for setup matrices Inconsistencies with order status/operation status TS_LCM_CONS_CHECK: Optional lock for planning version Make-to-order production orders in LC without operations Compare and reconcile production order reservations Report for processing temp. qty. assgnmts after LC recovery Reorganizing the operation table DP-BOM functions in the report /SAPAPO/TS_LCM_CONS_CHECK Delta report: Variable filter object size for data Repair tool for versions of a SNP planning area (2) Correction of incorrect sales order requirements with APO Repair tool for versions of a SNP planning area Collective note: CIF delta report performance Consistency Checks /SAPAPO/OM17/SAPAPO/CIF_DELTAREPORT Shipping notif. incorrectly consumed with sched. ag. rel. Performance-improvement of Compare & Refresh - Tool Stock interface: enhanced application log Initial data transfer: Some data are not transferred Delta report:APO sched.agreement delivery schedule lines Delta report performance: Stock comparison Only 100 planned orders transferred from R/3 to APO Long runtime for sales order comparison /SAPAPO/CCR comparison report reports crashes Comparison report performance for planned orders Comparison tool: Performance improvement new R/3 extractors Performance comparison report for manufacturing orders
If you experience problems with the delta report functions, create a SAPNet message in SAPNet R/3 frontend under the component APO-INT. http://service.sap.com/message.
2004 SAP AG
35
Background Information and References

Important: Check SAPNet regularly to see if new notes exist for the area SAPAPO/CIF_DELTAREPORT. In particular, you are recommended to check composite SAP Note 439438.
Known Problems
A heavy data load at the interface can lead to inconsistencies being reported that do not actually exist. This is because the data that is being transferred cannot be posted fast enough. A retransfer has no effect/the inconsistency cannot be rectified. Use qRFC monitor to check the relevant entry in the queue and then use the error number specified to find a relevant note in OSS. If this procedure and the debugging of the relevant queue does not produce any results, create an OSS message for SAP. Provide details about the queue name and all relevant logon data for your system.
Feedback and Questions

If you have any feedback, send an SAP customer message to component SV-GST. You can do this at http://service.sap.com/message.
Copyright 2004 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation. ORACLE is a registered trademark of ORACLE Corporation. TM INFORMIX-OnLine for SAP and Informix Dynamic Server are registered trademarks of Informix Software Incorporated. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies. Disclaimer: SAP AG assumes no responsibility for errors or omissions in these materials. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party Web pages nor provide any warranty whatsoever relating to third party Web pages.
2004 SAP AG

Internal and External Consistency

Uploaded by

Copyright:

Available Formats

Internal and External Consistency

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internal and External Consistency

Uploaded by

Copyright:

Available Formats

Internal and external consistency for SAP APO (3.x) / mySAP SCM (4.

Internal and external consistency for SAP APO

Applicability, Goals and Requirements

Staff and Skill Requirements

Internal and external consistency for SAP APO

Internal and external consistency for SAP APO

SAP R/3 Plug-In RDBMS

SAP APO System

SAP R/3 Plug-In RDBMS

Internal and external consistency for SAP APO

Internal and external consistency for SAP APO

Table 2: Tools for checking external consistency

Internal and external consistency for SAP APO

Checks for Internal Consistency

Internal Consistency Check for Setup Matrices

Internal and external consistency for SAP APO

Internal Consistency Check for Resources

Goal and Prerequisites

Technical System Prerequisites

Internal and external consistency for SAP APO

Internal Consistency Check for Temporary Quantity Assignments

Goal and Prerequisites

Internal and external consistency for SAP APO

For details on the procedure, see SAP Note 435827.

Internal Consistency Check for Procurement Scheduling Agreements

Goal and Prerequisites

Internal and external consistency for SAP APO

Internal Consistency Check for In-House Production Orders

Goal and Prerequisites

Internal Consistency Check for Operations

Internal and external consistency for SAP APO

Goal and Prerequisites

Internal Consistency Check for Product Allocations

Internal and external consistency for SAP APO

Goal and Prerequisites

Internal and external consistency for SAP APO

Consistency Check for Transportation Planning / Vehicle Scheduling (TP/VS)

Goal and Prerequisites

Internal and external consistency for SAP APO

Internal Consistency Check for SAP APO Models and Versions

Goal and Prerequisites

Internal and external consistency for SAP APO

Goal and Prerequisites

Internal and external consistency for SAP APO

Internal and external consistency for SAP APO

External Consistency Checks

External Consistency Checks Using CIF Postprocessing

External Consistency Checks Using CIF_ Deltareport3

Goal and Prerequisites

Internal and external consistency for SAP APO

Technical System Prerequisites

Internal and external consistency for SAP APO

Compare/Reconcile Report Performance

Internal and external consistency for SAP APO

Correction of Incorrect Sales Order Requirements

Goal and Prerequisites

Internal and external consistency for SAP APO

External Consistency Check for Production Order Items

Goal and Prerequisites

Note that a comparison is not made for co-products and by-products.