SAP FICO Interview Questions and Answers - 7

Accounts Receivable

182. Explain ‘Customer/Vendor Master Records.’

There are three categories of data maintained in a typical master record for a customer:

􀂃 General Data

􀂃 Company Code Data

􀂃 Sales Area Data (for customers)/Purchasing Organization Data (for vendors)

Figure 40: Vendor Master—Various Data

General Data includes general information such as account number, name, telephone, bank

information, trading partner, vendor (if the customer is also a vendor), group key, bank key, bank

account, alternate payee, etc., which are common to all the Company Codes using this master.

Company Code Data comprises terms of payment, payment methods, tolerance group, clearing

with vendor, dunning data (dunning procedure, dunning recipient, dunning block, dunning clerk,

etc.), reconciliation account, sort key, sales area (purchasing organization in the case of vendor

master), head office, etc. Except for sales (purchasing) related information, all other details are

usually maintained for the finance people who can also access the sales data when the master is

maintained ‘centrally.’

Sales Area Data in the Company Code area of a Customer master record contains the following:

􀂃 Order-related data (sales district, sales office, sales group, customer group, etc.)

􀂃 Price-related data (pricing group, pricing procedure, etc.)

􀂃 Shipping data (shipping strategy, delivery priority, etc.)

􀂃 Billing data (payment terms (different from the payment terms maintained at the

Company Code level), account assignment group, etc.)

Purchasing Organization Data in the Company Code area of a Vendor master record contains

the following:

􀂃 Conditions (order currency, payment terms, Incoterms, minimum order value, etc.)

􀂃 Sales data (a/c with Vendor)

􀂃 Control data (as in the screen shot below)

During creation of a master record, the system checks for ‘duplicates’ for the same customer

which is achieved by the system through the ‘Search-Id’ (Match Code) configured on the

customer’s address information.

As in the case of the GL account master record, the creation of the customer/ vendor master

record is also controlled by the ‘Account Group,’ which is called ‘Customer Account

Group/Vendor Account Group’ (CPD/CPDL/KREDI/LIEF) and controls the numbering of

customer/vendor master records, field status, whether an account is a regular one or a ‘One-

Time’ account, etc.

Open table as spreadsheet Activity In Accounting Centrally

Customer Vendor Customer Vendor

Create FD01 FK01 XD01 XK01

Change FD02 FK02 XD02 XK02

Display FD03 FK03 XD03 XK03

Block/Unblock FD05 FK05 XD05 XK05

Mark for Deletion FD06 FK06 XD06 XK06

Figure 41: Purchasing Data

183. Who is an ‘Alternate Payee’?

A customer who pays on behalf of another customer is known as an ‘Alternate Payee’ (or

Alternate Payer). Though the alternate payee pays on behalf of another, the system maintains

all the transaction details in the account of the original customer. Designating ‘alternate payee’

does not absolve the customer of his/her obligation for payment.

The ‘alternate payee’ can be maintained in Client-specific data or in the Company Code area.

When maintained in the Company Code area you can use that payer only in that Company Code;

if defined at the Client level you can use it across all Company Codes.

There are three ways to ‘select’ the alternate payee when an invoice is processed:

1. The alternate payee (say, 1000) entered in the customer master record is the one

selected by the system as the default.

2. When there is more than one alternate payer (say, 1000, 1900, 2100, etc.) defined for a

single customer in the master record (you will do this by clicking on the ‘allowed payer’

button and create more than one payer), you may select a payer (say, 2100) (other than

the default, 1000) while processing the invoice. Now the system will ignore the alternate

payer (1000) coming from the master record.

3. If you have put a check mark in the ‘individual entries’ check box in the ‘alternate payer in

document’ section in the customer master record, then this will allow you to propose a new

alternate payer, say, 3000 (other than those already defined in the system). Now, after

defining this alternate payer you can use it to process the invoice. In this case, the

alternate payer (3000) takes precedence over the payers (1000 and 2100) in step 1 and 2

above.

184. What is the ‘Trading Partner’ concept?

The ‘Trading Partner’ concept is used to settle and reconcile ‘inter-company transactions,’ both

sales and purchases. This is generally achieved by entering the Company-ID (not the Company

Code) to which a customer belongs in the ‘trading partner’ field under the tab ‘Account Control’ in

the customer master record. You can do a similar entry in the vendor master record.

185. Explain ‘Tolerance’ in Transaction Processing.

‘Tolerances’ are defined in the system to facilitate dealing with the differences arising out of

accounting transactions and to instruct the system on how to proceed further. Normally, you

define tolerances (either in ‘absolute terms’ or in ‘percentages’) beyond which the system will not

allow you to post a document should there be a difference.

In SAP, tolerances are defined per Company Code and there are several types:

􀂃 Employee tolerance

􀂃 Customer/vendor tolerance

􀂃 GL account clearing tolerance

You will define an ‘employee tolerance group’ in the system and assign the employees to these

groups. While defining the tolerance group you will specify:

1. Upper limits for various posting procedures

􀂃 Amount per document

􀂃 Amount per open account item

􀂃 Cash discount, in percentage

2. Permitted payment differences

How much over or under payment an employee is allowed to process. This is defined both in

absolute values and in percentages.

Figure 42: FI Tolerance Group for Users

Besides defining the above two, at the Company Code level, you will also define similar

tolerances for customer/vendor tolerance group. Once defined, each of the customers

(vendors) is assigned to one of these groups. Here also, you define the ‘permitted payment

differences’:

Figure 43: Customer/Vendor Tolerances

While processing, the system compares the tolerance of an employee against the customer

tolerance (or vendor tolerance or the GL) and applies the most restrictive of the two.

186. What is ‘Dual Control’ in Master Records?

‘Dual Control’ helps to prevent unauthorized changes to the important and ‘sensitive’ fields in the

master records in the system. (All such sensitive fields are defined in the Table T055F when

customizing the application. And these fields are defined per Company Code and per Client.)

Consider, for example, a sensitive field such as ‘payment block’ in a vendor master record.

When a user changes this field’s content, the system requires another user (usually of higher

authority) to approve this change and an audit trail is maintained of all such changes. Unless '

the change is approved, in this example, this particular master is blocked by the system for

considering the same in the next ‘payment run.’

Open table as spreadsheet Activity Customer Vendor

Display changes (accounting area) FD04 FK04

Display changes (centrally) XD04 XK04

Confirm changes, individually FD08 FK08

Confirm changes, in a list FD09 FK09

187. What is a ‘Bank Director’ in SAP?

SAP stores the master data (details such as bank key, bank name, bank country, bank address,

and so on) relating to the banks in the ‘Bank Directory’ (Table: BNKA). Remember, the ‘bank

masters’ are not created in the application but in the implementation side using the IMG. (Of

course, you can also create the bank master in the application side in FI-TR and not in FI-GL or

AP or AR.) However, if you are in the process of creating a master record for a vendor or a

customer and you enter some bank details, which the system does not find in the ‘Bank

Directory,’ then the system automatically brings in the relevant screens for you to maintain and

update the bank details in the bank directory.

You may create the bank directory in two ways:

1. Manually (IMG path: Financial Accounting>Bank Accounting>Bank Accounts>Define

‘House Banks’)

2. Automatically (by importing the bank details using a special program)

188. What is a ‘House Bank’?

A ‘House Bank’ is the bank (or financial institution) in which the Company Code in question

keeps its money and does the transactions from. A house bank in SAP is identified by a 5-

character alphanumeric code. You can have any number of house banks for your Company Code,

and the details of all these house banks are available in the ‘bank directory.’

Figure 44: Bank directory

Each ‘house bank’ in the system is associated with a country key (U.S., IN, etc.) representing

the country where the bank is located, and a unique country specific code called a ‘bank key.’

The system makes use of both the ‘country key’ and the ‘bank key’ to identify a ‘house bank.’

􀂃 For each of the ‘house banks,’ you can maintain more than one bank account; each such

account is identified by an account ID; i.e., Chek1, Check2, Pybl1, etc. Here, ‘Chek1’ may

denote Checking account 1, ‘Pybl1’ may denote Payables account 1, and so on. You may

name the accounts in a way that it is easily comprehensible. The ‘Account ID’ is referenced

in the customer/vendor master record and it is used in the payment program by the system.

􀂃 For each ‘account ID’ you will also specify the bank account number (maximum length

of this identifier is 18 characters). You may name this in such a way that it is also easily

comprehensible.

􀂃 For each ‘bank account number’ so defined in the ‘house bank,’ you need to create a GL

account master record, and while doing so you will incorporate the ‘house bank id’ and the

‘account id’ in that particular GL master record.

189. Explain a ‘Sales Cycle’ in SAP.

A ‘Sales Cycle’ comprises all activities including quotation/inquiry, sales order, delivery, billing,

and collection. The following are the various processes within SAP that complete a sales cycle:

Figure 45: Sales Cycle

Typically, the following are the documents created during a sales cycle:

􀂃 Inquiry

􀂃 Quotation

􀂃 Sales Order

􀂃 Delivery Note

􀂃 Goods Issue

􀂃 Order Invoice

􀂃 Credit/Debit Note

190. Explain ‘Automatic Account Assignment’ in SD.

During goods issue in the sales cycle, the system is usually configured to update the relevant GL

accounts automatically and to create the relevant accounting documents. This customization in

IMG is also called material account assignment and is achieved through a number of steps as

detailed below:

1. Determine ‘valuation level’ (Company Code or plant).

2. Activate ‘valuation grouping code’ and link it with the ‘chart of accounts’ for each

‘valuation area.’

3. Link ‘valuation class’ with ‘material type’ (FERT, HAWA, HALB, etc.) with the ‘account

category reference’ (combination of valuation classes).

4. Maintain ‘account modification codes’ for ‘movement types.’

5. Link ‘account modification codes’ with ‘process keys’ (transaction/event keys).

6. Maintain a GL account for a given combination of ‘chart of accounts’+ ‘valuation grouping

code ‘+’ account modification code ‘+’ valuation classes.’

Figure 46: Automatic account determination in a sales cycle

The process of Automatic Account Determination is as follows:

1. Depending on the ‘plant’ entered during goods issue (GI), the ‘Company Code’ is

determined by the system which in turn determines the relevant ‘Chart of Accounts.’

2. The plant thus entered in goods issue determines the ‘valuation class’ and then the

‘valuation grouping code.’

3. The ‘valuation class’ is determined from the ‘material master.’

4. Since the ‘account modification code’ is assigned to a ‘process key’ which is already

linked to a ‘movement type,’ the ‘transaction key’ (DIF, GBB, AUM, BSX, etc.) determines

the ‘GL account’ as posting transactions are predefined for each ‘movement type’ in

‘inventory management.’