2163267 - Time-Out-Dump When Processing Payment Allocations

When processing automated bank statements, resulting payment allocations cannot be edited due to time-out-dumps which make a finalization or clearing impossible.

Besides internal thresholds with regard to the volume of processed transactions in allocations and clearings - also definitions conducive to an effective bank statement processing are discussed in this document.

SAP Business ByDesign.

You can access relevant payment allocation either in:

1. Go to Payment Management work center.
2. Navigate to the Payment Allocations view.
3. Select the relevant payment allocation.

or via the posted bank statement.

1. Go to the Liquidity Management work center.
2. Open the Bank Statements view.
3. Navigate to the relevant bank statement and edit.
4. Follow the Postprocessing required link to access the relevant payment allocation.
5. The payment allocation is in status In Preparation.

Upon editing between tabs, choosing the respective documents for allocation or saving modification (e.g. payment method) the screen will freeze and you are eventually experiencing a time-out-dump.

Several aspects can contribute to the described behavior.

• Crossing thresholds for processing number of transactions in Payment Allocations/Clearings
• Matching of External Transaction Code and Payment Method
• Query searching for open candidate payments

Crossing Thresholds for Processing Number of Transactions in Payment Allocations/Clearings

Allocating and clearing bank statement items can lead to exponential complexity when processed concurrently and crossing a threshold for open candidate transactions for allocation/clearing. For allocations/clearings such limits can be reached by ca. 300 (+/-) transactions. The following points consequently explore how to reduce the amount of data processed in larger payment allocations.

 Matching of External Transaction Code and Payment Method

One critical processing step can be simplified by a conducive matching of External Transaction Code and Payment Method. For the remainder of the document we focus on bigger single incoming payments to be allocated against payments created in the system.

Example:

In payment allocation XYZ the External Transaction Code in bank statement describes an Incoming Direct Debit (i.e. SEPA direct debit (collective posting)). This, however, is automatically translated as Incoming Bank Transfer in the allocation.

This signals an intention to allocate not against existing payments but receivables. Consequently an additional editing step in the payment allocation is required to  either switch to the Payment Confirmations/Returns and/or adjust the Payment Method under Allocation Details.

 Query Searching for Open Candidate Payments

Per default a query is run automatically in the background yielding all non-confirmed payments as possible candidates for allocation. The automatic execution upon editing an allocation is hard-coded in order to facilitate automatic bank statement processing.

Depending on the volume of open non-confirmed payments and on how this query is configured - the sheer data load can provoke a time-out dump.

Matching of External Transaction Code and Payment Method

In order to eliminate one processing step by matching External Transaction Code with suitable Payment Method proceed as follows:

1. Go to the Business Configuration work center and navigate to Fine Tuning.
2. Choose the Automatically Generated Bank Statements / Edit import formats for automatic generated bank statements activity.
3. Highlight the relevant Import Format (e.g. MT940 DE).
4. For the External Transaction Code representing direct debit (e.g. SEPA Direct Debit) , the Payment Method would have to be changed from Payment Processing - Of Incoming Bank Transfer to Payment Processing - Of Incoming Direct Debit.

For existing allocations try and modify the Payment Method. Via Actions: Create Proposal. Suitable open payments should then be proposed for allocation.

Due to the processed data amount this is not always possible and the underlying query producing the data volume has to be modified.

Query Searching for Open Payments

Customizing this query will lead to significant reduction of processed transactional data in a payment allocation and will therefore minimize the occurrences of time-out-dumps.

1. In Payment Allocation XYZ go to the Payment Confirmations/Returns tab.
2. Enter Advanced mode.
3. Select Organize Queries.
4. Deselect irrelevant Payment Methods. In case of severe time-out situations, blank all payment methods.
5. Press OK and leave the allocation. Refresh the work center and re-enter.

In some situations a time-out dump will prevent you being able to edit the allocation and therefore from customizing the query.

Workaround: Choose any payment allocation in status In Preparation representing a transaction containing fewer open payments (e.g. Outgoing Bank Transfer).

Once saved this query is strictly user-specific and will be applied for all (also existing) allocations edited by this user. Note that once the situation of time-outs is overcome and described definitions have been implemented the query should be progressively modified in order to facilitate an automated bank statement processing.

When large numbers of payments have to be processed it is advisable to conduct a frequent and timely processing of statements - since the sheer amount of existing payments causes the problem. This situation can occur for business processes where regular large single payments (e.g. Collective Posting of Incoming Direct Debit) represent a huge number of smaller payments (e.g. Incoming Direct Debit).

bank statement performance issue, Payment allocation performance issue. , KBA , performance , payment allocation , time out , AP-PAY , Payment Processing , How To