Download - Application Monitor With SAP Solution Manager - Setup Guide

Business Process Monitoring Set-up and User Guideline

Application Monitor with SAP Solution Manager Release ST 3.2/4.0 and ST-A/PI 01H *

September 2006

© Copyright 2006 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®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic Server

TM are

trademarks of IBM Corp. in USA and/or other countries. ORACLE® is a registered trademark of ORACLE Corporation. UNIX®, X/Open®, OSF/1®, and Motif ® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood ®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. 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.

J2EE™ 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, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP Markets and Commerce One. All other product and service names mentioned are the trademarks of their respective owners. Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way. Documentation in the SAP Service Marketplace You can find this documentation at the following address: http://service.sap.com//bpm

SAP AG Neurottstraße 16 69190 Walldorf Germany T +49/18 05/34 34 24 F +49/18 05/34 34 20 www.sap.com

Application Monitor in the SAP Solution Manager

September 2006 3

TABLE OF CONTENTS

1 INTRODUCTION........................................................................................................................ 5

2 APPLICATION MONITOR WITHIN BUSINESS PROCESS MONITORING ............................. 6 2.1 Dialog Performance Monitoring on Function Code Level ....................................................................... 7 2.1.1 General information about Function Codes..................................................................................... 7 2.1.2 Setup of the Dialog Performance Monitor ..................................................................................... 11

2.1.2.1 Customizing Call Type Transaction Code and Function Code .................................................................. 12 2.1.2.2 Customizing Call Type HTTP: URL from the statistical record .................................................................. 13 2.1.2.3 Customizing Call Type Program or Function Module called via RFC ........................................................ 14 2.1.2.4 General Customizing Remarks.................................................................................................................. 16

2.1.3 General Information for setting up the Dialog Performance Monitor............................................. 16 2.1.4 Alert Types..................................................................................................................................... 16 2.1.5 Alert Handling ................................................................................................................................ 17 2.1.6 Appendix for Function Codes ........................................................................................................ 17 2.2 APO Demand Planning Application Log ............................................................................................... 19 2.2.1 Background information and motivation ........................................................................................ 19 2.2.2 Setup of SAPAPO Application Log (MC8K) .................................................................................. 19 2.2.3 Appendix: Messages table ............................................................................................................ 21 2.3 Material Requirements Planning Key Figures....................................................................................... 23 2.3.1 General information about MRP.................................................................................................... 23 2.3.2 Setup of the MRP Key Figure Monitoring...................................................................................... 23 2.3.3 Alert types for object “Appl. Monitoring: MRP Key Figures MRP List” .......................................... 24 2.3.4 Alert types for object “Appl. Monitoring: MRP Key Figures Statistic”. ........................................... 24 2.3.5 Appendix: Exception Groups......................................................................................................... 25 2.4 Due List Log Monitoring ........................................................................................................................ 27 2.4.1 Setup of Appl. Monitoring: Due List Log........................................................................................ 27

2.4.1.1 Monitoring Objects .................................................................................................................................... 27 2.4.1.2 Monitoring Alerts ....................................................................................................................................... 27

2.4.2 Appendix: Due List Log types........................................................................................................ 28 2.5 Mass Data Monitoring for Mass Activities (e.g. Industry Solutions, FI-CA) ......................................... 28 2.5.1 Technical Requirements for Satellite System................................................................................ 28 2.5.2 Background Information and Motivation........................................................................................ 28 2.5.3 Setup of Mass Data Monitor .......................................................................................................... 29

2.5.3.1 Detail Information ...................................................................................................................................... 29 2.5.3.2 Alert Types ................................................................................................................................................ 30

2.6 Business KPIs ....................................................................................................................................... 34 2.6.1 Introduction and one Setup Example ............................................................................................ 34

2.6.1.1 General Information................................................................................................................................... 34 2.6.1.2 Setup Example ‘Procurement’ ................................................................................................................... 34

2.6.2 Warehouse Management .............................................................................................................. 36 2.6.2.1 Transfer Requirements – Alert Types........................................................................................................ 37 2.6.2.2 Transfer Orders – Alert Types ................................................................................................................... 37 2.6.2.3 General Alert Types .................................................................................................................................. 37

2.6.3 Inventory Management.................................................................................................................. 39 2.6.3.1 Goods Movements – Alert Types .............................................................................................................. 39

2.6.4 Procurement .................................................................................................................................. 39 2.6.4.1 Planned Orders – Alert Types ................................................................................................................... 39 2.6.4.2 Purchase Requisitions – Alert Types......................................................................................................... 40 2.6.4.3 Purchase Orders – Alert Types ................................................................................................................. 40

2.6.5 Manufacturing................................................................................................................................ 40


4 September 2006

2.6.5.1 Planned Orders – Alert Types ................................................................................................................... 40 2.6.5.2 Automatic Goods Movements posted with error – Alert Types.................................................................. 41 2.6.5.3 Incorrect Costs caused by confirmation – Alert Types .............................................................................. 41 2.6.5.4 Confirmation Pool errors – Alert Types ..................................................................................................... 41

2.6.6 Plant Maintenance......................................................................................................................... 42 2.6.6.1 PM/CS Notifications – Alert Types ............................................................................................................ 42 2.6.6.2 PM/CS Orders – Alert Types ..................................................................................................................... 42 2.6.6.3 Automatic Goods Movements posted with error – Alert Types.................................................................. 43 2.6.6.4 Incorrect Costs caused by confirmation – Alert Types .............................................................................. 43 2.6.6.5 Confirmation Pool errors – Alert Types ..................................................................................................... 43

2.7 User exit ................................................................................................................................................ 44 2.8 Important SAP Notes............................................................................................................................. 44


September 2006 5

1 Introduction This document is an enhancement of the general “Business Process Monitoring – Setup Guide” which can be found on the SAP Service Marketplace under the Quick Link /BPM Media Library. The above mentioned Setup Guide describes all the basis functionalities of the Business Process Monitoring with the help of the SAP Solution Manager. This basis functionality was originally developed for SAP R/3 systems and can be used for all system with an SAP BASIS. Other non-SAP components can be included in the Business Process Monitoring via the CCMS infrastructure. New functionality that is more related to specific products (e.g. CRM, SCM or SRM purposes) or serves special requirements is now comprised in the monitoring set Application Monitor which will be described within this document.

As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. While the already established monitors are all evaluating specific logs or performance data these new monitors are considering (un-)processed documents in the SAP system and provide so called Business KPIs. These Business KPIs should especially provide

• Automated and early detection of application error situations and backlogs in the core business processes

• Automated error and backlog analysis tools

Currently there are available monitors in the following application areas:

• Warehouse Management (e.g. Transfer Requirements, Transfer Orders)

• Inventory Management (e.g. Goods Movements)

• Procurement (e.g. Planned Orders, Purchase Requisitions, Purchase Orders)

• Manufacturing (e.g. Planned Orders, Autom. Goods Movements posted with error, Confirmation Pool errors)

• Plant Maintenance (e.g. PM/CS Notifications, PM/CS Orders)

The additional User-Exit functionality that the Application Monitor set provides allows the integration of customer-developed data collectors. This functionality will only be described shortly in this document. More details can be found in the corresponding document ‘User Exit – Setup Guide’ also found on the SAP Service Marketplace under the Quick Link /BPM Media Library.


6 September 2006

2 Application Monitor within Business Process Monitoring

The Application Monitor is just one of many different Monitoring Types within Business Process Monitoring. For using this Monitoring Type the respective entry for a specific Business Process step has to be flagged and saved. In the then appearing sub-node you can load Monitoring objects from the corresponding satellite system on which the Business Process step is executed. The latest Monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system as well as on the SAP Solution Manager system. The Service Tool for ST-A/PI is available via the SAP Service Marketplace Quick Link /PATCHES Entry by Application Group Plug-Ins SAP Solution Tools ST-A/PI. Currently, the following Application Monitors are available:

• Dialog Performance Monitoring on Function Code Level – which is especially interesting for the mySAP Business Suite products like CRM, SCM and SRM where complex transactions (e.g. CIC0, SDP94, BBPSC02) provide many different functions so that a general average response time evaluation is of little benefit.

• APO Demand Planning Application Log – which makes an automatic evaluation of the /SAPAPO/MC8K transaction possible

• MRP Key Figure – which provides an automatic evaluation of MRP runs with more sophisticated monitoring possibilities as of 4.7 Enterprise Edition

• Due List Log Monitoring – which provides an automatic evaluation of the due list logs for delivery or billing. This functionality is identical to the “normal” due list log monitoring of Business Process Monitoring.

• Mass Data Monitoring for Mass Activity – which provides some automatic key figure evaluation for Mass activities in IS-U, e.g. for Payment, Billing, Invoicing or Dunning Proposal Runs.

• Business KPIs in the application areas Warehouse Management, Inventory Management, Procurement, Manufacturing and Plant Maintenance

• User Exit – which provides an easy possibility to include self-written monitoring collectors in the Business Process Monitoring

Monitor Available as of ST-A/PI release

Dialog Performance Monitor ST-A/PI 01F

APO Demand Planning Application Log ST-A/PI 01F

MRP Key Figure ST-A/PI 01F

Due List Log Monitoring ST-A/PI 01D

Mass Data Monitoring for Mass Activity ST-A/PI 01G

Business KPIs for Warehouse Management, Inventory Management, Procurement, Manufacturing and Plant Maintenance

ST-A/PI 01H

User Exit ST-A/PI 01E


September 2006 7

2.1 Dialog Performance Monitoring on Function Code Level 2.1.1 General information about Function Codes As of ST-A/PI01F it is possible to monitor Dialog Performance not just for the whole transaction, but also broken down to function code level of a transaction, i.e. specific dialog steps.

A dialog transaction consists of various dialog steps. A dialog step is usually a screen change within one transaction. But not all of these screen changes might be equally performance critical. For example, transaction VA01 can be used to create sales orders. Let’s imagine a customer is experiencing performance problems for this transaction while saving. During all other dialog steps (screen changes) the performance is very good. To monitor the performance of the whole transaction might not be very useful, since the very quick screen changes within the transaction compensate the long duration of the saving and therefore influence the average response time per dialog step. In order to just monitor the saving of VA01, you would need to monitor just the dialog steps with function code ‘SICH’ for transaction code VA01.

a. Function codes that are CUA internal commands

In order to find out the function codes for a dialog step transaction STAD can be used. For this, you need to fade-in the appropriate columns in STAD. Choose button “Sel.fields”.

In the popup choose CUA internal and confirm the popup.

At the end of the table a new column is added, containing the function codes of the dialog steps.


8 September 2006

In the above example you see that not all dialog steps have function codes assigned. The step with function code VA01 represents the initial calling of transaction VA01, the one with function code ‘SICH’ is the one for saving the created order.

Function codes may vary between the different transactions. Within one screen of a transaction you can display the function codes available from buttons and function keys via System Status.

In the popup, double click on the GUI status.

This brings you to an overview of function codes associated to function keys and menu buttons for the screen.


September 2006 9

b. Function codes that are part of HTTP requests

Many applications that are using Business Server Pages are transferring function codes within the HTTP request. One example is SAP CRM with its Activity Management functionality.

In this case the STAD looks different as neither a transaction code nor a function code is visible.


10 September 2006

By choosing the statistical record in the STAD list and then using the button “HTTP Info” as shown above, you can display the complete http string. Here, TCODE stands for transaction code and FCODE for function code.


September 2006 11

2.1.2 Setup of the Dialog Performance Monitor In order to set up the Dialog Performance Monitor you need to select the Application Monitor for a specific step first.

A sub-node is now created with the possibility to load available application monitoring objects from the involved satellite system via the button “<SID>: Reload App Mon Objects”. Afterwards, all available monitoring objects are displayed in table “Application Monitoring Objects”.

Select “Dialog Performance Monitor” and save. As result a sub-node will be created.


12 September 2006

In node Dialog Performance Monitor you have two different tab strips. Within the first one Key figures you choose the alert types you want to monitor. According to the alert types you selected, new nodes are created when saving your settings - one for each alert type.

In case that you want to monitor an SAP APO system you can choose the Alert Type DB proc. Call time (APO) which evaluates the average time spent in the live Cache according to the statistical records.

In the second tab strip of node Dialog Performance Monitor you specify the data collector period in column DC Period, i.e. how often the data collector is supposed to run. This is the time window in which the corresponding statistical records are summarized and for which an average value is calculated. The smallest possible value is 5 minutes which is usually most appropriate for the Dialog Performance Monitor. The default value is 60 minutes.

If you want the data collector only run once a day at a specific time you can maintain the column DC Start Time.

If the data collector should only run and evaluate certain days during the week you can flag the corresponding week day. So in the example above no alerts would be raised on Saturday and Sunday.

Once you save your entries you can customize the different alert types individually.

2.1.2.1 Customizing Call Type Transaction Code and Function Code


September 2006 13

For monitoring of the dialog performance on function code level the call type D needs to be selected in column Call Type by using the F4-help function.

For each of the alert types you can specify transactions in column Value1 and function codes in column Value2.

- If the transaction code is maintained in column Value1 and a wildcard ‘*’ is maintained for the function code column Value2, then the dialog performance for the selected transaction will be monitored for all function codes, i.e. all dialog steps independent of the function codes will be evaluated with the specified collector period.

- If the transaction code is maintained in column Value1 and the column Value2 is left blank all statistics will be evaluated where the transaction code does match the customized value and whose function code is blank. All function codes unequal to blank are not evaluated.

The above setup procedure applies for both, statistics of task type ‘dialog’ and of task type ‘http’.

The entries made in column Value 1 (Transaction Code) and Value2 (Function Code) should be written in capital letters. Otherwise it might happen that the corresponding Monitoring Object cannot be found.

2.1.2.2 Customizing Call Type HTTP: URL from the statistical record As of ST-A/PI01H it is possible to monitor Dialog Performance not just for the whole transaction, but also of Business Server Pages (BSP) calls being transferred using HTTP. You can find this information via transaction STAD.

After selecting the suitable statistical record click on the button “HTTP-Info” and will get the HTTP path used.


14 September 2006

Within the Business Process Monitoring setup you choose the Call Type H and maintain the HTTP string in column Value 1.

As the string length is limited to 120 characters per field you have the possibility to fill in the truncated characters under column Value2. The data collector will concatenate the characters maintained in columns Value1 and Value2.

2.1.2.3 Customizing Call Type Program or Function Module called via RFC As of ST-A/PI01H it is possible to monitor Dialog Performance on program name and/or function module level.


September 2006 15

Note that only the Server RFCs that have been executed on the monitored system can be evaluated and not the RFCs that have been called from the monitored system.

The setup procedure here is the same as described above for the dialog performance on function code level.

In the field of column Value1 the program name and under column Value2 the function module can be maintained.

It is possible to maintain either combinations of program name and function module or just a program name or just a function module.


16 September 2006

For Remote Function Calls only the total response time can be monitored and only server RFCs are considered.

2.1.2.4 General Customizing Remarks It is possible to maintain different combinations of transactions and function codes, HTTP strings or RFC calls for different Dialog Performance Monitor alerts within the same business process step. Hence the different Call Types described above can be combined in every way within the same business process step.

2.1.3 General Information for setting up the Dialog Performance Monitor Some of the value helps in the tables in nodes “Alert Types” are not working. Please ignore empty value helps.

Wild cards (*) can not be used to specify transactions and function codes. You always have to specify the exact transaction code and function code you want to monitor.

All the thresholds are related to the data collector frequency. Every time the collector runs it will check the statistical records that have been created since the last collector run and will evaluate the found statistical records according to the alerts specified. For all “time”-alerts this includes calculating average values for the respective times.

All alerts will be reported if the thresholds defined have been exceeded. Hence, the threshold for red alerts always has to be equal to or greater than the threshold for yellow.

2.1.4 Alert Types

The following is the list of Alert Types that can be monitored with the Dialog Performance Monitoring:

- DB response time: The database response time is the sum of the times for direct reads and sequential reads taken frm the statistical records.

- GUI response time: The GUI time directly corresponds to the GUI time in the statistical records. This field is not visible in the default screen of STAD and has to be chosen explicitly as selection field.

- Roll wait time: The Roll wait time directly corresponds to the Roll wait time of the statistical records. This field is not visible in the default screen of STAD and has to be chosen explicitly as selection field.

- CPU time: The CPU time directly corresponds to the CPU time in the statistical records.

- Total response time: The total response time corresponds to the statistical records Response Time found in transaction STAD.


September 2006 17

- Number of dialog steps (%): The number of relevant dialog steps (i.e. according to the transaction/function code customizing) is compared to the total number of dialog steps since the last collector run. The total number includes all steps of all task types for all transactions since the last collector run. The ratio represents the share of steps caused by this transaction/function code combination in %.

- Total number of dialog steps: This is the number of all dialog steps according to the transaction/function code customizing that occurred since the last collector run.

- DB procedure call time: The DB procedure call time directly corresponds to the ‘DB proc. Call time’ in the statistical records (only available in SAP APO systems). This is the time spent in the live Cache of an SAP APO systems according to the statistical records.

2.1.5 Alert Handling Alerts are only reported back to the SAP Solution Manager if statistical records for the transaction and function code specified have been found. Hence if the transaction has not been executed no alerts are determined. All alerts in the SAP Solution Manager remain grey until the first statistical record for the customized criteria (either transaction code and function code combination or program and function module name combination) has been identified, i.e. the transaction with that function code has been executed for the first time since the monitoring has been activated.

2.1.6 Appendix for Function Codes Within this appendix common Function Codes for important transactions from different Application Areas (CRM, SCM, SRM) are provided.

a. Function Codes for performance critical steps in the SAP CRM scenario ‘Customer Interaction Center’ for transaction CIC0:

Functionality Function Code

Login to CIC CIC0

Search contact person SEARCH

Search contact person by mouse click CSEARCH_SEARCH

Search Business Partner &IC1

Confirm Contact Person SCEARCH_CONTINUE

Search in the knowledge database %__GC123 1

Create document 10MAIN_CREATE

Open the action box e.g. %GC_110 2

Create sales order BUS_LOCATOR_SRCH_GO

End contact ECNT

b. Function Codes for SAP APO functionality /SAPAPO/SDP94:

Funktionality Function Code

Selection of Planning Book via double-click %_GC 136 22

Selection of Selection Profile via double-click %_GC 128 22

Loading from Key Figure values ALL_APPL_REFRESH

Drill down %_GC 307 1


18 September 2006

Drill up %_GC 307 2

c. Function Codes for SAP SRM functionality BBPSC02 (create shopping cart)

Funktionality Function Code

Add item from catalog ADDI

Call external catalog - selected via help value CTLG

Favorites FAVO

Order shopping cart SC_ORDER

Get results of catalog validation function VALI

Saving a confirmation BUTTON_SAVE

A spreadsheet about the function codes for other SRM transactions can be found on the SAP Service Marketplace under the Quick Link /SERVICEOPERATION EW Family SRM: Basis GA/GV/EW session.


September 2006 19

2.2 APO Demand Planning Application Log

2.2.1 Background information and motivation In the SAP APO Demand Planning area some of the most important background jobs are related to the ABAP report /SAPAPO/TS_BATCH_RUN. Variants of these jobs are created via transaction /SAPAPO/MC8D. At this transaction you define a specific job number for the corresponding job (corresponds with the variant that can be then seen in SM37). In case you flag Generate log during the definition, the job will write a related log file that you can view either as a spool file in transaction SM37 or with the help of transaction /SAPAPO/MC8K. As it is not unusual that these background jobs process several thousand characteristic combinations and not all generated log messages are of importance it is very cumbersome to manually analyze the log and evaluate if the job run was successful from an application point of view.

The new Application Monitor SAPAPO Application Log (MC8K) provides the opportunity to analyze and evaluate the log file automatically.

2.2.2 Setup of SAPAPO Application Log (MC8K) After loading possible monitoring objects from your APO satellite system there should appear one object called SAPAPO Application Log (MC8K). Flag this object and push Save + next open check.

A new sub-node appears where you get to see two tab strips (Detail Information and Alert Types). The first one shows you just the data collector frequency, i.e. how often the collector checks if new logs were written. The default value is 60 minutes and usually does not have to be changed.

The second tab strip provides a selection of two different alert types which are both related to the dialog transaction /SAPAPO/MC8K. The Alert Type Appl. Log Alerts gives you the opportunity to evaluate specific occurring log messages (e.g. warnings and errors). The Alert Type Appl. Log Summary provides just the same data as the summary screen that appears when you try to leave transaction /SAPAPO/MC8K. Flag these objects and push Save + next open check.

Two new sub-nodes appear.


20 September 2006

Node Appl Log Alerts

In the node Appl. Log Alerts you get a customizing table with columns Job Number, MSG TYPE, MSG ID, MSG NO and two threshold columns. The Job number is the same that was defined in transaction /SAPAPO/MC8D and would be used in /SAPAPO/MC8K. The most interesting Message Types are probably ‘W’ (Warning - normally indicated with a yellow alert) and ‘E’ (Error - normally indicated with a red alert). Typical Message IDs in these surroundings are /SAPAPO/MA, /SAPAPO/SDP and /SAPAPO/TSM. The Message Number is a one, two or three digit number.

One way to find out the relevant Message ID and Message Number is by double-clicking on a log file line within transaction /SAPAPO/MC8K.

The Job Number has to be written in capital letters. Otherwise it might happen that the corresponding log cannot be found.

The threshold values that you enter define how many error messages of the specified kind have to occur respectively so that the evaluation of the log file is considered to be yellow or red.

Node Appl Log Summary

In the node Appl. Log Summary you also have to enter the Job number as mentioned above and two threshold values. These threshold values define how many Characteristic Combinations were saved with error, so that a yellow or red rating appears.

Background information:

When you leave a log file in /SAPAPO/MC8K via the green arrow button (F3) you get to a summary screen like the following:

During the monitoring with SAP Solution Manager you will also get the information about the total number of characteristic combinations processed, thereof saved successfully, not saved or only saved with errors. The


September 2006 21

thresholds defined in the node Appl. Log Summary are only used for evaluating the characteristic combinations that were saved with errors.

2.2.3 Appendix: Messages table The following table shows important Application Log messages that might be interesting for monitoring purposes.

Message ID MSG No MSG Type Text Remark

/SAPAPO/MA 034 E Selection accesses data that is currently locked

/SAPAPO/MA 034 E The selection uses data that is currently locked

The affected char. comb. are reprocessed.

/SAPAPO/MA 257 E No job with the number & exists

/SAPAPO/MA 264 E No data for processing can be selected for job &

The error will cancel processing of the job

/SAPAPO/MA 282 E Application error during release to liveCache

Check quality of the data in the Planning Area, including plausibility of dates.

/SAPAPO/MA 289 E No requirements exist for product & in the release period

(Release to R/3)

/SAPAPO/MA 481 E No time buckets profile is selected The error will cancel processing of the job

/SAPAPO/MA 502 E Not possible to carry out the forecast - no historical data

/SAPAPO/MA 523 E Forecast profile & does not exist The error will cancel processing of the job

/SAPAPO/MA 785 E Multiple Linear Regression interrupted by an error.

(Forecast), Check if your MLR.EXE, which can be located on an dedicated host is up and running

/SAPAPO/MA 838 E Release has not been made (consumption group <> ‘&1’)

(Release to SNP)

/SAPAPO/MSDP_PB 016 E No data records found for selected data view &1

The error will cancel processing of the job. (e.g. Data View doesn’t exist)

/SAPAPO/OM_TS

502 E Lock could not be acquired


/SAPAPO/OM_TS 503 E Object has been changed since the start of the transaction



22 September 2006

Message ID MSG No MSG Type Text Remark

/SAPAPO/SDP 172 E You are not authorized to run background job &1

/SAPAPO/SDP 172 E You are not authorized to run background job &1


/SAPAPO/SDP 307 E A version preassigned in the rows cannot be selected

/SAPAPO/SDP_PAR 003 No parallel processing profile specified SCM 4.1

/SAPAPO/SDP_PAR 004 Parallel processing profile &1 does not exist

SCM 4.1 The error will cancel processing of the job

/SAPAPO/SDP_PAR 005 Internal error during parallel processing

SCM 4.1

/SAPAPO/SDP_PAR 008 Application indicator not specified SCM 4.1

/SAPAPO/SDP_PAR 009 Parallel processing profile &1 not permitted (incorrect appl. indicator)

SCM 4.1 The error will cancel processing of the job

/SAPAPO/TSM 023 E Transfer to R/3 using mixed periodicities is not allowed


/SAPAPO/TSM 207 E No liveCache anchor found

/SAPAPO/TSM 219 E Invalid data status (Forecast), Run /SAPAPO/TS_LCM_CONS_CHECK to check your Planning Area


September 2006 23

2.3 Material Requirements Planning Key Figures 2.3.1 General information about MRP Material Requirements Planning (PP-MRP) with transaction MD01

The main function of material requirements planning is to guarantee material availability, that is, it is used to procure or produce the requirement quantities on time both for internal purposes and for sales and distribution. This process involves the monitoring of stocks and, in particular, the automatic creation of procurement proposals for purchasing and production.

The automatic planning run in MRP determines any shortages and creates the appropriate procurement elements. The system creates MRP lists during the planning run according to how you set the creation indicator (normal MRP list or depending on the exception messages). These lists contain the planning result for the material.

The MRP list always displays the stock/requirements situation at the time of the last planning run and it also provides a work basis for the MRP controller (German: Disponent). Changes that are made after the planning date are not taken into consideration, so the list is static. MRP lists are stored in the system until they are either deleted manually or replaced by new lists from a subsequent planning run.

During the planning run, the system recognizes exceptional situations where you usually have to manually reprocess the planning result and it records these situations as exception messages (can be found via transaction MD05). The system displays the exception messages in the evaluations for MRP.

As of ST-A/PI01F it is possible to monitor the key figures of the MRP Run and raise alerts regarding the number of exceptions in the list and the MRP-runtime.

2.3.2 Setup of the MRP Key Figure Monitoring In the Setup Business Process Monitoring session, mark the flag for Application Monitor in the business process step where you want to set up the MRP Key Figure monitoring.

After saving, a node, ‘Application Monitor’ is created. There, choose ‘Reload Application Monitoring Objects’ from the satellite system and you will get the monitoring objects available in the corresponding satellite system where the business process step is performed.

Depending on the basis release of the satellite system, one or two objects are available.

For all releases higher 4.0 you can choose “Appl. Monitoring: MRP Key Figures MRP List”. If the basis release is 4.7 or higher, there is a second object available: “Appl. Monitoring: MRP Key Figures Statistic”.

Flag the objects for monitoring and save. A new node will appear for every object chosen.


24 September 2006

In the ’Detail Information’ tab, enter the desired frequency for the data collector. This is the time window for which new MRP Lists will be searched. The smallest possible value is 5 minutes. Default value is 60 minutes.

In the ‘Alert Types’ tab, select the appropriate alert types that should be monitored.

2.3.3 Alert types for object “Appl. Monitoring: MRP Key Figures MRP List”

MRP list:

Here you can configure the creation of yellow or red alerts when the number of exceptions contained in the MRP List exceeds the corresponding thresholds.

You can customize this alert for specific plant, user and exception group (1-8) combinations. You cannot maintain specific exception message numbers.

No MRP list:

This alert type provides you with a yellow or red alert if there was no MRP list created. The only thing to choose here is the criticality of the alert (yellow or red).

2.3.4 Alert types for object “Appl. Monitoring: MRP Key Figures Statistic”.

Please remember that this monitoring object is only available for release R/3 Enterprise (4.7) or higher.


September 2006 25

All alert types of this object are customized for a specific plant.

Runtime:

Here you can configure the creation of yellow or red alerts when the runtime of the MRP run exceeds the thresholds.

Enter the plant for which you want to monitor the MRP runtime and customize the number of minutes to set the thresholds when the MRP is running too long.

Cancelled:

Here you can configure the creation of yellow or red alerts when the number of cancelled materials in the MRP List exceeds the corresponding thresholds.

Enter the plant that you want to monitor and the thresholds for yellow or red alerts when the number of cancelled materials is too high.

Dumps:

Here you can configure the creation of yellow or red alerts if there is a dump during the MRP Run. The only thing to choose here is whether the alert should be yellow or red.

2.3.5 Appendix: Exception Groups The following table summarizes which exception groups exist in an SAP System and what messages are grouped within this exception group.

Exception Group Exception Message Number

Exception Message

69 Recursive BOM components possible 02 New, and opening date in the past

1 "new; opening date in the past” 05 Opening date in the past 03 New, and start date in the past 06 Start date in the past 2 "new; start date in the past”

63 Production start before order start 04 New, and finish date in the past 07 Finish date in the past 3 "new; finish date in the past”

64 Production finish after order finish 01 Rescheduled 42 Order proposal has been changed 44 Order proposal re-exploded 46 Order proposal has been manually changed 61 Scheduling: Customizing inconsistent 62 Scheduling: Master data inconsistent

4 "general exceptions”

80 Reference to retail promotion


26 September 2006

Exception Group Exception Message Number

Exception Message

82 Item is blocked 50 No BOM exists 52 No BOM selected 53 No BOM explosion due to missing config. 54 No valid run schedule

5 "exceptions from BOM explosion” 55 Phantom assembly not exploded

25 Excess stock 26 Shortage in individual segment 40 Coverage not provided by master plan 56 No requirements coverage 57 Disc. matl partly replaced by follow-up 58 Uncovered reqmt after effective-out date 59 Receipt after effective-out date 70 Max. release qty - quota exceeded

6 "exceptions from the availability check” 96 Stock fallen below safety stock level

10 Bring process forward 15 Postpone process 20 Cancel process

7 "exceptions from rescheduling” 30 Plan process according to schedule 8 "terminations” 98 Abnormal end of requirements planning

You assign exception messages to exception groups. You do this in Customizing for MRP, or for Consumption-Based Planning, in the IMG activity Define and group exception messages.

You can change the texts for exception groups. You do this in Customizing for MRP, or for Consumption-Based Planning, in the IMG activity Check exception group texts.

The assignment of exception messages to exception group 8 is fixed and cannot be changed.


September 2006 27

2.4 Due List Log Monitoring As a short remark it should be mentioned that this specific Application Monitor provides no added value to the standard Alert Type Due List Log. One gets exactly the same alerts and the same data collectors are used (compare section 5.3.7 in the general Setup Guide for Business Process Monitoring).

A due list is a list that contains several entries (documents) depending on selection criteria. There are different types of due lists in an SAP system of which the following two are the most important: delivery creation via VL04 or VL10 (type L), invoice creation via VF04 or VF06 (type F). The delivery due list log can be directly accessed via transaction V_SA, the billing due list log via transaction V.21.

You can get another view on the Due List logs by executing ABAP report SDSAMAN4. This allows more selection criteria and sometimes this report finds logs that are not displayed via V_SA or V.21.

In case of a billing due list, the list contains e.g. a number of sales documents that need to be billed. If the billing due list was processed previously and it is important to know which billing documents were created from this billing due list, it can be displayed in the due list log for this billing run.

2.4.1 Setup of Appl. Monitoring: Due List Log After loading possible monitoring objects from your satellite system there should appear one object called Appl. Monitoring:Due List Log. Flag this object and push Save + next open check.

2.4.1.1 Monitoring Objects The monitoring object is the respective due list type. That can be ‘Delivery’ or ‘Billing’. If a certain user is processing the due list, the name of the user can be specified here. If it is user independent a wild card ‘*’ can be used. The aggregation level needs to be defined. This could be ‘per day’, ‘per hour’ or ‘per log’.

2.4.1.2 Monitoring Alerts For the monitoring of due list log messages, four different Alert Types can be used:

‘No docs created’ refers to the status of the document creation itself. The alert rating (YELLOW or RED) will be raised if no documents were created during a Due List run.

‘Too few documents’ refers to a minimum number of documents that should be created during a Due List run. The threshold values for the number of documents that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained.

‘Num. Of messages in DL run’ refers to the total number of message created during a Due List run. The threshold values for the number of messages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained.

‘Messages’ refers to specific due list log messages. The message type, the message ID and the number can be specified. It is also possible to use wild


28 September 2006

cards. The threshold values for the number of messages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained.

2.4.2 Appendix: Due List Log types The following table summarizes which Due List Log types exist overall (of which many cannot be monitored automatically at the moment) and which are the transactions that write these logs.

Collective run type Description Transactions writing into the log

C Check Delivery D Delivery split VLSP F Invoices from VF04 VF04, VF06 G Revenue recognition VF02, VF04, VF06 K Picking VG01, VL06O L Deliveries from VL04 VL04, VL10 M Freight list VGM1 R Invoice lists VF24 S Cancel coll. run V.21 W Picking waves VG01, VL06O, VL35

2.5 Mass Data Monitoring for Mass Activities (e.g. Industry Solutions, FI-CA)

2.5.1 Technical Requirements for Satellite System

SAP BASIS 620 or higher

FI-CAX,

INSURANCE,

IS-H,

IS-M,

IS-PS-CA,

IS-T,

IS-U/CCS,

4.72

SAP Note 868435 (defines Counter for Mass Activities: Billing Run, Invoicing Run, Bill Printout)

2.5.2 Background Information and Motivation A lot of transactions which are processing a huge amount of data are using the Mass Activity technology, as for example in most of the Industry Solutions, such as SAP for Utilities, SAP for Insurance or FI-CA application. This framework provides key figures (so called ‘counters’) for some Mass Activity types which can be used to set up an Application Monitoring for those applications. Based on our experience, the most critical applications (in terms of performance) have been identified and are now available for the Application Monitoring:

- Payment Run (Transaction FPY1)

- Billing Run (Transaction EA38)


September 2006 29

- Bill Printout (Transaction EA29)

- Invoicing Run (Transaction EA26)

- Dunning Proposal Run (Transaction FPVA)

2.5.3 Setup of Mass Data Monitor After loading possible monitoring objects from your Industry Solution/FI-CA based satellite system there should appear one object called Mass Data Monitor. Flag this object and choose Save + next open check.

A new sub-node appears where you get to see two tab strips (Detail Information and Alert Types). The first one is essential to decide which Mass Activity should be monitored in which frequency.

2.5.3.1 Detail Information

Figure 2-1: Assignment of Mass Activity Type to Process Step


30 September 2006

In table Detail Information you can specify the Mass Activity Type, Run ID and the Data Collector Period.

Choose the correct Mass Activity Type (see F4 help). Only one Mass Activity Type can be chosen per business process step. Please use the following mapping to assign the relevant type:

- Payment Run PAYP

- Billing Run BILL

- Bill Printout BIPR

- Invoicing Run INVO

- Dunning Proposal Run MAHN

The Run ID is an optional parameter to identify the most important runs and to focus the monitoring on these processes.

Example: In a business scenario the customer is executing a Billing Run for a small portion of customers every day and one big Billing Run at the end of a month for more than 90% of the total customers. The daily runs always get the Run ID ‘ABC’ in transaction EA26. The monthly Invoicing Run gets the ID ‘XYZ’

Figure 2-2: Run ID for Invoicing Run in transaction EA26

Without specifying any Run ID in the corresponding parameter field in the Solution Manager, ALL Invoicing Runs would be monitored. This can lead to confusion and unnecessary alerts. Therefore, in this case it is vital to include the corresponding Run ID in the parameter field (in our example ‘XYZ’).

The last parameter defines the frequency of the execution of the Mass Data Monitor Collector. Minimum for the Data Collector Period is 5 minutes. Enter a suitable time period (in minutes).

2.5.3.2 Alert Types The second tab strip provides the selection of the different alert types which can be set for monitoring the mass activity. Choose the alert types relevant for your monitoring.


September 2006 31

The following alert types are available:

‘Selected Objects’ refers to the number of documents which have been selected to be processed in the specific Mass Activity (e.g. the number of selected items in Payment Run)

‘Successful Objects’ refers to the number of documents which have been successfully processed by the relevant Mass Activity (e.g. the number of successfully paid items in the Payment Run)

‘Exceptions’ refers to the number of documents which could not be processed by the Mass Activity due to not fulfilling business related conditions (e.g. not paid items in Payment run, due to a lock or if the amount is equal to 0 etc,)

‘Canceled Jobs’ refers to the number of jobs (if parallelization is used) which did not complete their processing (e.g. due to an ABAP dump, manual abortion etc.)

‘Duration’ refers to the total runtime of all jobs related to the Mass Activity (i.e. the timeframe from the start of the first and the completion of the last job of one Mass Activity)

‘Selected Objects compared to last run (in %)’ refers to ratio of the number of documents selected to be processed in the current run compared to the number of documents selected to be processed in the last run of the corresponding Mass Activity. This means that the current value is compared to the last value available in SAP Solution Manager. (Comparison is not possible if no data concerning previous runs of the relevant Mass Activity is yet available in SAP Solution Manager).

‘Successful Objects compared to last run (in %)’ refers to the ratio of the number of documents processed successfully in the current run compared to the number of successful documents in the last run of the of the corresponding Mass Activity This means that the current value is compared to the last value available in SAP Solution Manager. (Comparison is not possible if no data concerning previous runs of the relevant Mass Activity is yet available in SAP Solution Manager).

‘Exceptions compared to last run (in %)’ refers to the ratio of the number of documents which could not be processed in the current run compared to the number of unsuccessful documents in the last run of the of the corresponding Mass Activity This means that the current value is compared to the last value available in SAP Solution Manager. (Comparison is not possible if no data concerning previous runs of the relevant Mass Activity is yet available in SAP Solution Manager).

‘Duration compared to last run (in %)’ refers to the ratio of the total runtime of all jobs related to the current run compared to the total


32 September 2006

runtime of all jobs related to the last run of the corresponding Mass Activity This means that the current value is compared to the last value available in SAP Solution Manager. (Comparison is not possible if no data concerning previous runs of the relevant Mass Activity is yet available in SAP Solution Manager).

In general you have to distinguish between ‘total’ alerts (e.g. total runtime or total number of successfully processed objects) and ‘relative’ alerts (comparison with the last Mass Activity run). Every time the collector is running, a small history table is written or updated. For each Mass Activity there are only two values included in the history: the last run and the current run. The comparison is therefore only possible with the last run.

If the collector is executed the first time for a Mass Activity there are no history values available, therefore the comparison is not possible. In this case the status of this node will remain initial and in the alert text the message ‘Comparison of current run and last run not possible. Counter is 0.’ is shown.

When saving your entries you create sub-nodes in the session tree for the selected alert types. In these sub-nodes you can now customize thresholds for the alerts.

Thresholds for ‘Total’ Alerts

For all ‘total’ alerts (i.e. ‘Selected Objects’, ‘Successful Objects’, ‘Exceptions’, ‘Cancelled Jobs’ and ‘Duration’) the setup of the thresholds is identical:

The name in brackets shows the unit of the value to be entered. To define a YELLOW or RED rating you have to set a value in the corresponding column. The rating will change when the value is higher than the value defined.

Example: In the example above the rating would change from GREEN to YELLOW if the number of selected objects would be at least 100001 and would again change to RED if the number is 150001 or more.


September 2006 33

Thresholds for ‘Relative’ Alerts

For all ‘relative’ alerts (i.e. ‘Selected Objects compared to last run (in %)’, ‘Successful Objects compared to last run (in %)’, ‘Exceptions compared to last run (in %)’ and ‘Duration compared to last run (in %)’) the setup of the thresholds is identical:

In the column ‘Threshold for YELLOW’ you have to enter a percentage value. If this node is active, the collector always calculates the difference from the current run to the last run. If the percentage of the difference exceeds the threshold the rating will change correspondingly.

Example: Based on the example above, the rating would change from GREEN to YELLOW if the number of selected objects is 11% higher than the number of objects selected by the last job and would change again to RED if the percentage would be 21% or higher.


34 September 2006

2.6 Business KPIs 2.6.1 Introduction and one Setup Example 2.6.1.1 General Information As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. While the already established monitors described in the above sections are all evaluating specific logs or performance data these new monitors are considering (un-)processed documents in the SAP system and provide so called Business KPIs. These Business KPIs should especially provide

• Automated and early detection of application error situations and backlogs in the core business processes

• Automated error and backlog analysis tools

Currently there are available monitors in the following application areas:

• Warehouse Management (e.g. Transfer Requirements, Transfer Orders)

• Inventory Management (e.g. Goods Movements)

• Procurement (e.g. Planned Orders, Purchase Requisitions, Purchase Orders)

• Manufacturing (e.g. Planned Orders, Autom. Goods Movements posted with error, Confirmation Pool errors)

• Plant Maintenance (e.g. PM/CS Notifications, PM/CS Orders)

Further information on the different Business KPIs can be found either in SAP Note 945081 (short overview) or in the following sections.

2.6.1.2 Setup Example ‘Procurement’ As an example we take the application area Procurement. In this area you could evaluate the following KPIs:

• The number of Planned Order with start today

• The number of Planned Orders with Start in the past

• The number of Purchase Requisitions item created (today)

• The number of open Purchase Requisitions items

• The number of overdue Purchase Requisition items

• The number of Purchase Order item created (today)

• The number of open Purchase Order items

• The number of overdue Purchase Order items

Setup Procedure

After loading possible monitoring objects from your satellite system there should appear one object called Purchase Orders. Flag this object and push Save + next open check.


September 2006 35

Select the key figures to be monitored.

Then decide how often the data collector should run. You can either specify a certain data collection period (e.g. every 180 minutes) or specify a certain point of time during the day when the data collector should run.

For the configuration of alerts you only specify threshold values within the SAP Solution Manager. The configuration of the selection criteria for the alert is done via a so called CUSTID in the monitored system itself.

Hence call transaction ST13 on the corresponding satellite system and push F4. Then select the entry KPI_REPORTS and execute (F8).


36 September 2006

On the next screen you see different application areas with push-buttons Analyze and Customize respectively. The Analyze button is for the operational usage of the monitoring. For the setup only the Customize button is of interest. After pushing the Customize button you are able to define a three digit CUSTID. You just enter the arbitrarily chosen CUSTID and enter all the wished selection criteria. Then you save these settings.

Now back in the SAP Solution Manager you can chose this defined CUSTID via F4 value help for all alert types that you want to configure. In the example below the alert type No. of Purchase Order items created is configured, i.e. we want to get a yellow (red) alert if less than 2000 (1500) PO items are created per day.

You can assign different CUSTIDs to the same alert type as shown below

2.6.2 Warehouse Management All existing KPIs in the Warehouse Management area can only be set up if the Warehouse Activity Monitor (transaction LL01) is used in the R/3/ERP system. The information displayed depends on the settings and


September 2006 37

the selection criteria maintained in the customizing of the Warehouse Activity Monitor. Please use the Warehouse Activity Monitor in the R/3/ERP system for a detailed analysis.

2.6.2.1 Transfer Requirements – Alert Types Open Transfer Requirements

The conversion of Transfer Requirement (TR) to Transfer Order (TO) can be performed in three different ways:

- directly after the TR creation - automatically using the background job RLAUTA10 - manually with transaction LT04

The Transfer Requirement remains as an open document, if the Transfer Order can not be created. This might occur for different reason, for example:

1. in stock placement process: the destination storage bin can not be determined (error message L3 008) – because of incorrect customizing settings (not all storage types are considered in the storage type search sequence)

2. in stock removal process: the source storage bin can not be determined- because of incomplete customizing settings for the source storage type search sequence

3. in stock removal process: no stock could be proposed for picking – (because the stock placement process is not finished yet, the stock is only available on the interim storage types)

If the stock placement is finished, the open Transfer Requirement could be converted into Transfer Order automatically via the report RLAUTA10 if this is scheduled as a background job.

Additionally the outstanding, not processed TRs can be converted to TOs manually. Within manual execution the warehouse supervisor can then analyze the error’s and correct it. The backlog processing might be very time consuming, especially the error analysis and correction. Therefore it is very important that a person is assigned, which is responsible for the backlog processing.

2.6.2.2 Transfer Orders – Alert Types Unconfirmed Transfer Orders

This KPI measures the number of open binning/picking transfer order line items, which were created before a particular date. The binning/picking transfer orders are identified by the source/destination storage type in the order line item. The number of items is reported at storage type level, within a particular warehouse number.

2.6.2.3 General Alert Types Open posting change notices

This KPI measures the number of open posting change line items that were created before a particular date. The number of open line items is aggregated at movement type level within a particular warehouse.

This informs warehouse supervisors of posting change notices that were initiated by WM and that have not been processed in a timely manner.

Critical Deliveries

This KPI displays all WM-relevant deliveries for which not all items have been picked that meet one of the following conditions:

- The time requirements for staging were not met.

- The time deadline for loading the delivery was not met.

- The time period for the goods issue for the delivery was exceeded.


38 September 2006

This KPI can be used to inform warehouse supervisors in a timely manner whether deliveries have been processed on schedule. This makes it possible for you to take necessary measures to ensure on-time deliveries. This task also displays deliveries that may have been overlooked.

Which of the three conditions above are used to determine whether a delivery is critical or not depends on the comparison time you define for creating the picking wave in Customizing. If you do not define a comparison time, the warehouse activity monitor uses the loading time as a reference for the critical time period. The critical time period should be defined so that sufficient time remains to take any corrective measures necessary to ensure that goods can be delivered on schedule.

For deliveries that contain both items that are picked from a WM-managed storage location as well as those that are not WM-relevant, you need to ensure that the warehouse activity monitor decides whether a delivery is critical or not exclusively from the standpoint of WM. This means that a delivery is not seen as critical if all WM-relevant items have been picked even though non-WM-relevant items exist that have not been picked within the specified time period.

A special case exists if the system selects the material staging time as the reference time because the system enters this time in both the delivery header and in the delivery item. These time periods can vary. Since the warehouse activity monitor only processes data at the header level, only the material staging time period in the delivery header is considered when calculating the critical time period.

Negative Stocks

This KPI displays all negative stock that has exceeded the critical time period defined in the system.

The existence of negative stock also indicates incomplete processes that can be displayed by the warehouse activity monitor. For example, these can include:

• posting change notices that are not completely processed

• goods receipts processed in WM that were not yet posted in IM

Critical stocks for production supply

This KPI displays inconsistencies in stock quantities that are used for material staging to production.

These critical processes can appear during the staging of materials for production orders for which fixed production bins have been defined in a control cycle. Inconsistencies can occur between the transfer requirements and the transfer requirement quantities that are updated in a reservation when

- Transfer requirements are created manually to supply materials to production storage bins

- Reservations are deleted without making necessary corrections to open transfer requirements in WM

For PP/PP-PI production orders, when components are deleted or changed, the system modifies the transfer requirements automatically. For repetitive manufacturing, this automatic process is not available. As soon as this connection (and therewith, the reservation) is deleted for which transfer requirements have already been created, the transfer requirements are not modified.

The determination of such inconsistencies is important because they can lead to problems when creating transfer orders for the supply of necessary materials to production.

The warehouse activity monitor is able to determine for which materials and storage bins inconsistencies exist, therefore, making it possible to take necessary measures to correct potential bottlenecks in production.

Using the warehouse activity monitor, you can carry out the following additional functions for materials and storage bins for which inconsistencies are found:

• You can display transfer orders that correspond to the material and storage bin displayed.

• You can display all reservations and transfer requirements for the material and storage bin concerned.


September 2006 39

Interim storage stock, without movement

The display of critical stock in interim storage areas makes it possible to identify goods movements that have not been fully processed within an acceptable period of time.

The warehouse activity monitor displays stock in interim storage areas that has not moved within the time parameters defined in the Warehouse Activity Monitor.

Stock that exists in interim storage areas always indicates incomplete processes. Therefore, any stock that remains in interim storage areas for a lengthy period of time is considered to be critical.

For stock in interim storage areas, the Warehouse Activity Monitor can display the following open processes:

• Critical stock in the interim shipping area for deliveries:

This can mean that there are open goods issues for materials that have not yet been delivered.

• Stock in the interim storage area for differences:

This can indicate discrepancies (from taking inventory or when confirming transfer orders) that have not yet been cleared.

• Stock in the interim storage area for posting changes:

This means that there may be posting change notices that have not been fully processed.

• Stock in the interim area for goods receipts:

This indicates that there may be goods that have not yet been stored in the warehouse.

2.6.3 Inventory Management 2.6.3.1 Goods Movements – Alert Types A goods movement is a physical or logical movement of materials leading to a change in stock levels or resulting in the consumption of the material.

The Goods Movement Key Figures have been developed to provide high level indicators for the throughput in terms of document volume in business processes related to Goods Movements. These Key Figures allow measuring the number of goods movements (goods issues/ goods receipts) posted on a specific date.

Available Key Figures:

• GI (goods issue) throughput: This key figure allows to measure the number of goods issues posted on a specific date that fulfill the customized selection criteria of plant, storage location and movement type combination.

• GR (goods receipt) throughput: This key figure allows to measure the number of goods receipts posted on a specific date that fulfill the customized selection criteria of plant, storage location and movement type combination.

2.6.4 Procurement Usually an MRP run takes place within a procurement process. Hence also the MRP run should be monitored as described in section 2.3.

2.6.4.1 Planned Orders – Alert Types A Planned Order is a request created in the planning run or manually via MD11 for a plant to trigger the procurement of a material in a certain quantity and at a specific date.

The monitoring object 'Planned Orders' allows tracking the number of Planned Orders with start date today and earlier.


• Start Today (external): Planned orders for external procurement with start date 'Today'


40 September 2006

• Start < Today (external): Planned orders for external procurement with start date before 'Today'.

2.6.4.2 Purchase Requisitions – Alert Types A Purchase Requirement is a request or instruction to Purchasing to procure a quantity of a material or service so that it is available at a certain point in time.

The Purchase Requisition Key Figures have been developed to provide high level indicators for the throughput and backlog in terms of document volume in business processes related to Purchase Requisitions. These key figures allow measuring the number of purchase requisitions that have been created on the date of the data collection as well the number of purchase requisitions which are open / overdue. Available Key Figures:

• N° of Requisition Items created: This key figure allows measuring the number of purchase requisitions created on the date of data collection that fulfill customized selection criteria.

• N° of open Requisition Items: This key figure allows measuring the number of purchase requisitions that are open on the date of data collection and fulfill customized selection criteria.

• N° of overdue Requisition Items: This key figure allows to measure the number of purchase requisitions that are overdue (delivery date < date of data collection) and fulfill customized selection criteria.

The selection criteria are combinations of Purchasing Organization, Plant, Creation Indicator, Item Category and Document Type.

2.6.4.3 Purchase Orders – Alert Types A Purchase Order is a request or instruction from a purchasing organization to a vendor (external supplier) or a plant to deliver a quantity of material or to perform services at a certain point in time.

The Purchase Order Key Figures have been developed to provide high level indicators for the throughput and backlog in terms of document volume in business processes related to Purchase Orders. These key figures allow measuring the number of purchase orders that have been created on the date of the data collection as well as the number of the number of purchase orders which are open and overdue. A purchase order is overdue if the scheduled quantity until the date of data collection is less than the delivered quantity.


• N° of Purchase Order items created: Number of purchase orders created on the date of data collection that fulfill customized selection criteria.

• N° of open Puchase Order items: Number of Purchase Orders that are open on the date of data collection that fulfill customized selection criteria.

• N° of Puch. Ord. items overdue: Number of Purchase Orders that are overdue that fulfill customized selection criteria.

The selection criteria are combinations of Purchasing Organization, Plant, Document Category, Item Category and Document Type.

2.6.5 Manufacturing Usually an MRP run takes place within a manufacturing process. Hence also the MRP run should be monitored as described in section 2.3.

2.6.5.1 Planned Orders – Alert Types A Planned Order is a request created in the planning run or manually via MD11 for a plant to trigger the production of a product in a certain quantity and at a specific date.

The monitoring object 'Planned Orders' allows tracking the number of Planned Orders with start date today and earlier.



September 2006 41

• Start Today (internal): Planned orders for in-house production with start date 'Today'

• Start < Today (internal): Planned orders for in-house production with start date before 'Today'.

2.6.5.2 Automatic Goods Movements posted with error – Alert Types While posting of actual data goods movement of backflushed components might fail for several reasons e. g. stock level is insufficient at the time of the withdrawal posting. Depending on the application customizing a backlog is created in this case. This backlog has to be checked on a regular base using transaction COGI and documents have to be post processed.

This monitoring object checks pool for automatic goods movements with errors resulting from:

• PP Production Orders

• PS Network Orders

• PM Maintenance Orders

• PI Process Orders

• Total number of Orders

2.6.5.3 Incorrect Costs caused by confirmation – Alert Types If during the confirmation of an order an error is detected for cost determination then an entry is generated in the error pool for the cost determination. This error pool has to be checked on regular base using transaction COFC. If the error pool is not empty then all records - after error cause has been fixed - have to be post processed. If for example a record is not correct due to a not maintained price for the activity type, this price must be maintained before.

This monitoring object checks the pool of incorrect costs caused by confirmation of:

• PP Production Orders



• PI Process Orders


2.6.5.4 Confirmation Pool errors – Alert Types Monitoring object Confirmation pool checks for entries in the confirmation pool that derived from the Plant Data Collection (PDC) or the Cross-Application Time Sheet (CATS). In case of CATS, entries might be written while transfer of time sheet data to target component (e.g. Project System). This confirmation pool has to be checked on regular base.

Available Key Figures of Confirmation Pool errors caused by:

• PP Production Orders (PDC)

• PS Network Orders (CATS)

• PM Maintenance Orders (CATS)



42 September 2006

2.6.6 Plant Maintenance 2.6.6.1 PM/CS Notifications – Alert Types The PM/CS Notification Key Figures have been developed to provide high level indicators for the throughput and backlog in terms of document volume in business processes related to PM/CS Notifications. These key figures allow tracking the number of PM/CS notifications that have been created and closed on the date of the data collection. Furthermore, these key figures allow to monitor the number of overdue PM/CS Notifications with a Required End Date less than or equal to the date of data collection. The key figures allow distinguishing between notifications that origin from maintenance plan scheduling and notifications that do not origin from maintenance plan scheduling (manual notifications created with transactions IW21 and IW51).

Available Key Figures are:

• Total N° of Notif. created: Total number of PM/CS Notifications created on the date of data collection that fulfill customized selection criteria.

• N° of Notif. from Maint. Sched. created: Number of PM/CS Notifications that originate from maintenance plan scheduling created on the date of data collection that fulfill customized selection criteria.

• N° of manual Notif. created: Number of PM/CS Notifications that have been created manually on the date of data collection that fulfill customized selection criteria.

• Total N° of Notif. NOCOed per date: Total number of completed PM/CS Notifications on the date of data collection that fulfill customized selection criteria.

• N° of Notif. from Maint. Sched. NOCOed per date: Number of completed PM/CS Notifications that originate from maintenance plan scheduling on the date of data collection that fulfill customized selection criteria.

• N° of manual Notif. NOCOed per date: Number of completed PM/CS Notifications that have been created manually on the date of data collection and fulfill customized selection criteria.

• Total N° of Notif. overdue: Total number of overdue PM/CS Notifications that fulfill customized selection criteria. A notification is considered as overdue, if the notification is not yet completed and the Required End Date is less than or equal to the date of data collection.

• N° of Notif. from Maint. Sched. overdue: Total number of overdue PM/CS Notifications that originate from maintenance plan scheduling and fulfill customized selection criteria.

• N° of manual Notif. overdue: Total number of overdue PM/CS Notifications that have been created manually and fulfill customized selection criteria.

The selection criteria are combinations of Planning Plant, Notification Type and Date

2.6.6.2 PM/CS Orders – Alert Types The PM/CS Order Key Figures have been developed to provide high level indicators for the throughput and backlog in terms of document volume in business processes related to PM/CS Orders. These key figures allow measuring the number of orders that have been created (with transactions IW31 and IW61) and closed on the date of the data collection. In addition to that, this monitoring object allows tracking the overall number of orders in phase created, released, technically completed and closed.

Available Key Figures are:

• Number of orders created: Number of PM/CS Orders created on the date of data collection that fulfill customized selection criteria.

• Number of orders TECOed: Number of technically completed PM/CS Orders on the date of data collection that fulfill customized selection criteria. CAUTION: This key figure displays only PM/CS orders that have been technically completed on the date of data collection and are still in status TECO.


September 2006 43

• Orders in phase created: Total number of PM/CS Orders in phase created that fulfill customized selection criteria.

• Orders in phase released: Total number of PM/CS Orders in phase released that fulfill customized selection criteria.

• Orders in phase TECO: Total number of technically completed PM/CS Orders in phase that fulfill customized selection criteria.

• Orders in phase closed: Total number of PM/CS Orders in phase closed that fulfill customized selection criteria.

The selection criteria are combinations of Plant and Order Type.

2.6.6.3 Automatic Goods Movements posted with error – Alert Types While posting of actual data goods movement of backflushed components might fail for several reasons e. g. stock level is insufficient at the time of the withdrawal posting. Depending on the application customizing a backlog is created in this case. This backlog has to be checked on a regular base using transaction COGI and documents have to be post processed.

This monitoring object checks pool for automatic goods movements with errors resulting from:



2.6.6.4 Incorrect Costs caused by confirmation – Alert Types If during the confirmation of an order an error is detected for cost determination then an entry is generated in the error pool for the cost determination. This error pool has to be checked on regular base using transaction COFC. If the error pool is not empty then all records - after error cause has been fixed - have to be post processed. If for example a record is not correct due to a not maintained price for the activity type, this price must be maintained before.

This monitoring object checks the pool of incorrect costs caused by confirmation of:




2.6.6.5 Confirmation Pool errors – Alert Types Monitoring object Confirmation pool checks for entries in the confirmation pool that derived from the Plant Data Collection (PDC) or the Cross-Application Time Sheet (CATS). In case of CATS, entries might be written while transfer of time sheet data to target component (e.g. Project System). This confirmation pool has to be checked on regular base.

Available Key Figures of Confirmation Pool errors caused by:

• PS Network Orders (CATS)

• PM Maintenance Orders (CATS)



44 September 2006

2.7 User exit This guide explains how to implement the ‘user exit’ created to enable customers to monitor their application in a detailed and customized way. It is an extension of the already known functionality that allows monitoring the entire business process.

With the user exit you can define other monitoring objects specific to a transaction or application; develop your own data collector and display the alerts in the Solution Manager together with the rest of the standard monitoring alerts.

The customer defined monitoring object will be created with the customizing as explained in chapter 4. As this user exit was created to provide the maximal flexibility, nearly everything could be a monitoring object, i.e. number of entries of a specific table, status of IDocs in an R/3 system, etc.

The monitoring object is defined by the customer according to their needs, and its parameters are maintained to specify its details, i.e. object type, aggregation level.

After the new monitoring object has been defined, the next step is the definition of the alerts types that are desired for that monitoring object, i.e. ‘maximal number of entries reached’ or ‘too many IDocs with error status’.

The alert types are maintained in the customizing via the key figures. The parameters of those key figures are specified in the customizing too, and they will define the output fields and the alert details, i.e. the alert message that will be displayed, timestamp of the alert, etc.

2.8 Important SAP Notes SAP Note 558643 “Composite SAP Note - Errors in Business Process Monitoring”

SAP Note 705569 “BPMon: Important Msg's in Activation and Generation Protocol”

SAP Note 857898 “FAQ - Business Process Monitoring (BPMon)”