Manage operations for service parts order management with sap erp

Best Practice for Solution Operations

Manage Operations for Service PartsOrder Management with SAP ERP

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUS

internal finalDATE VERSION

August 5, 2009 1.1

SOLUTION MANAGEMENT PHASE SAP SOLUTION

Operations & Continuous Improvement Best Practices for Solution Operations

TOPIC AREA SOLUTION MANAGER AREA

Application & Integration Management Business Process Operation

Best Practice for Solution OperationsManage Operations for classical spare parts management

© 2010 SAP AG page 2/2

Date Alteration Reason Version

Dec 1, 2008 Creation 0.1

Mar 30th 2009 Finalization 1.0

Aug 5th 2009 Change of process name 1.1

Table of ContentsManagement Summary 5

1.1 Goal of Using this Best Practice 51.2 Alternative Practices 51.3 Staff and Skills Requirements 51.4 System Requirements 61.5 Duration and Timing 61.6 How to Use this Best Practice 61.7 Best Practice Procedure 6

1.7.1 Preliminary Tasks 61.7.2 Monitoring Concepts 61.7.3 Business Process Monitoring in SAP Solution Manager 71.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 8

1.7.4.1 Application Monitor 81.7.4.2 Background Job 91.7.4.3 ABAP Dump Collector 91.7.4.4 Dialog Performance 101.7.4.5 Update Errors 111.7.4.6 Due List Log 121.7.4.7 Application Log 131.7.4.8 Other CCMS Monitors 141.7.4.9 Analysis and Monitoring Tools 151.7.4.10 Monitoring Activities 161.7.4.11 Notifications 17

1.7.5 Business Process Monitoring Process 182 Business Process Monitoring for Service Parts Order Management with SAP ERP 19

2.1 Sample Scenario 192.2 Business Process Sales Order Management 19

2.2.1 Business Process Step 1: Create Urgent Order 202.2.1.1 Description 202.2.1.2 Monitoring Requirements: 202.2.1.3 Monitoring Objects in SAP Solution Manager 212.2.1.4 Monitoring without SAP Solution Manager 212.2.1.5 How to Find Meaningful Thresholds for Each Monitoring Object 21

2.2.2 Business Process Step 2: Create Stock Order 212.2.2.1 Description 212.2.2.2 Monitoring Requirements: 212.2.2.3 Monitoring Objects in SAP Solution Manager 21



2.2.2.4 Monitoring without SAP Solution Manager 222.2.2.5 How to Find Meaningful Thresholds for Each Monitoring Object 22

2.2.3 Business Process Step 3: Create Sales Order 222.2.3.1 Description 222.2.3.2 Monitoring Requirements: 222.2.3.3 Monitoring Objects in SAP Solution Manager 232.2.3.4 Further Monitoring Objects 232.2.3.5 Monitoring without SAP Solution Manager 232.2.3.6 How to Find Meaningful Thresholds for Each Monitoring Object 242.2.3.7 Scheduling of Background Jobs 24

2.2.4 Business Process Step 4: Create Delivery 242.2.4.1 Description 242.2.4.2 Monitoring Requirements: 242.2.4.3 Monitoring Objects in SAP Solution Manager 252.2.4.4 Further Monitoring Objects 252.2.4.5 Monitoring without SAP Solution Manager 25

2.2.5 Business Process Step 5: Create Pro-forma Invoice 252.2.5.1 Description 252.2.5.2 Monitoring Requirements: 262.2.5.3 Monitoring Objects in SAP Solution Manager 262.2.5.4 Monitoring without SAP Solution Manager 26

2.2.6 Business Process Step 6: Perform Shop Floor (Outbound) 262.2.6.1 Description 262.2.6.2 Monitoring Requirements: 262.2.6.3 Monitoring Objects in SAP Solution Manager 272.2.6.4 Monitoring without SAP Solution Manager 282.2.6.5 Scheduling of Background Jobs 28

2.2.7 Business Process Step 7: Create Pro-forma Invoice (and reprint if necessary) 282.2.7.1 Description 282.2.7.2 Monitoring Requirements: 282.2.7.3 Monitoring Objects in SAP Solution Manager 292.2.7.4 Monitoring without SAP Solution Manager 29

2.2.8 Business Process Step 8: Perform Billing 292.2.8.1 Description 292.2.8.2 Monitoring Requirements: 292.2.8.3 Monitoring Objects in SAP Solution Manager 302.2.8.4 Further Monitoring Objects 302.2.8.5 Monitoring without SAP Solution Manager 302.2.8.6 Scheduling of Background Jobs 31

2.2.9 Business Process Step 9: Send Invoice to the Dealer 312.2.9.1 Description 312.2.9.2 Monitoring Requirements: 312.2.9.3 Monitoring Objects in SAP Solution Manager 312.2.9.4 Monitoring without SAP Solution Manager 322.2.9.5 Scheduling of Background Jobs 32

3 Further Information 33



3.1 Troubleshooting 333.2 Related Best Practice Documents 333.3 Literature 333.4 Feedback and Questions 34

4 Appendix 354.1 Examples for Recommended Monitoring Objects 35

4.1.1 Example Background Job Monitoring 354.1.2 Example ABAP Dump Monitoring 364.1.3 Example Application Monitor “Messages” (Output Determination) 37

4.2 Background Jobs 39



Management Summary

1.1 Goal of Using this Best PracticeThis Best Practice helps you to set up a Business Process Monitoring concept for your SAP solution in theautomotive area. The concept aims to define procedures for business process-oriented monitoring and errorhandling, and escalation procedures for Service Parts Management using SAP ERP for the sales ordermanagement. These procedures are intended to ensure a smooth and reliable flow of this core businessprocess so you can meet your business requirements.This Best Practice provides guidance for defining suitable application-oriented monitoring objects to detectany irregularities or deviations from an ideal business process flow or to detect error situations concerning acore business process at an early stage.This Best Practice contains the recommended approach from SAP which uses SAP Solution Manager for theMonitoring functionalities whenever possible. However, even if you do not use SAP Solution Manager, werecommend that you follow the procedures described in this document as much as possible to ensure asmooth and reliable flow of your business processes, as well as an appropriate response if of unforeseenerrors arise.

1.2 Alternative PracticesYou can have SAP experts deliver this Best Practice on-site by ordering an SAP Solution ManagementOptimization (SMO) service for SAP Business Process Management (BPM). This service is exclusivelyavailable within SAP’s support engagements, SAP MaxAttention and SAP Safeguarding. If your companycurrently does not have any support engagement with SAP, it is also possible to get assistance by SAPexperts from SAP Consulting. In this case, please contact your local SAP Consulting representative.

1.3 Staff and Skills RequirementsTo implement this Best Practice, you require the following teams:Application Management TeamThis team creates the ERP Business Process Monitoring concept and consists of experts from several areasof your company:

Business department Solution support organization (for example, the Basis Support or the Application Support) Implementation project team

Business Process Operations TeamThe Business Process Operations team will be responsible for applying the resulting procedures derived fromimplementing this best practice. They include the following groups:

Persons designated to perform business process-oriented monitoring and ensure that the processruns smoothly (for example, the Business Process Champion for each business process)

All parties in your Solution Support Organization and IT department involved in monitoring focusedon the application aspects (Application Support, Development Support, Job SchedulingManagement)

SAP Technology Operations Team All parties in your Solution Support Organization and IT department involved in monitoring focused

on the system administration side (Program Scheduling Management, Software Monitoring Team,System Administration Team including the System Administrator)

Business Process Champion The Business Process Champion is the person in the business department that is responsible for the

successful execution of the business process. He or she coordinates all activities necessary for thebusiness process. Therefore, he or she is usually responsible for the escalation paths in case ofproblems. Often, the Business process Champion is a second level in the escalation procedure, ifthe application monitoring team needs to escalate an issue.



More information about roles and responsibilities of these teams can be found in the super-ordinate BestPractice General Business Process Management, which you can obtain through SAP Solution Manager orthe SAP Service Marketplace, quick link /BPM.

Necessary or Useful TrainingsSM300 Business Process Management and MonitoringE2E300 End-to-End Business Process Integration and Automation Management

1.4 System RequirementsTo monitor business processes running in your SAP solution via SAP Solution Manager, the SAP BasisRelease of the systems to be monitored have to be at least 4.6C. To have all described monitoring objectsavailable in SAP Solution Manager, the add-on ST-A/PI01L has to be installed on the SAP ECC systems.

1.5 Duration and TimingDurationCreating a Business Process Monitoring concept could take around one week per business process.Implementing the Business Process Monitoring concept might take approximately an additional week in total.TimingThe best time to apply this Best Practice is during the planning phase or during the implementation phase ofyour SAP solution.

1.6 How to Use this Best PracticeHere, you find a brief description of how you should proceed in using this document:

Read through the General Business Process Management Best Practice, available on the SAPService Marketplace. This document explains the procedures you should use to create a generalBusiness Process Management concept. This includes the definition and documentation of the corebusiness processes, definition of monitoring objects, definition of monitoring activities including errorhandling procedures, monitoring tools and monitoring frequencies, the definition of communicationand escalation procedures and the assignment of responsibilities.

At the beginning of section 2, you will find a typical flow chart of the core business process explainedin this Best Practice. It is intended to be used as a guideline for writing down your company specificprocess documentation.

In section 1.7.4, you can find further information that is relevant for more than one scenario. Ifinformation from the generic part is relevant for a specific business process step in one of thescenarios, you will find a clear link to the corresponding section in the generic part.

1.7 Best Practice Procedure1.7.1 Preliminary TasksBefore performing this Best Practice, ensure that you perform the following preliminary tasks or checks in thesystem:

Complete all installation and post-installation actions and procedures including customizing Ensure that the initial data load has been executed successfully Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations

resulting from customer problem messages Implement all current SAP Support Packages upon availability

1.7.2 Monitoring ConceptsThe monitoring procedures proposed for each business process step are the core of this Best Practice. Themonitoring procedures help you to ensure that the technical processes meet the requirements for stability,performance and completeness. These procedures cover monitoring for the five areas:

Error monitoring Performance monitoring



Throughput monitoring Backlog monitoring Data Consistency Monitoring

For each of the business process steps you will find the following information: A detailed functional description of the process step Identified monitoring requirements for the process step Defined monitoring objects, alerts and selection criteria Description of error handling procedures and restartability

General monitoring activities that are valid for all or most scenarios are described in the generic part insection 1.7.4. Recommendations for performance monitoring can also be found in this chapter. Theperformance of the most important steps of your core business processes should be monitored on a regularbasis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP solutionused for Spare Parts Management is generally the same. Therefore, you will only find specific performancemonitoring recommendations for selected business process steps.

1.7.3 Business Process Monitoring in SAP Solution ManagerBusiness Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and process-oriented monitoring of the most important or critical business processes, including the observation of alltechnical and business application-specific functions that are required for a steady and stable flow of thebusiness processes.

The core business processes that are implemented in an SAP system or other software and operated by acompany are of particular importance. Business Process Monitoring is intended to ensure a smooth andreliable operation of the business processes and, thereby, ensure that the core business processes meet acompany’s business requirements in terms of stability, performance, and completeness. SAP SolutionManager provides a graphical view to visualize a company’s (distributed) system and solution landscape andall related business processes. By using Business Process Monitoring, it is possible to define and customizealert situations from a basic set of configurable monitoring objects provided by the SAP Solution Manager.These resulting alerts are then visualized by green, yellow, and red alert icons for each individual businessprocess step in the graphical business process representation. The goal of Business Process Monitoring is todetect and respond to critical situations as early as possible in order to solve problems as quickly as possible.

In addition, SAP Solution Manager offers extended functionality for error handling and problem resolution. Bydefining contact persons and escalation paths, Business Process Monitoring can be integrated into thecompany’s overall strategy for Business Process Management and Solution Management within theirSolution Support Organization.

In general, Business Process Monitoring includes the solution-wide observation of: Business process performance (Key Performance Indicators) Background jobs (Job Scheduling Management tasks) Business application logs (such as any error log, general application log, due list logs, and so on) Data transfer via interfaces between software components Data consistency Technical infrastructure and components, which are required to run the business processes Required periodic monitoring tasks

For further details on Business Process Monitoring please refer to http://service.sap.com/bpm.

http://service.sap.com/bpm



1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution ManagerMonitoring Types are part of the functional scope of Business Process Monitoring as it is available in the SAPSolution Manager. This section provides a short overview of available monitoring types for referencepurposes only. The available Monitoring Types are:

Application Monitor (Throughput and Backlog Indicators, Data Consistency Checks, Mass ActivityMonitors, Due List Log, MRP key figures, User Exit, Interface Monitoring)

Background Jobs (Jobs running on SAP Systems with an SAP Basis) Dialog Performance (Dialog transaction performance) Update Errors (V1 and V2 update errors from SM13 for specific transactions and programs) Due List Log (messages for deliveries and billings) Application Log (messages from the Application Log SLG1) Document Volume (based on table call statistics in ST10) Other CCMS Monitor (all alerts that are configured in the CCMS Alert Monitor)

The relevant Monitoring Types must be selected depends on what is executed during a specific businessprocess step. To receive detailed information on how to set up the Monitoring Objects in the SAP SolutionManager, refer to the documentation that is available under http://service.sap.com/bpm.

One prerequisite for setting up Business Process and Interface Monitoring in SAP Solution Manager is that allbusiness processes and business process steps are maintained in the respective solution that contains allaffected system components. If you want to learn more about how to set this up, see (URLhttp://help.sap.com) SAP Solution Manager Basic Settings.

1.7.4.1 Application MonitorThe Application Monitor is just one of many different Monitoring Types within the Business ProcessMonitoring. The latest Monitoring objects are only provided if the latest ST-A/PI plug-in is installed on thesatellite system. The Service Tool for ST-A/PI is available via the SAP Service Marketplace Quick Link/installations Entry by Application Group -> Plug-Ins SAP Solution Tools ST-A/PI.

Please ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the respectivesatellite. In case of problems, refer to SAP Note 915933.

The Throughput and Backlog Indicator functions, available as of ST-A/PI 01J*, only work properly withST-SER 700_2007_1. This is due to changes in the underlying architecture.

More detailed information about the different Application Monitor functions and a detailed description on howto define self-written monitoring collectors for the user exit are explained in the documents ‘Setup Guide –Application Monitoring’ and ‘Setup Guide - User Exit’ respectively (URL http://www.service.sap.com/ AliasBPM Media Library).

1.7.4.1.1 Throughput and Backlog Indicators (TBIs)As of ST-A/PI 01H, a completely new set of Application Monitors has been introduced. While the alreadyestablished monitors all evaluate specific logs or performance data, these new monitors consider(un)processed documents in the SAP system and provide Throughput and Backlog Indicators.

These TBIs should especially provide: Automated and early detection of application error situations and backlogs in the core business

processes Automated error and backlog analysis tools

For ERP Logistics the following monitors are available:

http://service.sap.com/bpm

http://help.sap.com/

http://www.service.sap.com/



Sales and Services (for example, Sales Documents, Invoices) Warehouse Management (for example, Transfer Requirements, Transfer Orders) Inventory Management (for example, Goods Movements) Logistics Execution (for example, Deliveries, Shipments) Procurement (for example, Planned Orders, Purchase Requisitions, Purchase Orders) Manufacturing (for example, Planned Orders, Production or Process Orders, Autom. Goods

Movements posted with error, Confirmation Pool errors) Plant Maintenance (for example, PM/CS Notifications, PM/CS Orders)

For further information on the different TBIs refer to the document ‘Setup Guide - Application Monitoring’(URL http://www.service.sap.com/BPM Media Library).

1.7.4.1.2 Data Consistency ChecksThe DCC collectors are a subset of the Application Monitors used to retrieve a stored comparison result fromdata comparison check reports for SAP systems.

There are certain consistency check programs that are able to not only output their check result to a list orinto the spool, but can also permanently store a summary in database tables. Corresponding monitoringobjects can be configured to retrieve the number of found inconsistencies out of the stored summaryinformation and display that as alerts within the SAP Solution Manager Business Process Monitoring(Consistency Monitoring).

For further information, see the document Setup Guide – Data Consistency Monitoring (URLhttp://www.service.sap.com/ Technical Information).

1.7.4.2 Background JobThe background job monitoring should be part of a Job Scheduling Management concept (go tohttp://service.sap.com/solutionmanagerbp Topic Area “Business Process Operations” to find a BestPractice document ‘Job Scheduling Management’). Because of several restrictions regarding background jobscheduling, for example; time restrictions, restriction of hardware resources (CPU, main memory, …) orexisting dependencies between different activities (for example, invoices can only be created after thecorresponding goods issue is posted, or Back Order Processing and Material Requirements Planning shouldnot run at the same time), it is very important to ensure the stable running of background jobs. A canceledbackground job should be identified as soon as possible so that you can react as quickly as possible.Therefore, it is also necessary to define restart procedures and escalation paths.

1.7.4.2.1 Monitoring Objects and AlertsBefore setting up monitoring, the monitoring objects must be clearly defined. A monitoring object is a singlebackground job or a group of background jobs. There are four different possibilities to identify a specialbackground job or a group of background jobs. This information needs to be maintained in the sub-node‘Background Job’ below a business process step.

A more detailed description (than provided in this document) on the subject what kind of alerts make sense orwhat kind of alerts are possible are discussed in the Best Practice document “Background Job Monitoringwith SAP Solution Manager” which can be found on the SAP Marketplacehttp://service.sap.com/solutionmanagerbp Topic Area “Business Process Operation”.

1.7.4.3 ABAP Dump CollectorProvides monitoring features to alert on occurrences of ABAP dumps of specified runtime errors or collectstatistical data of ABAP dumps for reporting reasons.



http://service.sap.com/solutionmanagerbp

http://service.sap.com/solutionmanagerbp


© 2010 SAP AG page 10/10

1.7.4.3.1 Monitoring Objects and AlertsThe monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime errorname, the user who is responsible for the runtime error, the Client on which the runtime error occurs or theProgram which leads to the runtime error.

Possible Alerts types are the Number of ABAP Dumps (Delta) – all dumps since the last collector run – andNumber of ABAP Dumps (Reporting) – all runtime errors of specified type, client and program for this day orfor the previous day.

1.7.4.4 Dialog PerformanceDialog Performance implies the monitoring of the dialog transaction performance of any transaction in theSAP System. This could be a standard transaction or a self-developed transaction.

1.7.4.4.1 Monitoring Objects and AlertsThe monitoring object is the transaction itself. The Customizing has to be done in the node ‘DialogPerformance’. In the table ‘Transactions’, all transactions are already configured to that business processsteps are listed. The relevant transactions need to be selected for monitoring. It is also possible to add or toremove transactions within table ‘Add/Remove Transactions’. The monitoring can be performed per SAPinstance. Therefore, the respective instances have to be selected in the table ‘SAP Instances’. All instancesthat are maintained for a system are listed there. The table ‘Alert Types’ shows the dialog response time andall parts of the response time, like queue time, load and generation time, database request time and the front-end response time, that can be monitored. The times that are relevant for monitoring have to be selected.After saving this node a sub-node, ‘Performance Alerts’ will appear where the threshold values have to beentered.

Monitoring Objects – Dialog Performance

Each table in the sub-node ‘Performance Alerts’ corresponds to an alert type chosen in the higher-level node,and lists the combinations of specified transaction code and SAP instance.

For each combination of transaction code and instance that should be included in the monitoring, thethreshold values resulting in alert messages for changes from GREEN to YELLOW, from YELLOW to RED,back from RED to YELLOW, and back from YELLOW to GREEN have to be specified.

Since the Monitoring Object for Performance Monitoring is created on the satellite system, it is possible thatthe object already exists there. Therefore, you can load the current threshold values from the respectivesystems via the button "Load thresholds from XYZ", whereas “XYZ” represents the SID.


© 2010 SAP AG page 11/11

If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for thethreshold values were found for a certain transaction code, default values are set (indicated in column"Default"). To transfer the threshold values for a single line from right to left, the copy icon can be used. Totransfer all at once (all thresholds for all columns and tables) there is an additional button "Copy all".

Monitoring Alerts - Dialog Performance

1.7.4.5 Update ErrorsChanges to the data in an SAP system caused by a business process should be written to the database in fullor not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, thetransaction should not make any changes to the database. These activities are handled by the SAP updatesystem.

The SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2)update errors. This distinction allows the system to process critical database changes before less criticalchanges.

V1 modules describe critical or primary changes; these affect objects that have a controlling function in theSAP System, for example order creation or changes to material stock.V2 modules describe less critical secondary changes. These are pure statistical updates, for example, resultcalculations.

1.7.4.5.1 Monitoring Objects and AlertsMonitoring of Update Errors can be configured for online transactions and/or ABAP programs relevant in abusiness process. This is the object type. The name of the object is the name of a transaction or the name ofthe ABAP program itself. If desired, a user executing the transaction or the ABAP program can be specified.If no user is specified explicitly, all users (represented by '*') will be considered in monitoring data evaluation.


© 2010 SAP AG page 12/12

Monitoring Objects - Update Errors

Since update errors are usually very critical, the default configuration is to raise a yellow alert as soon as oneupdate error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 updateerror a threshold must be specified.

1.7.4.6 Due List LogA due list is a list that contains several entries (documents) depending on selection criteria. There aredifferent types of due lists in an SAP system of which the following three are most important: delivery (L),billing (F) and picking (K). The delivery due list can be directly accessed via transaction V_SA, and the billingdue list via transaction V.21. In the case of a billing due list, the list contains, for example, a number of salesdocuments that need to be billed. If the billing due list was processed previously and it is important to knowwhich billing documents were created from this billing due list, it can be displayed in the due list log for thisbilling run.

1.7.4.6.1 Monitoring Objects and AlertsThe monitoring object is the respective due list type. That can be ‘Delivery’, ‘Billing’ or ‘Picking’. If a certainuser is processing the due list, the name of the user can be specified here. If it is user-independent, a wildcard ‘*’ can be used. The aggregation level needs to be defined. This could be ‘per day’, ‘per hour’ or ‘perlog’.

For the monitoring of due list log messages, four different alert types can be used:1. ‘DocumentCreation’ 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.2. ‘MinQuantityDocs’ 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 toYELLOW (or back) and from YELLOW to RED (or back) must be maintained.

3. ‘TotalQuantityMsgs’refers to the total number of message created during a Due List run.4. 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.


© 2010 SAP AG page 13/13

5. ‘DLLogMsgs’ refers to specific due list log messages. The message type, the message ID and thenumber can be specified. It is also possible to use wild cards. The threshold values for the number ofmessages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (orback) must be maintained.

1.7.4.7 Application LogThe Application Log provides an infrastructure for collecting messages, saving them in the database, anddisplaying them as a log. Situations can arise at runtime in application programs that must be brought to theattention of the user in some way. These are usually errors. It can also be useful to report a successfulcompletion. The information that arises is called a message. The set of messages is a log. A log usually alsohas header information (log type, creator, creation time, and so on). A transaction can generate several logs.

The Application Log is not written consecutively but as a whole at one point in time.

1.7.4.7.1 Monitoring Objects and AlertsThe Application Log allows an application- or object-oriented recording of events. An object and any sub-object that belongs to it classify each event. The analysis of the logs is similarly object (or sub-object)oriented. The name of an object (and/or subobject) can be found in transaction /nSLG1 together with all otherspecific information to that log.

Monitoring Objects and Alerts - Application Log

It is possible to monitor for the total number of messages belonging to an object. Therefore, the number ofmessages that raises a YELLOW alert and the number of messages changing from a YELLOW to a REDalert must be maintained.

It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. To


© 2010 SAP AG page 14/14

configure the monitoring of critical application log messages, the relevant object-sub object combinationsneed to be selected. For each of these combinations, the message type, the message ID, and the messagenumber, as well as the threshold values for the number of critical messages that are supposed to result inchanges from GREEN to YELLOW and from YELLOW to RED, can be specified. It is also possible to usewild cards.

Monitoring Alerts - Application Log / Critical Messages

1.7.4.8 Other CCMS MonitorsWith other CCMS Monitors, it is possible to assign any CCMS monitoring tree element (MTE) to a businessprocess step. Therefore, it is necessary to call transaction RZ20 in the Satellite System and to open a monitorthat contains the required alert(s).

The name of the monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to becopied into the corresponding column of the table below (See screenshot “Other CCMS Monitors” below).

Under column Monitor Name it is possible to assign an individual name.The MTE used for monitoring should be an MTE on the lowest leaf level, that is, on attribute level. Ifan MTE of a higher branch-level (collective MTE) is chosen then the current and open view in thegraphics will show the right alerts but it isn’t possible to process these alerts within the BusinessProcess Monitoring session as the alerts are not replicated there.

To load the threshold values that are currently valid in the corresponding system, the button

can be used.

If successfully retrieved, the values are filled in the right-hand columns. If no active settings for the thresholdvalues were found these columns remain empty.

To transfer the threshold values for a single line from right to left, double-click the copy icon.


© 2010 SAP AG page 15/15

Other CCMS Monitors

Unlike all other Monitoring Types, the Other CCMS Monitoring provides the opportunity to assignMTEs from systems other than the one that the actual business process step is assigned to.

For example, you could be interested in monitoring the availability from a Portal system that possesses noCCMS but is included as one business process step in your business process. Now, you could use one MTEin the CCMS of the SAP Solution Manager to monitor the heartbeat of the Portal. You could then assign thecorresponding alert via Other CCMS Monitoring to business process step running on the Portal system.

1.7.4.9 Analysis and Monitoring ToolsIt is possible to specify analysis transactions or URL addresses (including file directories) per monitoringobject. In the case of analysis transactions, these should be used to analyze errors or problems either locallyin the SAP Solution Manager system itself (Call Option “1”) or directly in the respective satellite systems (CallOption “2”). By default, some standard transactions are maintained, for example, transaction SM37, whichprovides a job overview in an SAP System, is maintained for Background Jobs or transaction SLG1 to have alook into the application log.

It is also possible to add new transactions; these could be standard transactions or customer self-writtentransactions.


© 2010 SAP AG page 16/16

Analysis & Monitoring Transactions

On the second tab strip, it is possible to specify a URL which should be called to further analyze the givenproblem. This is especially interesting if you have some knowledge documents linked to a portal. You define aShort text and the URL to be called.

For web pages to be called, specify the full URL, for example, http://help.sap.com. For contentavailable on file servers specify the full file path, using the nomenclature: file://\\\<server>\..., forexample, file://\\\server1\operations_documents\operations-handbook.txt

Analysis & Monitoring URL

The specified transactions or URLs will be available in the form of buttons within a business process stepwhen using the monitoring later on inside the Business Process Monitoring Session. By pressing these

buttons (for example, ), the user will jump directly into the correspondingtransaction either in the SAP Solution Manager system (here: SAT) or the connected satellite system (here:

CT1) for further analysis. For URLs the push-button (for example, ) contains theShort text (limited to 20 characters) from the Set-up session and leads the user to the defined URL in a newlyopened browser window.

1.7.4.10 Monitoring ActivitiesMonitoring activities should be set up for every Monitoring Object within a business process step. Allmonitoring objects defined within a business process step are listed here. To ensure effective monitoring andefficient problem resolution the responsibilities should be assigned and problem resolution procedures shouldbe defined as described in the following table. Some information is taken from the previous node ‘SolutionSupport Organization’.

Monitoring Team Defines the team that is responsible for monitoring the relevantMonitoring Object. Use value help [F4].

Person Resp. Defines the Person who is responsible for monitoring the MonitoringObject. Use value help [F4].

Frequency Describes how often the responsible person should process the requiredmonitoring activity.

Start Time Describes at which time the responsible person should process therequired monitoring activity.

Problem Indicator A description about what indicates a problem.Error Handling Describes how to react on problems or errors, that is, how to solve the

problem/correct the error.

http://help.sap.com/


© 2010 SAP AG page 17/17

Escalation Path Describes the escalation path in case that the person responsible couldnot solve the problem. Persons who can be contacted should bemaintained here.

Additional information related to this business process step can be entered in the tables ‘MonitoringActivities’, ‘Error Handling’, ‘Restart of Step’ and ‘Escalation Path’. This information would be valid for thewhole business process step and helps users who have to carry out the monitoring and who are not sofamiliar with that particular business process.

1.7.4.11 NotificationsNotifications can be set up for the whole business process or for each business process step individually.There are two types of notifications: workflow notifications and Support notifications. Workflow notificationsallow sending messages in case of alerts to a specified recipient. This could be an e-mail or SAPOffice mail.Support notifications allow the setting up of a service desk message in case of an alert. The informationentered for the service desk message serves as a template. The service desk message can be createdmanually or automatically.

On business process level, it is possible to define notifications for the whole business process, that is, assoon as the business process gets an alert status, notifications will be triggered. Alternative notifications canbe defined for every Monitoring Type individually, for example, all alerts related to all background jobs of thebusiness process are forwarded to a defined e-mail address.

Notifications defined on business process step level will overrule the configuration made on the businessprocess level for this particular step.

1.7.4.11.1 Workflow Notification

Sender Must be a user within in the monitoring client of SAP Solution Manager. Thisuser can be even a system user without any roles or profiles, but the usermust have a valid e-mail address that is known by the used mail-server

RecipientAddress

Depending on the Recipient Type, the recipient name is required. This couldbe any e-mail address, an SAP user name in the same system, a RemoteSAP name or a shared distribution list. In case of an SMS you need to enter“SMS:<cell phone or pager number>”

Reci. Type There are currently 5 different Recipient Types: U (e-mail), K (for SMS andPager), B (SAP user name), R (Remote SAP name) and C (shareddistribution list).

No. of YellowAlerts

Number of YELLOW alerts that may occur before an automatic notification istriggered

No. of Red Alerts Number of RED alerts that may occur before an automatic notification istriggered

Max Wait Time[h]

Once the maximum wait time [hours] has elapsed, a notification is created,even if the thresholds are not exceeded

RED Only To restrict this mechanism only to red alerts the flag in column 'RED Only'must be set.

Detailed Triggers a long text for e-mails or SAPOffice mails, for example, name of thesolution, name of the business process step, …)


© 2010 SAP AG page 18/18

1.7.4.11.2 Support Notifications

Priority Defines the priority of the Support Notification.Queue Defines the support component on which the message is put. This

component must exist within the service desk.Processor Defines a default processor who should process the message. The

processor must be known within the service desk and must be an SAP username that is defined as a Business Partner with role “Employee”.

Text Template Text templates can be defined that will then be available for service deskmessages manually created for alerts.

Automatic Support Notifications will be created automatically depending on the alertthresholds.

Reporter Necessary when service desk messages are created automatically. Must bea SAP user name which is defined as a Business Partner with role “General”.

Num. of YELLOWAlerts

Necessary when service desk messages are created automatically, forexample, after 10 yellow alerts a service desk message should be created.

Num. of REDAlerts

Necessary when service desk messages are created automatically, forexample, after 5 red alerts a service desk message should be created.

If, in addition to queue, processor, priority and reporter, either one of the columns “Num of YELLOWAlerts” or “Num of RED Alerts” is filled with a value, the automatic Support Notification creation isconfigured. If both columns are filled with a value, the automatic Support Notification creation workswith a logical OR operation. Hence, with the figures in the table above the system would create aSupport Notification if there are either more than 9 yellow alerts OR more than 4 red alerts for which noSupport Notification has been created yet.

1.7.5 Business Process Monitoring Process

For a successful and efficient implementation of a Business Process Monitoring concept, a process for theexecution of the monitoring concept has to be defined. This includes the definition and assignment of theroles and responsibilities involved. It has to be defined who is supposed to carry out which activity within theprocess and how communication between the different roles within the support organization is supposed totake place.

A Business Process Monitoring concept has to be closely integrated with the support organization. Thisincludes the integration with the Incident/Problem Management process and the Change Managementprocess. These processes have to be adjusted to the Business Process Monitoring concept so thatcommunication and escalation procedures are adequate to support the Business Process Monitoring conceptincluding the final communication of open alerts to SAP.

Wherever communication connected with Business Process Monitoring happens outside these supportprocesses, separate communication and escalation paths and procedures have to be defined.See the separate Best Practice for General Business Process Management for further details.


© 2010 SAP AG page 19/19

2 Business Process Monitoring for Service Parts Order Management withSAP ERP

This section will show you, based on a typical example process, what business process monitoring forService Parts Order Management with SAP ERP should look like. It will give you an idea of how to identify abusiness process step you could keep an eye on and make you familiar with how to choose the mostpromising monitoring possibilities from the available ones.

2.1 Sample ScenarioVehicle OEM is a car producer. Its main business is selling and producing cars, but a big part of the revenueis constituted by selling service parts for broken cars from several distribution centers worldwide.Material stocks are kept in inventory management in the ERP system and in warehouse managementsystems for the different distribution centers where the physical movements are managed.To be able to do this, they use the following core business processes.

Sales Order Management.

The following section takes you through this core business process step-by-step, explaining where and howyou can identify focus points for Business Process Monitoring. For each business process step, the mosteffective way for Business Process Monitoring in the context of the example is highlighted.

2.2 Business Process Sales Order ManagementDuring the business process Sales Order Management, Spare Parts are ordered by car dealers ormaintenance shops from the OEM. During the complete process, and especially during order taking, youhave to distinguish two cases: standard stock replenishment orders by the dealer and urgent orders, knownas Vehicle-Off-Road or VOR orders.The sales order is typically created in a dealer management system and replicated to the OEM’s ERPsystem. During order creation, or in a separate step, the ordered parts may be replaced by other parts basedon availability or further criteria. Either the standard functionalities of SD may be used, or more complexsupersessions chains may be modeled by IS-automotive specific functionality. Once the final part has beendetermined, the delivery can be created. In addition to this step, pro-forma invoices may often be printed.After the shipping activities have been performed in the warehouse, the goods leave the plant physically andan invoice is sent to the dealer.


© 2010 SAP AG page 20/20

confidential

Sales Order Management for Spare Parts

DMS

(1) Create Urgent Order

R/3

(4) Create Delivery (VL10A)

(3) Create Sales Order

(5) Create Proforma Invoice

(6) Perform Shopfloor (Outbound)

(7) Compare Proforma Invoice (andreprint if needed)

(8) Perform Billing

(9) Send Invoice to Dealer

(2) Create Stock Order

2.2.1 Business Process Step 1: Create Urgent Order

2.2.1.1 DescriptionGeneral Information:A sales order is a contractual agreement between a sales organization and a sold-to party about deliveringproducts or providing a service for defined prices, quantities, and times. Different order types may be usedduring a process.

Sample Scenario-Specific Information:The sales orders are coming in via a dealer portal and are fed automatically via BAPI or IDoc into the ERPsystem. In the context of sales of spare parts, urgent orders are called Vehicle-Off-Road or VOR orders.

2.2.1.2 Monitoring Requirements:Error Monitoring:It is important to monitor the availability and correct execution of the interface between the dealer and theERP system. If the connection is not working or orders are rejected in the system, dealer and end customersatisfaction may decrease as a car may not be fixed quickly.

Performance Monitoring:It is vital to ensure dealer and end user satisfaction for the performance of the interface.


© 2010 SAP AG page 21/21

2.2.1.3 Monitoring Objects in SAP Solution Manager

MonitoringObject

SelectionCriteria

Alert Analysis Tool onSatellite System

MonitoringFrequency / Data

CollectionEvaluate RFCConnections(BORFCCON)

RFC Destination Availability of RFCconnection

SM59 Every 5 minutes

IDoc Monitoring(IMIDOC01)

Message Type,Basic Type, PartnerNumber, IDocs inStatus “51”

Delta NumberMonitor

WE05 Every 15 minutes

2.2.1.4 Monitoring without SAP Solution ManagerIf IDoc transfer is used, you should utilize transactions BD87 and WE05 to check for erroneous messages atleast once per hour.

2.2.1.5 How to Find Meaningful Thresholds for Each Monitoring ObjectAgree with the dealers on acceptable down-times of the system and set the threshold accordingly.

2.2.2 Business Process Step 2: Create Stock Order

2.2.2.1 DescriptionGeneral Information:A sales order is a contractual agreement between a sales organization and a sold-to party about deliveringproducts or providing a service for defined prices, quantities, and times. Different order types may be usedduring a process.

Sample Scenario specific Information:The sales orders are coming in via a dealer portal and are fed automatically via a BAPI or IDoc into the ERPsystem. File-transfer followed by Batch-Input-Processing is sometimes used to process stock orders.

2.2.2.2 Monitoring Requirements:Error Monitoring:It is important to monitor the availability and correct execution of the interface between the dealer and theERP system. If the connection is not working or orders are rejected in the system, dealer and end customersatisfaction may decrease as a car may not be fixed quickly.



MonitoringObject

SelectionCriteria



CollectionEvaluate RFCConnections(BORFCCON)

RFC Destination Availability of RFCconnection

SM59 Every hour


© 2010 SAP AG page 22/22

IDoc Monitoring(IMIDOC01)

Message Type,Basic Type, PartnerNumber, IDocs inStatus “51”

Delta NumberMonitor

WE05 Every 15 minutes

BatchInput-Monitoring(IMBTCINP)

Session Name,Created By

Errors per session,Job Cancellation,Sessions inspecified status(es)

SM35 Every hour to oncea day

2.2.2.4 Monitoring without SAP Solution ManagerIf IDoc-transfer is used, you should use transactions BD87 and WE05 to check for erroneous messages atleast once per hour.

If data is processed via BatchInput, you should check transaction SM35 for errors at least once per day.

2.2.2.5 How to Find Meaningful Thresholds for Each Monitoring ObjectAgree with the dealers on acceptable down-times of the system and set the threshold accordingly.

2.2.3 Business Process Step 3: Create Sales Order

2.2.3.1 DescriptionGeneral Information:A sales order is a contractual agreement between a sales organization and a sold-to party about deliveringproducts or providing a service for defined prices, quantities and times. Different order types may be usedduring a process.

Sample Scenario-Specific Information:The sales orders are coming in via a dealer portal and are fed automatically via a BAPI or an IDoc into theERP system.

During spare parts management, it is common that a service part is ordered by a dealer but that another parthas to be shipped. The most common reasons are that a newer, compatible part exists that supersedes theordered part or that an older, compatible model exists that has to be sold first to deplete the current stock.This supersession can be based on complex rules, which may affect performance and backlog if rules are notmanaged properly.

2.2.3.2 Monitoring Requirements:Error Monitoring:Error monitoring is mainly handled during interface processing as discussed during the preceding stepsCreate Urgent Order and Create Stock Order. No separate monitoring is necessary at this step.


Throughput Monitoring:For the success of the business process execution the throughput of sales orders (for specific sales areas) iscritical. It has to be ensured that enough sales orders are created each day to generate enough revenue.Sample Scenario-Specific:In addition, you have to distinguish between standard orders and VORs. VORs are usually more importantregarding customer satisfaction but standard orders generate more revenue

Backlog Monitoring:The sales orders have to be processed in a timely mannerSample Scenario specific:


© 2010 SAP AG page 23/23

In addition, you have to distinguish between standard orders and VORs. VORs usually have much faster,agreed delivery cycles and a backlog is therefore more critical than in standard cases.


MonitoringObject

SelectionCriteria



CollectionPerformance:BOPERFMO

Function Module,User

Response Time STAD every 15 minutes

Throughput: SalesDocuments(KPSD001)

Order type for StockOrders

Sales DocumentsCreated

VA03 Once per day

Throughput: SalesDocuments(KPSD001)

Order type forUrgent Orders

Sales DocumentsCreated t

VA03 Once per day ortwice per day: totaland after cut-offtime

Backlog: SalesDocuments(KPSD001)

Sales Area, OrderTypes

Orders (GI date inpast but notdelivered)

VA03 Once per day

Backlog: SalesDocuments(KPSD001)

Sales Area, OrderTypes

Orders with deliveryblock via indextable, Orders withcredit block viaindex table,Incomplete SalesDocuments

VA03, VA05 Once per day

Background JobMonitoring

Job Name, StartTime

Start Delay,Maximum Duration,Job Cancellation

SM37 Every 5 minutesduring job executionif interface data isprocessed inbackground

Data Consistency:SD-Requirements(DCSDRQCR21)

Variant Age of lastconsistency checkresult, % of itemswith errors/ checkeditems

Report SDRQCR21 Once per day

Errors: UpdateErrors

Object Type, ObjectName

No. of Errs for Red(Upd1)

SM13 N.A.

2.2.3.4 Further Monitoring Objects

Check in transaction ST22 whether short dumps occurred.

2.2.3.5 Monitoring without SAP Solution ManagerCheck the number of orders in backlog daily using the following transactions:

Incomplete Sales Orders using transaction V.02 Backorders using transaction V.15 Open Sales Orders using transaction VA05

In addition, the job log of the scheduled SDRQCR21 executions needs to be checked using transactionSM37.


© 2010 SAP AG page 24/24

Check every hour whether update errors occurred.

2.2.3.6 How to Find Meaningful Thresholds for Each Monitoring ObjectThe thresholds for throughput depend on your typical business volume. As a starting point, you shouldmeasure the actual number of documents created per day in your system differentiated by VOR and otherorders and add/subtract 20% to obtain a starting point for yellow and 30% to obtain a starting point for redalerts.

2.2.3.7 Scheduling of Background Jobs

Job Scheduling RequirementsRecommended or

Generated Job NameABAPReport

Variant Sche-duling

Predece-ssor Job

SuccessorJob

SchedulingRestriction

Error Hand-ling in Case

ofCancellation

S_<SYSIDClient>_<COUNTRY>_Sales_SDRQCR21_<PLANT>_D

SDRQCR21 Daily intestmode

Job shouldbe executedduring a timewhere norequirementsaregenerated

Restart job

2.2.4 Business Process Step 4: Create Delivery

2.2.4.1 DescriptionGeneral Information:An outbound delivery is created with reference to a sales order to start all activities needed to send therequested goods to the customer.

Sample Scenario specific Information:You should separate the delivery creation for VOR orders from the standard orders so that delivery of VORorders is not blocked or delayed by the processing of less important orders. To do this, you have to customizeVOR orders as immediate delivery or schedule a separate batch job to process these orders before the batchjob for delivery creation is started.

2.2.4.2 Monitoring Requirements:Error Monitoring:It is important that the jobs creating the delivery are finished in time and do not cancel. Furthermore, noexceptions should be issued during the processing, which indicate that a sales order could not be delivered.

Performance Monitoring:Performance problems can lead to a delayed creation of deliveries. Missing or delayed data could causeover-stock situations and bad customer satisfaction.

Throughput Monitoring:For the success of the business process execution the throughput of deliveries is critical. It has to be ensuredthat enough deliveries are created each day to prevent overstock and backlog situations.

Backlog Monitoring:The deliveries have to be processed in a timely manner. Especially the shop floor performance is critical.


© 2010 SAP AG page 25/25


MonitoringObject

SelectionCriteria



CollectionBackground Jobsfor delivery creation

Job Name, StartTime

Start Delay,Maximum Duration,Cancellation

SM37 every 5 minutesduring every jobexecution

Throughput:Deliveries(KPLE0001)

Shipping Point,Delivery Type, Datafrom prev. day,Created by

Outbound Deliveries(created)

VL03 Daily

Backlog: Deliveries(KPLE0001)

Shipping Point,Delivery Type, Datafrom prev. day,Created by

Outbound Deliveries(Overdue)

VL03 Daily

Errors: Due List Log Due List Type =Delivery, User,

No documentscreated, No. ofspecific messages

V_SA Daily




SM13 N.A.

Performance Transactions usedfor manual deliverycreation like VL01N

Response Time STAD Daily

2.2.4.4 Further Monitoring Objects

Check every hour in transaction ST22 whether short dumps occurred for the delivery process.

2.2.4.5 Monitoring without SAP Solution ManagerYou should check the log files of the delivery creation every day to see whether any errors occurred usingtransactions SM37 and V_SA. The collective run type to be used in transaction V_SA is “L”.

Check the run time of the jobs for delivery creation manually in transaction SM37 and compare it with yourtime window at least once per day.

Use transactions ST04 and STAD to check the response times of important manual transactions.

Check every hour in transaction SM13 whether update errors occurred.

Check every hour whether short dumps related to the delivery process have occurred using transactionST22-

2.2.5 Business Process Step 5: Create Pro-forma Invoice

2.2.5.1 DescriptionGeneral Information:A pro-forma invoice is a dummy billing document created prior to the real invoice. The pro forma invoice canbe used, for example, for invoice simulation or export papers. It is not unusual to send a pro-forma invoicewith the delivery especially in case of cross-border deliveries or intercompany processes where a subsidiaryis stocked.


© 2010 SAP AG page 26/26

Sample Scenario-Specific Information:Spare-parts business usually very time critical. To have these papers ready as early as possible, a pro-formainvoice can already be created while the shop floor activities are executed. As the final delivery may deviatefrom the expected outcome for example due to stock shortages a verification is needed after shop floorcontrol.

2.2.5.2 Monitoring Requirements:Error Monitoring:It is vital that all messages are processed successfully as otherwise the papers are not ready after loading thetruck thus delaying the physical goods issue and transport.


MonitoringObject

SelectionCriteria



CollectionBacklog: Messages(OutputDetermination)(KWMSG001)

Application,message type,transm. Medium,dispatch time,partner function,message partner,output device, printimmediately, username, older than xdays

Not processedmessages

every 5 minutes

Errors: Messages(OutputDetermination)(KWMSG001)


Incorrectlyprocessedmessages

Report RSNAST0F every 5 minutes

2.2.5.4 Monitoring without SAP Solution ManagerExecute report RSNAST0F to check for incorrectly processed messages every hour.

2.2.6 Business Process Step 6: Perform Shop Floor (Outbound)

2.2.6.1 DescriptionGeneral Information:Behind step 6 “Perform Shop Floor (Outbound)”, a complete process is hidden that starts with the creation oftransfer orders and picking lists and ends with the posting of the goods issue. Very often, this sub-process isexecuted in a separate warehouse management system due to the high volume encountered in spare partsmanagement.

2.2.6.2 Monitoring Requirements:Error Monitoring:When the shop floor activities are executed in an external system, the deliveries have to be replicated fromthe ERP system to the WMS system. You have to ensure that all interface documents are processedsuccessfully.


© 2010 SAP AG page 27/27

Performance Monitoring:It is vital to ensure quick response during the shop floor processing, especially in high volume businesses likea spare parts management.

Throughput Monitoring:You have to ensure that enough transfer orders are created and confirmed each day. Creation andconfirmation of less transfer orders than expected could indicate that users are not using the system in theintended way, for example, by picking stock physically without performing the appropriate actions in thesystem like confirmation of the transfer order. This could lead to understock situations and incorrect ATPinformation in the system.

Backlog Monitoring:Unconfirmed transfer orders should be detected as early as possible, because these indicate either a stockshortage situation as they could not been picked, or a bypass of the system as the goods may have beenpicked but not confirmed in the system. This would lead to inconsistencies.

Data Consistency Requirements:Especially if a decentralized warehouse management system is used the consistency between the stockinformation in the warehouse and the stock information in inventory management in ERP has to be checked.Inconsistencies indicate a discrepancy between the real world and the information in the ERP system usedfor example during ATP checks and MRP runs. This could lead to understock or overstock situations anddelays in the delivery process.


MonitoringObject

SelectionCriteria



CollectionData Consistency:WM-IM Stockcomparison(DCWMLX23)

Variant Existence of adifference, Age oflast consistencycheck result

SM37, LX23 Weekly

Throughput:Transfer Orders(KPWM002)

Warehouse number,Source storagetype, destinationstorage type, datafrom previous day

Outbound TO Items(created), OutboundTO Items(confirmed)

LT21, LL01 Daily

Throughput:TransferRequirements(KPWM005)


TR Items (created) Daily

Backlog: TransferOrders (KPWM002)

Warehouse number,Source storagetype, destinationstorage type, olderthan x days

Outbound TO Items(open)

LT21, LL01 Daily

Backlog: TransferRequirements(KPWM005)

Warehouse number,Source storagetype, destinationstorage type, olderthan x days

TR Items (open) LL01 Daily


© 2010 SAP AG page 28/28

Errors: TransferOrders (KPWM002)


Outbound TO Items(confirmed with diff.)

LT21 Daily

Errors: WarehouseActivity Monitor(KPWM001)

Warehouse number Negative Stocks,Stock in InterimStorage Types

LL01 Daily

2.2.6.4 Monitoring without SAP Solution ManagerUse the warehouse monitor (transaction LL01) to check for open transfer requirements, unconfirmed transferorders, negative stocks, and stock in interim storage types once per day.



Generated JobName

ABAPReport

Variant Sche-duling

Predece-ssor Job

SuccessorJob



ofCancellation

S_<SIDCLNT>_<COUNTRY>_SALES_RLABGL00_<PLANT>_M

RLABGL00 Everytwoweeksto oncepermonth

Should beperformedwhen nodocumentsaretransferredbetweenWMS andERP system

2.2.7 Business Process Step 7: Create Pro-forma Invoice (and reprint if necessary)

2.2.7.1 DescriptionGeneral Information:A pro-forma invoice is a dummy billing document created prior to the real invoice. The pro forma invoice canbe used, for example, for invoice simulation or export papers. It is not unusual to send a pro-forma invoicewith the delivery, especially in case of cross-border deliveries or intercompany processes where a subsidiaryis stocked.

Sample Scenario-Specific Information:Spare-parts business is in general very time critical. To have these papers ready as early as possible, a pro-forma invoice has already been created before the shop floor activities were executed. As the final deliverymay deviate from the expected outcome for example due to stock shortages a verification is needed aftershop floor control. During this step, the actual pick quantities are compared to the delivery quantity and asecond pro-forma invoice is created if deviations occurred.

2.2.7.2 Monitoring Requirements:Error Monitoring:As the timing is very critical, and the printing is done at a late process stage during this step, errors in theprinting process may delay the delivery. Therefore, it is vital to detect any errors as quickly as possible.Besides technical monitoring, user reactions are very quick at this stage.


© 2010 SAP AG page 29/29

Performance Monitoring:It is vital to ensure the performance for reprinting the pro-forma invoice as at this stage the truck driver mayalready be to leave the plant and the delivery especially in case of service parts for commercial vehicles.


MonitoringObject

SelectionCriteria






every 5 minutes





2.2.7.4 Monitoring without SAP Solution ManagerExecute report RSNAST0F to check for incorrectly processed messages every hour.

2.2.8 Business Process Step 8: Perform Billing

2.2.8.1 DescriptionGeneral Information:An invoice is a document that states the customer’s obligation. It is usually created after goods receipt andincludes information like the amount and taxes to be paid.

2.2.8.2 Monitoring Requirements:Error Monitoring:Invoices not created or transferred to FI will result in a delay of the customer payment potentially causing lossof money and affecting the cash flow. Therefore, it is important to monitor the scheduled jobs for cancellationand for any update errors or shortdumps during the invoice creation.

Performance Monitoring:It is vital to ensure customer and end user satisfaction for the performance for transaction VF01.

Throughput Monitoring:For the success of the business process execution, the throughput of invoices is critical. It has to be ensuredthat enough invoices are created each day to generate enough revenue. If an invoice is delayed, thecustomer will have to pay later resulting in financial losses and delayed cash flow.


© 2010 SAP AG page 30/30

Backlog Monitoring:Invoices have to be transferred to Financial Accounting for the necessary follow-up procedures like receivingthe incoming payment, and starting dunning procedures if the incoming payment is overdue.

Data Consistency Requirements:You should ensure the consistency between SD and FI. Inconsistencies between SD and FI could indicatemissing open items or duplicate billing to the customer if you use one step posting.


MonitoringObject

SelectionCriteria



CollectionBackground Job Job Name, Start

TimeStart Delay,Maximum DurationCancellation

SM37 every 5 minutesduring every jobexecution

Backlog: SDInvoices (AR)(KPSD0002)

Billing Type, BillingCat., Sales Org,Dist. Channel,Division, Createdby, older than xdays

SD Invoices notposted to FI

VF03, VFX3 Daily

Throughput: SDInvoices (AR)(KPSD0002)

Billing Type, BillingCat., Sales Org,Dist. Channel,Division, Createdby, data fromprevious day

Sales invoicesposted per day

VF03 Daily




SM13 N.A.

Performance:PerformanceMonitor(BOPERFMO) orDialoguePerformance

Transaction ResponseTime STAD N.A.

Throughput: DueList Log

Due List Type =“Billing”,Aggregation: “perlog”

No documentscreated

VF04, VF03 N.A.

Errors: Due List Log Msg Type = E, AMsg ID = ‘*’Msg. No = ‘*’*

No of specificmessages

VF04, VF03 N.A.

2.2.8.4 Further Monitoring ObjectsCheck once per day in transaction ST22 whether short dumps related to the invoice creation exist.

2.2.8.5 Monitoring without SAP Solution ManagerCheck daily for update errors related to the invoice creation using transaction SM13.

Check the performance of transactions executed in dialog regularly using transactions STAD and ST03N.


© 2010 SAP AG page 31/31

Check the correct execution for any background jobs you have scheduled for invoice creation usingtransaction SM37. In addition, you should check the job log of these executions in transaction SM37.

Check once per day in transaction ST22 whether short dumps related to the invoice creation exist.



Generated Job NameABAPReport

Variant Sche-duling

Predece-ssor Job

SuccessorJob



ofCancellation

S_<SIDCLIENT>_<COUNTRY>_SALES_RV60SBAT_<SALESORG>_D

RV60SBAT Daily After deliverycreation

2.2.9 Business Process Step 9: Send Invoice to the Dealer

2.2.9.1 DescriptionGeneral Information:An invoice is a document that states the customer’s obligation. It is usually created after goods receipt andincludes information like the amount and taxes to be paid. During this process, the invoice is sent to thedealer via output determination.

2.2.9.2 Monitoring Requirements:Error Monitoring:You should check for any incorrectly processed invoice messages. Messages not being printed and sent tothe customer will cause delays in the incoming payment.

Backlog Monitoring:You should check for any unprocessed invoice messages. Messages not being printed and sent to thecustomer will cause delays in the incoming payment.


MonitoringObject

SelectionCriteria






every 5 minutes


© 2010 SAP AG page 32/32





2.2.9.4 Monitoring without SAP Solution ManagerCheck the spool for unprocessed and erroneous messages for application V3.


If the invoice is not sent during invoice creation, ABAP report SDV70AV3A (transaction VF31) has to bescheduled on a regular basis to pick up invoices ready to be printed.


Generated Job NameABAP Report Variant Sche-

dulingError Handling in

Case ofCancellation

S_<SysIDCLNT>_<Country>_SPP_Invoice_Print_D

SDV70AV3A Every hourto once aday

Restart job or executetransaction VF31manually


© 2010 SAP AG page 33/33

3 Further Information

3.1 TroubleshootingIf executing this Best Practice did not produce the desired results

Search for related notes in the SAP Service Marketplace. Open an SAP Customer Message describing your problem (please see the respective component in

section Error Handling, Restartability and Escalation of every step).

3.2 Related Best Practice Documents

There are several other Best Practice documents available on the Service Marketplace underhttps://service.sap.com/solutionmanagerbp that relate to this Best Practice document. These documents are:

General Business Process Management: This document explains the procedures you should use tocreate a general Business Process Management concept. This includes the definition anddocumentation of the core business processes, definition of monitoring objects, definition ofmonitoring activities including error handling procedures, monitoring tools, monitoring frequencies,the definition of communication and escalation procedures and the assignment of responsibilities.ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focuson ALE Monitoring for your SAP solution. This document will outline possibilities on how to optimallymonitor ALE-based interfaces manually as well as automated by using SAP Solution Manager. Bothmonitoring approaches aim to detect any irregularities or deviations or to detect error situations at anearly stage.Job Scheduling Management: This Best Practice provides a detailed description what SAPrecommends as a standardized formal process to support a job request process, including an enduser job request form and an approval process. This integrated process will avoid error-prone andtime intensive manual processes of copying redundant data from one data source to another (forexample, MS excel to MS Excel or MS Excel to job scheduling tool).SAP Business Process Management for ERP Logistics: This Best Practice helps you set up aBusiness Process Monitoring concept for your SAP ERP solution. The concept aims to defineprocedures for business process oriented monitoring and error handling and escalation proceduresfor your company’s ERP core business processes. These procedures intend to ensure a smooth andreliable flow of the core business processes so that your business requirements are met.Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set upbackground job monitoring properly in the framework of Business Process Monitoring in the SAPSolution Manager.

Note that these documents are also available in the SAP Service Marketplace using alias RunSAPRunSAP Best Practices.

3.3 Literature

For detailed information on how to administer an SAP R/3 system, see the book: Liane Will, SAP R/3 System Administration, 2003

For information on how to monitor and tune the general system performance, see the book: Thomas Schneider, SAP Performance Optimization Guide, 2006

For information on how to monitor your business processes using the SAP Solution Manager, see thebook:

Thomas Schroeder, Business Process Monitoring mit dem SAP Solution Manager, 2009 (currently only available in German)

https://service.sap.com/solutionmanagerbp

https://websmp102.sap-ag.de/~sapidb/011000358700001194752006E


© 2010 SAP AG page 34/34

For information on how to set up general system monitoring using the SAP Solution Manager, see thebook:Corinna Weidmann, Lars Teuber, Konzeption und Einrichtung des Systemmmonitorings mit dem SAPSolution Manager, 2009(currently only available in German)

3.4 Feedback and Questions

Send any feedback by formulating an SAP customer message to component SV-SMG-MON-BPM. You cando this at http://service.sap.com/message.

http://service.sap.com/message


© 2010 SAP AG page 35/35

4 Appendix

In the following section, you will find examples on how you can set up the Monitoring within the SAP SolutionManager.

4.1 Examples for Recommended Monitoring Objects

4.1.1 Example Background Job Monitoring

Background Job Monitoring of Background Job RLABGL00 in SAP Solution Manager. The setup for the otherJobs is quite similar except for the Job specific parameters.

1. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER).2. Choose your solution.3. Go to 'Operation Setup' and navigate to 'Solution Monitoring' 'Business Process Monitoring'.4. Check 'Business Processes': select a business process for application monitoring.5. Check for your chosen business process: choose process steps to monitor.6. Check for your chosen step: Choose type of monitor, here 'Background Job'.7. Enter the information to be used to identify the job in this case the Job Name

S_PRD001_UK_SALES_RLABGL00_1000_M

8. Choose the key figures Job Cancellation and Maximum Duration to monitor the runtime of the job.9. In Maximum Duration check, you can enter thresholds that would raise a yellow or a red alert respectively

when exceeded.

10. In Job Cancellation check, you can decide whether a yellow or a red alert should be raised when the jobis cancelled.


© 2010 SAP AG page 36/36

11. Once you have entered all relevant information for the monitoring objects, generate the monitoringcustomizing and activate the monitoring within the ‘Business Process Monitoring’ session.

4.1.2 Example ABAP Dump Monitoring

To monitor the ABAP Dumps within the SAP Solution Manager, you have various possibilities. One possibilityis to use the scheduling user and monitor all ABAP dumps which are created from this scheduling user. Thesecond possibility is to monitor a special dump which occurs again and again, the third possibility is tomonitor a special Program or Function Module to see whether it causes a dump. The following describes thesetup procedure for a special scheduling user.

1. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER).2. Choose your solution.3. Go to 'Operation Setup' and navigate to 'Solution Monitoring' => 'Business Process Monitoring'.4. Check 'Business Processes': select a business process for application monitoring.5. Check for your chosen business process: choose process steps to monitor.6. Check for your chosen step: Choose type of monitor, here 'Application Monitor'.7. Choose the Application Monitor 'ABAP Dump Collector'

8. Choose Number of ABAP Dumps (Delta) This key figure will collect all dumps since the last run of the collector.

9. Enter a Wildcard in fields “Runtime Error” and “Program”, since the Program could call another FB andthe Runtime Error could be different for each of the called function modules. In our example all runtimeerrors for users that have a user ID starting with “UK” will be monitored.


© 2010 SAP AG page 37/37

10. You should always be informed if a dump occurs.

11. In the Monitoring Schedule, enter that the scheduling should be once a day

12. Once you have entered all relevant information for the monitoring objects, generate the monitoringcustomizing and activate the monitoring within the 'Business Process Monitoring' session.

4.1.3 Example Application Monitor “Messages” (Output Determination)

If you want to monitor messages that have been incorrectly processed or not been processed at all in thetable NAST, you can use the respective monitoring object in SAP Solution Manager.

1. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER).2. Choose your solution.3. Go to 'Operation Setup' and navigate to 'Solution Monitoring' => 'Business Process Monitoring'.4. Check 'Business Processes': select a business process for application monitoring.5. Check for your chosen business process: choose process steps to monitor.6. Check for your chosen step: Choose the type of monitor, here 'Application Monitor'.7. Choose the Application Monitor ‘Messages (Output Determination)’ (KWMSG0001)8. In a next step choose the key figure you are interested in (for example, “Incorrectly processed

messages”) and define a Monitoring schedule


© 2010 SAP AG page 38/38

9. In the next step, double-click the field “Counter” and enter the selection criteria the monitored messagesshould fulfill, for example, “V3” (SD Billing) as Application; “6” (EDI) as Transmission Medium and “1” asDispatch Time.

10. Now you can also enter threshold values for a yellow or a red alert. If these threshold values areexceeded based on the selection criteria entered above a yellow alert is raised – or a red alertrespectively.

11. Once you have entered all relevant information for the monitoring objects, generate the monitoringcustomizing and activate the monitoring within the 'Business Process Monitoring' session.


© 2010 SAP AG page 39/39

4.2 Background Jobs

Certain jobs must run periodically in a production SAP Automotive System, for example, deleting obsoletejobs or spool objects. If these periodic jobs do not run, system performance may get worse over time.Unfortunately, there is currently no easy-to-use support for such jobs in Basis Customizing. Therefore, thejobs must be scheduled manually. For more information, see SAP Note 16083. Note that a daily monitoring ofthe job log using Solution Manager is recommended.

Error Handling Procedures for Batch JobsIf one of the scheduled jobs fails, if one of the necessary jobs is not scheduled, or even if a scheduled jobhas finished, check for the current job status (refer to SAP R/3 documentation CD, component BC-CCM,chapter background processing) and proceed as follows:

In the case of status scheduled, the job steps have already been defined, but the start conditionhas not yet been defined. Contact the program scheduling management in order to clarify whenthe job will be fully defined.

In the case of status released, the job has been fully defined including a start condition and waitsfor the condition to fulfill.

In the case of status ready, the start condition of a released job has been met. A job schedulerhas put the job in line to wait for an available background work process.

In the case of status active, the job is currently running and cannot be modified or deletedanymore. Check if the job is within the given timeframe, depending on the data volume to beprocessed. Check for particular dependencies on other jobs. If the job exceeded the giventimeframe, contact the software monitoring team.

In the case of status finished, all steps that make up this job have completed successfully.Program scheduling management has to check whether the job ran in the given timeframe, andsoftware monitoring team and/ or application support have to check the respective job results(such as spool output lists, message logs, updates, etc.).

In the case of status cancelled, the job has terminated abnormally, which can happen in twoways. If an administrator intentionally cancelled the job, clarify why he did so and whether (and if,when) the job has to be re-run. If a program in a job step produced an error such as issuing an ‘E’or ‘A’ error message, contact the software monitoring team and investigate why the erroroccurred. In case of an SAP standard program search for appropriate messages in SAPNet andopen a customer message if you cannot solve the problem.

Job RestartabilityIn case of the cancellation of a background job, possible succeeding jobs or dependencies on other jobsmust be considered when restarting the aborted job. The start of succeeding jobs might be also delayed dueto the restart of the aborted job.

Escalation ProceduresIf it is not possible for any of your support levels to provide a solution for a particular problem, it isrecommended to open an SAP customer problem message.


© 2010 SAP AG page 40/40

© 2010 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, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9,iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server,PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporatedin the United States 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, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Instituteof Technology.

Java 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 byNetscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer and other SAP products andservices mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and othercountries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, andother Business Objects products and services mentioned herein as well as their respective logos are trademarks or registeredtrademarks of SAP France in the United States and in other countries.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this documentserves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.

This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.

SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.