Description
The report RFEBKA30 creates postings for bank statements in the bankdata store. It is possible either to create batch input sessions ordirect postings for the update to general and special ledger accounts.
By specifying parameters, you can specify whether both sessions shouldbe created in one run or only the session for G/L accounting first. Thebatch input session names are generated by the report, in which caseyou can choose from two rules:

• House bank identification code and account identification code (for
example DREBA-GIRO)

• House bank identification code and account statement number (for
example DREBA-034)
The batch input session name for subsidiary ledger always starts with/.

Interpretation of the note to payee fields
For incoming payments, the notes to payee lines of the accountstatement can be searched either for document numbers or referencedocument numbers by specifying the selection field (BELNR or XBELNR).Thus, the relevant information for clearing customer payments isobtained.
If you do not specify a selection field, the note to payee fields arenot interpreted.
For outgoing payments, one always searches for the document number.
Via the length of the selection field and the corresponding numberrange, you can narrow down the search for document numbers or referencedocument numbers and, in this respect, accelerate processing: Values,which do not correspond to the predefined length and are outside thespecified number interval, are recognized by the report as beinginvalid and, consequently, are not used as clearing information.
An individual user exit can be programmed for a specific interpretationof the note-to-payee fields (feasible for insurance, for example).

Precondition
The report checks whether the business transaction codes (externaltransactions) used by the bank were allocated to an "internaltransaction" within the default settings. This is necessary because theupdate on the G/L accounts and the subsidiary accounts is carried outvia posting rules that are stored for an internal transaction.
If the report encounters an external transaction that is not maintainedin the corresponding table, the report aborts after having imported theaccount statement and outputs a list with the missing entries (errorlog).

Procedure
The missing entries must be maintained so that the update transactionscan be created in corresponding sessions. Then the report must berestarted. Please note here that the statement "x - importingdata" is not selected this time since the account statement isalready in the SAP System.
When the report is restarted, it searches in the buffer for all lineitems not yet characterized as updated in the respective posting area.A line item is regarded as updated only when a posting is put into asession.

Output
The audit trail gives you information, separated according to postingarea, on all postings put into the batch input session. In addition,the external business transaction codes and the internal transactionscontrolling the update are listed.
The processing statistics tells you


• How many postings

Were created per session
Could not be created due to an error

• For how many line items no postings could be created by definition