Whereas account statements were previously retrieved from the house bank using ordinary telecommunications, you can now use Electronic Data Interchange (EDI). This means that account statement information is transferred to the system automatically, from where it can then be processed. For information on the EDI interface in the SAP R/3 System, refer to the IDoc Interface for EDI documentation.

The account statement consists of two levels of information. The totals level identifies the house bank account and gives details of the current account balance. The transaction level logs the transactions processed in the bank account. The transactions can be described in more detail using messages (debit/credit display). In cases where you have done these, the account statement contains only a reference to the relevant messages.

Account statement processing using EDI takes place in three stages: Data is automatically imported into the system where it is stored in the bank data storage or in the payment advice database. You then schedule report program RFEBKA30 which generates the postings that follow from the account statement. For more information, read the program documentation. You can process the account statement using transaction FEBA (Bank Statement Subsequent Processing)

The account statement query (Polling Information) is a special type of account statement. In this case no transaction figures are transmitted. The information is stored in a separate area in the bank data storage. Payment advice notes from cash management and forecast are generated, not however any postings. You can use report program RFEBPI20 for further processing. For more information, read the program documentation.

The payee’s bank sends an account statement as an EDI message (example: FINSTA in EDIFACT standard) to your customer. The customer’s EDI subsystem generates an interim document from the EDI message (in the example, IDOC type FINSTA01, logical message FINSTA) which is passed on to the SAP R/3 System. Further processing of this interim document is controlled by the process code in the partner profile.

During processing, data is transferred from the interim document to the SAP data store for the account statement and payment memos. The system evaluates Customizing and the Customizing data (postings rules, company code, house bank account data, and so on) is added to the account statement. The system then searches for the debit and credit displays referenced in the statement and enters the relevant key from the payment advice database in the statement. The system uses the information contained in the payment advice notes to clear payments. The payment advice notes may also contain the document number and any other criterion you need. If the credit memo or debit display does not include any detailed information (no payment advice note items), the data is transferred to the account statement item and the advice note deleted. If no errors occur, inbox processing ends with update of the bank data storage. You must then use program RFEBKA30 (see above) to generate the resulting postings.

As ISO codes are transmitted using EDI, the tables for converting SAP codes into ISO codes for currencies, quantity units, and countries must be fully maintained.

For more information, read the documentation for the following steps in the Global Settings Implementation Guide (IMG):

• Define countries

• Check currency codes

• Check units of measure

Account statements entered using EDI are a form of electronic account statement. This means you must maintain the Customizing tables for the electronic account statement.
When you use the account statement to find out the account balance (Polling Statement), you must enter a planning type for the process category in the bank assignment. The system then generates cash management and forecast payment advice notes automatically.

In the event of an error, the system initiates the standard workflow task FINSTA_ERROR. Ensure that an administrator is defined in the basic data for the task, so that he or she can then be automatically notified in the event of an error. You maintain tasks using transaction PFTC.

There are clearly defined interfaces which you can use to read or change the dataset when processing the interim document. To this end, the system supports a number of customer functions which are accessed at particular points during processing.
The function modules are stored in enhancement "FEDI0005".

The following customer functions are accessed during processing of type FINSTA01 interim documents; you can use the functions to create your own modifications:

1. Saving an account statement – function module "201":
   The system accesses function module 201 immediately before writing the data for a account statement. For detailed information, read the documentation on function module EXIT_SAPLIEDP_201 in enhancement FEDI0005.
   
2. Dynamic access
   You can also access the dataset when writing individual segments. You must first define the segments for which such access is to be made.
   To this end, maintain table FEDICUS as appropriate.
   The system then accesses function module 202 during processing of each of the segments you specify in the table.

You require an EDI subsystem on an EDI server.

Within a test system, you can change any IDoc data you want. You require the following authorization for this:

Object: S_'IDOCMONI'
Activity: '02'

The system logs all the changes made to an IDoc. To ensure that the subsystem actually processes the original data for a payment IDoc, you can, within a productive system, assign authorizations for exception cases only and for limited periods.

The EDI Interface Enhancement Concept enables you to add further segments (for example, for industry-specific or customer-specific data) to existing IDoc structures. These must be supplied by the converter as appropriate.