Ansicht
Dokumentation

/PF1/REPORT_EH_EXCEPTION_START - Start Report for Maintaining Routes and Clearing Agreements

/PF1/REPORT_EH_EXCEPTION_START - Start Report for Maintaining Routes and Clearing Agreements

BAL_S_LOG - Application Log: Log header data   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.
SAP E-Book

Purpose

Within advanced payment management, a distinction is made between Exception Handling response types for payment orders and response types for payment items. In order to be able to use response types, they must first of all be configured in the customizing of advanced payment management. Technically, response categories are provided that can be used by response types that are defined by the user. If all response types are defined on the basis of the response categories provided, master data can be created that determines, during the operation and on the basis of error indicators and other specified attributes, the response type that is to be used finally. In order to do this, rule sets must be created in the individual check phases for the individual business object categories (payment orders, ordering party items and recipient items).

The following response categories are available for payment orders:

  • Rejection
  • Transfer to postprocessing
  • Ignore error
  • Transfer to external foreign payment transactions system
  • Transfer to external authorization system

The following response categories are available for ordering party items (same as the response types for orders with one exception)

  • Rejection (payment order)
  • Transfer to postprocessing (payment order)
  • Ignore error (payment order)
  • Transfer to external foreign payment transactions system (payment order)
  • Transfer to external authorization system (payment order)
  • Exception: Reroute to a new transaction type

The following response types are available for recipient items:

  • Reroute with transfer posting (to ordering party)
  • Reroute to suspense account (CPD)
  • Reroute to another route
  • Ignore error
  • Reroute to a new transaction type
  • Execute automatic retry
  • Transfer to postprocessing

Integration

Prerequisites

Settings for Master Data

Master data should determine response types in the area of Exception Handling for errors that occur during processing. The determination of these response types takes place on the basis of a check phase concept, whereby a distinction is made between main processes, business object categories and check phases. For these check phases, it is configured on the system side on the development level which errors can be handled for which business objects and which phases. In addition, it is configured on the development level which response types are available for selection per phase. If a certain error occurs during processing, this is assigned to a certain Exception Handling check phase and can be handled there in accordance with the Exception Handling settings.

The determination of the response types for an error takes place on the basis of an error ID and attributes of the business object in question. For each phase, rules can be created that have a similar structure to the rules in route processing. If a search is being carried out in a phase for a suitable rule, the first appropriate rule is applied. If no suitable rule is found, the default response type for the corresponding phase and the corresponding business object is applied. If only one response type should be applied to all errors that occur in the phase, no rules must be created.

The following attributes are usually determined along with the response type:

  • Priority of the response type
  • Final response type
  • Correspondence required yes/no
  • Take repetitive errors into consideration yes/no

The priority of a response type is of significance if several errors occur at the same time for a business object in a check phase or if a recipient item is rerouted several times in succession.

The final response type is applied if the originally determined response type cannot be applied. With the exception of the response types Postprocessing and Ignore, the final response type is always defined with a response type.

If the attribute Correspondence Category is mapped to the response type, a business object "Correspondence" is created in Core. This is stored in the dataset DFKKCOH.

The attribute Take repetitive errors into consideration should prevent the same error from being handled several times with the same response type. If the same error occurs twice and should be handled with the same response type, this is displayed in the log but is automatically ignored by Exception Handling. For example, a customer-specific amount limit for the recipient item is exceeded and is handled with the response type Reroute to suspense account. The new item is reinserted into the SPT process at the beginning of Enrichment & Validation and the validation is carried out again. In doing so, the same error occurs, for which the same response type would be determined. If this is the case, then the error is automatically ignored.

Anomalies in the case of response types for ordering party items

If errors occur in ordering party items in advanced payment management, the same response types must usually be determined for these errors as for orders. This means that, for example, in the case of an erroneous bank code number of the ordering party item, the entire order should be rejected or transferred to postprocessing. As regards the check phase concept, this means that errors at the business object category Ordering party item have to be handled with a response type that is actually only intended for the business object category Order. In order to ensure this linking of the phases and the possible response types, dummy entries for the determined response type must be created for errors that should be handled on the order level.

As a consequence of these dummy orders, the corresponding error can now be handled in the phase "Processing ORP Item" at order level. In this phase, response types that are actually only valid for orders can now be determined for the errors.

The response types Ignore error and Reroute transaction type are exceptions: They can only be executed for the business object category Ordering party item, without being linked to the phase of the business object category Order.

Features

Selection

Standard Variants

Output

Activities

Example






CPI1466 during Backup   rdisp/max_wprun_time - Maximum work process run time  
This documentation is copyright by SAP AG.

Length: 8092 Date: 20240329 Time: 054257     sap01-206 ( 156 ms )