Ansicht
Dokumentation

Bank Statement After Legacy Data Transfer ( RELNBANK_402_BKK_KTOAUSZ )

Fill RESBD Structure from EBP Component Structure   ABAP Short Reference  
This documentation is copyright by SAP AG.

Short text

Bank Statement After Legacy Data Transfer

Description

Bank customers are informed about account activities/turnovers and balances with bank statements. Even when you change systems, the bank statements in the new system should be consecutively numbered.

To facilitate a smooth transition from the legacy system to the Bank Customer Accounts system, as of release 4.02 A, the following procedure applies:

1. Ensure that before the go-live date, a last bank statement is created in the legacy system, so that all items transferred in the course of legacy data transfer were already included on one of the statements in the legacy system.

Both the number of the last statement minus 1, and the current year must be transferred during legacy data transfer for bank statement creation. This means that the fields CURR_YEAR and CURR_NR in table BKKM2 show the values 'current year' and 'last statement number -1'. Accordingly, at the turn of the year, the fields CURR_YEAR and CURR_NR must recieve the values 'current year -1' and 'last statement number -1'. If both fields remain empty, the system creates a bank statement with all items from the legacy data transfer. This statement is numbered 1.

1. The field NEXT_DATE must show the posting date on which the last bank statement run was started in the legacy system. This date must be before or on the date entered at the start of the bank statment run (see below). This field may not be empty. After the legacy data transfer, a bank statement run must be started - before new items are transferred. You must start the bank statement run per bank area with the latest posting date of the items (transferred from the legacy system), meaning up to the posting date on which items were transferred. The 'dummy statement' created shows the number of the last statement in the legacy system. Only items appear on this that were already on a statement (in the legacy system). The statement is not issued but the data is updated. This means that for the next statement the beginning balance is the same as the end balance of the last statement (created in the legacy system). This first statement issued in the new system only shows items that were not yet on a statement.

All accounts for which a periodic bank statement is to be created must exist with entries in the balancing table BKKM2. For legacy data transfer for bank statements you must make entries in the balancing table BKKM2 as follows:

• First case: The statements are to be created with consecutive numbers. Prerequisite: All items and balances transferred from the legacy system have already appeared on a statement (see above). The items and balances transferred from the legacy system do not appear on the first 'real' statement from the new system. The fields CURR_YEAR and CURR_NR must show the values 'current year' and 'statement number -1'. If the statement had the number 1 in the legacy system, these fields must have the values 'current year' and '000' or 'current year -1' and last statement number last year -1'. The entries in fields PERIOD and PER_UNIT can be any. The field NEXT_DATE must have as entry the posting date on which the last bank statement before legacy data transfer was created. You must ensure that this date is before or the same as the date you enter when starting the first bank statement run (see above). The field NEXT_DATE may not be empty. During the first run in the new system the system calculates and updates the next due date depending on the period (field: PERIOD) and the unit (field: UNIT).

• Second case: The numbering of the bank statements starts with 1. On the first statements the items and balances transferred from the legacy system may appear. In this case, apart from the key fields of the balancing table BKKM2, only the fields PERIOD, PER_UNIT and NEXT_DATE must have entries. The field NEXT_DATE must have the posting date entered on which the last statement in the legacy system was created. The date is used for the selection of due accounts. If the field NEXT_DATE is empty but the fields PERIOD and PER_UNIT contain entries, this results in an error.

• Third case: Accounts for which no statements have ever been created and for which in future none will be created do not have to be entered in the balancing table BKKM2.

The following description applies to all three cases:

If balancing without posting is executed AFTER the creation of the dummy statement, you must note the following for the creation of the first 'real' bank statement. In this case, the balancing table T_CLOSINFO of business transaction event 00010510 (meaning the table of the bank statment BAPI) has an entry, as since the last bank statement (= dummy statement) account balancing was executed. You can see by the indicator T_CLOSINFO-XNOPOST if the balancing data transferred was posted or not. You must evaluate this field in the business transaction event according to your requirements. This problem does not arise if balancing without posting did not take place after the dummy statement.

Changes in procedure

Further notes

General Data in Customer Master   General Material Data  
This documentation is copyright by SAP AG.

Length: 5463 Date: 20240426 Time: 213008     sap01-206 ( 162 ms )