SAP FI Payment Processsing | http://sapdocs.info
•
18 likes•4,363 views
DOWNLOAD THIS PRESENTATION AND OTHER 29 SLIDES FROM http://hotfile.com/dl/21484810/fc876b9/SAP-FI-Training-Presentations.rar.html Want to get more SAP Downloads ? Visit http://sapdocs.info
![[object Object],[object Object],[object Object],[object Object],[object Object],Chapter 24 Outgoing Payment Processing](https://image.slidesharecdn.com/244-6fipaymentprocesssing-091222065736-phpapp02/85/sap-fi-payment-processsing-httpsapdocsinfo-1-320.jpg)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (10)
More from sapdocs. info
More from sapdocs. info (20)
Recently uploaded
Recently uploaded (9)
SAP FI Payment Processsing | http://sapdocs.info
- 2. Payment Program Overview Payment Data Configuration Online Parameters Payment Proposal Run Payment Run Print Program Process Proposal Proposal Data Payment Summary Payment Advice Payment Media Master Record Open Items Check Bank Transfer
- 4. Input Data Address Bank Account(s) Alternative Payee Master Record Payment Terms Payment Methods Payment Block Clear with Customer Our bank Payment Term Payment Block Payment Method Invoice Master Record Complete? Open Items to Pay? + Payment
- 5. Payment Program - Control Levels Company Codes All Company Codes Paying Company Codes Payment Methods Country Company Code Banks Ranking Order Amounts Accounts
- 6. Company Code Parameters All Company Codes Cash Discount Strategies
- 7. Cash Discount Strategies Cash Discount will only be taken if the applicable cash discount exceeds the percentage. Maximum Cash Discount will always be taken. Due Dates are not considered.
- 8. Company Code Parameters Paying Company Codes
- 10. Payment Methods in Company Code
- 11. Payment Methods in Company Code - Form Data
- 12. Bank Ranking Order and available Amounts
- 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 10000 G/L Account 0001 10000 C 10000 G/L Account 0002 . . . . . . . . 20000 B 20000 G/L Account 20000 C 20000 G/L Account 20000 D 20001 G/L Account
- 14. Payment Currency Euro JPY USD Payment Program AUD ARS SEK Open items It is possible to process payments that contain an alternative payment currency (i.e., a currency other than the invoice currency)
- 16. Automatic Line Item Example: Payment Program
- 17. Automatic Line Item Example: Cash Discount Received Office Supplies 2000 1 Fuji Bank 1940 2 Cash Discount Received 60 2 Accounts Payable 2000 2000 1 2 Automatic Line Item 1. Invoice 2000 (Payment Term: 3% Cash Discount) 2. Cash Disc. 60 3. Payment 1940 2
- 18. Automatic Line Items Example: Cash Discount Received Chart of Accounts 1000 Process SKE Account 700210 Rules Posting Keys Cash Discount Received - SKE Account Assignment Depends on: Debit / Credit Tax Code Posting Key Debit 40 Credit 50
- 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) 1 9999 1 9999 Additional Log TRACE
- 20. Payment Proposal Run Start date 06/06 Start time HH:MM:SS Start immediately Status Proposal is released Proposal is running Payment Proposal has been created Payment Run Date 05/27 Identification xyz
- 23. Payment Run 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 Payment Run Date 05/27 Identification xyz Status _________________________________ Parameters have been entered. Payment proposal has been created. Start date 06/06 Start time HH:MM:SS Start immediately Schedule Payment ( )
- 24. Payment Media Report RFFOUS_C Print Program Payment Data Check Payment Summary Payment Advice 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
- 28. Appendix 1. Alternate Payment Currencies The automatic payment program can create payments for documents in any desired payment currency. Local Currency Transaction Currency Payment Currency Payment Amount (optional)
- 29. Appendix 1. Alternate Payment Currencies Vendor 1750 BRL (10000 MXN) TC= BRL, LC= MXN, PC= USD 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: 5.714 + 1750 * 5.714 * 0.102 = $1,019.49 Table of exchange rates: M: MXN USD = 0.102
- 30. Vendor invoice 10 000 Local currency MXN Transaction currency BRL 1 750 Payment currency USD 1 000 Payment 9 500 1 750 1 000 EXCHANGE RATES BRL:MXN > 0.175:1 MXN:USD > 10:1 BRL:MXN > 0.2:1 MXN:USD > 9.5:1 MXN 1 250 exch. rate diff. gain MXN 500 GAIN MXN 750 underpmt loss MXN 8 750 Value of the open item at the current exchange rate 1750 / 0.2 Appendix 1. Alternate Payment Currencies
- 32. Appendix 2. Intermediary Banks and Bank Chains - Scenarios Scenario Description Gen. Search Rec. Search 0001 Sender oriented 0002 0003 No bank chain determination Receiver bank oriented 0004 Receiver oriented General search : Find bank chain using key fields: bank country and bank key Account no./ recipient specific search : Find bank chain using key fields: bank country, bank key and bank account number Customizing Application
- 33. Appendix 2. Intermediary Banks and Bank Chains - Scenarios Scenario Ranking Rec. Bank Pmt.Curr. 0002 0 Payment program run Example: Scenario 0002, Business partner specific search, sender bank is house bank Sender bank Recip. Bank ctry 0002 1 1st step: Search with key: sender bank (bank ctry and - key) and payment currency. (if not successful) 2nd step: Search with key “payment currency” No. Category 1 Corr. country 1 DE Corr. Bank key Corr. Bank acct. 40050060 86746352 Currency Bank ctry. sender UNI DE Bank key sender UNI 10020030 Bank chain assignment: Correspondence banks Output Pmnt. Currency : UNI House Bank ctry : DE House Bank key : 10020030 Vendor : Vendor 1 Vend.bank ctry: DE Vendor bank:12345678 bank acct. no: 87654320
- 34. Appendix 2. Intermediary Banks and Bank Chains - Scenario 1 HB1 CB 1 CB 2 Explanation: HB = House Bank CB = Correspondence Bank BPB = Business Partner Bank = Payment direction HB2 CB 3 HB3 BPBs
- 35. Appendix 2. Intermediary Banks and Bank Chains - Scenario II BPB 1 BPB 2 Explanation: HB = House Bank CB = Correspondence Bank BPB = Business Partner Bank = Payment direction HB BPB 3 CB 1 CB 2 CB 3
Editor's Notes
- 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.)
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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)
- 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.
- 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).
- 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.
- 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
- 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.
- 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.
- 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).
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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...
- 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,019.49 ) 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.
- 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 8750 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 0.025 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)
- 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.
- 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.
- 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 118015. It is possible to list the bank chains in the payment list.
- 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.
- 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.