SCM Planning Solutions IBP APO Ariba: July 2014

Wednesday, July 30, 2014

Data inconsistencies in SNP

Source: https://websmp230.sap-ag.de/sap%28bD1lbiZjPTAwMQ==%29/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F64653D3030312669765F7361706E6F7465735F6E756D6265723D35373730333826

Symptom

There are inconsistencies in your system that can cause errors in interactive Supply Network Planning (SNP), SNP mass processing, and SNP data extraction. The system may issue the following error messages:

E207(/SAPAPO/TSM) 'No liveCache anchor found.

E020(/SAPAPO/OM_TS) 'Time series does not exist'

E219(/SAPAPO/TSM) 'Invalid data status'

E230(/SAPAPO/TSM) 'No plannable characteristics combinations available'

E001(/SAPAPO/SDP_MD) 'Planning object could not be determined'

E085(/SAPAPO/SDP) 'Error reading data - planning book cannot be processed'

Memory consumption in the liveCache increases disproportionately in relation to the master data volume.

Other Terms

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

Reason and Prerequisites

SNP master data is created in the system for the APO master data. This enables navigation in SNP interactive planning. The SNP master data corresponds to the aggregates defined in the SNP planning area and is saved in the database tables.
           Aggregate Database table
           9AMALO /SAPAPO/MATLOC
           9AMALORE /SAPAPO/MATLORES
           9ALORE /SAPAPO/LOCRES
           9AMALA /SAPAPO/MATLANE
           9AMALARE /SAPAPO/MATLARES
           9AMAPR /SAPAPO/MATPPM
           9AMARE /SAPAPO/MATRES
           9AREPR /SAPAPO/RESPPM
           9AACPR /SAPAPO/ACTPPM
           9AMALOSA /SAPAPO/MALOSA
           9AMALASA /SAPAPO/MALASA

If you create master data in APO or change assignments, you must also create the missing SNP master data or time series. The SNP master data and the time series in the liveCache should normally be updated by the initialization of the planning version (and not by /SAPAPO/TS_LCM_CONS_CHECK).

These master data changes can lead to inconsistencies in one of the following situations:

The version is not initialized, or the initialization job terminates.

Jobs for changing the master data are terminated.

This problem is due to a program error.

Solution

Initialize the planning version
Initialize a version that has already been initialized, without first deinitializing it and without changing the initialization period (delta initialization).

For planning areas that do not have a time series key figure, it is sufficient to initialize one version.

For planning areas with time series key figures, you must initialize each version.

Correct inconsistencies
If the inconsistencies were generated by a program termination or a program error, you can correct them using /SAPAPO/TS_LCM_CONS_CHECK.

Correct the cause of the error
If the inconsistencies were generated by a program error, it is necessary to find the cause of the error and remove it. To ensure that SAP Support can find the cause of the error, you need to provide an exact description of the process that resulted in errors:

Which master data was changed and how?

Was the planning version initialized?

You can use the existing check programs to check the consistency of your data for each step: If you know which step led to the error, SAP can analyze your process with a view to providing a correction.

There are three check programs that you can use for consistency checks in SNP: /SAPAPO/TS_LCM_CONS_CHECK, /SAPAPO/TS_LCM_REORG_SNP and /SAPAPO/TS_LCM_REORG. You can execute the programs in repair mode by setting the "Repair" indicator. You should always block the planning version by setting the "Block planning version" indicator.

Check with /SAPAPO/TS_LCM_CONS_CHECK
This report checks the following for a version of a planning area:

The consistency of the SNP master data.
It checks for all characteristics combinations, whether master data exists (unnecessary characteristics combinations), and whether there is master data without SNP master data (missing characteristics combinations).
Since the SNP master data is version-independent, you only need to execute the master data check for one version of the model.

The liveCache anchors and time series in the liveCache.
The report checks whether there are liveCache anchors and time series in the liveCache for the time series key figures for all characteristics combinations.
If the 'Check liveCache anchor' indicator is set, the report checks whether the corresponding characteristics combinations exist for all liveCache anchors (only for DP planning areas).
In the case of planning areas with time series, the time series must be checked for each version.

To correct the inconsistencies, you can execute the report in repair mode. For example, you can execute it before the planning run or after a mass change to master data to ensure a consistent status.

If you have set the "Check SNP master data" indicator, the report creates the missing SNP master data in repair mode and deletes the unnecessary SNP master data. Since the SNP master data is version-independent, you only need to execute the master data check for one version of the model.

If the planning area has time series key figures, the report deletes the liveCache anchors without SNP master data and the related time series in the liveCache in repair mode.

Check with /SAPAPO/TS_LCM_REORG_SNP
The report checks whether there is SNP master data for all liveCache anchors for a version of an SNP planning area. This check is required after you have deleted a large amount of master data.

To delete the superfluous liveCache anchors and the related time series in the liveCache, you can run the report in repair mode.

Check with /SAPAPO/TS_LCM_REORG
The report checks for a version for all DP and SNP planning areas whether there are liveCache anchors for all time series in the liveCache. This check is necessary if technical inconsistencies occur after a job was terminated.

To delete the unnecessary time series without liveCache anchors, you can run the report in repair mode.

Sequence of steps:
We recommend that you execute these program steps in the following sequence:

Frequency of execution:
You should monitor the check programs over a sufficiently long period to estimate whether and when exactly they are required. Under normal circumstances, they should be used only to localize errors that create inconsistencies. You should execute the /SAPAPO/TS_LCM_CONS_CHECK program more often than the /SAPAPO/TS_LCM_REORG_SNP program and this more often than the /SAPAPO/TS_LCM_REORG program.

/SAPAPO/TS_LCM_CONS_CHECK
Since the SNP master data does not depend on either the planning area or the version, you only have to check the SNP master data for one version of the model. The consistency check is not required after the planning version has been initialized. In the normal process flow, the consistency check should not take place before the planning run, but it can be carried out weekly, for example.

/SAPAPO/TS_LCM_REORG_SNP
This program should be executed regularly after master data is deleted in the system. How often the program is executed depends on the quantity of deleted master data. You can always execute the program after a large quantity of master data is deleted, on a weekly basis, for example.

/SAPAPO/TS_LCM_REORG
This program should be executed monthly to check the consistency of the time series in the liveCache.

Header Data


Released On	05.06.2009 09:57:53
Release Status	Released for Customer
Component	SCM-APO-SNP-BF Basic Functions
Priority	Correction with medium priority
Category	Consulting

Validity

This document is not restricted to a software component or software component version

References

This document refers to:

SAP Notes

1384831		9AMAPR inconsistencies for PDS in inactive version
1344612		Performance: Planning areas with time series key figures
1331576		Initialization and Delta Handling for SNP Master Data
1045639		Consulting notes in SNP/CTM
997456		Delta queues level 2 are not deleted
669287		Superfluous time series for SNP planning areas
402046		Error message 'No LiveCache anchor found'

This document is referenced by:

SAP Notes (6)

1045639		Consulting notes in SNP/CTM
1331576		Initialization and Delta Handling for SNP Master Data
1344612		Performance: Planning areas with time series key figures
1384831		9AMAPR inconsistencies for PDS in inactive version
997456		Delta queues level 2 are not deleted
669287		Superfluous time series for SNP planning areas

Thursday, July 3, 2014

Wondering why your SNP PA consistency and SNP Planning run takes too long to run? Try this note

Source: https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F64653D3030312669765F7361706E6F7465735F6E756D6265723D3133333135373626
SAP Note 1331567

Symptom

Whenever you create/change/delete APO Master Data, the SNP planning objects need to be updated. This note explains the process for updating SNP Master Data and the time series objects in liveCache.

Other Terms

Delta Queue, /SAPAPO/TS_PAREA_INITIALIZE, /SAPAPO/TS_LCM_CONS_CHECK, /SAPAPO/TS_LCM_QUEUE_UPDATE

Reason and Prerequisites

SNP Master Data is a (redundant) combination of APO Master Data entities and is used to access master data faster. SNP Master Data are so called planning objects and correspond to the aggregates defined in the planning object structure. SNP Master Data is used to access master data more efficiently (performance).

Solution

In order to avoid SNP inconsistencies you must run the initialization of the planning area and planning version after updating master data and before any every Master Data access in SNP (Interactive Planning, Heuristic Planning Run, Optimizer, ...).

The process for updating SNP Master Data cosists of following steps:

1. Any change in APO Master Data is recorded in Delta Queue Table Level 1 (/SAPAPO/TSQUEUE):

Object Type (product, resource, ppm, transportation lane, ...)

Object Key (matid, resuid, ...)

Action (create, update, delete)

Sometimes the model

2. The change documents stored in /SAPAPO/TSQUEUE are converted into SNP Delta Queue Level 2 entries. This step corresponds to program /SAPAPO/TS_LCM_QUEUE_UPDATE.            Delta Queue Level 1 is analyzed (model(s) and version(s) are added), the possible characteristic combinations of Master Data are determined and stored to the Delta Queues Level 2.
           As a result, Delta Queue Level 2 will contain the combination of all keys of the changed master data, for all active planning areas and versions that are relevant for SNP.
              There are following Delta Queue Level 2 tables:            Aggregate Delta Queue Level 2 table
           9AMALO /SAPAPO/TSQMLO Material Location
           9AMALORE /SAPAPO/TSQMLOR Material Location Resource
           9AMALA /SAPAPO/TSQMLA Material Lane
           9AMALARE /SAPAPO/TSQMLAR Material Lane Resource
           9AMAPR /SAPAPO/TSQMP Material PPM/PDS
           9ARE /SAPAPO/TSQR Resource
           9AREPR /SAPAPO/TSQRP Resource PPM/PDS
           9AACPR /SAPAPO/TSQAP Activity PPM/PDS
           9AMALOSA /SAPAPO/TSQMLOSA Scheduling Agreement-Mat.-Loc.
           9AMALASA /SAPAPO/TSQMLASA Scheduling Agreement-Mat.-Lane

3. For the planning area and planning version which is currently processed, the Delta Queue Level 2 entries are processed to create missing SNP Master Data.               The SNP Master Data Tables are the following:            Aggregate Database table
           9AMALO /SAPAPO/MATLOC  (not SNP)
           9AMALORE /SAPAPO/MATLORES
           9ALORE /SAPAPO/LOCRES
           9AMALA /SAPAPO/MATLANE
           9AMALARE /SAPAPO/MATLARES
           9AMAPR /SAPAPO/MATPPM
           9AMARE /SAPAPO/MATRES
           9AREPR /SAPAPO/RESPPM
           9AACPR /SAPAPO/ACTPPM
           9AMALOSA /SAPAPO/MALOSA
           9AMALASA /SAPAPO/MALASA

4. For one planning area and planning version, the Delta Queue Level 2 entries are processed to create missing time series objects in liveCache (liveCache anchors). At the end of this step the Delta Queue Level 2 entries are deleted.

Remarks:

Steps 2 and 3 are automatically processed before every Master Data access in SNP (Planning Area Initialization, Interactive Planning, Planning Run, Optimizer, ...)

Step 4 is not automatically processed, you must run initialization of the planning area and planning version.
To not impact the performance, you must keep the delta queue level 2 tables as small as possible, this means step 4 needs to be processed for ALL initialized planning areas and planning versions.

If your APO Master Data is frequently updated and for performance reasons, the report /SAPAPO/TS_LCM_QUEUE_UPDATE equivalent to step 2 can be scheduled in background.

If you change/delete/add master data frequently and run consistency check report without performing snp relevant operations first, it is advised to run the report /SAPAPO/TS_LCM_QUEUE_UPDATE before as the Delta Queue Level 1 remains in this case and this can lead to remaining superfluous data.

In certain cases, the deletion of APO Master Data is not reflected to SNP Master Data and resulting of possible superfluous entries. This is due to performance reasons as the update of APO Master Data can occur frequently. It has no impact on SNP functionalities but can be fixed if needed by the consistency check report /SAPAPO/TS_LCM_CONS_CHECK.

You can check how many entries are in your system in the queue tables by running report Z_LCM_QUEUE_REORG which is attached to note 960941.