Show TOC

 Systematic Problem Analysis

The following information is only relevant if your SCM system is SAP Advanced Planning and Optimiza tion (SAP APO).

If certain data objects arrived incorrectly in the target system or did not arrive at all, you can perform a systematic analysis of the problem.

The following figures provide an overview of systematic problem analysis:

Problem Analysis for Online Transfer of Transaction Data to SAP APO

Problem Analysis for Initial Data Transfer of Master and Transaction Data to SAP APO

Transfer from SAP R/3 to SAP APO

Is the data saved under a different name in SAP APO?

Note that in the case of master data a distinction is made between external keys, that is, keys in SAP R/3, and SAP APO names. The name in SAP APO does not have to be same as in SAP R/3. Depending on the scenario, you may need to modify the SAP R/3 names so that you can uniquely identify different objects in SAP APO. In most cases, you do this using customer functions in SAP APO inbound. If in doubt, check whether a customer function that uses a modified SAP R/3 key as the SAP APO name is active. If this is the case, you must take it into account when searching for objects. In the case of products, the database table for the assignment between SAP R/3 and SAP APO names is /SAPAPO/MATMAP, for locations it is /SAPAPO/LOCMAP, and for resources it is /SAPAPO/RESKEY.

Is the data in the CIF application log of SAP R/3 (transaction CFG1)?

Check the appropriate application log subobjects for the data object, and the date and time of the transfer. For an initial data transfer, you can restrict the check to subobject INITIAL. The application log is written immediately after the function module responsible for the individual object type has sent its data to SAP APO by means of a qRFC call. The name of the function module used, for example, CIF_STOCK_SEND provides information about the object type.

You can define the fields that are logged in the CIF application log for each of the SEND modules. You do this by using transaction CFC6 and entering the module name. SAP delivers one presetting. In most cases, one line is included with administrative data, for example, the names of the systems involved, the user and transaction names, and so on.The keys, for example, the document numbers as well as the transfer methods, for example, N for Create new, should be included in the application log. You can use this method to quickly check whether a particular SAP R/3 document is relevant to SAP APO and was therefore added to a queue. If this is not the case, it could be that integration models were constructed and activated incorrectly.

You can use the filter object search (transaction CFM5) to determine whether a particular filter object occurs in integration models and whether these integration models are active.

Are there entries in the qRFC monitor (transaction SMQ1 or SMQ2)?

You can set up either outbound queues or inbound queues for using qRFCs. In SAP R/3, you do this in transaction CFC1. If outbound queues are set up, you must use transaction SMQ1 in SAP R/3 as the qRFC monitor. If the queue type is set to inbound queue, in most cases you use transaction SMQ2 in SAP APO as the qRFC monitor.

If problems occur with the network connection, it can be the case that the data cannot be sent to SAP APO. In this case, you can find the data in transaction SMQ1 in the sending SAP R/3 system. The names of the queues used by CIF all begin with CF so that you can restrict your selection to these. In the detailed display of function module calls, you can use the separators to tell which calls belong to the same LUW. You can see a restricted view of the data by double-clicking the function name.

Various statuses are possible for the queues: Recorded means that this call is not yet waiting to be processed. In most cases, this means that processing of a call linked to it by the LUWs and queues has not been completed or ended in an error. An LUW can only be started when all queues contained within it are waiting for processing. An error in one of the queues involved prevents the entire LUW from being started. This can then also block other queues. This means that a few errors can block many queues and thereby restrict data transfer.

In most cases, the status CPICERR means that a technical connection problem has occurred during the transfer. In this case, if the appropriate setting has been made, the qRFC administration attempts to repeat the call after a certain period of time. In the case of outbound queues, you can configure the parameters that do this in the sending system in transaction SM59 under tRFC Options . In the case of inbound queues, you can make these settings in the receiving system in transaction SMQR.

The status RETRY means that the application has deliberately requested that this LUW is reprocessed at a later time and not that a technical connection problem has occurred. In the majority of cases, this is the result of SAP liveCache locks when a CIF LUW wants to process data that is already locked by another LUW (CIF or not). The system recognizes this. As a result, the system re-executes the function calls for this LUW at a later point in time.

If one of the calls in the target system ends in errors, the entire LUW gets the status SYSFAIL. You can find a one-line error message in the status text in SMQ1 or SMQ2. In most cases, the application log of the SAP APO target system contains more information than the text in the qRFC monitor (see next paragraph).

Are there entries in the SAP APO application log (transaction /SAPAPO/C3)?

The CIF application log in SAP APO shows the result messages for the routines that transfer the data into SAP APO, grouped by object CIF and various subobjects. Even if no errors have occurred, you can tell which data has arrived in which target system. If the document numbers that you are looking for appear here and have not produced any errors, you can assume that CIF has correctly transferred the data to the SAP APO system. In this case, any problems that do occur are most likely to be due to the application.

If the application log is activated but does not contain any entries, it is highly likely that the data was not sent from SAP R/3. Even if faulty entries have been deleted in transaction SMQ1 in SAP R/3, application logs that have already been written are kept and can be used to draw conclusions about the data transfer. You can assign a faulty entry in transaction SMQ1 in SAP R/3 to the appropriate application log by means of the transaction ID. This is displayed in SMQ1 and can be copied to the selection screen of the application log transaction. Unlike in SAP R/3, you cannot configure which particular fields are to be logged in the application log in SAP APO. This selection is predefined.

Transfer from SAP APO to SAP R/3

The procedure for analyzing problems for the transfer from SAP APO to SAP R/3 is more or less the same as that for the transfer from SAP R/3 to SAP APO. You should first check the application log in SAP APO to ensure that SAP APO has triggered a transfer and that the data was placed into one or more queues. If this is not case, the problem could be due to incorrectly maintained distribution criteria (transaction /SAPAPO/CP1 or /SAPAPO/CP2). If the entries exist, you should next use the qRFC monitor (SMQ1 in SAP APO or SMQ2 in SAP R/3) to localize any problems. If you do not find any faulty or unprocessed queue entries in the qRFC monitor, check whether there are any entries for the orders to be checked in the SAP R/3 application log. Here you can also assign faulty queue entries in transaction SMQ1 by means of the transaction ID. The successful transfer of data to SAP R/3 indicates that CIF processing was correct. In this case, the problems were most likely to have been caused by the application and not CIF.