SAP Note

Header Data

Symptom

This note contains a description of the new additional interpretation algorithms as of Release 3.0F for the electronic bank statement.

Other Terms

Interpretation algorithms, RFEBKA00, RFEBKA30

Reason and Prerequisites

Customer requests and so on.

Solution

The following list gives you an overview of the new interpretation algorithms that have been included step by step since Release 3.0F. This list thus completes the documentation. Please note that not all interpretation algorithms listed below are already available in Release 3.0F. 014 (Outgoing payment: payment order number) ============================================ Do not use this algorithm ! Use algorithm 029 instead. 015 (Clearing procedure: Selection using assignment) ==================================================== This algorithm enables a clearing of open items using an assignment number. If the corresponding posting rule entails a clearing then the selection is made in this instance using the assignment number. If no clearing is to be made, the bank reference (such as check number) is written as an assignment number in the line item of the payment on account posting. As a result, you can later clear automatically using the assignment number (for example by using Report SAPF123W). You need to be aware of the following limitations when using this algorithm: An automatic clearing with the assignment number can only be made if it is possible to determine the account to be cleared (from bank data for customers/vendors, or from the posting rule for G/L accounts). The field 'Bank reference' or 'Check number' from the bank statement is used for the selection by assignment number (if this has not been filled, the beginning of the note to payee is used). A check needs to be made as to whether this is the correct information for searching for open items on the account. Since the assignment number is a text field, you may find that the information in the bank statement is not formatted correctly. If you want to use the selection by assignment number even though the information is either not in the bank statement or is present in the incorrect format, you can fill the field 'Check number' (FEBEP-CHECT) via the Customer Function. This interpretation algorithm is contained in the standard system in Release 3.1I and as of Release 4.5A. In Releases 4.0A and 4.0B, you can implement it according to Note 96656. 023 ( Bank transfer method (Germany only) with reference numbers ) =========================================================== This method is also used with the Japanese ZENGINKYO format. 025 (Invoice list) ==================

    114713 - New interpretation algorithms as of Rel. 3.0F  

Version   36     Validity: 01/20/2003 - active   Language   English

Released On 01/20/2003 15:58:40

Release Status Released for Customer

Component TR-CM-CM Basic Functions

FI-BL-PT-BA bank statement

Priority Recommendations / Additional Info

Category Upgrade information

Other Components

This algorithm is used to determine the corresponding document numbers via an invoice list number supplied in the note to payee. To ensure a successful search for invoice list numbers in the application of funds, the same properties must be taken into account as for reference document numbers. Also see Note 107592. Specifically:

1. The invoice list number must be returned to the bank statement in exactly the same manner that it is stored in the system (i.e. in the documents). In particular, all leading zeroes must be retained.

2. When the bank statement is read, the reference number interval must be correctly maintained (especially those that are not empty).

Procedure: If invoices are transferred from SD into Accounting, the generated documents receive the original invoice number in field 'Reference document number' (XBLNR) in Accounting. Using this, clearing can be executed automatically using the electronic bank statement (algorithm 021). However, if an invoice list is generated, the affected documents are updated in Accounting. These then receive the invoice list number for the reference document number and can be selected using algorithm 025. 026 (Reference doc. no. - search with leading zeroes, if < 10) (BETA)) ====================================================================== The ten-character reference document numbers supplied by SD (for example) can only be found by algorithm 021 if they are also returned with ten characters in the bank statement, that is they must have leading zeros. If leading zeros are not returned, algorithm 026 can be used. This works in three steps: Initially the note to payee is scanned for possible reference document numbers as for algorithm 021 (number interval XBLNR in the selection screen for importing the bank statement). Unlike algorithm 021, leading zeros are also supplied to expand the number to ten characters (in the present version of the algorithm always to exactly ten characters.) A check is then carried out for reference document numbers present in the system. 027 (Reference number (TIT0)) ============================= Intended for the Finnish 'TITO' bank statement format. A search is made using the 'payment reference' supplied there. Up to Release 4.5B also refer to Note 128418. 028 (Reference number using MULTICASH conversion programs) ========================================================== As with algorithm '027', if conversion occurred in MultiCash first, meaning the bank statement files have been imported in MultiCash format. Up to Release 4.5B also refer to Note 128418. 029 (Payment order number) ========================== Document search using payment order number. As of Release 4.0A. Payment orders are an entity in the context of automatic payment transactions. A payment order is created if the payment is to be carried out (form is created, transfer order is sent to the bank by DME), but if the posting of the payment is not to be made until the payment is reported in the bank statement of the house bank. For payment order numbers returned in the bank statement, the number interval XBLNR is used. For algorithnm 029, note the following: Example: The number interval for payment orders is 1000000000 - 1999999999 (payment order intervals are always numeric). In this case, for the variant of Transaction FF.5 used (Import Electronic Bank Statement), the 'number interval XBLNR' must be entered as 'ZR1000000000 to ZR1999999999', that is using the scheme ZRXXXXXXXXXX (always using 10 digits XXXXXXXXXX). The number interval used in the filter ought not to be "larger", as the problems described in Note 107592 always apply. Moreover, you should not use "low" payment order numbers. In particular, the number range interval 00 (0000000001 - 0999999999) may cause problems in connection with low number levels (four digits or below): The reason for this is that the note to payee in the bank statement does not only contain the payment order number but often other numbers as well (e.g. four-digit years). This may cause problems with how these numbers are automatically distinguished from the payment order numbers. (Setting the number range via Transaction FBN2.) For more information refer to the 4.0A release notes under 'Payment orders'.

030 (Brazilian search) ====================== Algorithm 030 is employed if you use the electronic bank statement in Brazil. The search is made here using the document number, the fiscal year and the number of the line item within the accounting document. 031 (Document number search (customer number from document line)) ================================================================= This algorithm basically works like the normal document number search (algorithm 020). An additional feature here is the option of automatically adding the bank details to the master data, if the corresponding business partner can be identified via a document number found in the note to payee. This option is normally only possible for reference document number search 021. Since the respective business partner bank details are generally supplied with the bank statement, these details can be used here to add to the master data, using report RFEBKA80. However, please note in the case of an alternative payer, for example, that the bank details supplied in the bank statement are not those of the business partner to whom the document number previously found in the note to payee refers. In this case, the corresponding bank details would be added to the wrong business partner. Moreover, the interpretation algorithm 031 is important in connection with the automatic generation of payment advice notes when importing the bank account statement: Such a payment advice note is created if not all open items can be cleared immediately on importing, because, for instance, not all document numbers supplied in the note to payee have been found. However, in these cases the payment advice note contains the document numbers found and can be used following manual addition for posting the corresponding account statement item. It is conceivable that the individual document numbers or payment advice note items belong to different business partners (for example, payment through common payer). These items are only automatically assigned to the correct business partner in the payment advice note if interpretation algorithm 031 is used. When you use algorithm 021 the individual payment advice note items are in each case to be supplemented manually with the correct business partner information. 032 (EDI payment advice search) ==================== As of Release 4.5B. See Notes 119847 and 140613. Interpretation algorithm used to search for REMADV payment advices (credit-side or debit-side) already imported into the system per EDI (i.e. existing in the system at the time the bank statement is imported). Please note that on account posting is ALWAYS made for payment advices if settlement failed, independent of whether you stored an on-account posting key with the posting rules in customizing. It must be possible to identify the payment advices via unique reference numbers ( E1IDKU1-BGMREF ). If there are several sending business partners, the uniqueness of the numbers need be ensured by prior consultation (disjunct reference number ranges). The reference number need to be contained in the bank statement, and the sending business partner first states the reference number in his or her bank's payment order. For more information refer to Note 119847. 033 (First search for payment advice note, then standard search) ================================================================ As of Release 4.6C. This algorithm first searches the note to payee for an advice number of a payment advice note existing in the system (Tables AVIK, AVIP). Number range XBLNR is used for that purpose. If a payment advice is found, it is used as clearing information when posting with clearing. Please note that  - like with the algorithm 032 - posting is ALWAYS made on account for payment advices, if clearing has failed, independent of whether you stored an on-account posting key with the posting rules in customizing or not. If no payment advice is found, the standard algorithm is run (algorithm 001: Search for document number and reference document number). 034 (Finland: Reference number for payment order with RFFOFI_A) =============================================================== Please read Note 388705 for more information. 040 (Treasury: first standard, then loan search) ================================================ For R/3 Enterprise, this algorithm is replaced by BTE function module LOAN_EB_EVENT_00002810. Algorithm 040 can be employed if you are using TR-TM. Basically, algorithm 001 is executed here as the first step, that is, a document and reference document number search. If this is without success, a search is then made for TR documents for which a special TR Customer Function is used. If a search is to be made for TR documents, you should note that the Customer Function must not be activated as a default. This remains deactivated and will nevertheless be run for algorithm 040. 041 TR: First loan search, then standard ========================================

For R/3 Enterprise, this algorithm is replaced by BTE function module LOAN_EB_EVENT_00002810. This algorithm corresponds to algorithm 040, only with the sequence reversed.

Validity

This document is not restricted to a software component or software component version

References

This document refers to:

SAP Notes

This document is referenced by:

SAP Notes (10)

738807   RFEBBU10: Interpretation algorithm 26 clears too much

168110   FEBA:Pymt on a/c fm pymt adv.notes w/el.bank statmt

163707   Check for payment reference KID in Norway

140613   RFEBKA00: Error EDI paymnt advice determ.(Note 119847)

128418   RFEBBU10: Algorithms 27 / 28 do not work

119847   RFEBKA00:Search algorthm f.EDI paymnt advice notes

107592   RFEBKA00: using the reference document number

104342   Missing DME Reference for Payment Medium France

96656   Electronic bank statement: selection by allocation

82794   Bank statemt:Paymt adv.note dur.paymt several cust.

140613   RFEBKA00: Error EDI paymnt advice determ.(Note 119847)

128418   RFEBBU10: Algorithms 27 / 28 do not work

119847   RFEBKA00:Search algorthm f.EDI paymnt advice notes

168110   FEBA:Pymt on a/c fm pymt adv.notes w/el.bank statmt

107592   RFEBKA00: using the reference document number

104342   Missing DME Reference for Payment Medium France

96656   Electronic bank statement: selection by allocation

82794   Bank statemt:Paymt adv.note dur.paymt several cust.

163707   Check for payment reference KID in Norway

738807   RFEBBU10: Interpretation algorithm 26 clears too much