- 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 intoconsideration. Payment requests which were already paid in a previousperiod (type 1), are ignored.Technical data for this division
The invoice is posted when the payment orders are released. Thisrelease also flags the payment requests as released setting theabove-mentioned flag to "X".
When a payment request is paid, the "Clearing date", "Clearing entrydate" and "Clearing document number" fields are filled so that it ispossible 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 ratedifferences which can occur due to different exchange rates whentranslating invoice currency into local currency or payment currencyinto local currency. Exchange rate differences which can occur due toexchange rate fluctuations in the time between issuing an invoice andpayment are not contained in the exchange rate differences totalsentered here.
Postings are always made sorted by type number (2 or 3), company code,business area and invoice currency, i.e. the payment requests withidentical type number, company code, business area and invoice currencyare grouped together per posting transaction. The end of a transactionof 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 differencepayment account (see "Posting payment requests of type 2" below), theexchange rate difference payment account can change when the G/Laccount defined in the payment request changes. Because of this, theremay be several line items for each transaction. The standard log fromthis program contains the line items with their exchange ratedifference totals and their respective assigned accounts. Every lineitem is displayed under the respective payment requests with theirindividual exchange rate differences so that the total listed in theline item can be easily understood by means of the individualdifferences above it.
Posting payment requests of type 2
Exchange rate difference totals for payment requests of type 2 areposted to the exchange rate difference payment account which is alsoused in the standard program. This account is determined depending onthe G/L account which is also stored in table PAYRQ. In addition, thechart of accounts and the currency type are read in the READ_T001_T001Asubroutine. The respective exchange rate difference payment accountcan be determined in the READ_T030H subroutine using the existingvalues for "Chart of accounts", "G/L account", "Invoice currency" and"Currency type". In contrast to the accounts specified on theselection screen, the exchange rate difference payment account is alsoseparated into a gains and a loss account. This means that both theposting key and the exchange rate difference payment account relevantto the posting changes when there are +/- sign changes to the exchangerate difference total. The offsetting entry is made to an exchangerate difference payment request account defined by the user on theselection screen. For positive values from the exchange ratedifference total, a debit posting is made to the corresponding exchangerate difference payment account, and a credit offsetting entry is madeto the exchange rate difference payment request account. For negativevalues, the exchange rate difference totals are posted the other wayaround.
Posting payment requests of type 3
Exchange rate difference totals for payment requests of type 3 are alsoposted to an exchange rate difference clearing account defined by theuser on the selection screen. The offsetting entry is made to anexchange rate difference payment request account as with type 2. Debitand credit postings are regarded in the same way as with paymentrequests of type 2.
Creating batch input sessions
All posting transactions are stored in a batch input session. Thestandard name of this session consists of the name of the program and afour-digit sequential number. Since only one batch input session iscurrently created, the name is presently "RFKDF0000001". The samenumber of transactions are generated within the batch input session asthere are payment request groups with identical type numbers, companycodes, business areas and invoice currencies. After every groupchange, the BATCH_INPUT subroutine is called in the program which makesentries in the line items ("BUCHUNGSZEILEN_FUELLEN" subroutine) andgenerates a posting transaction ("BI_FWBUCHUNG" subroutine). When theexchange rate difference payment accounts are changed, line items canalso be written between two group changes so that several postings canbe generated for one posting transaction.
Note on technical DP conversion
For each group change, i.e. per posting transaction, all the dataneeded for writing the line items is collected in an internal tableKDF_BUZEI. In this table, every table entry stands for a posting. Whencalling 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 thebatch input session.
Precondition
The selection screen allows you to select payment requests using thecriteria:
- 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 thefirst day of the next month as the reversal date if you do not enteranything else here.