Here is a detailed documentation on each of the Object Types

 
Consistency Check for Setup Matrices

The consistency check for setup matrices contains:

· A check whether the setup matrices exist in liveCache
· A check whether the setup transitions exist in liveCache
· A field comparison between the setup transitions in the database and those in liveCache
When the setup matrices are corrected, the setup matrices in liveCache are completely generated from those in
the database. Previously nonexistent setup matrices and setup transitions are newly created in liveCache.
Superfluous setup transitions are deleted from liveCache. Setup transitions that differ at the field level are
adjusted to match the database status.

Consistency Comparison for Block Basis Definitions

Use
When you set this indicator, checks are performed in liveCache and in the database on characteristic values for
block basis definitions:
· The existence of block basis definitions is checked.
· The consistency of the characteristic values is checked.
After the checks you can call a correction function in the check results display. When correcting the error, the
system deletes obsolete block basis definitions in liveCache. The system completes or corrects missing or
inconsistent block basis definitions in liveCache.
Note
The check is performed independently of the planning version.

Consistency Check for Resources

The consistency check for resources contains:

· A check that the resource and corresponding time stream exist in liveCache
· An check that a resource's characteristic blocks exist in liveCache
· A field comparison between the database resource and the liveCache resource
When correcting the resources, the resources in liveCache are completely generated from the database
resources. Previously nonexistent resources are created in liveCache.

Consistency check for downtimes caused by maintenance order

The consistency check for maintenance downtimes contains:

A check that the maintenance downtime has a reference to an existing maintenance order.
A check that the dates of maintenance downtime correspond to the exisiting maintenance order.
When correcting the maintenance downtime errors, downtimes without maintenance order are deleted and wrong
dates of downtimes are corrected in relation to the maintenance order.

Consistency Check for Product Location Combinations

Use
If you set this indicator the system executes a consistency check for product location combinations. The
consistency check for product location combinations includes:
· A check for the existence of a product location combination in the database and in liveCache
· A field comparison between product location combinations in the database and in liveCache
· The determination of obsolete entries for product location combinations in the database
· A check for the existence of characteristic value assignments for product location combinations in the database
and in liveCache
· A field comparison of characteristic value assignments for product location combinations in the database and in
liveCache
After the check you can call a correction function from the display of check results. For the correction, the system
deletes obsolete product location combinations from the database and in liveCache. The system corrects
inconsistent product location combinations and characteristic value assignments for product location
combinations in liveCache.

Consistency Check for Stocks

Use
If you set this indicator the system executes a consistency check for stocks. The consistency check for stocks
includes:
· A check for the existence of a stock in the database and in liveCache
· A field comparison between stocks in the database and in liveCache
· The determination of obsolete entries for stocks in the database
· A check for the existence of characteristic value assignments in the database and in liveCache
· A field comparison between characteristic value assignments for batch stocks in the database and in liveCache
After the check, you can call a correction function from the display of check results. For the correction, the
system attempts to correct inconsistent stocks in the database and in liveCache. If a correction is not possible,
the stocks are deleted in the database and in liveCache. The system corrects characteristic value assignments
for batch stocks in liveCache.
After inconsistent stocks have been corrected, it may be necessary to start the delta report in order to reconcile
SAP APO and SAP R/3.

Consistency Comparison of Configuration/CDP for Orders

Use
When you set this indicator, the system performs a consistency check with regard to configuration or CDP
(characteristic value assignments/ requirements) for receipts/requirements belonging to orders:
· In the case of products with variant configuration and product variants, the system checks whether there is a
referenced configuration in the database.
· In the case of products with CDP, the system checks whether CDP characteristics exist.
Note
In the area Restrictions, you can use the indicator CDP: Detailed Check to define a detailed check for CDP
characteristics. If you set this indicator, the CDP data used for the orders is also compared with the product
master.
· For products without configuration/CDP, the system checks whether invalid references to variant configuration
or invalid CDP characteristics data exist.
After the check, you can call a correction function in the check results display. When executing the correction, the
system tries to adjust inconsistent orders in liveCache.
After inconsistent orders have been corrected, you may need to start the delta report to compare the SAP R/3
system and SAP APO again.
Dependencies
The consistency check for configuration or CDP data is very time-consuming. You should therefore limit the
comparison as far as possible to certain products or locations.

Consistency Check for Production Campaigns

If orders are assigned to production campaigns that do not exist in the database, this leads to inconsistent
campaigns.
You can correct inconsistent production campaigns by removing all orders from them. That means that the
campaign assignments are removed from the orders in liveCache.

Consistency Check for Operations

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

Consistency Check for Planning Matrices

As planning matrices are not master data, they are only located in liveCache. For each production version, there
is a record in the database with information about matrices that must exist for this production version and
whether the last matrix explosion was successful.
The consistency check for planning matrices checks:
· Whether the matrices associated with each record on the database exist in liveCache
· Whether the records associated with all the matrices in liveCache exist on the database
· Whether the last matrix explosion was successful.
If inconsistencies are discovered, they can be corrected. As corrections are made by recalculating the
inconsistent matrices, the process can take a while and should only be done for large matrices (with many orders
or many item variants) at times when it can be guaranteed not to hinder any other system processes.

Consistency Check for Simulation Versions

This is a check for whether simulation versions exist in liveCache.

Correction does not take place automatically. Simulation versions that still exist in the database but no longer
exist in liveCache do not influence the running of the system. If necessary, they can be deleted using
transaction /SAPAPO/CDPSS0.

*******************************************

Consistency Check for Product Allocations

The consistency check for product allocations checks the data for product allocation assignment from the
database and compares this with the incoming orders quantity in Demand Planning. Surpluses or shortages are
displayed and can be corrected.
The reconcile is only executed for product allocation groups with a direct connection to the product allocation
group in the planning area if the connection is also fully defined.
There may be long runtimes during the consistency check due to the data structure. The following factors can
hinder performance:
· Number of characteristics combinations
· Number of periods in a time series
· Number of sales orders that take product allocations from a time stream

Error in the reconcile

If it is not possible to reconcile the incoming orders quantity, the data records are issued again with a relevant
error message. Check the following causes and attempt again.
Check:
· If the planning area to be checked is locked
· If the time streams are initialized (after liveCache has been initialized)
· If all characteristics combinations area available in the planning area
· The wildcard indicator for collective product allocation
· The settings for your planning area

************************

Due Delivery Schedules/Confirmations Consistency Check

When a scheduling agreement release is received from a customer for sales and distribution scheduling
agreement items, a due delivery schedule is created and stored in liveCache. As soon as a confirmation for a
due delivery schedule containing at least one schedule line with a quantity larger than zero is generated, an
object is also created for it in liveCache. The transaction data for sales and distribution scheduling agreement
items contains, amongst other things, an entry with the key of the due delivery schedule object currently located
in liveCache and an entry with the key of the confirmation that is currently valid in the database. During the
check, the system checks whether liveCache objects exist for sales and distribution scheduling agreement items
and whether the transaction data entries are correct.
The following individual checks are made for active sales and distribution scheduling agreement items:
· Is there an operative scheduling agreement release and/or forecast/planning delivery schedule in the database,
but no associated liveCache object?
· Is there a confirmation in the database, but no associated liveCache object?
· Is there a due delivery schedule in liveCache, without at least one existing operative scheduling agreement
release and/or forecast/planning delivery schedule?
· Is there a confirmation in liveCache, without an existing confirmation in the database?
· Is the key in the transaction data in the database that shows the current due delivery schedule in liveCache,
also that of the actual liveCache object?
· Is there actually a confirmation in the database for the key in the transaction data that shows the currently valid
confirmation in the database?
If a sales and distribution scheduling agreement item is inactive, there are not allowed to be any due delivery
schedules or confirmations in liveCache. In this case, the following checks are made:
· Is there a due delivery schedule in liveCache for an inactive sales and distribution scheduling agreement item?
· Is there a confirmation in liveCache for an inactive sales and distribution scheduling agreement item?

Consistency Check for Production Backflushes

Partially confirmed orders cannot be deleted from liveCache. For each partially confirmed order of the database
table, there must be a corresponding order in liveCache. If no order exists, there is a data inconsistency that can
only be rectified by deleting the order from the database tables of the confirmation.
Entries for orders that have already been confirmed exist in the status matrix. The entry in an order's status
matrix is deleted when the confirmed order is deleted by the /SAPAPO/PPC_ORD archiving report. Each status
matrix entry for which database tables of the confirmation do not exist, present an inconsistency that can only be
removed by deleting the status matrix entry.

Consistency Check for iPPE Objects

The iPPE object is not an iPPE master data structure. It is a data extract that is generated for each iPPE access
object.
The consistency check for the object checks that it exists in liveCache and also determines its identity using the
backup copy in the database. When correcting the object, the copy from the database is written to liveCache.
It is necessary to check the object if the following error message occurs: 'Error while calling COM routines via
application program' (/sapapo/om 102) with return code 1601, 1602, or 1603. This does not apply to liveCache
initialization.

Consistency Check for Procurement Scheduling Agreement Items

The following three objects represent procurement scheduling agreement items (scheduling agreement in short):
1. Scheduling agreement schedule lines
2. Release schedule lines
3. Confirmations
All these objects are located in liveCache. Release schedule lines and confirmations are also located in the
database with a historical record. Depending on the process that was set up for the scheduling agreement, not all
objects exist in liveCache or have historical records.
If goods movements exist for an object, there must always be at least one entry in liveCache. If all schedule lines
are covered by goods receipts, at least one schedule line will exist in liveCache with the number '0000000000'
and an open quantity of 0.
A liveCache crash, operator errors, and program errors can all cause inconsistencies. Below is a list of all the
inconsistent statuses that have been identified and that can be removed:
1. The object is not in liveCache but goods receipts exist.
2. The number of input nodes and output nodes is different.
3. There are no input nodes at the order, but the material exists in the source location for the order.
4. The original quantity at the source of an order is different from that at the destination.
5. The accumulated quantities in liveCache are different from those in the database (the cumulative received
quantity, for example).
6. The set process is compared with the status in liveCache.
7. A check is made to see whether the scheduling agreement is being planned in APO or in R/3 and whether the
schedule lines have the appropriate specification.
If a schedule line inconsistency is identified, no more checks for inconsistencies are made, instead it moves on to
the next schedule line.

Consistency Check for MSP Orders

Provides a list of maintenance and slot orders that
·     Exist in the database but have no corresponding orders in the liveCache
·     Exist in the liveCache, but have no corresponding orders in the database
Procedure
From within the list, you can either
·     Correct the inconsistencies
If you choose to do this, the system deletes the selected orders from the database and/or liveCache.
You receive a message that the selected order(s) have been deleted.
·     Leave the inconsistencies in the database and/or liveCache
Such inconsistencies place an unnecessary load on the database and/or liveCache.  Moreover, those orders that
exist in the liveCache, but have no corresponding orders in the database, influence the scheduling results of
subsequent orders in the liveCache