SAP FICO Interview Questions and Answers - 10

221. What Happens, in SAP, when You Post a ‘Goods Receipt’?

When you post a ‘Goods Receipt’ (GR), the stock account is debited (stock quantity increases)

and the credit goes to the GR/IR Clearing Account, which is the intermediate processing

account, before you actually process the vendor invoice or payments to the vendor:

􀂃 Debit: Inventory Account

􀂃 Credit: GR/IR Clearing Account

During this (1) a material document is created, (2) an accounting document to update the relevant

GL account is created, (3) PO order history is updated, and finally (4) the system enables you to

print the GR slip.

222. Explain ‘Invoice Verification’ (IV) in SAP.

‘Invoice Verification’ involves:

1. Validating the accuracy of the invoices (quantity, value, etc.).

2. Checking for ‘blocked’ invoices (which vary to a great extent from that of the PO).

3. Matching of invoices received from vendors with that of the Purchase Order/ Goods

Receipt. At this point in time, the PO History is updated for the corresponding PO Line

Item(s) of the matched invoice.

4. Passing of matched invoices to the FI module. The system posts the following entries:

􀂃 Debit: GR/IR Clearing Account

􀂃 Credit: Vendor a/c (Accounts Payable open line item)

􀂃 Credit: GL Reconciliation Account

The different scenarios in invoice verification include:

4. GR-based Invoice Verification indicator is not set in the PO detail screen:

Although this setting enables you to post the invoice referenced to a PO prior to

making a GR, the system will block the invoice for payment (this kind of posting

results in a Quantity Variance as there has not been a GR).

5. GR-based Invoice Verification indicator is set in the PO detail screen: When the

PO number is referenced the system brings up all the unmatched items of GR in

the selection screen. You will not be able to post the invoice for its full value, unless

the PO has been fully received.

223. How do You Deal with ‘Tax’ when You Post an Invoice?

When you enter an invoice, based on the configuration settings, the system checks the Tax Code

and calculates the applicable tax or validates the Tax Amount entered by you:

1. Manual Entry: Input the Tax Code and the Tax Amount. The system will validate and

issue a message in case it does not find the tax code or if the amount is different.

2. Automatic Entry: Leave the Tax Code and Tax Amount fields blank. Check the

‘Calculate Tax’ indicator. The system picks up the corresponding tax code and calculates

the tax amount automatically.

224. What ‘Variances’ do You come Across in Invoice Verification?

The system needs to be configured properly with ‘Tolerances’ so that you are not hampered with

variances when you try Invoice Verification. You need to define the lower and upper limits for

each combination of the Company Code and the tolerance key defined for the various variances.

The system then checks these tolerance limits and issues warnings or prevents you from

proceeding further when you process an invoice.

‘Variances’ arise because of mismatch or discrepancies between the invoice and the PO against

which the invoice has been issued. Normally you will encounter:

1. Price variances: If there is a discrepancy in invoice price and PO item prices.

2. Schedule variances: If the planned delivery date is later than the invoice postings.

3. Quantity variances: If the delivered quantity (or delivered quantity less the previously

invoiced quantity) is not the same as that of the invoiced quantity. When the invoiced

quantity is more than the GR, the system requires more GRs to square off the situation.

225. Outline ‘Vendor Payments’ in the SAP System.

The payments to single or multiple vendors can either be handled in a manual process or through

an ‘Automatic Payment Program.’ The open liability item created for the vendor during the

invoice verification will be squared off when you make the vendor payment or when you run the

automatic payment program. The payment program in SAP is designed to allow you to enjoy the

maximum discount allowed by that vendor.

226. Explain ‘Automatic Payment Program.’

The ‘Automatic Payment Program’ in SAP helps to process payment transactions both with

customers and vendors. AR/AP/TR/Bank Accounting uses the payment program.

The ‘automatic payment program’ helps in determining:

􀂃 What is to be paid? To do this, you specify rules according to which the open items to

be paid are selected and grouped for payment.

􀂃 When is payment to be carried out? The due date of the open items determines when

payment is carried out. However, you can specify the payment deadline in more detail via

configuration.

􀂃 To whom the payment is made? You specify the payee (the vendor or the alternate

payee as the case may be).

􀂃 How the payment is made? You determine rules that are used to select a payment

method.

􀂃 From where the payment is made? You determine rules that are used to select a bank

and a bank account for the payment.

227. Explain ‘Automatic Payment Program’ Configuration.

Before you are ready to run the ‘Automatic Payment Program,’ the following should have been

defined/configured in the system:

􀂃 House Bank and the corresponding bank accounts.

􀂃 Payment Methods to be used for the Company Code. SAP comes with predefined

payment methods, both for AR and AP. The following payment methods are available for you

to select from depending on the requirements:

a. Accounts Payable

o Check (S)/Transfer/Postal Giro transfer/Bill of exchange

b. Accounts Receivable

o Bank collection/Bank direct debit/Refund by check/Refund by bank

transfer/BE payment request

􀂃 Bank Chain defined, if necessary. Bank chains are used to make payment via more than

one bank, for example, via the correspondence banks of the house bank, the recipient bank,

or the intermediary banks. You can define up to three banks.

􀂃 Payment Forms defined. SAP delivers standard forms, which can be modified, or new

forms can be created for use. T CODE FBZP

Figure 55: Customizing Automatic Payment program using FBZP

You may do most of the configurations by using the Transaction Code FBZP and branching to

individual sections thereon. Or you may use the following Transaction Codes for individually

doing it:

1. (Sending) Company Code specifications  T Code OBVU

a. Sending the Company Code—if Company Code ‘A’ is making payments on

behalf of ‘B,’ then ‘B’ is the Sending Company Code. Otherwise, the sending

Company Code is considered the paying Company Code (both are one and the

same).

b. Tolerance days

c. Paying Company Code specifications

􀂃 Minimum amounts for incoming and outgoing payments.

􀂃 Forms for payment advice and EDI.

􀂃 Bill of Exchange parameters

2. Payment Methods/Country and Bank determination  T Code OBVCU

a. Payment Methods/Country

􀂃 Payment Method for outgoing/incoming?

􀂃 Payment Method classification

􀂃 Master data requirements

􀂃 Posting details—document types

􀂃 Payment medium details—Print programs

􀂃 Permitted currencies (leave blank to allow all currencies)

b. Bank Determination

􀂃 Ranking Order

o Per Payment Method:

􀁸 Which bank should be used first, second, etc.

􀁸 Currency

􀁸 Bill of Exchange

􀂃 Bank accounts

􀂃 Available amounts

o Per House Bank and Payment Method combination:

􀁸 Offset a/c for subledger posting

􀁸 Available funds in each bank

􀁸 Clearing accounts for Bill of Exchange

􀂃 Value date

􀂃 Charge

3. Payment methods per Company Code T Code OBVU

a. For each Payment Method and Company Code you need to define:

􀂃 Minimum/maximum payment amounts

􀂃 Whether payment abroad or in foreign currency is allowed

􀂃 Payment Media

􀂃 Bank optimization

4. House Bank  T Code FI12

228. How do You Execute an ‘Automatic Payment Program’?

The following are the series of events happening in the system when you try to execute an

‘Automatic Payment Program’:

1. Maintain Payment Parameters

To start with, you need to maintain the parameters required such as date of execution of

‘payment run,’ ‘payment run identifier,’ etc. Once this is done, you need to specify the

‘posting date’ of these payments, the ‘document date’ up to which the program should

consider the items, the paying Company Code, payment methods to be considered, the

‘next posting date,’ is there certain accounts which need to be excluded from the run, etc.

The payment run then needs to be scheduled either immediately or at a specified

time/date.

2. Payment Proposal

The system creates a ‘payment proposal’ based on the payment parameters maintained in

(1) above. The system selects the eligible Open Items based on the following sequence:

a. Due date is determined via the Base Line Date and the Terms of Payment for

each of the line items.

b. Program calculates the Cash Discount Period and due date for the Net

Payment.

c. Grace Periods are then added to this due date.

d. Which Special GL accounts are to be included, based on what you have already

maintained as the parameters in (1) above.

e. The system will determine whether to include an item during the current run or for

the future one based on the specifications you made in (1).

f. Blocking an item.

The payment proposal can be displayed for further processing; the ‘log’ can be

checked to see the system messages, and the exception list can be generated for

further evaluation.

3. Payment Proposal

With the payment proposal available, you can now edit the proposal to:

a. Change House Bank, from what was maintained earlier

b. Change Payment Method, if necessary

c. Change Payment Due Date to relax or restrict certain open items

d. Block/Unblock line items

4. Payment Run

After the payment proposal has been edited, you can run the Payment Program that

creates the payment documents and prepares the data for printing the forms or creating

the tape or disk. Before printing the forms, check the logs to determine that the payment

program run was successful.

5. Print Run

Payment Medium Programs use the data prepared by the payment program to create

forms (payment advice, EDI accompanying sheet, etc.) or files for the data media. The

data created by the payment program is stored in the following tables:

REGUH Payee or Payment Method data

REGUP Individual Open Items data

REGUD Bank Data and Payment Amounts data

You need to define Variants for print programs, which need to be defined:

a. Per Payment Method per country->assign a Print Program

b. To run the Print Program->at least one Variant per Print Program per Payment

Method  T Code F110

229. Can You Pay a Vendor in a Currency Other than the Invoice

Currency?

With release 4.5A, you can pay a vendor in a currency that is different from that of the

transaction/invoice currency. This is achieved by entering the required currency code directly in

the open item. Prior to this release, to pay in a different currency, you had to manually process

the payment.

230. What is a ‘Payment Block’?

A ‘Payment Block’ prevents you from paying an open item of a vendor. The payment block is

entered in the ‘Payment Block’ field in a vendor master record or directly in the open line item.

Use the payment ‘Block Indicators’ to define the ‘Payment Block Reasons.’ You may use the

SAP delivered payment block indicators (A, B, I, R, etc.) or create your own. An indicator such as

‘*’ is used when you want to skip the particular account, and a blank indicator indicates that the

account/item is free for payment. However, for each of these ‘block indicators,’ you need to

configure whether changes would be allowed while processing the payment proposal. Then, it is

also possible to block a payment or release a blocked one while processing the ‘Payment

Proposal.’

You may also propose a ‘payment block indicator’ while defining Terms of Payment.

231. How do You Release ‘Blocked Invoices for Payments’?

The system will block an invoice if it comes across with an item with a ‘Blocking Reason.’ The

blocking reason may be due to variances or inspection-related issues. When the system blocks

an invoice for payment, the ‘payment block’ field is checked by the system.

You will use an ‘Invoice Release Transaction’ to select the blocked invoices for processing

further. The ‘release’ of blocked invoices for payments can be handled either manually or

automatically.

232. What is the ‘Account Assignment Category’?

The ‘Automatic Account Assignment’ logic takes care of posting to the correct GL accounts for

‘Stock Material’ with the ‘Material Type’ permitting inventory management, and the material

master contains information as to which GL account needs to be updated. But there are material

line items (‘Non-Stock’ materials) created manually in the Purchase Requisition/Purchase

Order/Outline Agreement for which someone needs to decide the account assignment data and

manually enter it in the Purchase Requisition. Here, the Account Assignment Category

determines where to allocate the costs relating to such materials. The account assignment

category helps you to define the type of account assignment (Sales Order-C, Project-P, Cost

Center-K, etc.) and which accounts are to be posted to when GR/IR is posted to.

233. What is a ‘Credit Memo’?

A ‘Credit Memo’ is issued by a vendor who has earlier supplied you some services or materials.

The occasion is necessitated when the delivered goods are damaged or you have returned some

of the goods back to the vendor. The system treats both the invoices and the credit memo in the

same way, except that the postings are done with the opposite sign.

If the credit memo is for the entire invoiced quantity, the system generates the credit memo

automatically. However, if the credit memo relates to a portion of the invoiced quantity, you need

to process it manually in the system.

234. What are ‘Special GL Transactions’?

‘Special GL Transactions’ are not directly posted to the GL (Reconciliation Accounts) though

these are related to subledger accounts such as AR/AP. The transactions to these accounts are

shown separately in the balance sheet. There are specific posting keys/indicators defined in the

system to regulate the postings to these items. You need to specify a Special GL Indicator (such

as a F-Down Payment Request, A-Down Payment) for processing such a transaction. And the

system will make use of the specially defined posting keys (09-customer debit, 19-customer credit,

29-vendor debit, and 39-vendor credit) for posting these special GL transactions.

There are three types of Special GL transactions:

􀂃 Free Offsetting Entries (Down Payment)

􀂃 Statistical Postings (Guarantee)

􀂃 Noted Items (Down Payment Request)

Figure 56: Special GL Indicators

235. Differentiate ‘Free Offsetting Entry’ from a ‘Statistical Posting.’

‘Free Offsetting Entry’ postings are part of the regular postings but with a freely definable

offsetting entry, and relate to the On-Balance Sheet Items. On the other hand, in a Statistical

Posting, you will always be posting to the same offsetting entry, and these are all the Off-

Balance Sheet Items.

236. What is a ‘Noted Item’

‘Noted Items’ are never displayed on Financial Statements as they serve only as reminders of a

financial obligation such as outstanding payments to be made or due to us, such as a ‘Down

Payment Request.’ This kind of posting does not update any GL account in the system but helps

to keep track of such obligations for easy follow-up. This is also sometimes referred to as a

‘Memo Entry.’

It is interesting to note that while the Special GL Indicator for a Down Payment Request is ‘F,’ you

need to enter the indicator ‘A’ as the target Special GL indicator while you are in the Down

Payment Request Entry Screen. When you post this entry, the system creates a one-sided

memo entry for the customer or vendor but does not update the GL.