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

© 2004 SAP AG

2

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

3

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.

OLAP System 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.


© 2004 SAP AG

4

SAP R/3 Plug-In

OLTP System

RDBMS

SAP R/3 Plug-In

OLTP System

RDBMS

RDBMS

SAP APO System

liveCache

liveCache

OLAP System

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

5

many others) Material Management MM, Sales and Distribution SD, Production Order Processing PP-SFC, 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

6

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

X X X X X

TP/VS Checks SAPAPO/VSCC1

X

Temporary quantity assignments /SAPAPO/REBUILD_TQA1

X X

Consistency check for DP and SNP /SAPAPO/TS_LCM_CONS_CHECK

X X X

Consistency check for schedule line agreements and scheduling agreement confirmations1

/SAPAPO/PWB_KILL_INCO

X X X

Orders1 Z_CHECK_CONSISTENCY_ORDERS

X X X X

Order operations1 Z_CHECK_CONSISTENCY_OPERATIONS

X X X X

Product allocations TA /SAPAPO/ATPQ_CHKUSG

X X

n-handling for CTP rep. /SAPAPO/DMOPR_REORG_CTP

X X

Model and version management TA /SAPAPO/MVM

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 X X X X X X /SAPAPO/CIF_DELTAREPORT2 (only up to SAP APO 3.0 including SP 19)

X X X X X X

RCIFORDER_RESERVATIONS_COMPARE X /SAPAPO/SDRQCR21 X X X X X X /SAPAPO/VSCC X Schedule line agreements and scheduling agreement confirmations /SAPAPO/PWB_KILL_INCO

X

Configuration /SAPAPO/RCUIB_DELETE_CFG RCUIB_SEND_CONFIGURATION

X X

IPPE R/3 ⇔ APO Report IPPECIF_EKG_COMPARE

X X

Runtime Objects Report /SAPAPO/CURTO_ORDER_EXPLODE

X

1 Check is included in new transaction /SAPAPO/OM17 for APO 3.1 and SCM 4.0 / 4.1


© 2004 SAP AG

7

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

8

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

9

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.

Goal and Prerequisites 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.

Goal and Prerequisites 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.

Goal and Prerequisites 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

Goal and Prerequisites 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.

Verification/Subsequent Processing 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 ramp-

up 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.

Goal and Prerequisites 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.

Goal and Prerequisites 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, related-related objects, and so on.

Verification/Subsequent Processing 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).

Goal and Prerequisites 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.

Verification/Subsequent 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

Goal and Prerequisites 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.

Verification/Subsequent Processing 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 can’t 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.

Goal and Prerequisites 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.

Verification/Subsequent Processing

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

Important notes: • 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.

Correction of Incorrect Sales Order Requirements CIF_DELTAREPORT3 cannot repair all inconsistencies in the sales order area.

Goal and Prerequisites 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: R/3 plug-in 2002.2

APO: 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.

Goal and Prerequisites 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

Verification/Subsequent Processing 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.

Goal and Prerequisites 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.

Verification/Subsequent Processing 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.

Goal and Prerequisites 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 For more details, see the relevant sections.

Results Overview and Rectifying the Inconsistencies For more details, see the relevant sections.

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

Check Tool Check Frequency

Exists in New OM17 ?

Parallel Processing

0 Setup matrices /SAPAPO/MATRIX_TO_LC_SEND

See note 589136

APO 3.1: Tcode /SAPAPO/OM17

Once a day if needed

Y N

1 Resources APO 3.0: Transaction /SAPAPO/REST02

APO 3.1, SCM 4.0 / 4.1:

Transaction /SAPAPO/OM17


Y Y

2 Pegging Areas Tcode /SAPAPO/OM17

If needed once per day

Y N

2 Pegging Areas ‚make-to-order scenario’

APO 3.0/3.1: /SAPAPO/PEGKEY_REORG SAP SCM 4.0 / 4.1: /SAPAPO/DM_PEGKEY_REORG

If needed once per month

N N

3 CDP classes APO 3.1 note 597248 After initial data load or class changes within R/3

N N

2 Procurement Scheduling Agreements

APO 3.0 report /SAPAPO/PWB_KILL_INCO

APO 3.1: Transaction /SAPAPO/OM17

Only if errors occur

Y Y


© 2004 SAP AG

28



Exists in New OM17 ?

Parallel Processing

3 Order operations

458854

APO 3.0 report

Z_CHECK_CONSISTENCY_OPERATIONS

APO 3.1: Transaction /SAPAPO/OM17 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

Y N

3 Campaigns APO 3.1: Tcode /SAPAPO/OM17 If needed once per day

Y N

4 Handling for CTP

/SAPAPO/DMOPR_REORG_CTP If needed (e.g. CTP used) once per week (depends on volume)

N N

5 Models & versions

APO 3.0 / 3.1, SCM 4.0 / 4.1:

report /SAPAPO/CONSCHK


Y Y

2. Check Procedure/Restoration of External Consistency Sequence Object for

Consistency Check


Exists in New OM17 (APO3.1)

Parallel Processing

1 Configuration /SAPAPO/RCUIB_DELETE_CFG

RCUIB_SEND_CONFIGURATION

N N

2 CDP classes APO 3.1 SAP Note 597394 After initial data load or class changes within R/3

N N

3 Planned orders

Production orders

Sales orders

Purchase requisitions

Purchase orders

Confirmations

Stocks

Report /SAPAPO/CIF_DELTAREPORT3 Once a day if needed

N Y


© 2004 SAP AG

29




Parallel Processing

4 Sales Order requirements

/SAPAPO/SDRQCR21

see note 444641

After Deltareport3 if needed

N N

5 Production orders Report RCIFORDER_RESERVATIONS_COMPARE

After delta report 3

N N

6 iPPE Report IPPECIF_EKG_COMPARE After Delta-transfer of iPPE data, if needed.

Y Y

7 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:




Parallel Processing

1 Resources APO 3.0: Transaction /SAPAPO/REST02

APO 3.1, SCM 4.0 / 4.1:



Y Y

2 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


N Limited Y

3 Order operations (only for CTM)

APO 3.0 report

Z_CHECK_CONSISTENCY_OPERATIONS

APO 3.1, SCM 4.0 / 4.1:


Y N

4 Models & versions

APO 3.0 / 3.1, SCM 4.0 / 4.1:



Y Y


© 2004 SAP AG

30

Check Procedure/Restoration of External Consistency Sequence Object for

Consistency Check Check Tool Check

Frequency Exists in New OM17 (APO3.1)

Parallel Processing

1 Planned orders

Production orders

Sales orders


Purchase orders

Confirmations

Stocks

Report /SAPAPO/CIF_DELTAREPORT3


N Y


/SAPAPO/SDRQCR21

see note 444641


N N

Check Procedure/Restoration of Internal Consistency for DP

Sequence Object for consistency Check

Check Tool Check Freq.

Exists in new OM17 (APO3.1)

Parallel Processing


APO 3.0 / 3.1, SCM 4.0 / 4.1

Report:




Y N

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:




Parallel Processing

1 Temporary quantity assignments

APO 3.0 transaction /SAPAPO/REBUILD_TQA

After liveCache recovery

N Y

3 Handling for CTP APO 3.0 / 3.1, SCM 4.0 / 4.1:

report

/SAPAPO/DMOPR_REORG_CTP


N N

4 Models & versions APO 3.0 / 3.1, SCM 4.0 / 4.1:



N Limited Y


© 2004 SAP AG

31

Check Procedure/Restoration of External Consistency

Sequence

Object for Consistency Check



Parallel Processing

1 Configuration APO 3.0 / 3.1, SCM 4.0 / 4.1:

/SAPAPO/RCUIB_DELETE_CFG


N N

2 Schedule line agreements

APO 3.0 / 3.1, SCM 4.0 / 4.1:


Y N

3 Planned orders

Production orders

Sales orders


Purchase orders

Confirmations

Stocks

APO 3.0 / 3.1, SCM 4.0 / 4.1:



Y Y


APO 3.0 / 3.1, SCM 4.0 / 4.1:

/SAPAPO/SDRQCR21

see note 444641


N N

5 Production orders APO 3.0 / 3.1, SCM 4.0 / 4.1:

Report RCIFORDER_RESERVATIONS_COMPARE

After /SAPAPO/CIF_

DELTAREPORT3

N N

6 iPPE APO 3.0 / 3.1, SCM 4.0 / 4.1:

Report IPPECIF_EKG_COMPARE

After Deltatransfer of iPPE data, if needed.

Y Y

7 PP/DS runtime object Report


Internal Consistency Checks for Backorder Processing Sequence Object for

Consistency Check



Parallel Processing

1 Temporary quantity assignments

APO 3.0 transaction /SAPAPO/REBUILD_TQA

Directly after liveCache recovery

N Y

? Time series objects

APO 3.0 / 3.1, SCM 4.0 / 4.1:

report




N Limited Y

2 Product allocations

APO 3.0 / 3.1, SCM 4.0 / 4.1:

transaction /SAPAPO/ATPQ_CHKUSG

Y N


© 2004 SAP AG

32




Parallel Processing

4 Models & versions

APO 3.0 / 3.1, SCM 4.0 / 4.1:



Y Y

External Consistency Checks for Backorder Processing Sequence Object for

Consistency Check Check Tool Monitor

Frequency


Parallel Processing

1 Configuration APO 3.0 / 3.1, SCM 4.0 / 4.1:

/SAPAPO/RCUIB_DELETE_CFG


Y Y

2 Schedule line agreements

APO 3.0 / 3.1, SCM 4.0 / 4.1:


Y N

3 Planned orders

Production orders

Sales orders


Purchase orders

Confirmations

Stocks

APO 3.0 / 3.1, SCM 4.0 / 4.1:



Y Y

4 Production orders APO 3.0 / 3.1, SCM 4.0 / 4.1:

Report RCIFORDER_RESERVATIONS_COMPARE

After delta report 3

N N


APO 3.0 / 3.1, SCM 4.0 / 4.1:

/SAPAPO/SDRQCR21

see note 444641


N N

6 iPPE APO 3.0 / 3.1, SCM 4.0 / 4.1:

Report IPPECIF_EKG_COMPARE

After Deltatrans-fer of iPPE data, if needed.

Y Y

7 PP/DS runtime object Report


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


Check Tool Monitor Frequency


Parallel Processing


APO 3.0 / 3.1, SCM 4.0 / 4.1:

report /SAPAPO/TS_LCM_CONS_CHECK



N Limited Y


APO 3.0 / 3.1, SCM 4.0 / 4.1:

transaction /SAPAPO/ATPQ_CHKUSG

Y N


APO 3.0 / 3.1, SCM 4.0 / 4.1:

TA /SAPAPO/ATPQ_ALERT

After step 2 N N

Consistency Checks for TP/VS


Check Tool Monitor Frequency


Parallel Processing

1 TP/VS checks APO 3.0: Transaction /SAPAPO/VSCC


APO 3.1: Transaction

/SAPAPO/OM17

4 Models & versions APO 3.0 / 3.1, SCM 4.0 / 4.1:




© 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 Restrictions CIF error handling/postprocessing 597248 Report for the consistency check of CDP master data II 589136 Consistency check for setup matrices 574976 Inconsistencies with order status/operation status 543304 TS_LCM_CONS_CHECK: Optional lock for planning version 539199 Make-to-order production orders in LC without operations 538111 Compare and reconcile production order reservations 504133 Report for processing temp. qty. assgnmts after LC recovery 458854 Reorganizing the operation table 458666 DP-BOM functions in the report /SAPAPO/TS_LCM_CONS_CHECK 451446 Delta report: Variable filter object size for data 446360 Repair tool for versions of a SNP planning area (2) 444641 Correction of incorrect sales order requirements with APO 441398 Repair tool for versions of a SNP planning area 439438 Collective note: CIF delta report performance 425825 Consistency Checks /SAPAPO/OM17/SAPAPO/CIF_DELTAREPORT 414908 Shipping notif. incorrectly consumed with sched. ag. rel. 410696 Performance-improvement of Compare & Refresh - Tool 407708 Stock interface: enhanced application log 399709 Initial data transfer: Some data are not transferred 397840 Delta report:APO sched.agreement delivery schedule lines 397533 Delta report performance: Stock comparison

397362 Only 100 planned orders transferred from R/3 to APO

391780 Long runtime for sales order comparison 391408 /SAPAPO/CCR comparison report reports crashes 389193 Comparison report performance for planned orders 387236 Comparison tool: Performance improvement new R/3 extractors 387201 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. INFORMIX®-OnLine for SAP and Informix® Dynamic Server

TM 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.

internal and external consistency

Documents