end of-day processing exception handling

© 2010 SAP AG

Best-Practice Document

End-of-Day Processing - Exception Handling

Dietmar-Hopp-Allee 16

D-69190 Walldorf

DATE February 2011 SOLUTION MANAGEMENT PHASE SAP SOLUTION

Operations & Continuous Improvement SAP for Banking TOPIC AREA

Business Process Operations

Best-Practice Document End-of-Day Exception Handling

© 2010 SAP AG page 2/44

Table of Content 1 Introduction ..................................................................................................................................... 4

1.1 About This Document 4 1.2 Customer Requirements 4 1.3 Staff and Skills Requirements 4

2 Exception Handling During End-of-Day Processing .......................................................................... 6 2.1 Introduction 6 2.2 Exception Handling Overview 6 2.3 General Remark to Errors Within Mass Processing 9 2.4 Errors Within an Application Component 9 2.5 Errors Outside the Initiating Application Component 12 2.6 Errors “in Between” Application Components 14 2.7 Avoid Error Situations by Using Repeat Functionality of the Framework for Parallel Processing 15 2.8 Mass Run Monitoring with Transaction BANK_PP_MONITOR 16 2.9 Repeat of a Mass Run with the External Run ID 18 2.10 Summary 19

3 Return Code Handling ..................................................................................................................... 20 3.1 Introduction 20 3.2 Technical Job Status of a Background Job 20 3.3 Application Return Code 22 3.4 Handling of Job Status and Application Return Codes by an External Job Scheduling Tool 23 3.5 External Job Scheduling Example: Return Code Handling with the Central Process Scheduling by

Redwood for SAP NetWeaver 26 3.6 Simple Test Case to Verify If a Job Scheduling Tool can Handle Both Return Codes 29 3.7 Summary 30

4 Dependencies Within an End-of-Day Job Chain ............................................................................... 31 4.1 Introduction 31 4.2 Time-Based Dependencies 31 4.3 Date-Based Dependencies 31 4.4 Process-Based Dependencies 32 4.5 Dependent Locks 35 4.6 Summary 36

5 Appendix ......................................................................................................................................... 37 5.1 List of End-Of-Day Reports 37 5.2 Additional Information 43


© 2010 SAP AG page 3/44

Table of Figures Figure 1: Master Contract Management and Account Management Running on One Instance ............ 8 Figure 2: Master Contract Management and Account Management Running on Different Instances .... 8 Figure 3: Error Within an Application Component .............................................................................. 10 Figure 4: Error Outside the Initiating Application Component ............................................................. 12 Figure 5: Screenshot ECH Customizing ............................................................................................ 13 Figure 6: Error “in Between” Application Components ....................................................................... 14 Figure 7: Setup of Direct and Sequential Repeats ............................................................................. 15 Figure 8: Framework for Parallel Processing - Dynamic Model .......................................................... 16 Figure 9: BANK_PP_MONITOR - Overview of Mass Runs ................................................................ 17 Figure 10: BANK_PP_MONITOR – Packages ................................................................................... 17 Figure 11: BANK_PP_MONITOR – Objects per Package .................................................................. 17 Figure 12: External Run ID of a Mass Run ........................................................................................ 18 Figure 13: SM37 Job Overview ......................................................................................................... 21 Figure 14: Runtime View on Background Jobs .................................................................................. 21 Figure 15: Example of a Job Chain Definition with Redwood ............................................................. 26 Figure 16: Example of a Job Ended with Errors ................................................................................. 27 Figure 17: Final Status Handlers ....................................................................................................... 28 Figure 18: Return Code Mapping to Completed ................................................................................. 28 Figure 19: SLG1 Log ......................................................................................................................... 29 Figure 20: SM37 Job Log .................................................................................................................. 30 Figure 21: Job Status in Redwood..................................................................................................... 30 Figure 22: Locks of Other Application Types Relevant for Application Type ....................................... 35


© 2010 SAP AG page 4/44

1 Introduction

1.1 About This Document

In addition to the best-practice document, this document will provide more detailed information about exception handling within banking services from SAP. The main goal is to describe the different situations where errors can occur and which transactions (including the necessary setup) can be used for monitoring, analyzing, and follow-up activities.

The aspect of inter-application-component communication is especially taken into account. This aspect is important because—due to decoupling, scalability, and SOA enablement reasons—the kind of communication between application components within banking services from SAP is new compared to Transactional Banking (TRBK) releases.

Furthermore, this document describes some aspects to be considered during the setup and operation of end-of-day processing. So, for instance, it describes what kind of return codes, from a banking services from SAP point of view, are relevant with respect to end-of-day mass runs and how the return codes should be handled.

Last but not least, this document will discuss “Exception Handling” as an important part of a bank’s daily business.

1.2 Customer Requirements

Experiences from customer projects show that missing knowledge about exception handling and system monitoring sometimes leads to many unhandled errors in the system. Unhandled errors may lead to customer complaints (for example, if postings have not been performed) and unsatisfied customers. Depending on the error, it might be even more difficult to fix the longer it exists in the system. Therefore, exception handling and monitoring should be established as an essential part of the implementation project and daily operations. It is also essential that knowledge transfer and handover take place between the project teams, for example, from the implementation team to the operations team and to the user departments. Responsibilities should be clear for the involved parties.

1.3 Staff and Skills Requirements

This document will provide the operations team with an idea of what to do in case of errors and will give the implementation team more information about the system setup. The task of the operations team is to monitor the system (for example, backend system and job scheduling system) and analyze and fix technical errors. The implementation team is responsible for setting up the relevant business processes and tools, including Postprocessing Office (PPO) and Posting Control Office (PCO), to enable the user department to monitor and fix errors.


© 2010 SAP AG page 5/44

Depending on the kind of task, specific skills and roles are required from the bank.

The following tasks should be assigned to the corresponding teams:

Task Aim of the task Responsible team

Analyze Postprocessing Office (PPO) orders

Analyze and fix business-related errors.

User department

Analyze Posting Control Office (PCO) orders

Analyze and fix business-related errors.

User department

Analyze technical errors (communication or system-related errors) via transaction SM37/SM58/ST22/SXMB_MONI/BANK_PP_MONITOR

Analyze and fix technical errors. Operations team

Monitor job nets Fix and address errors. Operations team

Set up system to run business processes, for example, PPO and PCO

Provide the necessary tools for analysis and monitoring to the operations team and the user department.

Implementation team


© 2010 SAP AG page 6/44

2 Exception Handling During End-of-Day Processing

2.1 Introduction

The end-of-day process is an important task at a bank. End-of-day processing includes activities to close a day. These activities include, for example, settlement of accounts, creation of bank statements, and execution of standing orders. Because many activities are necessary during end-of-day processing, it is important to optimize these activities to perform them within a given time frame. Errors may influence the processing time, so it is important to streamline the error-handling processes. Knowledge about exception handling is therefore absolutely necessary.

Planning end-of-day activities is an important task within the implementation and operation project (more information can be found in the best-practice document SAP Banking Services / Deposit Management – End of Day/ Batch Processing). Exception handling should be part of this planning.

Errors may occur during the execution of the end-of-day processes. There could be runtime errors, for example, due to technical reasons (system or database problems) or software-related reasons, processing errors (for example, exceptional situations that lead to an error for a specific object), or business-process-related exceptions (for example, missing or incorrect configuration of a business process). Depending on the kind of error, there are different measures to handle them. The reaction time depends on the kind of error. System or database problems have to be handled with priority 1; otherwise, end-of-day processing cannot be continued and finished in time. The same is valid for runtime errors. If there is an exceptional situation that leads to an error, successor activities may not be started and the closing of the day may not be possible. Therefore, it is mandatory to monitor end-of-day processing activities.

But there are also other errors that are not that immediately critical and that can be analyzed on the next business day. For example, an account could not be settled because the settlement feature is locked. Usually, these are errors that can only be solved by the user department with special business process knowledge.

2.2 Exception Handling Overview

The most important tool for exception handling is the Postprocessing Office (PPO). Nearly all mass runs that can be used in end-of-day processing within banking services from SAP create PPO orders in case of errors. A postprocessing order contains information (for example, account number, business partner, business process information, error messages) that is helpful to analyze the cause of an error.

There are two kinds of PPO orders: “Classical” orders and the orders created by the Error and Conflict Handler (ECH). Classical PPO orders only contain information about the failed object (for example, account), additional objects (for example, business partner) and the error messages that occurred during processing. Once the error is solved, the relevant report can be restarted to reprocess the object and a user can set the


© 2010 SAP AG page 7/44

PPO order to “completed.” This type of PPO order is created, for example, by the account settlement and account statement mass runs.

PPO orders created by the Error and Conflict Handler (ECH) are created for asynchronous messages for which an error occurred during processing. ECH PPO orders include all data provided by the initiating process and, therefore, it is possible to repeat (manually or automatically) this specific process step out of the PPO once the error is analyzed and corrected. An example of a process that creates ECH PPO orders is the posting of payment orders or payment items created by combined settlement.

Asynchronous communication is used, for example, by the Master Contract Management applications Facilities or Combined Settlement, which communicate with accounts located in the Account Management component. Another example is the communication between Account Management and FI-CA for loans processes.

Within banking services from SAP, several application components, for example, Account Management and Master Contract Management, are decoupled from each other. Decoupling the components makes it possible to run them on different instances.

Communication between the application components is either synchronous (for example, immediate response to a query) or asynchronous (either no response is expected or response can be sent at a later time) and can be done using Remote Function Call or enterprise service, for example. In addition to the communication between application components within banking services from SAP, communication to other SAP or non-SAP systems may be necessary, for example, to FI-CA or to a general ledger system, for some processes.

The following diagrams show examples of the communication between different components via RFC channel.


© 2010 SAP AG page 8/44

Master Contract Management and Account Management Running on One Instance

Master Contract Management and Account Management Running on Different Instances


© 2010 SAP AG page 9/44

2.3 General Remark to Errors Within Mass Processing

Several error situations can occur during the processing of a mass run. The errors can be categorized as follows:

- Runtime errors (short dumps)

Runtime errors can occur if there are technical problems (for example, database or server problems) or if there was an exception during processing that cannot be handled by the software or software errors (syntax errors). If a runtime error occurs, the program and the related background job are terminated immediately. For a parallelized mass run, this means for example, that one parallel job (main job) is terminated. Other main jobs are not necessarily affected. In case of a general problem, however, all other main jobs will also end with a short dump. A PPO order will not be created when a program ends with a runtime error.

The mass run will end with an application return code = 8. It is recommended that you perform an error analysis by using transaction ST22. In addition, check the job log by using transaction SM37.

- Processing errors

There may be situations where the software is not able to continue processing an object because of an exceptional situation (for example, due to plausibility checks, locking situation, or incorrect or missing configuration). But instead of terminating (runtime error) the program, an error message is raised. As a result, a PPO order is created for the affected object. The error has to be analyzed to decide whether it is a configuration issue (for example, product not set up correctly) or a programming error.

The mass run will end with an application return code = 4.

- Business-process-related errors

Errors can also occur if a business object, for example, an account contract, violates certain business rules, for example, account is locked via Posting Lock Management and therefore a settlement cannot be executed. Business rules in the form of posting control rules are also used by item management, for example, limit check.

Note: Errors as a result of a posting control rule violation will end up in the Posting Control Office (PCO) and not in the Postprocessing Office.

The mass run will end with an application return code = 4.

2.4 Errors Within an Application Component

Nearly all mass runs in banking services from SAP create PPO orders in the case of errors. When an object cannot be processed, for example due to business rules, a PPO order is created with relevant information to analyze the error. The created PPO order is a “classical” order and is assigned to the application component in which the error occurred.


© 2010 SAP AG page 10/44

Error Within an Application Component

All error messages created by a mass run are also written to a log. You can display the mass run log either with a specific application transaction or with transaction SLG1. It is recommended that you use the specific application transactions to display the log, because they may use a special logic, for example, with regard to sorting.

Sorting of the SLG1 log may not be equal to the sorting when you use the specific application

transaction.

Within banking services from SAP, the following transactions are available to edit or display PPO orders:

- PPO orders for application component Account Management (FS-AM)

o BCA_PPO2 - Edit Postprocessing Order o BCA_PPO3 - Display Postprocessing Order

- PPO orders for application component Master Contract Management (FS-MCM)

o MCM_PPO2 - Edit Postprocessing Order o MCM_PPO3 - Display Postprocessing Order

- PPO orders for Posting Lock Management1

o PLM_PPO2 - Edit Postprocessing Order o PLM_PPO3 - Display Postprocessing Order

- General PPO transaction (application-component independent)

o /n/SAPPO/PPO2 - Edit Postprocessing Order o /n/SAPPO/PPO3 - Display Postprocessing Order

PPO Setup

By default, the creation of “classical” PPO orders is deactivated. You have to activate the creation in IMG by choosing Cross-Application Components General Application Functions Postprocessing Office Postprocessing Office Business Processes Activate Creation of Postprocessing Orders. 1 Currently, PPO orders assigned to FS-PLM are only created by the effective cash pooling process via ECH.


© 2010 SAP AG page 11/44

It is recommended to activate PPO for the following components: - FS-AM - FS-MCM - PRI (Pricing: Use transaction /n/SAPPO/PPO2 to work on Pricing PPO orders. There is no

specific transaction for Pricing.)

To activate PPO for all business processes of a component, leave the business process blank. At minimum, the following entries should exist in the table:

Component Business Process Act. FS-AM X FS-MCM X PRI X

You can also find the relevant PPO activities in the IMG path of the application component: Financial Services Account Management or Master Contract Management Postprocessing Office Business Processes Activate Creation of Postprocessing Orders. You should also consider if it makes sense to use worklists for PPO orders. With worklists, you are able to assign responsibilities for specific business processes to specific users. For example, if there are specific users who should take care of item-specific errors, these users can be assigned to an item worklist. Other users may take care of settlement-specific errors. These users can be assigned to a settlement worklist. The IMG path to define worklists is Financial Services Account Management or Master Contract Management Postprocessing Office Worklist. Once a worklist has been created, the PPO business processes can be assigned to it. Afterward, you can assign users to the worklist. You assign users to a worklist via the SAP Easy Access menu: Financial Services Account Management / Master Contract Management Postprocessing Office Worklist Change Assignment. When a user starts a PPO transaction, for example, BCA_PPO2 with “Order Assignment” = 1, the user will only see PPO orders that are assigned to his or her worklists.

A PPO order is assigned to a worklist during the order creation. If the assignment of a business process to a worklist is missing in the configuration, a PPO order related to this business process is not assigned to a worklist during creation.

If you reassign a business process to another worklist, the existing PPO orders are not updated.


© 2010 SAP AG page 12/44

2.5 Errors Outside the Initiating Application Component

In banking services from SAP, processes communicate either synchronously or asynchronously with other application components. Asynchronous communication means that the initiating process sends a message to another application component without expecting any response to that message. After an asynchronous message is sent, the initiating process continues. The asynchronous message is processed in the other application component. If there is an error during processing within the other component, the Error and Conflict Handler (ECH) takes care of it. The ECH passes all relevant information (including the processing data) to the PPO (default behavior). It is not necessary to activate PPO orders created by ECH.

Banking Services from SAP

Master Contract Management Application Component

Account Management Application Component

R

PPOECH

Inbound Proxy

Outbound ProxyApplication Application

Error Outside the Initiating Application Component

PPO orders created by ECH provide more possibilities than classical PPO orders. For instance, ECH PPO orders can be reprocessed manually and/or automatically. Depending on the kind of error, automatic reprocessing can successfully process orders without user interaction, for example, if there is a lock situation.

For automatic reprocessing, report /SAPPO/RESUBMIT_ORDERS_2 should be scheduled as a periodic job. The report can run several times during end-of-day processing. At the very least, it should run once at the end of end-of-day processing.

A mass run will end with application return code = 0 (assuming there are no errors within the

application component) if there are errors outside the initiating application component. Therefore, it is mandatory to monitor PPO, RFC queue (transaction SM58), and PI/XI queue (transaction SXMB_MONI).

ECH Setup


© 2010 SAP AG page 13/44

In the IMG you can define, per component and business process, a resolution strategy for the ECH PPO orders. If nothing is defined in the IMG, the general default resolution strategy is applied. The default resolution strategy is:

Create PPO orders. Allow automatic and manual retry. Allow manual finish and fail. Use no residence time and no resubmission group.

Use the following IMG activity to define your own resolution strategy if the default does not fit in your case: Cross-Application Components General Application Functions Error and Conflict Handler Define Resolution Strategy.

Here is an example of how a resolution strategy might look:

ECH Customizing

For the business process MIF_BAC_0005, Actions for Participant Account for Combined Settlement, ECH orders are created in case of errors. The orders will be stored in the database because the Persistent checkbox is selected (this should always be the case). The orders are assigned to the resubmission group “S30 Hourly.” This submission group can be used as selection criteria in a variant of report /SAPPO/RESUBMIT_ORDERS_2. A periodic job for report /SAPPO/RESUBMIT_ORDERS_2 should be scheduled. The scheduled job should run hourly and should use the variant with resubmission group S30. Because the repeat mode is set to “3 Automatically and Manually,” the report will repeat the orders automatically. A user can also repeat the order manually out of the PPO. The confirmation mode is set to “0


© 2010 SAP AG page 14/44

No Processing.” This means that it is not allowed to finish this PPO order. In the context of business process MIF_BAC_0005, this means that no positive confirmation (everything is okay) can be sent to the original sender (in this case, the Master Contract Management component). The positive confirmation is only sent when the repetition is successful. This is useful for preventing inconsistencies.

But it is allowed to discard the order. If the order is discarded, a negative confirmation is sent to the original sender. This means that the sender has to make sure that the state before sending the message has to be restored. Discard is possible either automatically via report /SAPPO/RESUBMIT_ORDERS_2 or manually out of the PPO.

The residence time is four weeks. After four weeks, the order can be discarded automatically by report /SAPPO/RESUBMIT_ORDERS_2 if processing fails.

It is not recommended to use the transient resolution strategy, because it could lead to problems

during processing of messages sent via XI. Always use the persistent resolution strategy. Make sure that the Persistent flag is always selected; otherwise, no PPO order is created.

2.6 Errors “in Between” Application Components

In some cases, errors can also happen “in between” application components. This is the case if the initiating process sent a message but the message did not arrive at the target application component. The problem could be a communication error, for example, target system is not available, or the called function is faulty or not available.

Error “in Between” Application Components

For RFC-based communication, you can use transaction SM58 to monitor and analyze such calling errors. The transaction provides information about the called function, the error, and the target system. If the target system cannot be reached because the connection is not active, report RSARFCSE is scheduled automatically as background job and is called at regular intervals. If there is a problem with the called function (for example, syntax error or short dump) you must analyze the problem and correct the error. Check the runtime errors in the target system with transaction ST22 to get more information about the error. Once the


© 2010 SAP AG page 15/44

error is solved, you can restart the RFC via transaction SM58. Additionally, schedule report RSARFCEX, “Execute Calls Not Yet Executed,” as a periodic background job to restart aborted RFCs.

For message processed via the Process Integration Server (PI/XI), you can use transaction SXMB_MONI for monitoring and analyzing.

The mass run will end with application return code = 0 if there are errors “in between” application

components. Therefore, it is mandatory to monitor PPO, RFC queue (transaction SM58), and XI/PI queue (transaction SXMB_MONI).

2.7 Avoid Error Situations by Using Repeat Functionality of the Framework for Parallel Processing

To avoid errors resulting from lock situations, you can define the number of parallel and sequential repeats per application type in the Framework for Parallel Processing configuration (IMG: Financial Services Account Management / Master Contract Management Tools Parallel Processing Maintain Customer Settings for Application Types).

Setup of Direct and Sequential Repeats

The application itself makes the decision about the repeat behavior. The object can be repeated only if the application sets a certain status for an object within parallel processing.

Parallel repeat means that packages that include objects with a certain status are repeated in parallel (with the same number of jobs defined for the run) after all packages have been processed once. If a sequential repeat is defined, all packages that include objects with a certain status are repeated in one single background job after the parallel repeat(s).


© 2010 SAP AG page 16/44

© SAP 2008 / Page 7

Parallel Processing Framework: Dynamic Model (simple scenario)

Number of parallel jobs is defined by application type in IMG by customerIMG: Financial Services Account Management Tools Parallel Processing Maintain Job Distribution

Job 2

write

Package DB Table

Build Packages

Fetch Package

Process Package

read

Job 1 Job n

Finalize Run

Objects in Work List DB(optional)

read / write

[package selected?]

yes no

[repeat?]

Number of repeats defined via transaction bank_cus_pp/bank_cus_ppcper application type

Framework for Parallel Processing – Dynamic Model

2.8 Mass Run Monitoring with Transaction BANK_PP_MONITOR

Transaction BANK_PP_MONITOR can support you in analyzing erroneous mass runs. If a mass run ends with errors, the information about the mass run is stored by the Framework for Parallel Processing. With transaction BANK_PP_MONITOR you can, for example, see the number of created and processed packages of the mass run. You can also see the status of each object within a package.


© 2010 SAP AG page 17/44

BANK_PP_MONITOR – Overview of Mass Runs

Double-click on a line to get detailed information about the package processing.

BANK_PP_MONITOR – Packages

Select a package and choose the Single Objects button to get a list objects processed within this package and the status for each object.

BANK_PP_MONITOR – Objects per Package


© 2010 SAP AG page 18/44

You can also use this transaction to monitor the processing status during an active mass run. Navigate to the packages to find out how many packages have already been processed and how many packages still have an initial status.

Transaction BANK_PP_MONITOR is more a monitoring transaction then a transaction to analyze errors.

2.9 Repeat of a Mass Run with the External Run ID

If a mass run ends with a return code <> 0, the run can be repeated after the causing error is solved. If a banking service from SAP mass run provides the field External Run ID on the selection screen, it is possible to repeat the run with the external run ID of the original run.

External Run ID of a Mass Run

The advantage of repeating the external run ID of the original run is that the run is repeated with exactly the same input parameters of the selection screen, and the due objects do not need to be selected again by the application (the selection by the application may be a bit slower because of the complexity of the selection). The objects selected by the original run, which were not processed successfully, are stored by the Framework for Parallel Processing (PPF). During the repeat of the run, the stored objects are selected by the PPF and re-processed. If a mass run provides the external run ID, a run should be repeated with the original run ID in case of errors.

If a run ended with return code = 0, the usage of the external run ID for another mass run will not

repeat the original run. Instead a new run with the same ID is started. Once a run ends with return code = 0 administrative, data relating to this mass run is always automatically removed from the system.

An erroneous single object can also be repeated with a single run (if the application provides one)

when the causing error has been solved.

A mass run can also be repeated without using the external run ID of the original run. In this case, the application will select and process the due objects again.


© 2010 SAP AG page 19/44

2.10 Summary

Although a mass run ends with return code = 0, this does not mean that no errors occurred during execution. Therefore it is absolutely vital to monitor the system regularly, especially during and after the end-of-day processing.

The following table provides a list of transactions that can be used for monitoring and analysis:

Transaction Description

/SAPPO/PPO2 Edit Postprocessing Orders (Generic entry point)

BCA_PPO2 Edit Postprocessing Orders (Account Management)

MCM_PPO2 Edit Postprocessing Orders (Master Contract Management)

PLM_PPO2 Edit Postprocessing Orders (Posting Lock Management)

SM37 Overview of job selection

SM58 Asynchronous RFC Error Log

ST22 ABAP Dump Analysis

SLG1 Display application logs

Banking specific application log transactions

See in the SAP Easy Access Menu, for example, Financial Services Account Management Logs

SXMB_MONI Integration Engine – Monitoring of messages send via XI/PI

BANK_PP_MONITOR Transaction to monitor mass runs

Schedule the reports /SAPPO/RESUBMIT_ORDERS_2, “Resubmission of Postprocessing Orders,”

and RSARFCEX, “Execute Calls Not Yet Executed,” as periodic job to avoid manual processing of errors if they are only temporary, for example, lock errors.


© 2010 SAP AG page 20/44

3 Return Code Handling

3.1 Introduction

Banking services from SAP mass runs that are used in the end-of-day processing sometimes have dependencies between each other, for example, the creation of a bank statement should be done after the settlement, because the settlement results should also be visible on the bank statement. These dependencies have to be considered during the setup of the end-of-day job chain. A static view on the job chain should reflect these dependencies for example, by defining successor job(s). During runtime, a dynamic component has to be considered, too. This dynamic component is the status of a job. But not only the technical status of a job is relevant, but also an application-related return code. It could be that technically a job has ended without errors, but from an application point of view there might be errors. An external job scheduling tool should be able to cope with both, the technical job status and the application return code.

3.2 Technical Job Status of a Background Job

End-of-day mass runs are usually executed in background. The corresponding background job can have one of the following technical statuses.

Job Status Explanation

Planned (P) Steps that make up the job have already been defined, but the start condition has not yet been defined.

Released (S) The job has been fully defined, including a start condition. Without a start condition, a job cannot be released. Only an administrator or a user with appropriate authorizations for background processing can release a job, preventing unauthorized users from running jobs without approval.

Ready (Y) The start condition of a released job has been met. A job scheduler has put the job in line to wait for an available background work process.

Active (R) The job is currently running. Active jobs can no longer be modified or deleted.

Finished (F) All steps that make up this job have completed successfully.

Canceled (A) The job has terminated abnormally. This can happen in three ways: An administrator intentionally terminates a job with Transaction SM37,

Job Cancel active job A job step contains a program that produces an error System error or database problems

The status of the background job can be seen in the job overview (transaction SM37).


© 2010 SAP AG page 21/44

For banking services mass runs using the Framework for Parallel Processing you will find one start job and multiple main and end jobs in the job overview. Only the status of the start job is relevant for the job scheduling tool.

SM37 Job Overview

© SAP 2008 / Page 8

Child Process

Runtime View – Batch Jobs

Main jobs do the data processing (report RBANK_PROC_START)

End jobs set process status in database (report RBANK_PROC_END)End jobs are defined as successor jobs of the main jobs

Start report resp. parent process is sync point for child processes

DEMO Job 01

DEMO Job 02

DEMO Job 03

E:DEMO Job 02

E:DEMO Job 03

START_REPORT

E:DEMO Job 01

Process Data

Main Job

End Job

Parent Process

Start Job

Runtime View on Background Jobs


© 2010 SAP AG page 22/44

3.3 Application Return Code

In addition to the technical return code, an application-related return code at the end of a batch job with the following values is provided by banking services mass runs:

Return Code

Description

0 Completed successfully: Processing of subsequent processes of the job net can continue. In the case of a restart of the job net, steps with this return value should be skipped.

2 Completed with warnings: Processing of subsequent processes can continue. In the case of a restart of the job net, steps with this return value should be skipped.

4 Completed with single errors: The mass run could not process all objects successfully. Errors occurred for certain objects. The system recorded these errors in the log. You can still continue the end-of-day processing but it is vital that you analyze the errors. If technically possible you can repeat the run once the errors are solved.

8 Terminated: Serious errors occurred when the system was processing the data. Job control should not continue with subsequent processes. First analyze the errors and do not continue with end-of-day processing until the errors are corrected.

99 Predefined value: Job has been started but no status was set so far. This means the report is still running. It could also be that the report terminated before a final status could be set.

In case of return code = 4, it is possible to change the return code to 8 based on the relation of due and successful processed objects. In the IMG activity Financial Services Account Management End-of-Day Processing Define Return for Mass Runs, you can set a relation between due and successfully processed objects with an upper limit (basis counter for the number of accounts processed) and the maximum proportion (percentage) up to which limit the run can be interpreted as “Completed with single errors, continuation possible” (return code = 4).

In addition to the maximum percentage, you can also specify an absolute maximum. In this case, the smaller of the two values is relevant on the highest permitted number of incorrect objects. If the percentage or the highest permitted number is exceeded, the application related return code is set to 8, which means terminated.


© 2010 SAP AG page 23/44

Here are some criteria for the decision on what to customize:

The standard (no customizing) delivers a return code 4 (individual errors) even if 100.000 out of 100.000 due objects have individual errors.

A certain number of single errors can indicate a kind of general error. In this case it makes sense to correct this error before continuing the job net.

It is not easy to define this “certain number.” The entries should be valid for small numbers of due objects (for example, settlements on a non-ultimo day) and for huge numbers (month-end) also.

Example

Basis Counter

Counter Relation

Upper Limit Limit Individual Error %

Absolute

ACCDUE ACCSUC 10.000 5

ACCDUE ACCSUC 100.0000 5 1.000

ACCDUE ACCSUC 5 1.500

Up to a limit of 10,000 due accounts, or a maximum of 5% of the due accounts, the process is handled as individual error (application return code = 4); if more accounts are affected, this counts as a termination error (application return code = 8).

At the end of a mass run the application-related return code is set by checking the customizing table mentioned above.

3.4 Handling of Job Status and Application Return Codes by an External Job Scheduling Tool

The application return code is transferred to the background job and stored together with other job information. This is done in the business transaction event (BTE) 0BANK015. The standard function module that is called at the end of a banking services mass run is STD_PROCESS_0BANK015. The function module calls the relevant function module to transfer the return code to the background job.

The external job scheduling tool can retrieve the application return code as well as the technical job status with the BAPI BAPI_XBP_GET_APPLICATION_RC.

The technical job status is provided in the exporting parameter STATUS. The value in field STATUS can be mapped to the job statuses mentioned above, as follows:

P = Planned S = Released/Scheduled Y = Ready R = Active/Running F = Finished A = Canceled/Aborted


© 2010 SAP AG page 24/44

The application-related return code is provided in the exporting parameter APP_RC.

Depending on the combination of the technical job status and the application-related return code, the job scheduling tool has to decide if the successor job can be started or not, for example, if the application return code = 4 and the technical job status = F (finished), the successor job can be started. Therefore the external job scheduling tool has to be able to interpret the two return codes correctly.

Example

Technical Job Status

Application return code

Result in the job control tool

Possible reactions of the job control tool

F = finished 0 – Completed successfully

OK Start next job(s)

2 – Ended with a warning


4 – Completed with individual errors


With the possibility to start this job later after having corrected the objects

8 – Terminated NOK - stop Restart this job or start next job(s) after analysis of the error

A - canceled 0 – Completed successfully

NOK - stop Restart this job or start next job(s) after analysis of the error

2 – Ended with a warning


4 – Completed with individual errors


8 – Terminated NOK - stop Restart this job or start next job(s) after analysis of the error


© 2010 SAP AG page 26/44

3.5 External Job Scheduling Example: Return Code Handling with Central Process Scheduling by Redwood for SAP NetWeaver

The SAP Central Process Scheduling application by Redwood for SAP NetWeaver is able to handle return codes, the technical job status, and the application-related return code. The job status and the application return code influence the processing behavior of the whole job chain. To understand the processing behavior of a job chain in SAP Central Process Scheduling, the basic principal of a job chain is be explained first.

A job chain in SAP Central Process Scheduling consists of three elements: The job chain itself

The job chain consists of several steps. The steps are processed one after the other. Steps

A step consists of several jobs. All jobs of a step are executed in parallel. Jobs

A job represents a report that is started in the back-end system with specific parameters, for example, a variant.

Example of a Job Chain Definition with SAP Central Process Scheduling

A job chain consists of n steps. Once a step is processed successfully, the next step is processed. A step consists of m jobs. A step is processed successfully if all jobs within the step are processed successfully. All jobs within a step are processed in parallel. A job chain is finished successfully if all steps are completed successfully.


© 2010 SAP AG page 27/44

So the overall status of a job chain is derived from the status of the single steps within the job chain. The status of a step is derived from the status of the single jobs within the step.

For a single job, the overall job status is derived from the technical job status and the application-specific return code. The derived status could be one of the following:

Status Description

Completed Process execution finished successfully.

Error The execution of the process failed.

Killed The process was terminated while it was running.

Unknown The service was terminated while the process was running. It can occur that the job gets deleted in the SAP system before the final status has been retrieved by SAP CPS. In this case, the job will get the status Unknown in the job monitor.

Example of a Job Ended with Errors


© 2010 SAP AG page 28/44

For the application return code = 4, the overall job status “Error” is derived. The status of the step and the job chain is also “Error.” Due to the fact that the step has status “Error,” the successor steps are not processed.

As mentioned above, an application return code = 4 indicates that single errors occurred. As long as the technical job status is “Finished,” the job chain can be continued. SAP CPS offers several possibilities to react on errors. One possibility is to use so-called “Status Handlers” on step level.

Final Status Handlers

On step level you can define what to do in case of errors. The final status handler “On Error” can be used to define what do to. If you are sure that no critical reports are included in this step you can set, for example, the action “Continue” to continue with the next step.

Another possibility is to use return code mapping within the job definition.

Return Code Mapping to Completed


© 2010 SAP AG page 29/44

With the above setting, mass runs that end with an application return code 0, 2, or 4 will end with an overall status “Completed” (assuming the technical job status is “Finished”). So if all jobs within a step end with application return code 0, 2, or 4, the overall status of the step will be “Completed” and the next step can continue.

3.6 Simple Test Case to Verify If a Job Scheduling Tool can Handle Both Return Codes

To find out whether a job scheduling tool can handle both return codes, try the following:

Check the posting date of an existing bank posting area.

Create a variant for the program RBCA_DATE_POST_SET – “Set Posting Date for Payment Transactions” – with a new posting date in the past and deactivate the simulation flag.

If you run this report in dialog, you get the following error messages:

o BCA_BPARE009 - New pst date in bank pst area &1 must be after the one currently valid

o BCA_BASIS010 - Program completed with return code 8 / ABEND

Let the job control start the program RBCA_DATE_POST_SET with the variant you created. The result in SAP should be:

o Applicational RC (best to be found in the protocol of transaction slg1) = 8

SLG1 log

o Technical RC (transaction sm37) = finished


© 2010 SAP AG page 30/44

SM37 job log

The result in the job control tool should be a return code that means “stop – an error occurred in the last job.”

Job Status in Redwood

If the result in the job control tool stands for “everything OK,” you have an issue to solve.

3.7 Summary

Banking services from SAP mass runs provide an application return code in addition to the technical job status of the background job.

An application return code = 4 can be changed to 8 depending on the ratio of due and successful processed objects (depending on customizing).

Consider dependencies of mass runs during set up of the job chain. An external job scheduling tool should be able to cope with the application return code and

the technical job status.


© 2010 SAP AG page 31/44

4 Dependencies Within an End-of-Day Job Chain

4.1 Introduction

The following section provides an overview of dependencies that should be considered during the setup of an end-of-day job chain. In context with exception handling, it is important to know these dependencies, because in case of errors during the end-of-day processing it can be assessed how critical this error is for the whole job chain.

Besides the dependencies mentioned here, there may be also other organizational or technical dependencies that should also be taken into account.

4.2 Time-Based Dependencies

The end-of-day processing should take place within a certain time window. For instance, the end-of-day processing cannot start before the bank has physically closed its doors and, of course, the processing should be finished before the doors open the next day. To fulfill this requirement it has to be checked which end-of-day activities can be done in parallel. Furthermore, a proper hardware and system setup is required, for example, enough background work processes.

4.3 Date-Based Dependencies

One question to be considered during the setup of an end-of-day job chain is: “What should be processed or posted with which date?”

At the end of the day the bank needs a basis for calculating interests or “counting” the money of the accounts and reconciling against the general ledger. But due to the fact that nowadays a bank is “open” for customers 24/7, there is a need to handle postings that are performed during the end-of-day processing hours of the bank. Nevertheless, the bank has to fulfill the same legal requirements (or even more) on a daily basis. A “bank day” does not exactly correspond with the calendar day of the real world but with the working days of the bank with a slight shift in times. So a day at the bank may end earlier than the real day. The step of closing a day is called the “cutoff.” Banking services from SAP works with three cutoff dates.

1. Posting date for payment transaction

After changing the date it is not possible anymore to post transactions with an “old” posting date. This is the basis for being able to calculate interest. All transactions posted after cutoff are not relevant for the settlement (assuming the value date is the same or greater than the posting date), because the posting process uses the new posting date.

Advantage: It is not necessary to stop the system for postings.

The Assign Present Method “posting date” for accounts and master contracts (IMG: Financial Services Account Management Contract Management General Settings Assign Present Method) synchronizes the validity of master data changes with the posting date.

Example


© 2010 SAP AG page 32/44

19:00: change of a limit from 2.000 EUR to 5.000 EUR of account 1

20:00: change of posting date from 15.05.2009 to 16.05.2009

21:00: change of a limit from 5.000 EUR to 1.000 EUR of account 2

The new limit from account 1 is valid from 15.05.2009, and the one from account 2 from 16.05.2009, although the change was made before midnight.

2. End-of-day processing date

All postings belonging to the end-of-day process are posted with this date.

Only after having posted all related items will this date be changed according to the new posting date.

3. General ledger date

At the end of a day, after having posted everything, the GL day has to be closed.

This makes sure that no postings with the old day (backdate postings) are possible anymore.

It is the basis for calculating items for the GL transfer according to the rules defined in the customizing.

Most of the end-of-day reports have a dependency on at least one of the dates.

4.4 Process-Based Dependencies

Business processes may consist of several process steps. For each step an own end-of-day report may exist. Therefore it is important to perform the necessary steps in the right sequence. This logical sequence has to be reflected in the end-of-day job chain.

The following examples will point out important dependencies. The examples do not contain all reports that can be used in the end-of-day processing. Furthermore it is not mentioned in which time intervals the mass runs should be scheduled. The examples should support you in setting up the end-of-day job chain.

The sequence number (Seq#) in the tables below reflects the processing order within a job chain.

General Account Management report dependencies - FS-AM


© 2010 SAP AG page 33/44

Seq# Report Description Report Name 1.

Set posting date for payment transaction RBCA_DATE_POST_SET 2.

Execute Due Account Closures RBCA_OR_TOC_PP_START_BCA_BOTC 3.

Standing Order Execution (for variable amounts)

RBCA_SORD_RUN_PP

Select Accounts with Backdated Changes RBCA_BACKDATED_CHANGES 4.

Execute Account Billing RBCA_BL_AL_RUN_PP 5.

Execute Account Settlement RBCA_SETTLE_RUN_PP 6.

Accrue/Defer Account Results RBCA_ACCRUE_RUN_PP 7.

Start Bank Statement Mass Run RBCA_BAST_RUN_PP 8.

Set Posting Date for End-of-Day Processing RBCA_DATE_CLOSE_SET 9.

Close Posting Day for General Ledger RBCA_GL_CLOSE_DAY 10.

Balance Sheet Preparation RBCA_BSPREP_RUN_PP 11.

Transfer Postings to General Ledger RBCAGL01_Y 12.

Standing Order Execution (for fix amounts) RBCA_SORD_RUN_PP

Forward Order RBCA_FORD_RUN_PP

Combined Settlement Process (includes Bundle Pricing and Compensation) - FS-MCM


Set posting date for payment transaction RBCA_DATE_POST_SET 2.

Select Accounts with Backdated Changes RBCA_BACKDATED_CHANGES

Determine Backdated Changes /FSBPR/BDC_START_DETERMIN 3.

Request Account Settlement Date /FSBPR/TRIGGER_ACC_SETTLE_PP 4.

Execute Account Settlement RBCA_SETTLE_RUN_PP 5.

Execute Combined Settlement /FSBPR/SETTLE_RUN_PP 6.

Accrue/Defer Account Results RBCA_ACCRUE_RUN_PP 7.

Execute Accrual/Deferral of Master Contracts /FSBPR/ACCRUAL_RUN_PP


© 2010 SAP AG page 34/44

8. Set Posting Date for End-of-Day Processing RBCA_DATE_CLOSE_SET

9. Close Posting Day for General Ledger RBCA_GL_CLOSE_DAY

Effective Cash Pooling Process - FS-MCM


Effective Cash Pooling - Create PLM Documents

/FSECP/CREATE_PLM_DOC_PP

2. Activate PLM documents (for the ECP specific event types)

RBCA_DEH_RUN_PP_BCA_PLMACT

3. Set posting date for payment transaction RBCA_DATE_POST_SET

4. Execute Cash Pooling /FSECP/RUN_CASH_POOLING

5. Deactivate PLM documents (for the ECP specific event types)

RBCA_DEH_RUN_PP_BCA_PLMEND

6. Execute Account Settlement RBCA_SETTLE_RUN_PP

7. Set Posting Date for End-of-Day Processing RBCA_DATE_CLOSE_SET

8. Close Posting Day for General Ledger RBCA_GL_CLOSE_DAY

Overdraft Protection Process – FS-MCM

Seq# Report Description Report Name

Set posting date for payment transaction RBCA_DATE_POST_SET

Execute Overdraft Protection /FSODP/AL_MASSRUN_START

Execute Account Settlement RBCA_SETTLE_RUN_PP

Set Posting Date for End-of-Day Processing RBCA_DATE_CLOSE_SET

Close Posting Day for General Ledger RBCA_GL_CLOSE_DAY

Combined Statement – FS-AM / FS-MCM

Seq# Report Description Report Name


© 2010 SAP AG page 35/44

1. Set posting date for payment transaction RBCA_DATE_POST_SET

2. Create Combined Statement (FS-MCM part) RFSPL_CST_RUN_PP

3. Create Combined Statement (FS-AM part) RBCA_CST_RUN_PP

4.5 Dependent Locks

The dependencies of mass runs are reflected in the setup of the job chain. The job scheduling tool that controls the processing sequence of the job chain also monitors the return code of the runs. As explained above, mass runs can end with an application return code = 4 (ended with single errors). In this case, successor mass run(s) can be executed. From a business process point of view, it might make no sense to process an object, for example, an account, when it was not processed without errors by a predecessor run. For instance, if the settlement of an account was not successful, it makes no sense to create the bank statement for this account, because the settlement results will not be on the statement. Banking services from SAP provides a functionality to implement this behavior. The setup can be done in the IMG: Financial Services Account Management / Master Contract Management Tools Parallel Processing Maintain Locks of Other Application Types Relevant for Application Type.

Example Account Settlement Account Statement

Locks of Other Application Types Relevant for Application Type

The first entry means: If an account has been locked by the account settlement mass run because of an error, the statement for this account will not be produced. This entry only makes sense if the statement must include the results of the settlement of the same day.

Not all application types support locking.


© 2010 SAP AG page 36/44

4.6 Summary

During the setup of an end-of-day job chain, certain dependencies have to be considered. These dependencies can be:

Time-based (for example, time window for end-of-day processing) Date-based (for example, which date is relevant for processing or posting) Process-based (for example, logical processing sequence of end-of-day reports)

Some end-of-days reports set locks to certain business objects in case of processing errors. The locks can be used to prevent successor activities to process the locked object.


© 2010 SAP AG page 37/44

5 Appendix

5.1 List of End-Of-Day Reports

The following list of end-of-day reports is based on banking services from SAP 7.0. The reports can also be found in the IMG: Financial services Account Management / Master Contract Management End-of-Day Processing Define Job Nets. Select Usable reports within the maintenance view.

Report Name Description Application Component

/FSPD/RIPD_MASS_RUN_PP1 Execute Payment Distribution FS-AM

/FSPD/RIPD_MASS_RUN_PP2 Execute Automatic Postprocessing for Payment Distribution

FS-AM

R_BCA_PRI_PP_PACKAGE_CN Adapt Contract to Product Pricing List FS-AM

RBAPA_TOOLS_PP_BAPA_PCO1 Update of Priority of Account Orders FS-AM

RBAPA_TOOLS_PP_BAPA_PCO2 Automatic Processing: Resubmission of Posting Control Orders

FS-AM

RBAPA_TOOLS_PP_BAPA_PCO3 Automatic Processing: Final Processing of Posting Control Orders

FS-AM

RBCA_ACCRUE_RUN_PP FS-AM: Transfer Postings to General Ledger

FS-AM

RBCA_BACKDATED_CHANGES Select Accounts with Backdated Changes

FS-AM

RBCA_BANO_RUN_PP Start Balance Confirmation Mass Run FS-AM

RBCA_BAST_RUN_PP Start Bank Statement Mass Run FS-AM

RBCA_BL_AL_RUN_C_PP Correct Account Billing (Mass Run) FS-AM

RBCA_BL_AL_RUN_PP Execute Account Billing FS-AM

RBCA_BL_AL_RUN_REV_PP Reverse Account Billing FS-AM

RBCA_BSCHCK_RUN_PP FS-AM: Check Balance Sheet Preparation for General Ledger

FS-AM

RBCA_BSPREP_RUN_PP FS-AM: Balance Sheet Preparation GL FS-AM

RBCA_BSPRPR_RUN_PP FS-AM: Print Data of Balance Sheet Preparation

FS-AM


© 2010 SAP AG page 38/44


RBCA_CA_CRV_RUN_PP Mass Run: Credit Standing Check for Cards

FS-AM

RBCA_CA01_RUN_PP Renewal Run for Cards FS-AM

RBCA_CA02_RUN_PP Ordering File for Cards FS-AM

RBCA_CARD_CHANGE_MASTER_DATA Forward Master Data Change to Processor

FS-AM

RBCA_CARD_ORDER_ATTR_BCA_CA04 Process Confirmation from Provider Re. Order

FS-AM

RBCA_CCON_CREATE_PP_PACK Creation of Package Templates for The Cash Concentration Mass Run

FS-AM

RBCA_CCON_RUN_PACK_PP Mass Run for Cash Concentration with Package Template

FS-AM

RBCA_CCON_RUN_PP Mass Run for Cash Concentration Without Package Template

FS-AM

RBCA_CL_AC_CLOSE_RUN_PP Massrun for Clearing Account Closure FS-AM

RBCA_CLEARING_EXT_RUN_PP Clearing Payment Items with External Clearing Reference

FS-AM

RBCA_CLEARING_RUN_PP Clear Old Open Payment Items FS-AM

RBCA_CMPJOU_RUN_PP Print Report for Posting Journal FS-AM

RBCA_CN_BKK92_INSERT_PP Create Starting Point for Settlements FS-AM

RBCA_CN_PP_MASTER_RUN Account Master data : Extraction and Distribution Tool

FS-AM

RBCA_CNFW_EVENT_GEN_MASS_RUN Generic Mass run for Events FS-AM

RBCA_COPR_RUN_PP Start Mass Run - Correspondence Print FS-AM

RBCA_CRRV_RUN_PP Mass Run for Credit Standing Check for Accounts

FS-AM

RBCA_CST_RUN_PP Create Combined Statement FS-AM

RBCA_DATE_CLOSE_SET FS-AM: Set Posting Date for End-of-Day Processing

FS-AM

RBCA_DATE_POST_SET FS-AM: Set Posting Date for Payment Transactions

FS-AM


© 2010 SAP AG page 39/44


RBCA_DEBPOS_RUN_PP Debit position run FS-AM

RBCA_DEH_RUN_PP_BCA_PLMACT Activate PLM Documents FS-AM

RBCA_DEH_RUN_PP_BCA_PLMEND Close PLM Documents FS-AM

RBCA_DEH_RUN_PP_BCA_PLMEND2 Close PLM Documents Prematurely for Archiving

FS-AM

RBCA_DEH_RUN_PP_BCA_PLMWF Start PLM Documents Workflow FS-AM

RBCA_EXE_BP_RL_LIM Transfer Data for Checking Validity of Role

FS-AM

RBCA_FORD_RUN_PP Forward Order Execution FS-AM

RBCA_GL_CLOSE_DAY FS-AM: Close Posting Day for General Ledger

FS-AM

RBCA_INSMON_RUN_PP Monitor Installment Payments FS-AM

RBCA_INV_ANALYSIS FS-AM: Inventory of Evaluation and Legacy Data Transfer Runs

FS-AM

RBCA_INV_RUN_PP FS-AM: Start Inventory Run FS-AM

RBCA_INVA_RUN_PP FS-AM: Inventory Preparation for Legacy Data Transfer to GL

FS-AM

RBCA_INVPR_RUN_PP Print Result of Inventory FS-AM

RBCA_ITEM_EX_RUN_PP Distribute Item Data FS-AM

RBCA_LINK_CONSISTENCY Consistency Check for Link Table FS-AM

RBCA_OR_CCPP_CP_START Edit Mass Product Change (Card Pool) FS-AM

RBCA_OR_CCPP_PVCP_START Edit Optimized Mass Product Version Change (Card Pool)

FS-AM

RBCA_OR_CCPP_TEV_START Execute Due Product Changes (Card Pool)

FS-AM

RBCA_OR_CNCL_PP_BCA_BOCL Execute Due Cancellations FS-AM

RBCA_OR_COCP_CARD_STA_BCA_BOSC Edit Mass Product Change (Card) FS-AM

RBCA_OR_COCP_CARD_STA_BCA_PVCC Edit Optimized Mass Product Version Change (Card)

FS-AM

RBCA_OR_COCP_TEV_STAR_BCA_BODC Execute Due Product Changes (Card) FS-AM


© 2010 SAP AG page 40/44


RBCA_OR_COP_ACC_PACKG_BCA_BOCA Edit Mass Product Change (Account) with Package Template

FS-AM

RBCA_OR_COP_ACC_START_BCA_BOCA Edit Mass Product Change (Account) FS-AM

RBCA_OR_COP_ACC_START_BCA_PVCA Optimally Edit Mass Product Version Change (Account)

FS-AM

RBCA_OR_COP_TEV_START_BCA_BOCP Execute Due Product Changes (Account)

FS-AM

RBCA_OR_RESC_PP_BCA_BORS Execute Due Rescissions FS-AM

RBCA_OR_TOC_PP_START_BCA_BOTC Execute Due Account Closures FS-AM

RBCA_PAYF_RUN_PP Post Payoff Execution Charge FS-AM

RBCA_PAYMITEM_PROCESS_ENQ Process Payment Item from BCA_PAYMITEM_ENQ

FS-AM

RBCA_PO_RESEND_EXTERN Restart Payment Order (Transfer to PTS Again)

FS-AM

RBCA_PREPARE_PP_OBJV Formatting of Table BCA_BCT_CN_OBJV for BW Delta Upload

FS-AM

RBCA_RC_FTD_DUE Call Time Deposits FS-AM

RBCA_RC_FTD_DUECORR Create Notices of Maturity FS-AM

RBCA_RC_FTD_FIXING Fix Time Deposits FS-AM

RBCA_RC_IBS_ACT_EOT End Savings Scheme FS-AM

RBCA_RC_IBS_DUECOR_EOT Create Correspondence for End of Savings Scheme

FS-AM

RBCA_RC_IBS_DUECOR_SP Create Correspondence for End of Payment Phase

FS-AM

RBCA_RCN_COMP_CROSS Comparison: Completeness of Balance Sheet Preparation

FS-AM

RBCA_RCN_COMP_CROSS_GLOUT Comparison: Completeness of Balance Sheet Prep. W. Item Mgt Outgoings

FS-AM

RBCA_RCN_COMP_GLOUT_GLIN Comparison Item Mgt Outgoings to G/L with G/L Incomings

FS-AM


© 2010 SAP AG page 41/44


RBCA_RCN_COMP_SUMS_IN_CROSS Comparison between IM Incomings with Completeness of Bal. Sheet Prep.

FS-AM

RBCA_RENW_RUN_PP Mass Run for Renewal and Contract End Processing

FS-AM

RBCA_RREP_CREATE_PP_PACK FS-AM: Creation of Package Templates for Regulatory Reporting Run

FS-AM

RBCA_RREP_RUN_PACK_PP FS-AM: Start Regulatory Reporting Run with Package Template

FS-AM

RBCA_RREP_RUN_PP FS-AM: Start Regulatory Reporting Run

FS-AM

RBCA_SET_PRESENT_DATE Shift Present for Contract Processing Forward

FS-AM

RBCA_SETTLA_RUN_PP Execute Alternative Account Settlement FS-AM

RBCA_SETTLA_RUN_PP_CARD Execute Alternative Card Settlement FS-AM

RBCA_SETTLE_EX_RUN_PP Distribute Settlement Data FS-AM

RBCA_SETTLE_RUN_PP Execute Account Settlement FS-AM

RBCA_SETTLE_RUN_PP_CARD Execute Card and Card Pool Settlement

FS-AM

RBCA_SETTLP_RUN_PP Simulate Account Settlement in Settled Period

FS-AM

RBCA_SETTLR_RUN_PP Reverse Settlement FS-AM

RBCA_SNITEM_EX_RUN_PP Distribute Accrual/Deferral Data FS-AM

RBCA_SORD_RUN_PP Standing Order Execution FS-AM

RBCA_TBBWAN_RUN_PP Analysis Report for BW Delta Upload FS-AM

RBCA_TBBWPP_RUN_PP Formatting of Table BCA_BCT_CN_OBJV for BW Delta Upload

FS-AM

RBCA_TBBWPS_RUN_PP Delete BW Delta Upload Objects (Postprocessing)

FS-AM

RBCA_UPDPER_RUN_PP Edit Entries for Dissolved Contracts in FS-AM


© 2010 SAP AG page 42/44


BCA_CN_PER_ACBAL

RBCAGL01_Y FS-AM: Transfer Postings to General Ledger

FS-AM

R_PRI_PP_PACKAGE_BP Adapt Changes to BP Hierarchy FS-FND-PRI

/FSBPR/ACCRUAL_RUN_PP Execute Accrual/Deferral FS-MCM

/FSBPR/BDC_START_DETERMIN Determine Backdated Changes FS-MCM

/FSBPR/SETTLE_REVERSAL_RUN_PP Reverse Combined Settlement FS-MCM

/FSBPR/SETTLE_RUN_PP Execute Combined Settlement FS-MCM

/FSBPR/TRIGGER_ACC_SETTLE_PP Request Account Settlement Date FS-MCM

/FSECP/CREATE_PLM_DOC_PP Effective Cash Pooling - Create PLM Documents

FS-MCM

/FSECP/RUN_CASH_POOLING Execute Effective Cash Pooling FS-MCM

/FSFAC/AL_PP_CHECK Run Facility Checks FS-MCM

/FSFAC/AL_PP_EXTRACT Transfer Data to BI FS-MCM

/FSFAC/AL_PP_GLTRANSFER Open Credit Commitments for General Ledger Transfer

FS-MCM

/FSFAC/AL_PP_MONITOR Monitor Consistency FS-MCM

/FSFAC/AL_PP_REORG Reorganize Facility Data FS-MCM

/FSODP/AL_MASSRUN_START Execute Overdraft Protection FS-MCM

/FSPDM/PDM_CORRESPONDENCE Create Plan Statement FS-MCM

/FSPDM/RAMOUNT_CALC_PP Calculate Plan Key Figures FS-MCM

RBCA_MCCH_RUN_PP Check and Correct Participation Conditions

FS-MCM

RBCA_MCM_PP_MASTER_RUN Master Data: Extraction and Distribution Tool

FS-MCM

RBCA_OR_CMCP_START_PVC_RUN_PP Change Product Version for Master Contract

FS-MCM

RBCA_OR_TAP_PP_START_BCA_BOTP Terminate Due Master Contracts FS-MCM

RFSPL_CST_RUN_PP Create Combined Statement FS-MCM


© 2010 SAP AG page 43/44

5.2 Additional Information

The following table provides a list of sources where additional information about end-of-day processing and job scheduling can be found.

Link Description

http://service.sap.com/solutionmanagerbp

(select “Banking” as filter value for “SAP Solution”)

Banking Services best-practices documents

http://www.sdn.sap.com/irj/sdn/nw-scheduling The SAP Central Process Scheduling application by Redwood on the SAP Developer Network. The page includes also a link to the latest XBP documentation

http://service.sap.com/~sapidb/011000358700000671072009E

Exception Handling in Banking Services from a Solution Manager Point of View


Best Practices RFC Monitoring


Best Practices Job Scheduling Management


© 2010 SAP AG page 44/44

© Copyright 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 Incorporated in 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 Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of 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 by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer 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 other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks 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 document serves 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 form or 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 document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be 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 the information, 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 that may 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 may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.