Tuesday, October 30, 2012

Setting up the Automatic Payment Program


Q1:  What is the process of payments using the Automatic Payment Program?

A: The process in general is as follows.
You launch transaction F110 and specify parameters for the selection of items to be paid. Then you run Proposal Run which creates Payments Proposal. This proposal is analysed by Treasury / Accountants / somebody else and then it is approved immediately or with some corrections. After that you run Productive Run. At this moment postings are done (or not done – see separately). When Productive Run is finished, you can create payment file or paper payment documents for the bank and/or payment recipients.

Q2: What should I start an APP configuration from?

A: The process begins with understanding of payment types in use. Have a look at the bank statement, talk to the people responsible for payments and statements. You will create special payment method for each of the payment types.
Basic configuration of APP is carried out in transaction FBZP. Go through all the sections in it and understand what you will configure and what you will copy from existing examples (maybe just use existing examples without copying).

Q3: We have a special payment type when paper fax is sent to the “bank”. This fax contains all the parameters for the payment processing. The “bank” is not a real bank but company within our holding. It gives us periodic statements like paper bank statements. Payments of this type are absolutely manual. Do I need to set up special payment method for this?

A: 1)
If the payment is done for the preliminary known open items, you can simply use “Manual payments” transaction F-53 without APP. No payment method is required in this case. Payment document can be printed out in external system (Word/Excel) or via Correspondence functionality.

2) If you want APP to choose the documents to be paid via “fax”, then you have to use it. Special payment method is required. Of course, you can set up your own printing program for this payment method, as for usual payment method.

Q4: We periodically pay to the government authorities. For example, taxes. How should we process these payments?

A: I saw 3 scenarios:
1) Russian. You create special vendor with reconciliation account in area of “tax” GL accounts. You post “invoice” from this vendor, even though there is no actual invoice. Amount is taken from the tax return. Then you pay the amount to vendor as usual.
2) Western with direct debit. Very simple. Tax authorities take money from the bank account by themselves.
3) Western with invoice. It is like scenario 1, but actual invoice exists.

Q5: Bill of exchange. What is this? IMG has lots of settings about it, but I do not understand if I need them.

A: It is payment with notes (bill of exchange, bill). I have never seen it in use. Simply forget about it.

Q6

: Are there any recommendations as to best usage of Identification field in transaction F110? The one below the date, on the first screen. Should we put clerk’s initials in there, country code, company code?

A: The approach depends on number of people processing the payments, if they have on-line connection to each other etc. If people are locates in several geographical locations, then it is logical to put code of the country or Company Code. If they sit next to each other, they can work out their own rules.

Q7: Why do I have Vendors and Customers on the selection screens of APP? What is relations between Customers and Payment program which is used for outgoing payments?

A: First of all, we can pay Customers too. For example, refunds or returns of down payments.
Second, APP can be also used for payments collection. For example, direct debits.
That’s why customers are pretty much on their place in APP.

Q8: Are there any recommendations as to how to use “Next run date” field in APP? How often should the Payment Run be executed?

A: If you use early settlement discount functionality and automatic payment optimization, then the field “Next run date” should contain the date of next run. Frequency of them depends on company rules and varies from 1 day to 1 month. If you select open items manually using the external lists and factors, then 31.12.9999 will do.

Q9: What is the trigger for APP run? Vendor invoice? Purchase order?

A: APP processes posted invoices and down payment requests. Purchase orders have nothing to do with APP. Frankly speaking, Purchase Orders are not relevant to Finance whatsoever.

Q10: We can control outgoing payments: what and how to pay. There is different situation with incoming payments. How would we know that customer has paid us in order to process the incoming payment in APP? How shall we know which bank account it sent us the money to, if we have several bank accounts? It is also unclear how customer calculates early settlement discount.

A: APP is used for the outgoing payments initiated by our company. Incoming payments are only processed via APP if we initiate them (i.e. direct debit).

Q11: Can we specify payment method in open items? Is it done in invoice?

A: Payment method is specified in several places in SAP system:
1) Vendor master record. You can specify several payment methods in there, and APP will automatically select the best one.
2) Directly in the invoice.
3) In the payment terms, and then this value will be inherited into the invoice.
Payment method in the invoice has a priority over the payment method in vendor master record.

Q12: I have specified payment method in the vendor master record. But it is not automatically copied into the posted invoice. Why? What should I do?

A: You can specify several payment methods in vendor master record. How should system decide which one you want to copy into the document, what do you think? That is why there is no such functionality in SAP.
As an alternative solution, you can specify payment method in the payment terms and then put payment terms into the vendor master record. Payment terms will be inherited into the document and will bring the payment method too.

Q13: Is it possible to change payment method in Payment proposal? Or we need to block the payment and change the payment method somewhere else?

A: When APP has analysed the open items and created a Payment Proposal, you can edit the Proposal: change payment methods, banks, regroup payments etc. There is a button for this on the Edit Proposal screen.

Q14: Do I need to make any developments for the APP?

A: You will need development only for the output forms, and only if:
1) extraordinary requirement from the bank in regards of output file. For example, development is required for the integration with Russian bank-client systems;
2) amend forms for cheques/ /Payment advice for the company/bank requirements (logo, fields location and other small details)

Q15: How will the bank know that it has to process the payment? What is the file format for the bank? Does APP process have a step for the output file generation?


A: Formats for the bank – you should as the bank yourself. SAP has lots of standard formats used worldwide and locally. You should only understand which ones to switch on.
Based on my own experience, international banks work well with formats SWIFT MT101 or MT103. They are in the standard delivery of PMW (Payment Medium Workbench).
Unfortunately, Russian banks a very self-conceited and only accept their own formats. One of the national standard (but not official) is format of “1C” system, but standard SAP does not support it. That is why file extract for the bank-client system is a development in this case.
Of course, file or printout for the bank is one of the results of APP work. You can generate them using the “Print” button on the instrument panel in APP.

Q16: Which format can we extract data from the system to send it to the bank?


A: It depends on the formats which bank accepts. SWIFT MT101 is very convenient and widespread. Some countries have their own requirements for the format. As a rule, they are already in SAP standard delivery.
If you are on the cross-road and do not know what to start with, try to give SWIFT MT101 file to the bank as look at their reaction. You can also ask Treasury which format they use at present.

Q17: What do I need to do in APP settings to enable generation of file with information about outgoing payments?


A: There are 6 buttons in transaction FBZP which you should start with. One of them (Payment method for the country) has a choice of “classical” payment program or Payment Medium Workbench.
Next we set up a variant for “classical” program or set up PMW (also known as DMEE).
You can find lots of customizing options for the extraction file in the IMG:
Financial Accounting > AP/AR > Business Transactions > Outgoing Payments > Automatic Outgoing Payments. Exact list of nodes you need to go into depends on format you have chosen.
IDOC is another option for the sending payments to the bank. Program RFFOEDI1 generates IDOCs and is always available in F110 on the “Print” tab.

Q18: I have decided to use SWIFT MT101 format. Which settings are required in the system in this case? Do I need to make settings for each individual bank?


A: Format MT101 is defined by SWIFT which is international organisation. It should not be changed. In the meantime, there are some parameters (fields) values in which can be changed because of requirements of client or bank.

Q19: Bank asks different structure of field 59 in format SWIFT MT101 for domestic and international payments. How should I set it up?


A: Separate payment method is usually used for international payment. Different payment methods can have different variants in PMW.

Q20: How can I set up instruction key which defines who pays commission for the payment, payer or payee? This instruction key is used in field 71A of format SWIFT MT10. How can I assign the key to the bank or vendor?


A: IMG Node
Financial Accounting (New) > Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments > Automatic Outgoing Payments > Payment Media > Data Medium Exchange > Define Instruction Keys.
You define instruction key for the payment method. Then, payment method is assigned to the vendor or invoice (see above).
By the way, my own experience shows that banks are usually ignore this instruction and always charge payer with the commission.

Q21: How can I activate functionality “State Central Bank indicator” (SCB indicator), which is used in the field 77B of format SWIFT MT101?


A: IMG Node:
Financial Accounting (New) > General Ledger Accounting (New) > Periodic Processing > Report > Foreign Trade Regulations > Enter Company Data for Foreign Trade Regulations
Here we put the Company Code, i.e. “activate” SCB for it.
Next IMG node allows us to create our own SCB indicators.
When “SCB indicator” functionality is activated for the Company Code, “Details” tab of Invoice entry transaction (FB60) will have relevant fields: SCB ind and Suppl.Cntry. The condition: vendor should belong to the country different from country of Company Code. Play with these fields and see which information is taken to the field 77B. The rest is just a technical question.

Q22: Where do I set up output forms?

A: Output forms are defined in the payment methods. You can assign program/form or Payment Payment Medium Workbench (PMW) structure. There are tons of output forms ready to use. All the standard (including European) forms are supported. Print programs can be found using the RFFO* mask. List of PMW variants can be seen using the F4 key. You can create your own PMW forms in transaction DMEE. Please read PMW and DMEE documentation.
Other than payment order itself, company may require to produce Payment Advice which informs vendor about the payment details. You can configure the form for Payment Advice in the Paying Company Code section of transaction FBZP.

Q23: Do I need to configure anything for format SWIFT MT101 in transaction DMEE? I do not see anything like this in PAYM tree. If I need to create my own format, which option to choose: flat file or XML message? How can I assign / activate my own new format?

A: Format SWIFT MT101 exists in standard PMW delivery. DMEE covers only few PMW formats. Fortunately, SWIFT MT101 requires only minimal configuration, and it is not done in DMEE. Have a look at:
Financial Accounting (New) > General Ledger Accounting (New) > Business Transactions > Outgoing Payments > Automatic Outgoing Payments> Payment Media > Make Settings for Payment Medium Formats from Payment Medium Workbench > (Adjust Payment Medium Format).
And also Create/Assign Selection Variants (OBPM4) in the same IMG node.
If you need to create something very new, you can use DMEE for configuration and then assign newly created format to payment method in the same IMG node which I already mentioned.
Type of the tree (xml / flat file) depends on the bank’s preferences and requirement.

Q24: I have run the Payment Program, posted the documents and planned the print phase. Where should I see the file in the format SWIFT MT101?

A: F110 – Environment – Payment Media

Q25: I need to print a document for vendor which informs him about payment details. Where can I configure it?


A: You can do this in transaction FBZP, section “Paying Company Code”. This is called “Payment Advice”. It is usual form. SAP has delivered form for IDES which can be adjusted with a little ABAP.

Q26: Company uses bank chains. What is this? Does APP support them?


A: Bank chains are usually used in international payments, and very rare in domestic payments. Generally speaking, banks can usually determine how to transfer money from payer to payee themselves. But if company wants to help the bank and speed up the process, bank chains can help.
In short, here is the purpose of bank chains. If you want to transfer money from one bank to another, these banks should have accounts for each other (correspondence accounts). It means that banks put money into these accounts. When client of bank A pays client of bank B, then bank B increases the balance of the correspondence account and bank A reduces the balance. There is no physical money transfer unless the balances are negative. As soon as there are too many banks in the world, it is impossible to have correspondence accounts for each pair of the banks. There are some historical banks which carry out functions of intermediate banks. For example, Bank of New York (BONY). In this case banks A and B open correspondence accounts with BONY, but not with each other. When client of bank A transfers money to client of bank B, there are only movements on the correspondence accounts which link banks (A and BONY) and (BONY and B). Again, there is no physical money movement. BONY has no impact on its balance, but it gets commissions from the transaction. If payer wants to specify bank chain, it has to let its own bank know that BONY is an intermediate bank, and sometimes correspondence accounts of bank A in BONY.
There can be 2 intermediate banks in the worst scenario.
SAP has very simple customising of bank chains. IMG Node: Financial Accounting (New) > Bank Accounting > Bank Chains. Сами банковские цепочки – это Основные данные, вводятся в основном меню Accounting – Financial Accounting – Banks – Master Data – Bank Chains.
If bank chains are active, system will automatically find the necessary chain and put it into internal table of APP. These data will get into payment order.

Q27: What are the possible options to display Payment Proposal and list of items in Proposal?

A: Payment Proposal and list of items in it can be viewed in 2 variants: classical and ALV-grid. You can customize classical display in IMG. If you want to switch display to ALV-grid, you have to put parameter in user master record (transaction SU3). Parameter code is F110OALV.
It may not work in new versions (6.0 and higher) where ALV-grid is set up as default.

Foreign currency revaluation


Q1: Transaction FAGL_FC_VAL (foreign currency revaluation) has tab "Open items" and tab "G/L balances". What is the difference? 


A: Open items tab is for revaluation of vendors, cutomers and GL accounts managed with open items. Revaluation of these items always go via special technical GL account and always reverses. Reversal is usually done for the next day which falls into next posting period.
G/L balances tab is for revaluation of GL accounts without open items management. For example, bank accounts. As a rule, revaluation goes to the same GL account, although nothing stops you from posting it to separate GL account. Then, usually GL balances revaluation is not reversed. Checkbox "Reverse postings" at the bottom of the "Postings" tab controls reversal of these revaluation postings.

Q2: I configured revaluation for KDF transaction, assigning GL account to be used for revaluation purposes. But I still have problems with account determination in FAGL_FC_VAL (foreign currency revaluation). What have I done wrong? 


A: When you specify GL accounts for KDF transaction, you do it for your Chart of Accounts. Versions with NewGL also require Valuation Area to be specified there. If you only specified Chart of Accounts, system will create records in configuration table with empty Valuation Area. These records will not be found by FAGL_FC_VAL. In order to put Valuation Area, please click small button with yellow arrow on the pop-up window with Chart of Accounts request.


Assignment fields in down payments


Q: I want to open fields like WBS-element and others in transaction F-29 (or F-37, F-47, F-48) for the customer down payments. How can I find Field Status Group for it?


A: First of all, we need to check customer or vendor reconciliation account. Transaction FD03 or FK03 correspondingly.
Then we need to find alternative reconciliation account for the target Special GL indicator. For example, we need A in case of Down Payment Request F->A. Transactions OBYR and OBXR correspondingly.
Next, check Field Status Group for the alternative reconciliation account in transaction FS00. Double click on the field gives us display of the settings of this Field Status Group. Here we can: 1) check if the field is already open; 2) see Field Status Variant for the Company Code (for future usage).
Once we confirmed on the previous step that field is hidden in the Field Status Group, we go to transaction OBC4. Here we find the necessary Field Status Group (if there are several Field Status Variants, we choose the one we found recently).
Finally, we can open necessary field in the Field Status Group.
 
If field does not appear on the Down Payment Request entry screen after the described procedure, we need to repeat it for the GL account from the Special GL indicator F. 
Not all the accounts assignments are available for the down payment posting. Availability of the field can be checked on the technical screen of down payment entry. Some skills in ABAP-components and navigation within them are required. If field exists on the technical screen, then you can dig further. If field is not there, please think again why would you need this field in the down payments.

Taxes in down payments recieved and paid


Q1: I receive the down payment (prepayment) from customer and SAP generates posting

Dr Bank118
Cr Customer Down Payment 100
Cr Output VAT18

 

Why does system behaves itself wrong way? It should be

Dr Bank118
Cr Customer Down Payment118
Cr Output VAT18
Dr VAT from down payments received 18

A: System will use special GL account "VAT from down payments" when several prerequisites are met:
  • Customer line items has Special GL indicator of "down payment" type. Check this in transactions OBXR.
  • Reconciliation account for the customer down payment should have tax category +B. Alternative GL account is defined in the same transaction OBXR. Tax category of GL account can be checked in transaction FS00.
  • Postings should contain tax code with "Output tax" category. This can be checked in transaction FTXP.
"Output VAT" GL account number is set up in tax code (the same transaction FTXP).
"VAT from down payment received" GL account number is set up in transaction OBXB for MVA transaction. You can specify the same clearing account for all down payments, or split them using the clearing account identificators. If you want to use split functionality, please tick the "Output tax clearing" checkbox in the rules for MVA transaction. Then you can specify different clearing account for different identificators in transaction OBXB. These identificators are assigned to Special GL indicators in transaction OBXR.


Q2: I pay down payment (prepayment) to vendor and SAP generates posting

Cr Bank118
Dr Vendor down payment 100
Dr Input VAT18

 

Why does system behaves itself wrong way? It should be

Cr Bank118
Dr Vendor down payment118
Dr Input VAT18
Cr VAT from down payments paid 18

A: System will use special GL account "VAT from down payments" when several prerequisites are met:
  • Vendor line items has Special GL indicator of "down payment" type. Check this in transactions OBYR.
  • Reconciliation account for the vendor down payment should have tax category -B. Alternative GL account is defined in the same transaction OBYR. Tax category of GL account can be checked in transaction FS00.
  • Postings should contain tax code with "Input tax" category. This can be checked in transaction FTXP.
"Input VAT" GL account number is set up in tax code (the same transaction FTXP).
"VAT from down payment paid" GL account number is set up in transaction OBXB for VVA transaction. You can specify the same clearing account for all down payments, or split them using the clearing account identificators. If you want to use split functionality, please tick the "Input tax clearing" checkbox in the rules for VVA transaction. Then you can specify different clearing account for different identificators in transaction OBXB. These identificators are assigned to Special GL indicators in transaction OBYR.

Integration of APP and EBS


Q1: What is the rule for GL accounts creation for payments? (APP and bank statement)

A: Each physical bank account should be configured as bank account in transaction FI12.
Additional technical accounts should b created in General ledger (transaction FS00). I would recommend naming them with a purpose description: cheques, transfers etc. They should have open itemsmanagement. You do not need to create separate “bank” accounts for technical GL accounts in FI12.
Bank accounts and GL account are linked to each other via special fields. You should only do this for real bank GL accounts, but not for technical ones.
As a ruleyou do not need special technical accounts for bank charges and exchange rate differences. Usually bank charges are posted directly to the special GL account (Cr Bank Dr Costs or Dr/Cr Bank Cr/Dr Exchange rate difference). Of course, you can only do this if bank shows these charges and FX differences as a separate transaction type. It is very arguable if bank should put exchange rate differences into bank statement or not. Please agree with a bank that these transactions are not in the statement, if you can.


Q2: Which GL accounts should be used in Automatic Payment Program (APP) from accounting point of view? Should they be the same as for bank statement? Do I need to clear these accounts?

A: YesThe process is precisely the same as described in the question itself. If you use APP to make a postings, then it should use the same GL accounts which will be posted from the bank statement from another side. These 2 open items (APP and EBS ones) should be cleared then. Doing this way, you can check which payments were sent to bank but not processed by it yet, or any other discrepancies etc.

Posting schema is like this:
1. APP – outgoing payment
Dr Vendor
Cr Bank technical outgoing payment

2. Bank statement
Dr Bank technical outgoing payment
Cr Bank

3. Technical account clearing
Cr Bank technical outgoing payment
Dr Bank technical outgoing payment
(Clearing document can have no line items in versions up to 5.0)


Q3: What is the best way to split technical bank accounts in GL? I understand they should be split by payment methods. But how will be distinguish domestic and international payments in bank statement? Do I need to create separate technical GL accounts for incoming and outgoing payments?

A: You should know the limit when split the technical accounts. If you cannot distinguish different payment methods in the bank statement, then it is useless to split GL accounts in APP. But you can always distinguish incoming and outgoing payments, so they should be definitely split.


Q4: Do I need to have the same document types in EBS and APP?

A: Usually you can use different document types for APP and EBS. This will help to distinguish them in the items list.
 

Q5: We post a payment in APP and then in EBS. Is there duplication?

ANoBank Statement has 1stand 2nd posting areas. You can choose whether you do second are or not. APP can only do send area, but only for payments generated by APP. There should not beduplication.


Q6: Automatic Payment Program can be configured with or without postings. What is the difference? I think that APP with postings makes more sense.

A: APP with postings is the most used variant in the Western countries. It reduces the configuration complexity because only one posting area will be necessary for the bank statement.
If you configure APP without postings, it only produces the payment order which you send you the bank. You should ask your bank to return payment order in corresponding field of the bank statement. Otherwise you will have very bad situation. Items paid with payment order can be only cleared via link to this payment order. They are not visible in clearing transactions with any other selection option.
Consecutively, if you have a choice, go for the postings option. Unfortunately, Russian accountants are not very flexible in these terms and prefer to make a posting on the basis of bank statement. That is why in Russia you have to configure APP without postings.


Q7: House banks are the banks in which our company has bank accounts for incoming and outgoing paymentsWhat should I do with other bank data? Do I need to maintain all the banks which are used by our vendors and customers? I heard that I need to specify bank data in the vendor or customer master record if I want to process APP correctly. Does it mean I need to maintain all the banks of our customers and vendors?

A: House banks are the banks in which our company holds the accounts. You maintain thses house bank accounts in transaction FI12.
There are also banks of our partners. You can maintain them in transaction FI02. In general, you get bank data maintenance screen (analogue of FI02) from the customer or vendor master record when specify combination of bank country and bank key which does not exist yet. System will ask you about the name, SWIFT code etc.
You have to maintain bank master data only for those payment methods which are paid directly to the bank account of our partner. Not all the payment methods require this. For example, you can draw a cheque without bank details of payee. But most of modern payment methods require bank data. It means we need to think about bank master data maintenance.
Of courseyou create any GL account (normal or technicalonly for our own bank accounts in house banks.
It is slightly confusing that both bank account and GL account are called “account”, but this is terminology we use.


Q8: We have non-standard situation with bank accountsWe have 2 house banks (A and B) with 3 bank accounts: one account in bank A and two accounts in bank B. First account in bank B is used for normal payments. Second account in bank B is only technicalThere are no direct transactionson this accountBalance of bank accounts in bank B is zero at the end of each day. Full available balance of first account automatically transfers to second account, and then from there to the account in bank A. The account in bank A is also use for normal payments. How can I configure this in SAP?

A: SAP will not be able track the balance of the bank account. We can only see the movements in the bank statement which is issued post-factum. Usually you agree with the bank all the automatic money movements, including zero-balancing. These agreements have nothing to do with SAP.
All the transfers between bank accounts for SAP are just transfers between main and technical bank accounts in General Ledger.


Q9: What is Direct Debit? How should I process it?

A: Direct Debit is a transaction when vendor automatically withdraws money from customer bank account for the goods or services sold. It is widely used in the Western countries, especially for communal payments, instalments, municipal and tax payments. Russian analogue is Payment Request which is not in common use.