Checklist for Setting Up the System InfrastructureThe following table shows the Customizing steps required for the technical integration via Core Interface

(CIF).

If you work with SAP R/3 4.0B or higher, an Implementation Guide (IMG) is available for CIF Customizing in the ERP System. There is also an IMG for CIF Customizing in the SCM System. You find the relevant

IMG activities in the corresponding IMG under the structure nodes Basic Settings for Creating the System Landscape and Basic Settings for Data Transfer.

CIF Customizing in the ERP System

Step Transaction Obligatory?Check ALE settings and activate, as required:

● Define the logical system

● Assign logical system to client

SALE Obligatory

Define the RFC destination SM59 ObligatorySet up the target system and

assign the queue type

If you set the Inbound Queue queue type in the ERP system, you have to register CIF queues (CF*) in the QIN scheduler in the

SCM system.

CFC1 Obligatory

Maintain SCM release NDV2 Obligatory

Set number ranges for parallelization

CFC7 If needed

Activate BTEs for integration

BF11 If needed

Register CIF queues in the QIN scheduler if you have changed to inbound queues

SMQR If needed

in the SCM system

CIF Customizing in the SCM System

Step Transaction Obligatory?Check ALE settings

● Define the logical system

● Assign logical system to client

SALE Obligatory

Define the RFC destination SM59 Obligatory

Maintain business system group /SAPAPO/C1 Obligatory

Assign Logical System to Business System group /SAPAPO/C2 SNSCLNT001 to BSG_01

Assign logical system and queue type

If you set the Inbound Queue queue type in the

SCM system, you have to register CIF queues (CF*) in the QIN scheduler in the

ERP system.

CFC1 Obligatory

Register CIF queues in the QIN scheduler if you have changed to inbound queues in the ERP

system

SMQR If needed

Register CIF queues in the QOUT scheduler, if you have configured outbound queues

in the ERP system

SMQS If needed

Maintain distribution definitions

/SAPAPO/CP1 Obligatory

Create customer exits for uniquely identifying master

CMOD (Customer Exits)If needed

data. For more information, see the Implementation Guide

(IMG) for SCM Basis.SE19 (Business Add-Ins)

Symptom

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

Other terms

Internal consistency, external consistency, comparison, compare, consistency check, CIF Compare & Reconcile Deltareport, refresh

/SAPAPO/TS_LCM_CONS_CHECK, /SAPAPO/TS_LCM_CONS_CHECK_ALL/SAPAPO/TS_LCM_REORG

Solution

Internal consistency refers to the consistency between the liveCache data and the APO database.

External consistency refers to the consistency between the APO system and one or more dedicated R/3 Systems.

Before you check the external consistency and set it up again, if necessary, make sure that the internal consistency of the APO system is guaranteed.

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

relevant consistency checks.You can find the path for this document in note 572003.

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

----------------------------------------------------------------

Internal consistency check - transaction /SAPAPO/OM17

Internal consistency refers to the consistency between the liveCache data and the APO database.

Inconsistencies may occur if the APO database data or the liveCache data can no longer be completely restored due to system crashes and

inappropriate backup strategies.Since there is currently no logging for Demand Planning data, inconsistencies can still occur in this area following a recovery.To check the external consistency between the APO database and

the liveCache and to set it up again, if necessary, use transaction /SAPAPO/OM17.

The following data is checked in particular:

Pegging areas, stocks, campaigns and planning versions are checked.

Master data:This data is saved redundantly in the APO database and in the liveCache, this means that data which is only on the APO DB, can be generated in the liveCache.If data still only exists in the liveCache,

you can select this for deletion.

No resources are checked.The 'Resources' option is provided in older versions of the /SAPAPO/OM17 report, but you should avoid using this option as the results are inadequate.The results are not satisfactory.

Internal consistency check for resources - transaction /SAPAPO/REST02

(also in the initial screen of the resource maintenance under the menu Tools/liveCache check)

You can select different options on the selection screen of the report.

Check existence in the LC - liveCache checkOnly checks which resources do not exist in the liveCache and displays

a list of these resources.

Save non-exist. res. LC - liveCache saveThis option checks the resources and creates missing resources in the

liveCache.Resources, for which a backup is not possible in the liveCache, are assigned a red traffic light and a corresponding error

message in the list of results.

Save selected res. LC - liveCache saveThis option saves all the resources in the liveCache that meet the

selection conditions.

A list with yellow traffic lights is displayed for those resources where there are differences between the database and the liveCache.The

differences are highlighted.Resources, which could not be saved in the liveCache, are displayed with a red traffic light.Corresponding error texts are displayed in the

list of results for these resources.

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

green traffic light in the "Bucket vector" column.

Consistency checks for product allocations

To date, there is no consistency check for product allocations within transaction /SAPAPO/OM17 - the check tool is available in the menu tree for

product allocations "Global ATP - Environment - Product Allocations - Repairs".

In the product allocation, the incoming order quantities can be directly updated in the liveCache during a direct connection to the planning

area.Using the tool in the liveCache, you can reconcile the data with the product allocation assignment on the database.The tool allows you to check

and then correct the data.

/SAPAPO/ATPQ_CHKUSG -Check product allocation assignmentProduct allocation assignment without complete incoming order quantity

Product allocation assignment without order itemProduct allocation assignment without allocation group

Inconsistent temporary quantity assignments after the LC recovery

Previously, there was neither a consistency check nor a repair option within transaction /SAPAPO/OM17 for inconsistent and incorrect temporary quantity

assignments that may occur after an LC crash and a subsequent LC recovery.

These inconsistencies only occur for APO Release 3.0 if you are using a liveCache lower than Version 7.4. As of LC Version 7.4, the LC itself performs the correct data recovery.You can use the /SAPAPO/REBUILD_TQA report to eliminate the inconsistencies after an LC recovery for APO 3.0. This report

deletes incorrect temporary quantity assignments and creates missing quantity assignments.

However, it is not possible to use the report to correct all inconsistencies

automatically and you must perform this manually in some cases. For a detailed description of the procedure, see note 435827.

Demand Planning consistency check

The /SAPAPO/TS_LCM_CONS_CHECK_ALL report checks all existing time series networks of the Demand Planning.Any inconsistencies are displayed

for each planning area and version without the option of being able to delete these.

The /SAPAPO/TS_LCM_CONS_CHECK report performs the same checks as the /SAPAPO/TS_LCM_CONS_CHECK_ALL report, but only for one planning

area to be selected in each case and also for each planning version (if desired).You can also activate the 'repair' option.Any inconsistencies are

then automatically eliminated during the run.If you select the 'Repair' option, no other processes may be active for the selected planning area and the

selected planning version. To make sure that this is the case, you can set an optional lock after implementing note 543304 or as of Support Package 22. If you cannot set the optional block, execution of the report is terminated for

this version and a list of system users who have already set a change lock for the planning version is displayed.

The following is checked:

Storage buckets profile in the liveCache:With the storage buckets profile the system checks, in addition to the

existence, whether the start times of the time buckets and the weighting factors are correct.The system runs its checks on the basis

of the settings of the planning area's storage buckets profile (cf. transaction /SAPAPO/TR32).Any inconsistencies here cannot be

repaired.However, this case only occurs very rarely (for example, if the fiscal year variant has been subsequently changed).The

inconsistencies can only be eliminated by creating (initializing) the time series again.

Time seriesWith the time series, the system checks whether the corresponding

liveCache anchors, and in turn all corresponding time series for these anchors, exist in the liveCache for all characteristics combinations in

accordance with the planning object structure (DB).Missing anchors or time series are created.

However, these time series are created with initial information.Therefore, if data is lost during a liveCache crash, this data

must be produced again (for example, by restarting a planning run, reloading historical data from an InfoCube).

DP relationshipsWith the DP relationships, the check starts from the planning object

structure and the related aggregates to ascertain whether all the relationships exist. The check also verifies whether unnecessary

relationships exist. Missing relationships are created and unnecessary relationships deleted.

Provided the data still exists in the corresponding planning object structure, the DP relationships can be completely created again

(except for firming information).If the time series of the planning object structure were created again with initial values in the case of a

liveCache crash, this (initial) information is also copied to the DP relationships.When the time series of the planning object structure (see above) are recovered, the DP relationships are automatically

adjusted.

DP-BOM relationships (only as of APO 3.0 Support Package 19/APO 3.1 Support Package 03 or note 458666)

With the DP-BOM relationships, the system checks, on the basis of the existing characteristic combinations and the master data, whether all

relationships exist in the liveCache between the dependent characteristic combinations.(Characteristic combinations are

dependent if they show the same PPM and the same user-defined characteristics).The system also checks whether the BOM coefficients of the PPMs agree with the coefficients in the liveCache.The check for the DP BOM relationships assumes that all characteristic combinations

exist.Missing BOM relationships are created and changed BOM coefficients are adjusted.

The report /SAPAPO/TS_LCM_REORG (supplied with note 542946 or Support Package 22) determines all liveCache time series and period patterns from a

selected planning version that do not have any 'liveCache anchors', independently of planning areas.These objects do not have any reference to the application data and are therefore not inconsistent as such, but simply

unnecessary objects which result in increased liveCache memory consumption.For this reason, you should only have to run the report approx.

If you have selected the 'Repair' option, any unnecessary time series and period patterns are deleted.

When you run the report /SAPAPO/TS_LCM_REORG, no other processes for a planning area (applies only to planning areas with key figures based on liveCache time series) should be allowed to run with the same planning

version, since this would result in liveCache objects that are still required by the other parallel process being recognized as unnecessary (and then

possibly deleted).For this reason, we recommend that you always run the report with the option 'Lock planning version'.In this case, all planning areas

that use the planning version to be checked are locked for the relevant

version.If you cannot activate the lock, report execution is interrupted and a list of system users is displayed, showing users who have already set a

change lock for the planning version.

Supply Network Planning using time series

If time series are used in the Supply Network Planning in a SNP planning area, the /SAPAPO/TS_LCM_CONS_CHECK report can also be used to check this time series network and to eliminate inconsistencies if required.The

report is used in exactly the same way as for Demand Planning.In addition you have the option to check and correct the SNP master data.

However, the /SAPAPO/TS_LCM_CONS_CHECK_ALL report is not available for SNP planning areas.

As of Support Package 17, and to a greater extent as of Support Package 19, the consistency can also be checked for SNP data stored in the time series.

For more information, see notes 446360 and 441398.If time series are used in the Supply Network Planning in an SNP planning

area, you can also use the report /SAPAPO/TS_LCM_REORG.The report is used in exactly the same way as for Demand Planning.

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

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

APO master data relevant for TP/VS, such as vehicle resources, transportation lanes, locations

Customizing and optimization profiles

R/3 OLTP and APO TP/VS integration and carrier selection settings

Consistency between liveCache and TP/VS anchor tables (orders and transport requests)

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

liveCache (the statuses are different in the liveCache and anchor tables).Inconsistent entries in the anchor tables are deleted.

Transaction /SAPAPO/VSCC was developed primarily to recognize possible

inconsistencies.If an inconsistency is displayed and if it cannot be eliminated by forward navigation, open a problem message.

Consistency check for scheduling agreements

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

There is a different number of input and output nodes, but neither number is 0.

Orders that do not have any inputs but whose material is maintained in the vendor location and that are contained in a planning version.These

orders would cause terminations in the future.

Orders whose quantity fields are different in the source and target.

The accumulated numbers of goods receipt and goods issue in the liveCache must agree with those in the database.

Cross-check with the set process:the order GUID in ordmap refers to the incorrect request type.Objects exist, even though the process

makes no provision for them.

There are still APO scheduling agreement schedule lines even though the scheduling agreement in R/3 is already flagged as an OLTP

scheduling agreement

There are still APO scheduling agreement schedule lines even though the scheduling agreement in R/3 is already flagged as an OLTP

scheduling agreement

Neither a delivery nor a goods issue exists on the database, but they are allocated in the liveCache

Since the data is deleted and created again in the liveCache, you should proceed very carefully.You should only use the check if you notice

inconsistencies or following a liveCache crash.In the first case, you should only consider this specific scheduling agreement and in the second case, all

scheduling agreements should be checked.

Consistency check for operations

In the database table of /SAPAPO/OPR operations, operations may exist which have no orders in the liveCache or no orders for a simulation version

or orders for deleted simulation versions or no external operation number.These operations place an unnecessary burden on the database

table and may cause poor system performance.

To delete operations, which are no longer required, from the database, you should schedule the Z_CHECK_CONSISTENCY_OPERATIONS report on a

weekly basis.To create the above report, follow the instructions in note 458854.

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

External consistency check CIF Compare/Reconcile function

External consistency refers to the consistency between the APO system and one or more dedicated R/3 Systems.

Inconsistencies may occur if at least one of the systems crashes and cannot be fully recovered again.In the same way, inconsistently deleting CIF queues

or unwanted user settings can cause inconsistencies.

You can use transaction /SAPAPO/CCR to execute the CIF Compare/Reconcile function. Note:In APO 3.0, Version 3 is available after the downgrade using note 459402;you can only start the Compare/Reconcile function, Version 3,

in APO 3.0 by executing the /SAPAPO/CIF_DELTAREPORT3 report./SAPAPO/CCR only checks the data of the active planning version (planning version 000) since R/3 data is only integrated through CIF with this planning

version.You do not need to check the external consistency after a complete recovery

of the liveCache and/or of the APO-DB.

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

Only transaction data is checked.

Only existence is checked in Version 2:A check is only performed on production and planned orders at header level, purchase orders,

purchase requisitions and sales orders at schedule line level to see if they exist.The quantity is also checked but only for stocks.

In addition to the existence check, important quantities and dates are compared in Version 3. The level of detail distinguishes itself here with

different compared transaction data.

If inconsistencies are found between the systems, these are not cleared automatically.You must select one or several of the objects in

question on the detailed screen and initiate the transfer of the object in the required direction (APO, R/3) by selecting the corresponding

button.