End of-day processing exception handling


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

End of-day processing exception handling

  1. 1. 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© 2010 SAP AG
  2. 2. Best-Practice DocumentEnd-of-Day Exception HandlingTable of Content1 Introduction ..................................................................................................................................... 4 1.1 About This Document 4 1.2 Customer Requirements 4 1.3 Staff and Skills Requirements 42 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 193 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 304 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 365 Appendix ......................................................................................................................................... 37 5.1 List of End-Of-Day Reports 37 5.2 Additional Information 43© 2010 SAP AG page 2/44
  3. 3. Best-Practice DocumentEnd-of-Day Exception HandlingTable of FiguresFigure 1: Master Contract Management and Account Management Running on One Instance ............ 8Figure 2: Master Contract Management and Account Management Running on Different Instances .... 8Figure 3: Error Within an Application Component .............................................................................. 10Figure 4: Error Outside the Initiating Application Component ............................................................. 12Figure 5: Screenshot ECH Customizing ............................................................................................ 13Figure 6: Error “in Between” Application Components ....................................................................... 14Figure 7: Setup of Direct and Sequential Repeats ............................................................................. 15Figure 8: Framework for Parallel Processing - Dynamic Model .......................................................... 16Figure 9: BANK_PP_MONITOR - Overview of Mass Runs ................................................................ 17Figure 10: BANK_PP_MONITOR – Packages ................................................................................... 17Figure 11: BANK_PP_MONITOR – Objects per Package .................................................................. 17Figure 12: External Run ID of a Mass Run ........................................................................................ 18Figure 13: SM37 Job Overview ......................................................................................................... 21Figure 14: Runtime View on Background Jobs .................................................................................. 21Figure 15: Example of a Job Chain Definition with Redwood ............................................................. 26Figure 16: Example of a Job Ended with Errors ................................................................................. 27Figure 17: Final Status Handlers ....................................................................................................... 28Figure 18: Return Code Mapping to Completed................................................................................. 28Figure 19: SLG1 Log......................................................................................................................... 29Figure 20: SM37 Job Log .................................................................................................................. 30Figure 21: Job Status in Redwood..................................................................................................... 30Figure 22: Locks of Other Application Types Relevant for Application Type ....................................... 35© 2010 SAP AG page 3/44
  4. 4. Best-Practice DocumentEnd-of-Day Exception Handling1 Introduction1.1 About This DocumentIn addition to the best-practice document, this document will provide more detailed information aboutexception handling within banking services from SAP. The main goal is to describe the different situationswhere 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 isimportant because—due to decoupling, scalability, and SOA enablement reasons—the kind ofcommunication between application components within banking services from SAP is new compared toTransactional 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 SAPpoint 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 dailybusiness.1.2 Customer RequirementsExperiences from customer projects show that missing knowledge about exception handling and systemmonitoring sometimes leads to many unhandled errors in the system. Unhandled errors may lead to customercomplaints (for example, if postings have not been performed) and unsatisfied customers. Depending on theerror, it might be even more difficult to fix the longer it exists in the system. Therefore, exception handling andmonitoring should be established as an essential part of the implementation project and daily operations. It isalso essential that knowledge transfer and handover take place between the project teams, for example, fromthe implementation team to the operations team and to the user departments. Responsibilities should beclear for the involved parties.1.3 Staff and Skills RequirementsThis document will provide the operations team with an idea of what to do in case of errors and will give theimplementation team more information about the system setup. The task of the operations team is to monitorthe 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, includingPostprocessing Office (PPO) and Posting Control Office (PCO), to enable the user department to monitor andfix errors.© 2010 SAP AG page 4/44
  5. 5. Best-Practice DocumentEnd-of-Day Exception HandlingDepending 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) Analyze and fix business-related User department orders errors. Analyze Posting Control Office Analyze and fix business-related User department (PCO) orders errors. Analyze technical errors Analyze and fix technical errors. Operations team (communication or system-related errors) via transaction SM37/SM58/ST22/SXMB_MONI/BA NK_PP_MONITOR Monitor job nets Fix and address errors. Operations team Set up system to run business Provide the necessary tools for Implementation processes, for example, PPO and analysis and monitoring to the team PCO operations team and the user department.© 2010 SAP AG page 5/44
  6. 6. Best-Practice DocumentEnd-of-Day Exception Handling2 Exception Handling During End-of-Day Processing2.1 IntroductionThe end-of-day process is an important task at a bank. End-of-day processing includes activities to close aday. These activities include, for example, settlement of accounts, creation of bank statements, andexecution of standing orders. Because many activities are necessary during end-of-day processing, it isimportant to optimize these activities to perform them within a given time frame. Errors may influence theprocessing time, so it is important to streamline the error-handling processes. Knowledge about exceptionhandling is therefore absolutely necessary.Planning end-of-day activities is an important task within the implementation and operation project (moreinformation can be found in the best-practice document SAP Banking Services / Deposit Management – Endof 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, forexample, due to technical reasons (system or database problems) or software-related reasons, processingerrors (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 thekind 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 becontinued and finished in time. The same is valid for runtime errors. If there is an exceptional situation thatleads 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 nextbusiness 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 processknowledge.2.2 Exception Handling OverviewThe most important tool for exception handling is the Postprocessing Office (PPO). Nearly all mass runs thatcan 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, businessprocess 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 ConflictHandler (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 6/44
  7. 7. Best-Practice DocumentEnd-of-Day Exception HandlingPPO order to “completed.” This type of PPO order is created, for example, by the account settlement andaccount statement mass runs.PPO orders created by the Error and Conflict Handler (ECH) are created for asynchronous messages forwhich an error occurred during processing. ECH PPO orders include all data provided by the initiatingprocess and, therefore, it is possible to repeat (manually or automatically) this specific process step out of thePPO once the error is analyzed and corrected. An example of a process that creates ECH PPO orders is theposting of payment orders or payment items created by combined settlement.Asynchronous communication is used, for example, by the Master Contract Management applicationsFacilities or Combined Settlement, which communicate with accounts located in the Account Managementcomponent. Another example is the communication between Account Management and FI-CA for loansprocesses.Within banking services from SAP, several application components, for example, Account Management andMaster Contract Management, are decoupled from each other. Decoupling the components makes it possibleto run them on different instances.Communication between the application components is either synchronous (for example, immediateresponse to a query) or asynchronous (either no response is expected or response can be sent at a latertime) and can be done using Remote Function Call or enterprise service, for example. In addition to thecommunication between application components within banking services from SAP, communication to otherSAP or non-SAP systems may be necessary, for example, to FI-CA or to a general ledger system, for someprocesses.The following diagrams show examples of the communication between different components via RFCchannel.© 2010 SAP AG page 7/44
  8. 8. Best-Practice DocumentEnd-of-Day Exception Handling Master Contract Management and Account Management Running on One Instance Master Contract Management and Account Management Running on Different Instances© 2010 SAP AG page 8/44
  9. 9. Best-Practice DocumentEnd-of-Day Exception Handling2.3 General Remark to Errors Within Mass ProcessingSeveral error situations can occur during the processing of a mass run. The errors can be categorized asfollows: - 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 ComponentNearly all mass runs in banking services from SAP create PPO orders in the case of errors. When an objectcannot be processed, for example due to business rules, a PPO order is created with relevant information toanalyze the error. The created PPO order is a “classical” order and is assigned to the application componentin which the error occurred.© 2010 SAP AG page 9/44
  10. 10. Best-Practice DocumentEnd-of-Day Exception Handling Error Within an Application ComponentAll error messages created by a mass run are also written to a log. You can display the mass run log eitherwith a specific application transaction or with transaction SLG1. It is recommended that you use the specificapplication transactions to display the log, because they may use a special logic, for example, with regard tosorting. 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 SetupBy default, the creation of “classical” PPO orders is deactivated. You have to activate the creation in IMG bychoosing Cross-Application Components General Application Functions Postprocessing OfficePostprocessing 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 10/44
  11. 11. Best-Practice DocumentEnd-of-Day Exception Handling 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 XYou can also find the relevant PPO activities in the IMG path of the application component:Financial Services Account Management or Master Contract Management Postprocessing OfficeBusiness 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 toassign responsibilities for specific business processes to specific users. For example, if there are specificusers who should take care of item-specific errors, these users can be assigned to an item worklist. Otherusers 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 ContractManagement Postprocessing Office Worklist.Once a worklist has been created, the PPO business processes can be assigned to it. Afterward, you canassign users to the worklist. You assign users to a worklist via the SAP Easy Access menu: FinancialServices Account Management / Master Contract Management Postprocessing Office WorklistChange Assignment.When a user starts a PPO transaction, for example, BCA_PPO2 with “Order Assignment” = 1, the user willonly 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 11/44
  12. 12. Best-Practice DocumentEnd-of-Day Exception Handling2.5 Errors Outside the Initiating Application ComponentIn banking services from SAP, processes communicate either synchronously or asynchronously with otherapplication components. Asynchronous communication means that the initiating process sends a message toanother application component without expecting any response to that message. After an asynchronousmessage is sent, the initiating process continues. The asynchronous message is processed in the otherapplication component. If there is an error during processing within the other component, the Error andConflict Handler (ECH) takes care of it. The ECH passes all relevant information (including the processingdata) to the PPO (default behavior). It is not necessary to activate PPO orders created by ECH. Banking Services from SAP Master Contract Management Account Management Application Application Component Component R Outbound Inbound Application Application Proxy Proxy ECH PPO Error Outside the Initiating Application ComponentPPO orders created by ECH provide more possibilities than classical PPO orders. For instance, ECH PPOorders can be reprocessed manually and/or automatically. Depending on the kind of error, automaticreprocessing 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 theend 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 12/44
  13. 13. Best-Practice DocumentEnd-of-Day Exception HandlingIn the IMG you can define, per component and business process, a resolution strategy for the ECH PPOorders. If nothing is defined in the IMG, the general default resolution strategy is applied. The defaultresolution 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 DefineResolution Strategy. Here is an example of how a resolution strategy might look: ECH CustomizingFor the business process MIF_BAC_0005, Actions for Participant Account for Combined Settlement, ECHorders are created in case of errors. The orders will be stored in the database because the Persistentcheckbox 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 bescheduled. 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 ordersautomatically. A user can also repeat the order manually out of the PPO. The confirmation mode is set to “0© 2010 SAP AG page 13/44
  14. 14. Best-Practice DocumentEnd-of-Day Exception HandlingNo Processing.” This means that it is not allowed to finish this PPO order. In the context of business processMIF_BAC_0005, this means that no positive confirmation (everything is okay) can be sent to the originalsender (in this case, the Master Contract Management component). The positive confirmation is only sentwhen 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 originalsender. This means that the sender has to make sure that the state before sending the message has to berestored. Discard is possible either automatically via report /SAPPO/RESUBMIT_ORDERS_2 or manually outof 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 ComponentsIn some cases, errors can also happen “in between” application components. This is the case if the initiatingprocess sent a message but the message did not arrive at the target application component. The problemcould be a communication error, for example, target system is not available, or the called function is faulty ornot available. Error “in Between” Application ComponentsFor 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 targetsystem cannot be reached because the connection is not active, report RSARFCSE is scheduledautomatically 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 theruntime errors in the target system with transaction ST22 to get more information about the error. Once the© 2010 SAP AG page 14/44
  15. 15. Best-Practice DocumentEnd-of-Day Exception Handlingerror 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 formonitoring 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 ProcessingTo avoid errors resulting from lock situations, you can define the number of parallel and sequential repeatsper application type in the Framework for Parallel Processing configuration (IMG: Financial ServicesAccount Management / Master Contract Management Tools Parallel Processing Maintain CustomerSettings for Application Types). Setup of Direct and Sequential RepeatsThe application itself makes the decision about the repeat behavior. The object can be repeated only if theapplication 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 (withthe same number of jobs defined for the run) after all packages have been processed once. If a sequentialrepeat is defined, all packages that include objects with a certain status are repeated in one singlebackground job after the parallel repeat(s).© 2010 SAP AG page 15/44
  16. 16. Best-Practice DocumentEnd-of-Day Exception Handling Parallel Processing Framework: Dynamic Model (simple scenario) Number of parallel jobs is defined by application type in IMG by customer IMG: Financial Services Account Management Tools Parallel Processing Maintain Job Distribution Build Packages write Job 2 read Fetch Package Package DB Table [package selected?] Job 1 Job n yes no Process Package read / write Objects in Work List DB [repeat?] (optional) Number of repeats defined via transaction bank_cus_pp/bank_cus_ppc Finalize Run per application type © SAP 2008 / Page 7 Framework for Parallel Processing – Dynamic Model2.8 Mass Run Monitoring with Transaction BANK_PP_MONITORTransaction BANK_PP_MONITOR can support you in analyzing erroneous mass runs. If a mass run endswith errors, the information about the mass run is stored by the Framework for Parallel Processing. Withtransaction BANK_PP_MONITOR you can, for example, see the number of created and processed packagesof the mass run. You can also see the status of each object within a package.© 2010 SAP AG page 16/44
  17. 17. Best-Practice DocumentEnd-of-Day Exception Handling BANK_PP_MONITOR – Overview of Mass RunsDouble-click on a line to get detailed information about the package processing. BANK_PP_MONITOR – PackagesSelect a package and choose the Single Objects button to get a list objects processed within this packageand the status for each object. BANK_PP_MONITOR – Objects per Package© 2010 SAP AG page 17/44
  18. 18. Best-Practice DocumentEnd-of-Day Exception HandlingYou can also use this transaction to monitor the processing status during an active mass run. Navigate to thepackages to find out how many packages have already been processed and how many packages still havean 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 IDIf a mass run ends with a return code <> 0, the run can be repeated after the causing error is solved. If abanking service from SAP mass run provides the field External Run ID on the selection screen, it is possibleto repeat the run with the external run ID of the original run. External Run ID of a Mass RunThe advantage of repeating the external run ID of the original run is that the run is repeated with exactly thesame input parameters of the selection screen, and the due objects do not need to be selected again by theapplication (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 theFramework for Parallel Processing (PPF). During the repeat of the run, the stored objects are selected by thePPF and re-processed. If a mass run provides the external run ID, a run should be repeated with the originalrun 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, theapplication will select and process the due objects again.© 2010 SAP AG page 18/44
  19. 19. Best-Practice DocumentEnd-of-Day Exception Handling2.10 SummaryAlthough 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-dayprocessing.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 See in the SAP Easy Access Menu, for example, Financial log transactions 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 19/44
  20. 20. Best-Practice DocumentEnd-of-Day Exception Handling3 Return Code Handling3.1 IntroductionBanking services from SAP mass runs that are used in the end-of-day processing sometimes havedependencies between each other, for example, the creation of a bank statement should be done after thesettlement, because the settlement results should also be visible on the bank statement. Thesedependencies have to be considered during the setup of the end-of-day job chain. A static view on the jobchain should reflect these dependencies for example, by defining successor job(s). During runtime, adynamic component has to be considered, too. This dynamic component is the status of a job. But not onlythe technical status of a job is relevant, but also an application-related return code. It could be that technicallya job has ended without errors, but from an application point of view there might be errors. An external jobscheduling 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 JobEnd-of-day mass runs are usually executed in background. The corresponding background job can have oneof 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 problemsThe status of the background job can be seen in the job overview (transaction SM37).© 2010 SAP AG page 20/44
  21. 21. Best-Practice DocumentEnd-of-Day Exception HandlingFor banking services mass runs using the Framework for Parallel Processing you will find one start job andmultiple main and end jobs in the job overview. Only the status of the start job is relevant for the jobscheduling tool. SM37 Job Overview 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 Start Job START_REPORT Parent Process DEMO Job 01 E:DEMO Job 01 Main Job Process DEMO Job 02 E:DEMO Job 02 Data DEMO Job 03 E:DEMO Job 03 Child Process End Job © SAP 2008 / Page 8 Runtime View on Background Jobs© 2010 SAP AG page 21/44
  22. 22. Best-Practice DocumentEnd-of-Day Exception Handling3.3 Application Return CodeIn addition to the technical return code, an application-related return code at the end of a batch job with thefollowing values is provided by banking services mass runs: Return Description Code 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 andsuccessful processed objects. In the IMG activity Financial Services Account Management End-of-DayProcessing Define Return for Mass Runs, you can set a relation between due and successfully processedobjects 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, continuationpossible” (return code = 4).In addition to the maximum percentage, you can also specify an absolute maximum. In this case, the smallerof the two values is relevant on the highest permitted number of incorrect objects. If the percentage or thehighest permitted number is exceeded, the application related return code is set to 8, which meansterminated.© 2010 SAP AG page 22/44
  23. 23. Best-Practice DocumentEnd-of-Day Exception HandlingHere 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 Upper Limit Limit Individual Absolute Counter Relation Error % 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 ToolThe application return code is transferred to the background job and stored together with other jobinformation. This is done in the business transaction event (BTE) 0BANK015. The standard function modulethat is called at the end of a banking services mass run is STD_PROCESS_0BANK015. The function modulecalls 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 statuswith the BAPI BAPI_XBP_GET_APPLICATION_RC.The technical job status is provided in the exporting parameter STATUS. The value in field STATUS can bemapped 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 23/44
  24. 24. Best-Practice DocumentEnd-of-Day Exception HandlingThe 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 jobscheduling tool has to decide if the successor job can be started or not, for example, if the application returncode = 4 and the technical job status = F (finished), the successor job can be started. Therefore the externaljob scheduling tool has to be able to interpret the two return codes correctly. Example Technical Job Application Result in the job Possible reactions of Status return code control tool the job control tool F = finished 0 – Completed OK Start next job(s) successfully 2 – Ended with a OK Start next job(s) warning 4 – Completed OK Start next job(s) with individual With the possibility to errors 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 NOK - stop Restart this job or start successfully next job(s) after analysis of the error 2 – Ended with a NOK - stop Restart this job or start warning next job(s) after analysis of the error 4 – Completed NOK - stop Restart this job or start with individual next job(s) after analysis errors of the error 8 – Terminated NOK - stop Restart this job or start next job(s) after analysis of the error© 2010 SAP AG page 24/44
  25. 25. Best-Practice DocumentEnd-of-Day Exception Handling© 2010 SAP AG page 25/44
  26. 26. Best-Practice DocumentEnd-of-Day Exception Handling3.5 External Job Scheduling Example: Return Code Handling with Central Process Scheduling by Redwood for SAP NetWeaverThe SAP Central Process Scheduling application by Redwood for SAP NetWeaver is able to handle returncodes, the technical job status, and the application-related return code. The job status and the applicationreturn code influence the processing behavior of the whole job chain. To understand the processing behaviorof 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 SchedulingA job chain consists of n steps. Once a step is processed successfully, the next step is processed. A stepconsists of m jobs. A step is processed successfully if all jobs within the step are processed successfully. Alljobs within a step are processed in parallel. A job chain is finished successfully if all steps are completedsuccessfully.© 2010 SAP AG page 26/44
  27. 27. Best-Practice DocumentEnd-of-Day Exception HandlingSo the overall status of a job chain is derived from the status of the single steps within the job chain. Thestatus 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-specificreturn 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 27/44
  28. 28. Best-Practice DocumentEnd-of-Day Exception HandlingFor the application return code = 4, the overall job status “Error” is derived. The status of the step and the jobchain 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 thetechnical job status is “Finished,” the job chain can be continued. SAP CPS offers several possibilities toreact on errors. One possibility is to use so-called “Status Handlers” on step level. Final Status HandlersOn step level you can define what to do in case of errors. The final status handler “On Error” can be used todefine what do to. If you are sure that no critical reports are included in this step you can set, for example, theaction “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 28/44
  29. 29. Best-Practice DocumentEnd-of-Day Exception HandlingWith the above setting, mass runs that end with an application return code 0, 2, or 4 will end with an overallstatus “Completed” (assuming the technical job status is “Finished”). So if all jobs within a step end withapplication return code 0, 2, or 4, the overall status of the step will be “Completed” and the next step cancontinue.3.6 Simple Test Case to Verify If a Job Scheduling Tool can Handle Both Return CodesTo 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 29/44
  30. 30. Best-Practice DocumentEnd-of-Day Exception Handling 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 30/44
  31. 31. Best-Practice DocumentEnd-of-Day Exception Handling4 Dependencies Within an End-of-Day Job Chain4.1 IntroductionThe following section provides an overview of dependencies that should be considered during the setup of anend-of-day job chain. In context with exception handling, it is important to know these dependencies, becausein case of errors during the end-of-day processing it can be assessed how critical this error is for the wholejob chain.Besides the dependencies mentioned here, there may be also other organizational or technical dependenciesthat should also be taken into account.4.2 Time-Based DependenciesThe end-of-day processing should take place within a certain time window. For instance, the end-of-dayprocessing cannot start before the bank has physically closed its doors and, of course, the processing shouldbe 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, forexample, enough background work processes.4.3 Date-Based DependenciesOne question to be considered during the setup of an end-of-day job chain is: “What should be processed orposted with which date?”At the end of the day the bank needs a basis for calculating interests or “counting” the money of the accountsand reconciling against the general ledger. But due to the fact that nowadays a bank is “open” for customers24/7, there is a need to handle postings that are performed during the end-of-day processing hours of thebank. 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 ofthe bank with a slight shift in times. So a day at the bank may end earlier than the real day. The step ofclosing 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 31/44
  32. 32. Best-Practice DocumentEnd-of-Day Exception Handling 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 DependenciesBusiness 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 tobe reflected in the end-of-day job chain.The following examples will point out important dependencies. The examples do not contain all reports thatcan be used in the end-of-day processing. Furthermore it is not mentioned in which time intervals the massruns 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 32/44
  33. 33. Best-Practice DocumentEnd-of-Day Exception Handling 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 RBCA_SORD_RUN_PP amounts) 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 Seq# Report Description Report Name 1. 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 33/44
  34. 34. Best-Practice DocumentEnd-of-Day Exception Handling 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 Seq# Report Description Report Name 1. Effective Cash Pooling - Create PLM /FSECP/CREATE_PLM_DOC_PP Documents 2. Activate PLM documents (for the ECP specific RBCA_DEH_RUN_PP_BCA_PLMACT event types) 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 RBCA_DEH_RUN_PP_BCA_PLMEND specific event types) 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 34/44
  35. 35. Best-Practice DocumentEnd-of-Day Exception Handling 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_PP4.5 Dependent LocksThe dependencies of mass runs are reflected in the setup of the job chain. The job scheduling tool thatcontrols the processing sequence of the job chain also monitors the return code of the runs. As explainedabove, 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 toprocess 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 bankstatement for this account, because the settlement results will not be on the statement. Banking services fromSAP provides a functionality to implement this behavior. The setup can be done in the IMG: FinancialServices Account Management / Master Contract Management Tools Parallel ProcessingMaintain 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 35/44
  36. 36. Best-Practice DocumentEnd-of-Day Exception Handling4.6 SummaryDuring the setup of an end-of-day job chain, certain dependencies have to be considered. Thesedependencies 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 beused to prevent successor activities to process the locked object.© 2010 SAP AG page 36/44
  37. 37. Best-Practice DocumentEnd-of-Day Exception Handling5 Appendix5.1 List of End-Of-Day ReportsThe following list of end-of-day reports is based on banking services from SAP 7.0. The reports can also befound in the IMG: Financial services Account Management / Master Contract Management End-of-DayProcessing 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 FS-AM Payment DistributionR_BCA_PRI_PP_PACKAGE_CN Adapt Contract to Product Pricing List FS-AMRBAPA_TOOLS_PP_BAPA_PCO1 Update of Priority of Account Orders FS-AMRBAPA_TOOLS_PP_BAPA_PCO2 Automatic Processing: Resubmission FS-AM of Posting Control OrdersRBAPA_TOOLS_PP_BAPA_PCO3 Automatic Processing: Final FS-AM Processing of Posting Control OrdersRBCA_ACCRUE_RUN_PP FS-AM: Transfer Postings to General FS-AM LedgerRBCA_BACKDATED_CHANGES Select Accounts with Backdated FS-AM ChangesRBCA_BANO_RUN_PP Start Balance Confirmation Mass Run FS-AMRBCA_BAST_RUN_PP Start Bank Statement Mass Run FS-AMRBCA_BL_AL_RUN_C_PP Correct Account Billing (Mass Run) FS-AMRBCA_BL_AL_RUN_PP Execute Account Billing FS-AMRBCA_BL_AL_RUN_REV_PP Reverse Account Billing FS-AMRBCA_BSCHCK_RUN_PP FS-AM: Check Balance Sheet FS-AM Preparation for General LedgerRBCA_BSPREP_RUN_PP FS-AM: Balance Sheet Preparation GL FS-AMRBCA_BSPRPR_RUN_PP FS-AM: Print Data of Balance Sheet FS-AM Preparation© 2010 SAP AG page 37/44
  38. 38. Best-Practice DocumentEnd-of-Day Exception HandlingReport Name Description Application ComponentRBCA_CA_CRV_RUN_PP Mass Run: Credit Standing Check for FS-AM CardsRBCA_CA01_RUN_PP Renewal Run for Cards FS-AMRBCA_CA02_RUN_PP Ordering File for Cards FS-AMRBCA_CARD_CHANGE_MASTER_DATA Forward Master Data Change to FS-AM ProcessorRBCA_CARD_ORDER_ATTR_BCA_CA04 Process Confirmation from Provider FS-AM Re. OrderRBCA_CCON_CREATE_PP_PACK Creation of Package Templates for The FS-AM Cash Concentration Mass RunRBCA_CCON_RUN_PACK_PP Mass Run for Cash Concentration with FS-AM Package TemplateRBCA_CCON_RUN_PP Mass Run for Cash Concentration FS-AM Without Package TemplateRBCA_CL_AC_CLOSE_RUN_PP Massrun for Clearing Account Closure FS-AMRBCA_CLEARING_EXT_RUN_PP Clearing Payment Items with External FS-AM Clearing ReferenceRBCA_CLEARING_RUN_PP Clear Old Open Payment Items FS-AMRBCA_CMPJOU_RUN_PP Print Report for Posting Journal FS-AMRBCA_CN_BKK92_INSERT_PP Create Starting Point for Settlements FS-AMRBCA_CN_PP_MASTER_RUN Account Master data : Extraction and FS-AM Distribution ToolRBCA_CNFW_EVENT_GEN_MASS_RUN Generic Mass run for Events FS-AMRBCA_COPR_RUN_PP Start Mass Run - Correspondence Print FS-AMRBCA_CRRV_RUN_PP Mass Run for Credit Standing Check FS-AM for AccountsRBCA_CST_RUN_PP Create Combined Statement FS-AMRBCA_DATE_CLOSE_SET FS-AM: Set Posting Date for End-of- FS-AM Day ProcessingRBCA_DATE_POST_SET FS-AM: Set Posting Date for Payment FS-AM Transactions© 2010 SAP AG page 38/44
  39. 39. Best-Practice DocumentEnd-of-Day Exception HandlingReport Name Description Application ComponentRBCA_DEBPOS_RUN_PP Debit position run FS-AMRBCA_DEH_RUN_PP_BCA_PLMACT Activate PLM Documents FS-AMRBCA_DEH_RUN_PP_BCA_PLMEND Close PLM Documents FS-AMRBCA_DEH_RUN_PP_BCA_PLMEND2 Close PLM Documents Prematurely for FS-AM ArchivingRBCA_DEH_RUN_PP_BCA_PLMWF Start PLM Documents Workflow FS-AMRBCA_EXE_BP_RL_LIM Transfer Data for Checking Validity of FS-AM RoleRBCA_FORD_RUN_PP Forward Order Execution FS-AMRBCA_GL_CLOSE_DAY FS-AM: Close Posting Day for General FS-AM LedgerRBCA_INSMON_RUN_PP Monitor Installment Payments FS-AMRBCA_INV_ANALYSIS FS-AM: Inventory of Evaluation and FS-AM Legacy Data Transfer RunsRBCA_INV_RUN_PP FS-AM: Start Inventory Run FS-AMRBCA_INVA_RUN_PP FS-AM: Inventory Preparation for FS-AM Legacy Data Transfer to GLRBCA_INVPR_RUN_PP Print Result of Inventory FS-AMRBCA_ITEM_EX_RUN_PP Distribute Item Data FS-AMRBCA_LINK_CONSISTENCY Consistency Check for Link Table FS-AMRBCA_OR_CCPP_CP_START Edit Mass Product Change (Card Pool) FS-AMRBCA_OR_CCPP_PVCP_START Edit Optimized Mass Product Version FS-AM Change (Card Pool)RBCA_OR_CCPP_TEV_START Execute Due Product Changes (Card FS-AM Pool)RBCA_OR_CNCL_PP_BCA_BOCL Execute Due Cancellations FS-AMRBCA_OR_COCP_CARD_STA_BCA_BOSC Edit Mass Product Change (Card) FS-AMRBCA_OR_COCP_CARD_STA_BCA_PVCC Edit Optimized Mass Product Version FS-AM Change (Card)RBCA_OR_COCP_TEV_STAR_BCA_BODC Execute Due Product Changes (Card) FS-AM© 2010 SAP AG page 39/44
  40. 40. Best-Practice DocumentEnd-of-Day Exception HandlingReport Name Description Application ComponentRBCA_OR_COP_ACC_PACKG_BCA_BOCA Edit Mass Product Change (Account) FS-AM with Package TemplateRBCA_OR_COP_ACC_START_BCA_BOCA Edit Mass Product Change (Account) FS-AMRBCA_OR_COP_ACC_START_BCA_PVCA Optimally Edit Mass Product Version FS-AM Change (Account)RBCA_OR_COP_TEV_START_BCA_BOCP Execute Due Product Changes FS-AM (Account)RBCA_OR_RESC_PP_BCA_BORS Execute Due Rescissions FS-AMRBCA_OR_TOC_PP_START_BCA_BOTC Execute Due Account Closures FS-AMRBCA_PAYF_RUN_PP Post Payoff Execution Charge FS-AMRBCA_PAYMITEM_PROCESS_ENQ Process Payment Item from FS-AM BCA_PAYMITEM_ENQRBCA_PO_RESEND_EXTERN Restart Payment Order (Transfer to FS-AM PTS Again)RBCA_PREPARE_PP_OBJV Formatting of Table FS-AM BCA_BCT_CN_OBJV for BW Delta UploadRBCA_RC_FTD_DUE Call Time Deposits FS-AMRBCA_RC_FTD_DUECORR Create Notices of Maturity FS-AMRBCA_RC_FTD_FIXING Fix Time Deposits FS-AMRBCA_RC_IBS_ACT_EOT End Savings Scheme FS-AMRBCA_RC_IBS_DUECOR_EOT Create Correspondence for End of FS-AM Savings SchemeRBCA_RC_IBS_DUECOR_SP Create Correspondence for End of FS-AM Payment PhaseRBCA_RCN_COMP_CROSS Comparison: Completeness of Balance FS-AM Sheet PreparationRBCA_RCN_COMP_CROSS_GLOUT Comparison: Completeness of Balance FS-AM Sheet Prep. W. Item Mgt OutgoingsRBCA_RCN_COMP_GLOUT_GLIN Comparison Item Mgt Outgoings to G/L FS-AM with G/L Incomings© 2010 SAP AG page 40/44
  41. 41. Best-Practice DocumentEnd-of-Day Exception HandlingReport Name Description Application ComponentRBCA_RCN_COMP_SUMS_IN_CROSS Comparison between IM Incomings FS-AM with Completeness of Bal. Sheet Prep.RBCA_RENW_RUN_PP Mass Run for Renewal and Contract FS-AM End ProcessingRBCA_RREP_CREATE_PP_PACK FS-AM: Creation of Package FS-AM Templates for Regulatory Reporting RunRBCA_RREP_RUN_PACK_PP FS-AM: Start Regulatory Reporting FS-AM Run with Package TemplateRBCA_RREP_RUN_PP FS-AM: Start Regulatory Reporting FS-AM RunRBCA_SET_PRESENT_DATE Shift Present for Contract Processing FS-AM ForwardRBCA_SETTLA_RUN_PP Execute Alternative Account Settlement FS-AMRBCA_SETTLA_RUN_PP_CARD Execute Alternative Card Settlement FS-AMRBCA_SETTLE_EX_RUN_PP Distribute Settlement Data FS-AMRBCA_SETTLE_RUN_PP Execute Account Settlement FS-AMRBCA_SETTLE_RUN_PP_CARD Execute Card and Card Pool FS-AM SettlementRBCA_SETTLP_RUN_PP Simulate Account Settlement in Settled FS-AM PeriodRBCA_SETTLR_RUN_PP Reverse Settlement FS-AMRBCA_SNITEM_EX_RUN_PP Distribute Accrual/Deferral Data FS-AMRBCA_SORD_RUN_PP Standing Order Execution FS-AMRBCA_TBBWAN_RUN_PP Analysis Report for BW Delta Upload FS-AMRBCA_TBBWPP_RUN_PP Formatting of Table FS-AM BCA_BCT_CN_OBJV for BW Delta UploadRBCA_TBBWPS_RUN_PP Delete BW Delta Upload Objects FS-AM (Postprocessing)RBCA_UPDPER_RUN_PP Edit Entries for Dissolved Contracts in FS-AM© 2010 SAP AG page 41/44
  42. 42. Best-Practice DocumentEnd-of-Day Exception HandlingReport Name Description Application Component BCA_CN_PER_ACBALRBCAGL01_Y FS-AM: Transfer Postings to General FS-AM LedgerR_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 FS-MCM Documents/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 FS-MCM Ledger Transfer/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-MCMRBCA_MCCH_RUN_PP Check and Correct Participation FS-MCM ConditionsRBCA_MCM_PP_MASTER_RUN Master Data: Extraction and FS-MCM Distribution ToolRBCA_OR_CMCP_START_PVC_RUN_PP Change Product Version for Master FS-MCM ContractRBCA_OR_TAP_PP_START_BCA_BOTP Terminate Due Master Contracts FS-MCMRFSPL_CST_RUN_PP Create Combined Statement FS-MCM© 2010 SAP AG page 42/44
  43. 43. Best-Practice DocumentEnd-of-Day Exception Handling5.2 Additional InformationThe following table provides a list of sources where additional information about end-of-day processing andjob scheduling can be found. Link Description http://service.sap.com/solutionmanagerbp Banking Services best-practices documents (select “Banking” as filter value for “SAP Solution”) The SAP Central Process Scheduling http://www.sdn.sap.com/irj/sdn/nw-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/01100035870000 Exception Handling in Banking Services from a 0671072009E Solution Manager Point of View http://service.sap.com/~sapidb/01100035870000 Best Practices RFC Monitoring 0491282008E Best Practices Job Scheduling Management http://service.sap.com/~sapidb/01100035870000 1250602005E© 2010 SAP AG page 43/44
  44. 44. Best-Practice DocumentEnd-of-Day Exception Handling© 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 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, MassachusettsInstitute 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 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 provideany warranty whatsoever relating to third-party Web pages.© 2010 SAP AG page 44/44