Kontakt

Ansicht
Dokumentation

RFKDF000 - EU: Periodic Exchange Rate Differences Postings for Payment Requests

RFKDF000 - EU: Periodic Exchange Rate Differences Postings for Payment Requests

General Material Data   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.
SAP E-Book

This program is used for the monthly balancing of exchange rate differences between payment requests and invoices after releasing the payment order. Exchange rate differences can only occur if the three currencies "invoice currency", "payment currency" and "local currency" to be considered are not identical.

Description

The payment requests stored in table PAYRQ which were flagged as posted (XRELD field = "X") form the basis of the periodic exchange rate difference postings.

Within this group, the payment requests can be divided up into three categories:

  • Type 1: Payment request was already paid before the current period
  • Type 2: Payment request was paid in the current period
  • Type 3: Payment request is still open in the current period, i.e.
    payment request was not yet paid or was paid with a date from
    the next period.

This program only takes payment requests of type 2 and type 3 into consideration. Payment requests which were already paid in a previous period (type 1), are ignored.

Technical data for this division

The invoice is posted when the payment orders are released. This release also flags the payment requests as released setting the above-mentioned flag to "X".

When a payment request is paid, the "Clearing date", "Clearing entry date" and "Clearing document number" fields are filled so that it is possible to distinguish between payment requests of type 2 and type 3.

In contrast to the programs which already exist in the standard system ("RFSBEW00", "SAPF100"), this program only considers exchange rate differences which can occur due to different exchange rates when translating invoice currency into local currency or payment currency into local currency. Exchange rate differences which can occur due to exchange rate fluctuations in the time between issuing an invoice and payment are not contained in the exchange rate differences totals entered here.

Postings are always made sorted by type number (2 or 3), company code, business area and invoice currency, i.e. the payment requests with identical type number, company code, business area and invoice currency are grouped together per posting transaction. The end of a transaction of this sort is marked by a separator in the posting log.

Exchange rate difference totals are posted as debits or credits, depending on the +/- sign. When using the exchange rate difference payment account (see "Posting payment requests of type 2" below), the exchange rate difference payment account can change when the G/L account defined in the payment request changes. Because of this, there may be several line items for each transaction. The standard log from this program contains the line items with their exchange rate difference totals and their respective assigned accounts. Every line item is displayed under the respective payment requests with their individual exchange rate differences so that the total listed in the line item can be easily understood by means of the individual differences above it.

Posting payment requests of type 2

Exchange rate difference totals for payment requests of type 2 are posted to the exchange rate difference payment account which is also used in the standard program. This account is determined depending on the G/L account which is also stored in table PAYRQ. In addition, the chart of accounts and the currency type are read in the READ_T001_T001A subroutine. The respective exchange rate difference payment account can be determined in the READ_T030H subroutine using the existing values for "Chart of accounts", "G/L account", "Invoice currency" and "Currency type". In contrast to the accounts specified on the selection screen, the exchange rate difference payment account is also separated into a gains and a loss account. This means that both the posting key and the exchange rate difference payment account relevant to the posting changes when there are +/- sign changes to the exchange rate difference total. The offsetting entry is made to an exchange rate difference payment request account defined by the user on the selection screen. For positive values from the exchange rate difference total, a debit posting is made to the corresponding exchange rate difference payment account, and a credit offsetting entry is made to the exchange rate difference payment request account. For negative values, the exchange rate difference totals are posted the other way around.

Posting payment requests of type 3

Exchange rate difference totals for payment requests of type 3 are also posted to an exchange rate difference clearing account defined by the user on the selection screen. The offsetting entry is made to an exchange rate difference payment request account as with type 2. Debit and credit postings are regarded in the same way as with payment requests of type 2.

Creating batch input sessions

All posting transactions are stored in a batch input session. The standard name of this session consists of the name of the program and a four-digit sequential number. Since only one batch input session is currently created, the name is presently "RFKDF0000001". The same number of transactions are generated within the batch input session as there are payment request groups with identical type numbers, company codes, business areas and invoice currencies. After every group change, the BATCH_INPUT subroutine is called in the program which makes entries in the line items ("BUCHUNGSZEILEN_FUELLEN" subroutine) and generates a posting transaction ("BI_FWBUCHUNG" subroutine). When the exchange rate difference payment accounts are changed, line items can also be written between two group changes so that several postings can be generated for one posting transaction.

Note on technical DP conversion

For each group change, i.e. per posting transaction, all the data needed for writing the line items is collected in an internal table KDF_BUZEI. In this table, every table entry stands for a posting. When calling the "BI_FWBUCHUNG" subroutine within the "BATCH_INPUT" subroutine, table KDF_BUZEI is worked through and transferred to the "POSTING_INTERFACE_DOCUMENT" function module for inserting into the batch input session.

Requirements

The selection screen allows you to select payment requests using the criteria:

  • Paid / open payment requests (type 2/3)
  • Company code
  • Document number
  • Fiscal year
  • Business area and
  • Posting period.

You can specify whether a batch input session is to be created or not. In addition, you can choose between a standard and an extended log.

You must make entries in at least the following fields:

  • Document type
  • ER diff. on pymt req. and
  • ER diff. on clearing.

The current date is always set as a default in the "Document date" field. The last day of the month appears as the posting date and the first day of the next month as the reversal date if you do not enter anything else here.






CL_GUI_FRONTEND_SERVICES - Frontend Services   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 7654 Date: 20240601 Time: 053606     sap01-206 ( 186 ms )