1. Chapter 24 Outgoing Payment Processing
Outgoing Payment Processing is the final step in the Procurement Cycle. The system employs an automated Payment Program which provides full functionality for processing Vendor payments.
Chapter Objectives
Describe the input data needed to configure the Payment Program.
Discuss cash discount strategies.
Execute the Payment Program.

2. Payment Program Overview
Configuration
Online Parameters
Master Record
Open Items
Payment Proposal Run
Process
Proposal
Proposal Data
Payment Run
Payment Data
Print Program
Overview of the Outgoing Payment Program:
Reviews all Open Items of selected Vendors/Customers.
Ranks these Open Items based upon Payment Terms and Days Outstanding.
Creates a Proposal Run after which the user can select Open Items to pay and to block.
Runs the final program. (All related journal entries are posted, bank data is updated, and the checks are created.)
Payment Media
Check
Payment Advice
Payment Summary
Bank Transfer

3. Payment Program Input Data
Master Record
Online Parameters
Configuration
Open Items
Address
Account Control
Bank Details
Account Mgmt.
Paymt. Transaction
Automatic Paymt.
Transactions
Payment Program
Select Open Items
Select Bank(s)
Payment Method
Minimum Amounts
Available Amounts
Block Reason
Payment Date
Select Accounts
Select Company Codes
Next Payment Date
Cash Discount fields
Payment Method
Payment Block
Specific Bank
The input data to the Payment Program includes:
Fields in Customer / Vendor master records
Configuration of the Payment Program
Online Parameters
Fields in the Open Items

4. + Input Data Master Record Address Bank Account(s) Alternative Payee
Complete?
Payment Terms
Payment Methods
Payment Block
Clear with Customer
Our bank +
Invoice
Payment Term
Payment Block
Payment Method
Open Items
to Pay?
Certain fields in Customer and Vendor master records must be maintained. These settings enable the Payment Program to process payments automatically.
At least one Payment Method must be entered in either the master record or the Open Item. The Payment Method specification in the Open Item overrides any additional specifications made in the master record or in the Payment Program Online Parameters.
A Payment Block must be entered in the master record if the user wants all of the Open Items related to this master record to be blocked. Payment Blocks can also be specified for an Open Item.
Payment

5. Payment Program - Control Levels
Company Codes
All Company Codes
Paying Company Codes
Country
Company Code
Payment Methods
Ranking Order
Amounts
Accounts
The Payment Program is controlled at three levels:
Company Code parameters
Payment Method parameters
Bank parameters
The IMG Activity: Configure Payment Program leads to the Payment Program Configuration initial screen. This Screen leads via Push Buttons to the different Control Levels described above.
Note: When running the Payment Program, you may also reach the configuration via the Environment menu path.
Banks

6. Company Code Parameters All Company Codes
The Paying Company Code must be specified for each Company Code.
The Paying Company Code is the company that physically pays the Open Items or from where the money is drawn. If the Paying Company Code differs from the Sending Company Code (who has the invoice on-hand or sends out the checks), then the user can differentiate between the two entities. For example, with centralized Purchasing, the Paying Company Code can be the corporate headquarters paying on behalf of its regional offices (Sending Company Code).
Other items that can be set include:
Special G/L Transactions that can be paid via the Payment Program.
Minimum and Maximum Cash Discounts.
Note :The payment program can clear only open items posted in sub-ledgers, not on G/L accounts.
Cash Discount Strategies

7. Cash Discount Strategies
will only be taken if the
applicable cash discount
exceeds the percentage.
Maximum Cash Discount
will always be taken.
Due Dates are not
considered.
The Payment Program pays Open Items that must be paid immediately because based on the date of the next Payment Run, the following situations exist:
Cash discount will have expired.
Due date for net payment will have passed.
Through configuration, different cash discount strategies for outgoing payments can be established:
If the user wants to achieve the highest possible cash discount, the Always Maximize Cash Discount field must be selected. The Payment Program will then always pay in time to secure cash discount terms for items with this specification.
If the user has specified a minimum discount percentage in the Outgoing Payment with Cash Discount field, the Payment Program only pays the items if it can secure the specified discount percentage in the current Payment Run. If this is not possible, the item is paid on the net due date.
If the user wants to pay as late as possible, thus forgoing any cash discount, they should enter 99% as a minimum percentage rate when configuring the payment program. This setting ensures the system always pays net due.

8. Company Code Parameters Paying Company Codes
Under General Specifications, the Minimum Amount and Form for the Payment Advice fields must be specified.
By specifying minimum amounts, payments can be suppressed if the payment amount does not justify the expense incurred to process the payment. If the amount specified is not met, the Open Items are printed in an Exception List (during the Proposal Run).
The Payment Advice Form field allows the correct payment advice to be selected. The information includes fonts and page formatting of the payment advice.
The Texts functionality allows texts to be assigned per Company Code to the payment forms. (This function can be found by selecting the Sender button at the top of the screen.) The text information includes Letter Header, Footer Text, Signature, and Sender information.

9. Payment Method in Country
Payables
Check
Bill of Exchange
Bank of Transfer (domestic + foreign)
Postal Bank Transfer
Check / Bill of Exchange
Group Clearing (between Company Codes)
Receivables
Bank Collection
Bank Direct Deposit
Request for Bill of Exchange
Bill of Exchange
Refund by Bank Transactions
Refund by Check
Payment Methods specify the acceptable types of payment. Examples include:
Check
Bill of Exchange
Bank of Transfer
In the Customer or Vendor master record the Payment Methods that are used for the Account must be specified. The possible Payment Methods are already defined in the System.
For each country, the system contains definitions in Payment Methods that you can use within that particular country.
These standard Payment Methods are delivered with the system. It is advised not to modify the configuration for the Payment Method in the country, except to modify the Document Type.

10. Payment Methods in Company Code
A Payment Method can be specified:
Based on the amount
For foreign payments
With Optimization by Bank Group, the user can ensure that the money transfer is made from the user’s House Bank to the bank of the Vendor as fast as possible.
With Optimization by Postal Code, House Bank selected is according to the Postal Code (Zip Code) of the Vendor.
For each Payment Method, a form data must be specified (see next slide)

11. Payment Methods in Company Code - Form Data
When a payment is made, a Note to the Payee (Vendor) is attached to the check describing the items being paid by the checks. The user can define the number of Line Items that can be included on the Note.
If more items are to be paid than can be listed, specifications can be made as to whether a Payment Advice should be printed or an additional form is necessary.

12. Bank Ranking Order and available Amounts
For each Company Code, Payment Method and Currency, a Ranking Order of banks can be specified.
During ranking, the user sets an order priority by Payment Method.
The planned available amounts for incoming and outgoing payments can be determined for each House Bank.
The Payment Program does not carry out amount splitting. If the planned amount in a bank account is not sufficient for a payment, the Payment Program selects another Bank Account. If it finds no Bank Account from which it can post the entire amount for a payment, it does not carry out the payment and adds the item to the exception list.
Also, the functionality ” Number of days to value date” can be set up. This feature indicates the probable number of days before a debit and/or a credit memo is actually posted to the bank account. The number of days is added to the posting date and results in the date relevant for cash management and forecasting.
Note: Available amounts can be updated through the IMG, Payment Program (Environment), or Cash Management (Planning).

13. G/L Account Assignment for Bank Accounts
Company Code Name of Company
1000 Boots - R - Us . .
House Payment Currency Account G/L Clear Charge BusA Bank Method ID Account Account Type
10000 B G/L Account C G/L Account B G/L Account C G/L Account D G/L Account
To have the Payment Program post a payment, a G/L Account for the Bank Account for each House Bank, Payment Method and Currency must be specified.
Assigning a G/L Account to a Bank Account ID ensures that accounting transactions involving the Clearing Account corresponding with the Bank Account will be reflected in the General Ledger.
To trace payments in process, the G/L Account must be managed on an Open Item basis.
It is not possible to make two entries that have the same house bank and payment method. If a payment method is to be used more than once then the entries must differ not only by Account ID but also by House Bank.

14. Payment Currency Euro Payment Program JPY USD Open items AUD SEK ARS
It is possible to process payments that contain an alternative payment currency (i.e., a currency other than the invoice currency)
In the SAP R/3 System, line items posted in one currency can be paid in a different (alternative) currency either when paying line items manually or making automatic payment transactions.
As a rule, payers and vendors either come to a general agreement on what constitutes acceptable alternative currencies, or they agree on the payment currency and the payment amount per transaction. Prior to Release 4.5A, payments in an alternative currency could only be created and posted manually.
As of Release 4.5A, it is possible to enter a payment currency that differs from the transaction currency directly in the open item. You can also specify an amount equivalent to the gross amount of the item in the payment currency.
The payment currency feature is supported in both A/P and A/R.
This feature is useful in situations such as the following.
You are in a country where the possession of foreign exchange or the currency exchange is restricted. So you may have one hard currency available, but not the one of the invoice and it is difficult to obtain this hard currency.
A vendor might send you an invoice in a less accessible currency. For you it is difficult/expensive to get this currency. The vendor agrees that you pay him in a hard currency which he can exchange easily / at a good rate in his home country.
You have invoices and credit memos of a business partner in different currencies, but you want to pay them together in one payment. This requires one payment currency.
See the Appendix for a detailed example

15. Payment Blocking Reasons
A Payment Block can be specified in the Vendor master record, affecting all Open Items associated with that master record. A Payment Block prevents an open item from being paid.
A Payment Block can also be entered on an Open Item.
Users can either use the system-delivered Blocking Reasons or create their own.
If the ability to add or remove a payment block while processing the payment proposal is desired then the blocking indicator has to be set up to be changeable.

16. Automatic Line Item Example: Payment Program
Every group of automatic line items covers a series of posting processes to be followed.
Every process is managed under a system-specific three-character Process Code, which is delivered with the system and cannot be changed.
Every automatic posting process is defined at the Chart of Accounts level.

17. Automatic Line Item Example: Cash Discount Received
Office Supplies
2000 1
Accounts Payable
Fuji Bank
1940 2 1 2
Cash Discount Received 60
Automatic Line Item 2
1. Invoice (Payment Term: 3% Cash Discount)
2. Cash Disc
3. Payment 1940
Cash Discount Received Process Codes:
Cash Discount Received SKE
Cash Discount Expenses SKT
Cash Discount Clearing (net invoice procedure) SKV
Revenue / Expense from Over / Underpayment UBS
To allow the system to automatically post a cash discount received when making a payment to a vendor, G/L Accounts must be defined for the Cash Discount Received process (SKE). 2

18. Automatic Line Items Example: Cash Discount Received
Cash Discount Received - SKE
Chart of Accounts Process SKE Account
Rules Posting Keys
Account Assignment Depends on:
Debit / Credit Tax Code
Posting Key
Debit 40 Credit 50
The rules for automatic G/L Account assignment must be defined, including the Posting Keys to be used.
Rules determine the account assignments that will occur automatically:
Are different Accounts posted for debit and credit entries?
Are different Accounts used for individual Tax Codes?

19. Maintaining Parameters
Payment Run Date 05/27/YY
Identification xyz
Posting Date 05/27/YY
Document Entered Until 05/26/YY
Company Codes Payment Next Posting Method Date
1000 US 06/14/YY
Vendors (from/to) Customers (from/to)
Additional
Log
TRACE
Every payment run of the payment program is identified by two fields:
Run Date
Identification
The run date does not have to be the actual date when the program is executed but this is recommended. Its main purpose is to help identify the program run.
The field “Identification” is used to differentiate between program runs that have the same run date.
The Payment Program selects Open Items to be paid depending on the following:
Date of the Payment Run
Next Posting Date
While editing the parameters, an Additional Log can be requested for test purposes. If the Proposal Payment Run does not pay certain Open Items, the reasons are detailed in this log. On the basis of this information, the user can decide how to resolve the situation.

20. Payment Proposal Run Payment Run Date 05/27 Identification xyz
Start date 06/06
Start time HH:MM:SS
Start immediately
Status
Proposal is released
Proposal is running
Payment Proposal has been created
The proposal run:
Searches the accounts and documents you entered in the parameters for due items.
Groups due items together to create payments.
Selects appropriate payment methods, house banks and partner banks for payment.
The Payment Proposal can be started immediately or scheduled for a later date and / or time. The System then runs the Payment Proposal in batch mode.

21. Intermediary Banks: Solution
Vendor Bank
Own Bank
Payment Program
Companies have the option to specify not only the banks at the start and at the end of the payment cycle (House bank and the business partner bank) but also the banks via which the payment should be made in between.
The payment program can determine a predefined combination of intermediary banks for each payment
Intermediary banks are banks which companies use to make/receive payments to/from their business partners abroad. These banks are used in addition to house banks and business partner banks. Payments made using intermediary banks utilize a bank chain, which consist of a house bank, a partner bank, and upto three intermediary banks.
The bank chain function can be activated according to the client. A scenario for determining a bank chain needs to be assigned to a client.
Bank chains transcend payment medium boundaries. For any payment medium that requires bank information in the master record of the business partner, the following formats are supported in Release 4.5A: S.W.I.F.T., MT100, MT200, MT202, EDI (Basis- IDOC: PEXR2002), sending of payment data via ALE (Basis-IDOC: FIPARQ01).
This feature is useful when:
The house bank does not know which intermediary / clearing bank(s) it should use.
The combination of intermediary banks selected by the house bank leads to a lengthy duration for the money transfer.
As the house bank has to determine a combination of intermediary banks…
It may charge a higher fee for the transfer
It needs more time to process the transfer internally, which leads to a longer overall duration
Note: The above references to “house bank” refer to actions taken by the actual bank (e.g., Citibank) not the internal SAP “house bank” record.
For additonal details about intermediary banks and bank chains see Appendix 2.

22. List of Blocked Accounts/Items
Payment Proposal Data
Proposal Data
Process
Display List
Display Exceptions
Proposal Log
Payment List
Amounts by Business Areas
Amounts by Countries
Amounts by Currencies
Amounts by Payment Methods
Amounts by Banks
List of Blocked Accounts/Items
Due date check
Select Payment Method
Payment Records
After the Payment Proposal is run, the proposal dates can be processed to select which Open Items should be paid and which should be blocked.
The Payment Proposal creates a complete list and partial lists according to different criteria.
If there are any blocked Accounts or Items, the System creates Exception Lists.
The Proposal Log will list any configuration errors. In this case, no payment is possible. The errors must be corrected, the Payment Proposal deleted and a new Payment Proposal processed.

23. Payment Run ( ) Payment Run Date 05/27 Identification xyz
Status _________________________________
Parameters have been entered.
Payment proposal has been created.
Schedule Payment
Start date 06/06
Start time HH:MM:SS
Start immediately
Status _________________________________
Parameters have been entered
Payment proposal has been created
Payment run has been released
Payment run is in process
Payment run has been carried out:
1 generated, 1 completed
Payments have been posted
The payment run:
Posts payment documents.
Clears open items.
Supplies data for the payment media print programs.
The actual Payment Run can be started immediately or scheduled to run at a later date and / or time. The Payment Run is executed in batch mode. ( )

24. Payment Media Payment Data Print Program Report RFFOUS_C Check
Payment Advice
Payment Summary
Printing Payment Media, the Payment Advice, and Payment Summary can be integrated with running the Payment Program. To do this, variants for the print reports must be created.
Variants supply the Print Program with specifications for the Company Code, Print Forms, and Language of the text. Information stored in variants can be used repeatedly.
The Print Program produces the payment transfer mediums (and Payment Advice if required) and the Payment Summary from data in REGUH, REGUD and REGUP. (See next bullet.) The Print Program can also process data from payment configuration tables.
The Payment Program creates the following tables:
REGUH contains data about the Payee or Payment Method.
REGUP contains data from the individual Open Items.
REGUD contains the complete Bank Data and the Payment Amounts.
Bank Transfer

25. Check Form Structure HEADER ADDRESS PAGE INFO Your account at vendor
MAIN
Text
Heading
Line items
Total
CARRYFWD Amount to carry forward
CHECK/CHECKADD
Voided or Valid
The structure of the Check Form contains five windows. The Print Program processes the elements automatically.
If all check data does not fit on one page, the Print Program voids the check on the first page.
The next page contains the rest of the line items, the total amount of the payment and the valid check.
There is a summary page per Company Code. It contains the following:
The number of checks printed
The number of forms with Payment Advice
The net total paid
The voided checks

26. Outgoing Payment Program Chapter Summary
Key Terms
Outgoing Payment Program
Payment Method
Payment Block
Paying Company Code
Sending Company Code
Optimization by Bank Group
Optimization by Postal Code
Variant
Outgoing Payment Program - An automatic process that reviews all Open Items of selected Vendors, ranks these Open Items based upon Payment Terms and Days Outstanding; creates a Proposal Run ; and runs the Print Program.
Payment Method - A field that specifies the acceptable types of payment such as a check, bill of exchange or wire transfer.
Payment Block - Functionality within the system that prevents an Open Item from being paid.
Paying Company Code - The company which physically pays for the Open Items or from where the money is drawn.
Sending Company Code - The company which possesses the physical invoice on-hand or who sends out checks. (The Sending Company Code and the Paying Company Code can be the same.)
Optimization by Bank Group - An indicator that ensures that the money transfer is made from the user’s House Bank to the bank of the Vendor expeditiously.
Optimization by Postal Code - An indicator that selects the House Bank according to the Postal Code (Zip Code) of the Vendor.
Variant - A value that supplies the Print Program with specifications for the Company Code, Print Forms, and Language of the text.

27. Outgoing Payment Program Chapter Summary
Key Terms
Payment Currency
Intermediary Bank
Bank Chain
Payment Currency - A currency other than the document currency that is used to make/receive payment instead of the document currency.
Intermediary Bank - A bank by which companies make/receive payments to/from their business partners abroad, in addition to their house banks and their business partners’ banks.
Bank Chain - A series of banks through which funds are passed.

28. Appendix 1. Alternate Payment Currencies
The automatic payment program can create payments
for documents in any desired payment currency.
Local Currency
Transaction Currency
Configuration Prerequisites
Field status groups of G/L account and posting keys need to defined so that the fields “Payment currency” and “Amount in payment currency” are optional.
In the document change rules for the fields “Payment currency” (BSEG-PYCUR) and “Amount in payment currency” (BSEG-PYAMT), you define if these fields are able to be changed following posting. Note that changing these fields only makes sense if the line item has not yet been cleared.
The payment currency has to be defined in Payment Program configuration:
Payment method country -> currency
Payment method company code -> currency
How it works:
You specify the payment currency in the invoice item any time prior to payment.
You may optionally enter a specific amount to paid using the payment currency. This amount will be taken as the gross amount by the payment program (that is before deducting possible cash discounts or withholding tax).
See the Appendix for additional detailsExample continues on following slides...
Payment Currency
Payment Amount
(optional)

29. Appendix 1. Alternate Payment Currencies
TC= BRL, LC= MXN, PC= USD
Vendor
1750 BRL (10000 MXN)
Vendor line item: Entering Altern pymt currency: USD Altern pymt amount : $1000
Warning/ Error: Payment amount differs by 2% from calculated amount:
Currency translation: BRL->MXN: * * = $1, Table of exchange rates: M: MXN  USD = 0.102
In the example above, the document is posted in a foreign currency – Brazilian Real. The local currency is Mexican Pesos. In the document, the user specifies that U.S. Dollars will be the payment currency.
Note: You will learn about Currencies and Exchange Rates in Chapter 26.
While not required, a payment amount of $1000 is also specified.
Note: The payment amount is subject to a validation check. During this check, the system accesses the Exchange Rate Table to determine if the amount entered is consistent with the current exchange rates. If the amount entered differs from the amount calculated by a percentage rate that exceeds the tolerance specified in the company code table (maximum exchange rate difference in Financial Accounting Global Settings) the system displays a warning message.
In the example above, the system converts Brazilian Real into Mexican Pesos and then Mexican Pesos into U.S. Dollars. The difference between this calculation ($1, ) and the negotiated amount ($1000) exceeds the tolerance so a warning message is given.
The warning message (Message F5 874) may be configured to produce a hard error or not appear at all.

30. Value of the open item at the current exchange rate 1750 / 0.2
Appendix 1. Alternate Payment Currencies
Transaction currency
BRL
Local currency
MXN
Payment currency
USD
EXCHANGE RATES
Vendor
invoice
1 750
10 000
1 000
BRL:MXN > 0.175:1
MXN:USD > 10:1
Payment
1 750
9 500
1 000
BRL:MXN > 0.2:1
MXN:USD > 9.5:1
MXN 8 750
Value of the open item at the current exchange rate 1750 / 0.2
MXN exch. rate diff. gain
MXN 750 underpmt loss
When you specify the payment amount (in the payment currency) two kinds of differences in local currency may occur.
Over/underpayments may occur because at the time of payment the payment program calculates the amount in local currency based on the agreed payment amount. In the example above, at the time of payment 1000USD translates into 9500 MXN. However, the actual dollars necessary to pay the item is only MXN (1750 BRL/.2 MXN), so we are overpaying buy 750 MXN.
Exchange Rate Differences may occur between the time of invoice and the time of payment. This difference is based on changes between the exchange rates of the transaction currency and the local currency. In the example above, the exchange rate between BRL and MXN change from 0.175:1 to 0.2:1 (One MXN now buys more BRL). This change means that the item which originally required conversion of 10,000 MXN now only requires 8750 MXN. So you have gained 1250 MXN due to the change in exchange rates.
Depending on the fiscal authorities, these gains and losses may or may not be tax relevant. So from a bookkeeping point of view, these differences have to be accounted for separately. If the payment difference account is tax relevant (country specific), you have to assign an additional clearing account in customizing.
When you enter credit memos referencing this invoice the payment currency and a possible payment amount in the payment currency are taken over proportionally. (e.g., Credit memo of MXN 1000 results in the payment currency amount being reduced by USD 100)
MXN 500 GAIN

31. Appendix 2. Intermediary Banks and Bank Chains - Activities
1. DEFINE SCENARIO (general, business partner specific)
2. ACTIVATE SCENARIO
3. DEFINE A BANK CHAIN
A) General bank chain - independently of a business partner’s bank details - in IMG OR
B) Partner Specific - on the application side
Described on this slide are the activities to be done in IMG and/or on the application side to prepare bank chains for processing.
There are two types of bank chains:
General Bank Chains -This type is created in bank chain customizing. They are of a general nature and not related to a particular procedure (e.g., Treasury transactions) or business partner. For example, they can be dependent on the foreign country to/from which the payment is made, foreign bank key, or foreign currency.
Partner-Specific Bank Chain - These bank chains are contingent upon master data (e.g., Treasury business partners or creditors) and thus represent master data themselves. They are created using a partner's account connection. The individually supported partners are Creditors, Debtors, Treasury Business Partners, and House Banks.
You can maintain bank chains for creditors, debtors, and house banks in Release 4.5A via the menu path Accounting  Financial Acct.  Banking  Master data  Bank chain (on the application side).
The system is only able to determine the bank chain if a payment method is used for which a bank chain is needed (e.g. bank transfer) On the other hand, no bank chain is determined for for payments by check if it is not defined specifically for this payment method.
A bank chain is chosen according to the settings in bank chain determination during the payment run (both for open items and for payment requests from treasury and cash management). If one of the values relevant to the bank chain is changed in the payment proposal (e.g., a house bank or partner bank), the bank chain is reconfigured and shown to the user.
House bank
Business partner (customers and vendors)
Cash management carry over

32. Appendix 2. Intermediary Banks and Bank Chains - Scenarios
Description
Gen. Search
Rec. Search
0001
No bank chain determination
0002
Sender oriented
0003
Receiver bank oriented
0004
Receiver oriented
Account no./ recipient specific search: Find bank chain using key fields: bank country, bank key and bank account number
General search:
Find bank chain using key fields: bank country and bank key
The scenarios describe how bank chain determination should take place. A number of typical scenarios are provided by SAP. The scenarios displayed in the slide are standard R/3 scenarios and cannot be changed.
You can define additional scenarios for your own purposes.
Any scenario you want to use must be activated in a further step.
Note scenario 0003:
First, the system tries to find the bank chain in the tables by using the key’s bank country, bank key, and bank account number of the recipient or the sender. If, for example, a specific intermediary bank was defined for the particular foreign recipient (vendor) within the application menu, the system includes the intermediary bank in the payment proposal of the payment program. If entries cannot be found in the partner specific bank chain definition, the system searches in customizing for the entries by using the more general key’s bank country and bank key.
Customizing
Application

33. Appendix 2. Intermediary Banks and Bank Chains - Scenarios
Example: Scenario 0002, Business partner specific search, sender bank is house bank
Scenario
Ranking
Sender bank
Recip. Bank ctry
Rec. Bank
Pmt.Curr.
0002 1
0002
Payment program run
Output
Currency
Bank ctry. sender
Bank key sender
1st step: Search with key: sender bank (bank ctry and - key) and payment currency. (if not successful) 2nd step: Search with key “payment currency”
UNI DE
UNI
Pmnt. Currency : UNI House Bank ctry : DE House Bank key : Vendor : Vendor 1
Vend.bank ctry: DE Vendor bank: bank acct. no:
The characteristics of scenario 0002 contain a sender bank and a currency-oriented search strategy.
The ranking determines the order of searching entries in the table of bank chains.
Similar to business partner oriented bank chains, you can assign bank chains referring exclusively to your house bank, which will be determined within the payment program run. In the case described on the above slide, the system determines the intermediary (corresponding) bank based on the house bank and/or currency used.
This rule is configured on the application side (Accounting  Financial Acct.  Banking  Master data  Bank chain  House Banks)
If business partner oriented definitions exist and they contain the same house bank as the house bank oriented definitions (described above), the business partner specific definition takes precedence over the house bank definition, which could result in the determination of different bank chains.
If you want to integrate the bank chain on the payment advice please refer to note
It is possible to list the bank chains in the payment list.
Bank chain assignment:
Correspondence banks
No.
Category
Corr. country
Corr. Bank key
Corr. Bank acct. 1 1 DE

34. Appendix 2. Intermediary Banks and Bank Chains - Scenario 1
HB1
HB2
HB3
Explanation: HB = House Bank
CB = Correspondence Bank
BPB = Business Partner Bank
= Payment direction
CB 1
CB 2
CB 3
The sequence of intermediary banks may depend on the following:
House bank of the company that uses R/3
Bank of the vendor
Bank of customer
House bank of the treasury business partner
Currency
Payment method supplement
In conjunction with the customizing of the payment program (payment methods, bank selection), every dependency can be modeled.
The example above depicts a bank chain that depends on your house bank.
BPBs

35. Appendix 2. Intermediary Banks and Bank Chains - Scenario IIHB
CB 1
CB 2
CB 3
Explanation: HB = House Bank
CB = Correspondence Bank
BPB = Business Partner Bank
= Payment direction
BPB 1
BPB 2
BPB 3
Example for a bank chain that depends on the business partner bank. Using this bank chain, you need the information from the business partner, specifically the correspondence bank. If you have not configured the business partner related bank chain, interpretation will occur based on the definitions in the general bank chain. If entries do not exist for the general bank chain, then no bank chain will be determined.