101. What is a ‘Posting Period Variant’?
A ‘Posting Period Variant’ is useful in ‘opening/closing’ posting periods across many Company Codes at one time. You define a posting period variant and assign it to various Company Codes. Since the posting period variant is cross-Company Code, the opening and closing of the posting period is made simple. Instead of opening and closing individually for different Company Codes, you just need to open or close the posting period variant.
102. Can You Selectively ‘Open’ and ‘Close’ accounts?
Yes. It is possible to selectively control the ‘opening’ and ‘closing’ for various types of accounts. Usually, a ‘+’ is mentioned in the top-most entry indicating that all the account types are allowed for posting. Now, for the GL(S) accounts, you will need to specify the period which needs to be opened. This ensures that all the account types are open for the current period, indicated by ‘+,’ and only the GL accounts are open for the previous period.
Select account types can also be opened or closed for a specific period; select accounts within an account type can also be opened or closed.
103. Why is it not Possible to Post to a Customer A/C in a Previously Closed ‘Period’?
When you want to selectively ‘close’ or ‘open’ the posting period of some accounts (account range), there will be no problem with that if you are doing it for GL accounts. But, if it is a subledger account (such as the customer), it has to be achieved via opening or closing the account interval of the ‘reconciliation account’ of that account type.
104. Can You Open a ‘Posting Period’ only for a Particular User?
Yes. SAP allows you to open or close the posting period only for specific users. This can be achieved by maintaining an authorization group at the document header level.
105. What is a ‘Special Period’? When do You Use it?
Besides the normal posting periods, SAP allows for defining a maximum four more posting periods, which are known as ‘Special Periods’ as these are used for year-end closing activities. This is achieved by dividing the last posting period into more than one (maximum four) period. However, all the postings in these special periods should fall within the last posting period.
The special periods cannot be determined automatically by the system based on the posting date of the document. The special period needs to be manually entered into the ‘posting period’ field in the document header.
106. What is the Maximum Number of ‘Posting Periods’ in SAP?
Under GL accounting, you can have a maximum of 16 posting periods (12 regular plus 4 Special Periods). However, you can have up to a maximum of 366 posting periods as is the case in ‘special purpose ledgers.’
107. What is a ‘Special Purpose Ledger’?
‘Special Purpose Ledgers’ (FI-SL) are used in reporting. These are basically user-defined ledgers, which can be maintained either as GL or subsidiary ones with various account assignment objects (with SAP-dimensions such as cost center, business area, profit center, etc., or customer-defined dimensions such as region, area, etc.).
Once defined, this functionality helps you to report at various levels. Ideally you collect the information, combine it, and create the totals. This is something such as an additional reporting feature, and use of this feature will have no effect on the regular functionalities of SAP.
108. What Variations are Possible when Defining a ‘Fiscal Year’?
The Fiscal Year is the same as a Calendar Year
The fiscal year starts on January 1 and there are 12 posting periods; the posting periods correspond to the calendar months; there is no need to define each of the posting periods.
The Fiscal Year is NOT the same as a Calendar Year
In this case, you need to specify how many posting periods you want and how the system should derive the posting period. Since the posting period does not correspond to the calendar month, the start and end date of each of the posting periods need to be maintained.
109. What is known as ‘Year Shift/Displacement’ in a Fiscal Year?
When the fiscal year is not the same as the calendar year, we need to define a ‘displacement factor’ for each of the posting periods to correctly identify the number of posting periods.
For example, consider the fiscal year variant V3 (Figure 25). The fiscal year starts on April 1st and ends on March 31st of the next calendar year so the displacement factor or year shift from April to December is ‘0,’ and for January to March, it will be ‘−1’. By defining it this way, the system is able to recognize the correct posting period. A posting made on January 25th, 2006 will then be interpreted as the 10th posting period in fiscal year 2005.
Figure 25: Year shift/displacement in Fiscal Year Variant
110. Can You have ‘non-Calendar’ Months as ‘Periods’ in a ‘non-Calendar’ Fiscal Year?
Yes. The ‘non-calendar fiscal year’ can either correspond to calendar months or to non-calendar months.
In the case of non-calendar months as the posting periods, you need to specify the start and end date of these posting periods. Consider a fiscal year starting on April 16th, 2005 and ending on April 15th, 2006. Here, the posting period-1 starts on April 16th and ends on May 15th and so on. Note that the posting period-9 will have 2 displacements (0 and −1) as indicated below in the Table:
As a result, a posting made on December 27th, 2005, as well as the posting made on January 14th, 2006 are correctly identified as postings corresponding to period-9.
111. What is a ‘Year-dependent’ Fiscal Year?
A calendar year fiscal variant, when defined as ‘year-dependent,’ is relevant and valid only for that year.
112. What Precautions should you Take while Defining a ‘Shortened Fiscal Year’?
Note that the ‘Shortened Fiscal Year’ is always year-dependent. This has to be followed or preceded by a full fiscal year (12 months). Both the shortened and the full fiscal year, in this case, have to be defined using a single fiscal year variant.
113. Tell me more about a ‘Shortened Fiscal Year.’
As mentioned already, a ‘Shortened Fiscal Year’ is one containing less than 12 months. This kind of fiscal year is required when you are in the process of setting up a company, or when you switch over one fiscal year (e.g., calendar year) to another type of fiscal year (non-calendar).
114. How do You Open a new ‘Fiscal Year’ in the System?
You do not need to ‘open’ the new fiscal year as a separate activity. Once you make a posting into the new fiscal year, the new fiscal year is automatically opened. Or, the new fiscal year is automatically opened when you run the ‘balance carry-forward’ program.
However, you need to have (1) the relevant posting period already open in the new fiscal year, (2) completed the document number range assignment if you are following a year-dependent number range assignment, and (3) defined a new fiscal year variant if you follow the year-dependent fiscal year variant.
115. How do you ‘Carry-Forward’ Account Balances?
If you have already posted into the new fiscal year, you do not need to ‘carry-forward’ the balances manually. But you can use the various ‘carry-forward’ programs supplied by SAP for this task.
116. Can You Explain how ‘Carry-Forward’ Happens in SAP?
Sure. For all the Balance Sheet items, the balances of these accounts are just carried forward to the new fiscal year, along with account assignments if any. This also true for customer and vendor accounts.
In the case of Profit & Loss accounts, the system carries forward the profit or loss (in the local currency) to the Retained Earnings account, and the balances of these accounts are set to ‘0.’ No additional account assignments are transferred.
117. Is there a Prerequisite for ‘Carry-Forward’ Activity?
Yes, for Profit & Loss accounts, you should have defined the Retained Earnings account in the system. Additionally, you should have also specified the ‘Profit & Loss Account Type’ in the master record of each of these for Profit & Loss accounts.
There are no such requirements for GL accounts, customer and vendor accounts.
118. How many ‘Retained Earnings’ A/C can be Defined?
You can define as many ‘Retained Earnings Accounts’ as you need. But normally, companies use only one retained earnings account. Remember, to define more than one, you should use the profit & loss account type.
119. Can You have Multiple ‘Retained Earnings’ A/C?
Normally it is sufficient if you use one ‘retained earnings’ account. However, if you are configuring for a multinational company where the legal requirements require treating some of the tax provisions differently from other countries, then you will need more than one retained earnings account.
120. How do You Maintain ‘Currency’ in SAP?
‘Currency’ (the legal means of payment in a country) in SAP is denoted by a 3-character Currency Code, maintained per ISO standards. Example: USD (U.S. Dollars), INR (Indian Rupee), GBP (Great Britain Pound), etc. Each currency code in the system will have a validity defined.
A currency is defined in SAP using the IMG path: General settings>Currencies >Check exchange rate types.
121. What is a ‘Local Currency’?
When you define a Company Code, you also need to mention in which currency you will be maintaining the accounts/ledgers in financial accounting. This currency is called the ‘Local Currency.’ This is also known as ‘Company Code Currency.’
122. What is a ‘Parallel Currency’?
When defining the currencies for a Company Code, it is possible to maintain, for each of these company Codes, two more currencies in addition to the ‘Local Currency.’ These two currencies are called the ‘Parallel Currencies,’ which can be the:
• Group Currency
• Hard Currency
• Global Company Currency
• Index-based Currency
To translate the values from one currency to the other, you will need to maintain an exchange rate for each pair of the defined currencies in the system. When parallel currencies are defined, the system maintains the accounting ledgers in these currencies as well, in addition to the local currency.
123. What is a ‘Group Currency’?
This is the currency defined at the Client level.
124. What is the ‘Global Company Code Currency’?
The currency defined for the Company (or the Consolidated Company) is called the ‘Global Company Code Currency.’
125. What is an ‘Account Currency’?
When defining the GL accounts in the system, you are required to define a currency in which an account will be maintained, and this is called the ‘Account Currency.’ This is defined in the ‘Company Code’ area of the GL master record, and is used for postings and account balance display.
126. What are all the Prerequisites for Posting in a ‘Foreign Currency’?
The following are the prerequisites you need to consider before posting in a foreign currency:
• Local currency already defined for the Company Code (in the global parameters)
• Foreign currency defined in the currency code Table
• Exchange rate defined for the foreign currency and the local currency
• Translation Ratio maintained for the local and foreign currency
127. How are ‘Exchange Rates’ Maintained in SAP?
An ‘Exchange Rate’ is defined for each pair of currencies, and for each ‘exchange rate type’ defined in the system. The exchange rate is defined at the document header level.
128. What is an ‘Exchange Rate Type’? List some of them.
The ‘Exchange Rate Type’ is defined according to various purposes such as valuation, translation, planning, conversion, etc. The commonly used exchange rate types include:
Figure 26: Exchange Rate Types
129. What is known as the ‘Translation Factor’?
The relation between a pair of currencies per ‘exchange rate type’ is known as the ‘Translation Factor.’ For example, the translation factor is 1 when you define the exchange rate for the currencies USD and INR:
130. Is there an Easy Way to Maintain Exchange Rates in SAP?
SAP offers a variety of tools to maintain exchange rates on an on-going basis. The tools include:
• Exchange Rate Spreads
• Base Currency
• Inversion
Use the SAP supplied program, RFTBFF00, for populating the exchange rate table automatically from an input file in a multi-cash format from a commercially available input file.
131. What is known as an ‘Exchange Rate Spread’?
The difference between the ‘bank-buying rate’ and the ‘bank selling rate’ is known as the ‘Exchange Rate Spread,’ which remains almost constant. When you maintain the exchange rate spread, it is sufficient if you maintain the ‘average rate’ for that currency in question in the system as you will be able to deduce the buying/selling rate by adding/subtracting the spread to/from the average rate.
132. Explain the use of ‘Direct’ or ‘Indirect Quotations.’
It is possible to maintain the exchange rates, in SAP, by either of these two methods. What determines the use of a particular type of quotation is the business transaction or the market standard (of that country).
SAP adopts two prefixes to differentiate direct and indirect quotes during entering/displaying a transaction:
• ‘’—Blank, no prefix. Used in Direct Quotation
• ‘/’—Used in Indirect Quotation
When there is no prefix entered, (blank), the quotation is construed as the ‘direct quote’ by the system. Possible scenarios include:
• The company in question is mainly using the ‘Indirect Quotation.’
Use ‘’ (blank) as the prefix for default notation for indirect quotation. Use ‘*’ as the prefix for the rarely used direct quotation. If someone tries entering a transaction using direct quotation, but without the ‘*’ in the exchange rate input field, the system will issue a warning.
1. The company in question is mainly using the ‘Direct Quotation.’
You do not need any specific settings as the default is the ‘’ (blank) prefix for the direct quotation, and ‘/’ for the indirect quotation. So, unless you make a transaction entry with ‘/’ prefix, the system takes all the entries as that of direct quotation.
2. There could be instances where you are required to configure in such a way that a prefix is mandatory irrespective of the type of quotation. In this case, define the direct quotation prefix as ‘*’, and the indirect one as the system default ‘/’ prefix. This necessitates a prefix each of the entries either by ‘*’ or ‘/.’ Otherwise, the user will get a warning to correct the entry.
133. Explain how ‘Taxes’ are Handled in SAP.
SAP takes care of tax calculation, tax postings, tax adjustments, and tax reporting through the three FI components; namely GL, AP, and AR. The processing of the following kinds of taxes is possible:
1. Tax on Sales and Purchases
a. Input Taxes (Purchase Tax)
b. Output Taxes (Sales Tax)
2. Additional Taxes (these are country specific and in addition to the tax on sales and purchases)
3. Sales Tax
4. Withholding Tax
a. Classic Withholding Tax
b. Extended Withholding Tax
SAP allows taxation at three levels:
1. National level or federal level (Europe, South Africa, Australia, etc.)
2. Regional or jurisdiction level (USA)
3. National and Regional level (India, Canada, Brazil etc.)
134. How is Tax Calculated in SAP?
SAP uses a technique called ‘Condition Method’ to calculate taxes (except Withholding Tax) in the system. The system makes use of ‘Tax (Calculation) Procedures’ defined in the system together with the Tax Codes for calculating the quantity of tax.
1. The Tax Code is the starting point in the tax calculation. The tax code is country specific, with every country having a country specific Tax Procedure defined in the standard system, which is used as the template for defining various tax codes. The system uses the tax code to verify the following:
Figure 27: Condition Type (Tax Processing)
a. Tax type
b. Amount of tax calculated/entered
c. GL account for tax posting
d. Calculation of additional tax portion, if any
2. Tax Rates are defined for each of the tax codes. The tax rates are then associated with Tax Types, which are included in the tax procedures. (Because of this relationship, it is technically possible that a single tax code can have multiple tax rates for various tax types.)
3. The tax code is assigned to a Tax Procedure, which is tagged to a GL master record. A particular tax procedure is accessed whenever that GL account is used in document processing.
Figure 28: Steps in Tax processing
A Tax Procedure contains the following:
• Steps— To determine the sequence of lines within the procedure.
• Condition Types— Indicates how the tax calculation model will work (whether the records are for fixed amount or percentages and whether the records can be processed automatically, etc.)
• Reference Steps— Where the system obtains the amount/value it uses in its calculation (for example, the base amount)
• Account/Process Keys— Provide the link between the tax procedure and the GL accounts to which tax data is posted. This helps in automatic tax account assignments. To enable that these keys have the necessary information for automatic assignment, you need to define the following:
o Posting keys (unless you have a specific requirement, it will be sufficient to use the GL posting keys: Debit: 40, Credit: 50)
o Rules to determine on which fields the account determination is to be based (such as the tax code or country key)
o Tax accounts to which the postings need to be made
SAP comes with a number of predefined account/process keys, and it is recommended that the standard keys be used.
4. The Access Sequence helps in identifying the sequence of Condition Tables to be used and identifying which field contents are the ‘criteria’ for reading the Condition Tables (a group of Condition Types).
5. The tax amount so calculated is normally posted to the same side as the GL posting that contains the tax code. When exchange rate differences occur (due to tax adjustments in foreign currencies) these differences are generally posted to the specific account(s) for exchange rate differences. However, it is possible to specify (per Company Code) that the exchange rates for tax items can also be entered manually or determined by the posting or the document date, and the resulting differences posted to a special account.
Figure 29: Account/Process Key for tax processing
6. R/3 has a number of predefined account keys, and it is recommended that the standard keys be used.
135. Explain the Configurations Required for Taxes in SAP.
You need to define the following to customize SAP for this purpose:
1. Base Amount for Tax Calculation
For each Company Code you need to define whether the Base Amount includes the cash discount as well. If the base amount includes the discount, then the tax base is called ‘Gross,’ otherwise, it is ‘Net.’ You may also define a similar base amount for calculating the ‘Cash Discount.’ This also has to be maintained for each of the Company Codes.
2. Tax Codes
The Tax Code is a 2-digit code specifying the percentage of tax to be calculated on the base amount. While defining the tax code, you will also specify the ‘Tax Type’ to classify a tax code relating to either ‘Input Tax’ or ‘Output Tax.’ The tax types are country specific and determine how a tax is calculated and posted.
3. Tax Rate
The Tax Rate is the percentage of tax to be calculated on a base amount. You will be able to define tax rates for one or more tax types when you define a single tax code.
4. Check Indicators
By using the check indicators, you configure the system to issue Error/Warning Messages when the tax amount entered manually is incorrect.
136. What is a (Tax) ‘Jurisdiction Code’?
A ‘Jurisdiction Code,’ used in countries such as the United States, is a combination of the codes defined by tax authorities. It is possible to define up to four tax levels below the federal level. The four levels can be the:
• Sub-city level
• City level
• Country level
• State level
Before you can use the jurisdiction codes for tax calculation, you need to define the following:
1. Access Sequence (to include the country/tax code/jurisdiction fields)
2. Condition Types (which references the access sequence as defined above)
3. Jurisdiction Codes
The tax rates are defined in the tax code by jurisdiction. When posting taxes with a jurisdiction code, note that the taxes may be entered per jurisdiction code or per tax level.
137. Tell me about the ‘Tax Reports’ in SAP.
SAP comes delivered with country-specific default ‘Tax Reports’ to meet your tax-reporting requirements. However, it is not uncommon to use third-party software for the same purpose. As a process, it is recommended that the ‘closing operations’ are completed before running the tax reports. This will ensure that the system makes relevant adjustment entries (between payables and receivables, exchange rate differences, etc.) so that the correct tax amounts are reported.
138. How is ‘Master Data’ different from ‘Transaction Data’?
There are three kinds of data residing in any SAP system:
1. Table Data
2. Transaction Data
3. Master Data
Table Data refers to the customized information for a particular Client. This includes data such as payment terms, discounts, pricing, tolerance limits, etc., which you do not normally change on a day-to-day basis.
Transaction Data is the day-to-day recording of business information such as purchase orders, sales returns, invoices, payments, collections, etc. This includes both system-generated data (tax, discount, etc., automatically calculated by the system during document posting) as well as user-generated data.
Master Data is the control information required to decide how transaction data gets posted into various accounts (such as customers, vendors, GL, etc.). The master data is usually shared across modules (for example, customer master records are common both to FI and SD in SAP) obviating the need for defining it in various application areas. The master data remains in the system for fairly a long period.
In the case of GL Master Records, the data is created in two areas:
1. Chart of Accounts Area (common to all Company Codes: Chart of accounts, GL account number, account name (short and long text), B/S or P&L indicator, account group, etc.).
2. Company Code Area (specific to that particular Company Code: Company Code, tax code, currency, open item management, line item display, sort key, etc.).
In the case of the Customer/Vendor Master Record, the data is created in two areas:
1. Client Specific (general data such as account number, name, telephone, bank information, etc., which is common to all the Company Codes using this master).
2. Company Code Specific (valid only for the Company Code, this includes: terms of payment, dunning procedure, reconciliation account, sort key, sales area, purchasing information, etc.).
139. Can You Post an A/C Document if the ‘Credit’ is not Equal to the ‘Debit’?
In general, unless the ‘debits’ equal the ‘credits’ in a document, you will not be able to post the document. However, the system allows you to post some of the documents, even if this not true, which includes the following:
• Noted items: this will contain only a debit or credit. Since there is no updating of accounting entries, the system will allow you to go ahead with the posting of these items.
General Ledger Accounting
140. What is a ‘Document’ in SAP?
SAP is based on the ‘document principle’ meaning that a document is created out of every business transaction in the system. The Document is the result of a posting in accounting in SAP, and is the connecting link between various business operations. There are two types of documents:
1. Original Documents: these documents relate to the origin of business transactions such as invoices, receipts, statement of accounts from bank, etc.
2. Processing Documents: These include ‘accounting documents’ generated from postings in the system, ‘reference documents,’ ‘sample documents,’ etc. The processing documents other than the accounting ones are also known as ‘special documents’ and they aid in the simplification of document entry in the system.
Every document consists of:
• A Document Header
• Two or more Line Items
Before attempting to enter a document, call up the relevant document entry function as the system provides a variety of ready-made document entry templates suited to different transactions such as regular GL entry, customer invoice posting, etc. The details entered in a document can be simulated and displayed before the document is actually posted in the system. You may also choose to ‘park’ the document and post it later.
141. What is a ‘Document Header’?
The ‘Document Header’ contains information that is valid for the whole document such as:
• Document Date
• Document Type (Control Information)
• Document Number
• Posting Date
• Posting Period
• Company Code
Besides the above, the document header also has information (editable, later on) such as (a) trading partner, (b) document header text, (c) reference, (d) cross-Company Code number, etc.
142. What is a ‘Document Type’?
SAP comes delivered with a number of ‘Document Types,’ which are used in various postings. The document type helps to classify an accounting transaction within the system, and is used to control the entire transaction and determine the account types a particular document type can post to. For example, the document type ‘AB’ allows you to post to all the accounts, whereas type ‘DZ’ allows you to post only the customer payments. Every document type is assigned a number range.
The common document types include:
143. How is ‘Account Type’ Connected to ‘Document Type’?
The ‘Document Type’ is characterized by a 2-character code such as AA, DG, etc., whereas an ‘Account Type’ is denoted by a 1-character code such as A, D, etc., specifying which accounts a particular document can be posted to. The common account types include:
• A Assets
• D Customer (Debtor)
• K Vendor (Creditor)
• M Materials
• S GL
Figure 30: Document and Account Types
144. What do You mean by ‘Net’ Postings’?
Usually, when a transaction is posted, for example, a vendor invoice (document type: KR), the system posts the ‘Gross’ amount with the ‘tax’ and ‘discount’ included. However, SAP provides you the option of posting these items as ‘Net.’ In this case, the posting excludes ‘tax’ or ‘discounts.’ Remember to use the special document type KN. (Similarly, you will use the document type DN for ‘customer invoice-Net’ compared to the normal invoice postings for the customer using the document type DR.) For using this ‘net method’ of posting you should have activated the required settings in the customization.
145. Explain the Various ‘Reference Methods.’
SAP recommends ‘Reference Methods’ as a ‘document entry tool’ to facilitate faster and easier document entry into the system, when you are required to enter the same data time and again. Besides making the document entry process less time-consuming, this also helps in error-free document entry.
The various Reference Methods used in SAP include:
1. Reference Documents
2. Account Assignment Models
3. Sample Documents
146. What is the ‘Document Change Rule’?
The functionality ‘Document Change Rules’ configured in the system maintains the information relating to ‘what fields can be changed?’ and ‘under what circumstances?.’ As you are already aware, SAP’s document principle does not allow changing the ‘relevant’ fields once a document is posted; any changes can only be achieved through ‘Reversal’ or additional postings. Fields such as company code, business area, account number, posting key, amount, currency, etc., can never be changed once the document is posted. However, SAP allows changing some of the fields in the line items such as payment method, payment block, house bank, dunning level, dunning block, etc. These can be changed document by document or by using ‘mass change’ for a number of documents in a single step.
The changes to ‘master data’ are tracked and stored per user for an ‘audit trail.’
147. Differentiate between ‘Account Assignment Model,’ ‘Recurring Entries,’ and ‘Sample Document,’
‘Account Assignment Model’ is a ‘reference method’ used in document entry when the same distribution of amounts to several Company Codes, cost centers, accounts, etc., is frequently used. Instead of manually distributing the amount among accounts or Company Codes, you may use equivalence numbers for distributing both the credit and debit amounts. A cross-Company Code account assignment model can also be created.
The account assignment model may contain any number of GL accounts. The GL account items need not be complete. The model can be used across several Company Codes, and can even include Company Codes from non-SAP systems.
Figure 31: Account Assignment Model
• You can use the account assignment model while ‘parking’ a document (but you cannot use a ‘reference document’ for ‘parking’).
• The use of account assignment models is limited to GL accounts.
Unlike a ‘Sample Document,’ an account assignment model may be incomplete and can be completed during document entry by adding or deleting or changing the data already saved in the model.
The ‘Recurring Entry’ original document is used by the system as a ‘reference document’ for enabling posting of periodically recurring postings such as loan repayments, insurance premium payments, rent, etc. Since this document is not an accounting document, the account balances are not affected. In a recurring entry original document, you will not be able to change the (a) posting key, (b) account, and (c) amount. The recurring entry documents are defined with a special number range (X1). Unlike an account assignment model, these documents cannot be used for cross-Company Code postings.
The recurring entry document does not update transaction figures, per se, but acts only as a reference and as the basis for creating accounting documents. The SAP program SAPF120 creates the accounting documents from the recurring entry original document. There are two ways to set the exact date when this document should be posted to:
• Posting frequency: enter the day of the month and the period (in months) between two postings.
• Scheduled run: configure the ‘run schedule’ specifying the calendar days on which the program should post these documents.
A Sample Document is like a template, which is created and stored so that the information contained therein can be easily copied into new documents and posted in the system. But once a sample document is created note that you will not be able to change the ‘line items’ already contained in that document; all you can do is change the amounts in that sample document. But you can overcome this by defining a new sample document that can contain other line items or you may add new line items to the FI document, which is created by copying from the original sample document.
Sample documents have separate number ranges (X2).
148. What is a ‘Line Item’?
The ‘Line Items’ contain information relating to account number, amount, debit/ credit, tax code, amount, etc. SAP allows a maximum of 999 line items in a single document. Besides the one entered by you during an document entry, the system may also create its own line items called ‘system generated line items,’ such as tax deductions, etc. Irrespective of the number of line items entered, ensure that the total of these is always zero (that is, total debits should equal total credits). Otherwise, the system will not allow you to post the document.
149. What is a ‘Posting Key’?
A ‘Posting Key’ in SAP is a 2-digit alphanumeric key that controls the entry of line items. SAP comes with many posting keys for meeting the different business transaction requirements: 40 (GL debit), 50 (GL credit), 01 (customer invoice), 11 (customer credit memo), 21 (vendor credit memo), 31 (vendor payment), etc.
The posting key determines:
1. What account can be posted to
2. Which side of the account (debit or credit) to be posted to, and
3. What ‘layout’ screen needs to be used for that particular transaction.
It is a normal practice not to change any of the default posting keys in the system, as you would very rarely require additional posting keys.
150. Differentiate between the ‘Parking’ and the ‘Holding’ of Documents.
The ‘Parking of a Document’ in SAP is one of the two preliminary postings (the other being the ‘Holding’ of documents) in the system and refers to the storing of incomplete documents in the system. These documents can later be called on for completion and posting. While ‘parking’ a document, the system does not carry out the mandatory ‘validity checking.’ The system does not also carry out any automatic postings (such as creating tax line items) or ‘balance checks.’ As a result, the transaction figures (account balances) are not updated. This is true in the case of all financial transactions except in the area of TR-CM (Cash management) where ‘parked’ documents will update the transactions.
The parking of documents can be used to ‘park’ data relating to customers, vendors, or assets (acquisition only). When a cross-Company Code document is ‘parked,’ only one document is created in the initial Company Code; when this ‘parked’ document is posted all other documents relevant for all other Company Codes will also be created. However, it is to be noted that substitution functionality cannot be used with document ‘parking,’ as substitution is activated only on transaction processing.
The added advantage is that a document ‘parked’ by an accounting clerk can be called on for completion by someone else. The ‘parked’ documents can be displayed individually or as a list from where the required document can be selected for completion and posting. The number of the ‘parked’ document is transferred to the posted document. The original ‘parked’ document, if necessary, can be displayed even after it has been posted to.
During a transaction when you do not have a piece of required information, you can ‘Hold the Document’ and complete it later. As in the case of ‘parked’ documents, here also the document does not update the transaction figures.
The essential difference between these two types of preliminary postings can be summarized as follows:
151. What is an ‘Automatic Posting’?
When you post documents in SAP, there are instances where the system also adds some more line items (such as tax, cash discount, gain/loss from foreign exchange transactions, etc.) besides the ones you have entered in the document. This helps to reduce your work as the system calculates these automatically. However, you need to define accounts you want the system to automatically post to; this will ensure that no manual posting is allowed to any of these accounts.
152. What is ‘Clearing’?
‘Clearing’ in SAP refers to squaring-off open debit entries with that of open credit entries. Clearing is allowed in GL accounts maintained on an ‘open item’ basis and in all customer/vendor accounts. The clearing can either be manual or automatic. In the case of manual clearing, you will view the open items and select the matching items for clearing. In the case of automatic clearing, a program determines what items need to be cleared based on certain pre-determined open item selection criteria and proposes assignments before clearing these assigned items. Whatever the type of clearing, the system creates a clearing document with the details and enters the ‘clearing number’ against each of the cleared open items. The clearing number is derived from the document number of the clearing document.
You will also be able to do a ‘partial clearing’ when you are unable to match open items exactly; in this case, the balance amount not cleared is posted as a new open item. You may also configure clearing tolerance and also define rules on how to tackle the situation where the net amount after clearing is not zero (such as, writing off, posting the difference to a separate ‘clearing difference’ account, etc.).
In the case of customers who are also vendors, you will be able to clear between these two provided it is duly configured in the relevant master data (by entering the customer number in the vendor master record and the vendor number in the customer master record).
153. Explain ‘Reversal of Documents’ in SAP.
If you need to change some of the accounting information relating to an already posted document, you can only achieve this by ‘Reversing’ the original document and posting a new one with the correct information. However, reversal is possible only when:
• The origin of the document is in FI (not through SD or MM, etc.)
• The information such as business area, cost center, etc., is still valid (that you have not deleted these business objects)
• The original document has no cleared items
• The document relates only to the line items of customer/vendor/GL
While reversing, the system automatically selects the appropriate document type for the reversal, and defaults the relevant posting keys. (Remember that the document type for the reversal document would have already been configured when the document type was defined in the configuration.) Also note that if you do not specify the posting date for the reversal document, the system defaults to the posting date of the original document.
154. Explain ‘True Reversal,’ How is it different from regular ‘Reversal’?
As you are aware, any reversal results in opposite postings to the credit/debit sides of the original posting, leading to an increase in the account balances and the ‘trial balance’ is automatically inflated on both the sides. This is against the law in some countries such as France where it is required that even after reversal, there should not be an increased account balance. As a result, SAP came out with ‘True Reversal’ which overcomes this problem by ‘negative postings’ to the same line item(s) during reversal. The account balance, which was originally increased, is restored to the actual balance during the reversal:
155. What is ‘Fast Entry’?
Instead of the regular document entry screens, SAP provides ‘Fast Entry’ screens for facilitating a quick way of entering repetitive line items in a transaction. For achieving this, you need to define a Fast Entry Screen Layout, which will specify what fields you will require for data entry, and in what order. You may configure these fast entry screen layouts for GL account line items, credit memos, and customer/vendor invoices. Each of these fast entry screen layouts will be denoted by a 5-character screen variant in the system. Fast entry screens are used in complex (general) postings.
SAP’s enjoy postings are also meant for similar data entry screens, but the difference is that in the case of ‘fast entry’ you will start from scratch when identifying the fields, positioning them in the line item, etc., whereas in enjoy postings, the system comes with all the fields activated and you will select the fields that you do not want to be made available for data entry.
156. How do You Create ‘GL Account Master Data’?
‘GL Account Master Data’ can be created using any one of the following methods:
1. Manually
2. Creating with reference
3. Through Data Transfer Workbench
4. Copying from existing GL accounts
The Manual Creation of GL account master records is both laborious and time consuming. You will resort to this only when you can’t create master records using any of the other methods listed above.
You will follow the second method, Creating With Reference, when you are already in SAP and have an existing Company Code (Reference Company Code) from which you can copy these records to a new Company Code (Target Company Code). You will be able to do this by accessing the Menu: ‘General Ledger Accounting>GL Accounts>Master Data>GL Account Creation> Create GL Accounts with Reference.’ While doing this, you can copy the ‘account assignments’ as well ensuring that the integration of GL with other applications is intact. SAP facilitates so that you can (i) limit the number of GL records thus copied to the target Company Code, (if) create new records if necessary, and (iii) change the account number/name.
When your GL accounts are in a non-SAP system and you feel that these accounts will meet your requirements you will then use the ‘Data Transfer Workbench’ of SAP to transfer these records into SAP, and change them to suit the SAP environment. Since this will not have ‘Account Assignment’ logic as defined in SAP, you need to be careful when defining these assignments.
You will resort to the last option of Copying from Existing GL Accounts only when you feel that there is a Chart of Accounts in the system that meets your requirements 100%. Otherwise, follow the second method described above.
157. What is ‘Collective Processing’ of GL Accounts?
‘Collective Processing’ helps you to make systematic changes to a number of GL accounts in a single step. For example, you have used the ‘creating with reference’ method to create GL accounts in a new Company Code and you want to change the account names as well as the ‘GL account type’ (P&L or B/S). Then you will use the mass processing method. You can make changes to:
1. Chart of accounts data
2. Company Code data
Use Menu Path: ‘Accounting>Financial accounting>General ledger accounting>Master records>Collective processing.’ This can be achieved in IMG through: ‘Financial Accounting>General Ledger Accounting>GL Accounts> Master Data>GL Account Creation>Change GL Accounts Collectively.
Remember that the ‘collective processing’ helps only to edit and you cannot use this method if you need to create new master records.
158. What is ‘Individual Processing’ of GL Accounts?
In contrast to the ‘collective processing’ of GL accounts where you edit a number of accounts in a single step, Individual Processing helps to edit or create GL account master records one at a time. Here you can edit (including display, change, block, unblock, and delete) or create a new GL account in three different ways:
1. Centrally: You will be editing or creating a GL account master record in both the Chart of Accounts area and Company Code area in one step. This is also known as ‘one-Step’ GL creation.
2. In the Chart of Accounts area: you first edit or create the record here before doing it in the Company Code area.
3. In the Company Code area: you edit or create the record here after it has been done in the Chart of Accounts area.
Put together, steps 2 and 3 relate to the ‘step-by-step’ creation of GL account master records.
159. Is it Possible to Change an Existing B/S GL A/C to the P&L Type?
Technically, you will be able to change all the fields, except the account number, of a GL account in the Chart of Accounts area. However, in this particular instance when you change the ‘GL account type’ from ‘B/S’ to ‘P&L,’ make sure that you again run the ‘balance carry-forward’ program after saving the changes so that the system corrects the account balances suitably.
160. Why doesn’t the System allow You to Change the ‘Tax Category’ in a GL A/C Master?
You will be able to change the ‘Company Code’ related fields such as tax category, currency, etc., provided that there has not been any posting to these accounts. Pay attention to the following:
1. If you need to denote an existing GL account to later be managed on an ‘open item basis’ or vice versa, then make sure that the account balance is zero in either case.
2. If you are trying to change an existing ‘reconciliation account’ (to a regular GL), then make sure that the account has not been posted to.
3. If you are attempting to denote an existing ordinary GL account into a ‘reconciliation account,’ ensure that the account has a zero balance.
161. What is an ‘Account Group’?
The ‘Account Group’ (or GL Account Group), a 4-character alphanumeric key, controls how the GL account master records are created in the system. This helps to ‘group’ GL accounts according to the ‘functional areas’ to which they must belong. Account group is mandatory for creating a master record. The same account groups can be used by more than one more Company Code if they all use the same Chart of Accounts. Each GL account is assigned to only one account group.
The Account Group determines:
1. The number interval that is to be used while creating the master record.
2. The screen layout that is to be used while creating the master record in the Company Code area.
While defining the account groups in the system, you also need to define the corresponding field status for each of these groups. Otherwise, you will not be able to see any fields as all these would be hidden by default.
SAP comes delivered with a number of ‘account groups’ such as:
• SAKO (GL accounts general)
• MAT. (Materials Management accounts)
• FIN. (Liquid Funds accounts)
Figure 32: GL Account Group
In most situations, you will not require additional groups other than the ones already available in the standard system. However, if you need to create a new one, it is easier to copy an existing one and make modifications to it instead of creating one from scratch.
162. Describe ‘Number Range Interval.’
A ‘Number Range’ refers to a number interval defined in the system so that when documents are posted, the system assigns a number from this range. You will define different number ranges for different document types. Each document in SAP is uniquely identified by the combination of (a) document number, (b) company code, and (c) fiscal year.
The number range for a document type can be defined:
1. Per fiscal year or
2. Until a fiscal year in future.
If defined to last only one fiscal year, then the number range needs to be defined every year. When number ranges are defined every year, the system starts from the first number in the range for that particular year, which helps to prevent reaching the upper limit too fast.
Figure 33: Document Number Range
If you specify the fiscal year as ‘9999,’ then the document number range is valid forever (well, almost!) and you do not have to do this exercise of maintaining number ranges every fiscal year. But every year the system starts from the last number used up in the previous year and if a small number range is defined for a document type, you could easily run out of the number range fast.
The document numbers can either be:
1. Internally assigned by the system or
2. Externally input when the same is created.
The number ranges can be defined in such a way that the system generates the number automatically when a document is created. This is known as ‘internal number assignment.’ Under this, the system stores the ‘last number’ used for a document in the ‘Current Number’ field and will bring up the next number when another document is created.
If ‘external numbering’ is used, the user needs to input a document number every time a document is created in the system. Since the user supplies the number every time, the subsequent numbering may not be sequential. Unlike an internal numbering, the system does not store the ‘last number’ in the ‘Current Number’ field.
The numbers in a number range can either be numeric or alphanumeric. If numbers are numeric, the system will prefix the number with the required zeros to make the number length uniform at 10 digits. If you are using alphanumeric numbering, then the number is padded with zeros from the right. If you are following ‘year-specific’ numbering, it is better not to mix numeric and alphanumeric numbering for a particular document type in various fiscal years.
The system creates a minimum of one document when a transaction is created/completed. SAP recommends ‘filing’ original documents (under the number of the processing document (the document generated in SAP)). The best practice is to enter the (external) number of the ‘original document’ in the ‘Reference’ field of the document created in the SAP system. For easy cross-reference, the SAP document number thus created needs to be noted on the ‘original document.’
The following are the activities you need to complete for configuring the number ranges properly in the system:
1. Defining the number ranges
2. Copying the number ranges to Company Code(s)
3. Copying the number ranges to fiscal year(s)
163. What is a ‘Screen Layout’?
The ‘account group’ determines which ‘Screen Layout’ should be used while creating a GL account master record. For each of the account groups, you can define different screen layouts, which essentially determine the ‘Field Status’ of a field.
The field status refers to whether the field is:
1. Suppressed (field is invisible, hidden from display)
2. Required (display on, entry mandatory)
3. Optional (display on, entry not mandatory)
Figure 34: Field Status
All the above three are shown as ‘radio buttons’ against each of the fields in the screen layout, and you should select any one to set the status to that field; by default all the fields are ‘suppressed.’
There are two levels of controls of field status:
1. Field status at the account group level
2. Field status at the activity (create/change/display) level (i.e., at the transaction level).
You may also have the field status defined for posting keys (40-debit and 50-credit for the GL account postings). Also remember to define the field status for ‘reconciliation accounts’ as you will not be able to define any such status in the subledger accounts (for example, customer or vendor).
SAP has built-in rules, called link rules, to link these two levels and to decide the final status of a field in the ‘screen layout.’ The link rules also help to overcome the field-status setting differences arising out of different settings at the Client level (field status for posting keys) and the Company Code level (field status settings at the account group level).
164. What is a ‘Field Status Group’?
The ‘field status’ of an individual field or a group of fields is marked in a ‘Field Status Group,’ which is then assigned to individual GL account master records. You may attach field status groups to a field status variant so that the ‘field status groups’ are used in various Company Codes.
Figure 35: Field Status Variant (FSV)
The Field Status Variant is named similar to the Company Code. For example, if your Company Code is 1000, the field status variant is also named 1000, and it is assigned to the Company Code.
Figure 36: Assign a FSV to Company Code
165. What do You mean by ‘Balances in Local Currency’ Only?
When you create GL account master records, it is necessary to decide whether you want an account to have the transactions updated only in local currency. You will set this indicator accordingly in the ‘Company Code area’ of the master record. Make sure to set this indicator for clearing accounts such as:
• Cash discount clearing accounts
• GR/IR clearing accounts
Note that you need to set this indicator ‘on’ for all the ‘clearing accounts’ where you use the local currency to clear the line items in various currencies so that the transactions are posted without posting any exchange rate difference that otherwise might arise.
Example: Consider an invoice for USD 1,000, which on that day translates into an amount of INR 45,000 with an exchange rate of I USD=INR 45. Imagine that when the goods are received, the exchange rate was 1 USD=INR 44.
• If the indicator is set, the system ignores the exchange rate as if the line items have been maintained only in the local currency (INR), and the items are cleared.
• If the indicator is NOT set, the system makes a posting for the ‘exchange rate difference’ (INR 1, 000) before clearing the two line items.
166. What is ‘Line Item Display’?
To display line items of an account, you need to set the indicator ‘Line Item Display’ to ‘on’ in that account’s master record. This is mandatory for customer and vendor accounts. The line items can be displayed using the classical display or the SAP List Viewer (ALV). You can also use several ‘display variants’ to display various fields when you feel that the Standard Variant is not meeting your requirements.
167. What is ‘Archiving’? How does it differ from ‘Deletion’?
‘Archiving’ refers to deleting data from the documents in the database and storing the data in a file, which can be transferred to an ‘archiving system’ later on. Archiving does not physically delete the documents. ‘Deletion’ actually removes the documents from the database. To proceed with archiving and deletion you need to:
1. Block posting to these archived master records.
2. Mark (the master records) for deletion: Mark for deletion at the ‘Chart of Accounts area’ to delete the records from all the Company Codes. However, if you do not want to delete from all the Company Codes, but only from one or more Company Codes then do the same in the ‘Company Code area’ of the master record(s).
3. Archive all the transaction figures from the relevant documents.
4. Call up a special program to ‘delete’ the records: The program will check whether that particular document could be deleted. If yes, it will proceed to ‘archive’ and then to ‘deletion.’
168. Tell me the Two uses of ‘Blocking’ an Account.
You may use ‘Blocking’ to:
• Block an account from further postings.
• Block the creation of the account itself (at the Company Code level or Chart of Accounts area).
169. How do You Configure the GL A/C for the ‘House Bank’?
A ‘House Bank’ is defined using transaction code FI12. A ‘bank key’ represents the bank. The house bank can contain several accounts; for each of these accounts you need to maintain a GL account. The bank determination, for an automatic payment program, is configured using the Transaction Code FBZP.
170. What is an ‘Intermediate Bank’?
‘Intermediate Banks’ are used in SAP in addition to the house banks and partner banks for making or receiving payments from business partners abroad. The payment processing, involving an intermediate bank, makes use of the ‘bank chain,’ which may consist of a house bank, a partner bank, and a maximum of intermediate banks.
171. Explain ‘Intercompany Postings.’
‘Intercompany Postings’ arise when a Company Code, for example, in a centralized procurement, pays for itself and on behalf of other Company Codes. When posted, the transaction results in three documents: (1) one for the paying Company Code (say, 1111) (2) one for the other Company Codes (say, 2222 and 4444), and (3) one for the intercompany transaction itself.
Before making intercompany transactions, you need to configure both ‘intercompany payables’ and ‘intercompany receivables.’ For each combination of these Company Codes, you will be required to maintain a ‘clearing account,’ which must be referenced in each of these Company Codes. You will also be able to configure whether you manually input the transaction number or allow the system to automatically assign the numbers. In the case of system-generated transaction numbers, this 16-digit number consists of (1) a 10-digit document number (1222222222) of the paying Company Code, followed by (2) 4 digits representing this paying Company Code (1111), and (3) 2 digits representing the last two digits of the financial year (07) (for example, 1222222222111107).
172. How can You Manually ‘Clear’ ‘Open Items’? When?
Under ‘Manual Clearing,’ you will select the open items, based on the incoming payment so that the selected ‘open items’ are ‘cleared’ (knocked-off). In cases like refunds from a vendor or transactions involving bank sub-accounts and clearing accounts, etc., you will use manual clearing. When cleared, the system flags these line items as ‘cleared,’ creates a clearing document, and enters the clearing document number and clearing date in these open items. Besides the clearing document, the system may also generate ‘additional documents’ in cases such as partial or residual processing, and for posting the loss/gain to the assigned GL account.
While doing this, if there is a payment difference, it can be treated the way it is configured in the system:
• If the difference is within the tolerance limit, defined in the system using the tolerance groups (defined at the Company Code level), the cash discount is adjusted or the system automatically posts the difference to a gain/loss GL account.
• When the payment difference exceeds the limits of defined tolerance, then the incoming amount may be processed as a partial payment (the original open item is not cleared, but the incoming payment is posted with a reference to that invoice) or the difference is posted as a residual item (the original open item is cleared and a new open item is created by the system for the difference amount) in the system.
You may also use the Menu Path: Accounting>Financial Accounting> Account Receivable>Document entry>Incoming payment>Post or Accounting >Financial Accounting>GL>Document entry>Incoming payment>Post
173. How do You Perform ‘Period Closing’ in SAP?
You do a ‘(Period) Closing’ in SAP in three steps:
• Completing the Pre-closing activities
• Financial Closing
• Managerial Closing
174. What is ‘Pre-closing’?
You need to ensure the following as part of the ‘Pre-closing’ activities:
1. Post all the Recurring Entries for expenses and accruals.
2. Ensure that all the interfaced programs have been run so that the required data have been transferred to the system.
3. Post all the depreciation, material receipts, invoices, salaries, etc. In short, ensure that all the transactions for the period in question have been duly recorded and posted into the system.
175. Explain ‘Financial Closing.’
‘Financial Closing’ involves completing the following activities and taking out the financial statements for the period concerned:
1. Revaluate/Regroup:
• Revalue Balance Sheet items managed in foreign currencies—use the report RFSBEW00 to valuate GL Balance Sheet Accounts managed in a foreign currency. (The report generates a Batch Input session to post the revenue or expense resulting from any exchange rate differences.)
• Clear Receivables or Payables with the ‘exchange rate difference.’
• Valuate all the Open Items using the report SAPF100. This is used to valuate all the open receivables and payables, using the period-end exchange rates. Here also, the report generates a Batch Input session to post the entries resulting from any exchange rate differences.
• Regroup GR/IR using the program RFWERE00 to allocate the net balance (depending on whether the balance is a net debit or credit) in the GR/IR Account to one of two GL Accounts (created to actually depict the net effect of the balance in the GR/IR Account).
2. Ensure accounting accuracy:
• Use the program SAPF190 to compare the totals created by the system in the (1) indexes (customers, vendors, and GL) and documents (customers, vendors, and GL) with that of the (2) account balances (customers, vendors, and GL) to ensure the transaction accuracy.
3. Run required reports:
• Generate the financial statements (balance sheet and profit & loss account) using the financial statement versions. You may also generate the key figure/ ratio reports (use the GL account information system).
176. What is a ‘Financial Statement Version’?
A ‘Financial Statement Version’ helps to define the Financial Statements (both the Balance Sheet and Profit & Loss statements). When you copy the settings from an existing Company Code to a new one, you will also be copying the financial statement version defined for the ‘source’ Company Code.
Figure 37: Financial Statement Versions
You may also define a new financial statement version and build the financial statements from scratch. You may create the financial statements both for external reporting (Company Code financial statements) and internal reporting (business area financial statements).
You may also create the balance sheets for a group of Company Codes using FI-SL (Special Purpose Ledgers). The financial statements may be defined to provide information from a period accounting point of view (GL account groups wise) or a cost of sales point of view (functional area financial statements).
All the above statements can be configured and defined to provide different levels of detail:
Figure 38: Financial Statement Version—BAUS
A financial statement version can have a maximum of 10 hierarchy levels, with each level assigned with an item (account category). As you go down the hierarchy, you define the account categories in more detail, with the lowest level being represented by the GL accounts. The system displays the relevant amount for each of these items.
177. What Items are Required in a ‘Financial Statement Version’?
Irrespective of the details you require in a ‘Financial Statement Version,’ it is mandatory that you have, at least, the following items defined:
1. Assets
2. Liabilities
a. Net Result: Profit
b. Net Result: Loss
3. P/L result (during annual closing, when you run the program RFBILA00, the system calculates the profit or loss by subtracting the ‘total liabilities’ from ‘total assets’ and updates the relevant Net Result item—Profit or Loss).
4. Not assigned (posted amounts but not yet assigned to any of the account groups).
178. How do You Ensure ‘Correct’ Balances in the ‘Financial Statement Version’?
In order to have a balanced statement (Profit & Loss and Balance Sheet) you need to ensure that the accounts are correctly and completely assigned to the nodes of the Financial Statement Version. You may do this by resorting to the necessary assignments at the account balance level or node balance level.
At the account balance level, you need to ensure that the account is shown in two different nodes, but you will turn “ON” the ‘debit indicator’ of the account on one node and turn “ON” the ‘credit indicator’ on the other node. Imagine that you have a bank current account 10001000. When you turn “ON” the debit indicator, this account shows only the debit balances and is construed as the asset. On the other hand, when the credit indicator is turned “ON,” the balances on this node now indicate that you owe to the bank (overdraft).
You may also use the node-level assignment. In this case, the system uses the ‘debit/credit shift’ and shows only the ‘effective’ balance at the node and not at the individual account level.
179. How do You Perform ‘Annual Closing’ in SAP?
‘Annual Closing’ is like any other ‘period closing’ and you will be performing all the activities that are required for a period-end-close. In addition to those activities, you will also:
• Carry forward Vendor and Customer accounts
• Carry forward the GL account balances of all the Balance Sheet items
• Close the Profit & Loss Accounts and carry forward the balance (profit or loss) to the retained earnings account(s)
For a GL account ‘carry forward,’ use the program SAPF011.
180. Explain ‘Managerial Closing.’
In ‘Managerial Closing’ you will:
• Do a preliminary Controlling period closing
• Settle/re-allocate costs across Controlling organization
• Draw and review internal reports
• Re-open the Controlling period
• Correct and adjust the accounting data, if required
• Reconcile FI and CO by running the FICO Reconciliation Ledger
• Run re-adjustment programs to ensure that the Business Areas and the Profit Centers are balanced
• Draw reports and analyze
181. What is the ‘New FI-GL’ in FI in ECC?
The traditional or ‘Classic FI-GL accounting’ in FI has been focused on providing comprehensive external reporting by recording all business transactions in the system. However, to meet modern-day requirements, this has now been enhanced, called the ‘New FI-GL,’ and includes the following:
• Parallel accounting: Maintaining several parallel ledgers to meet different accounting principles.
• Integrated legal and management reporting: Unlike the traditional GL, the ‘New FI-GL’ enables you to perform internal management reporting along with legal reporting. So you are in a position to generate Financial Statements for any dimension (for example, profit center) in the business.
• Segment reporting: With the introduction of the Segment dimension, SAP now enables you to produce Segment Reports based on IFRS (International Financial Reporting Standards) and the GAPP (Generally Accepted Accounting Principles) accounting principles.
• Cost of sales accounting: It is now possible to perform cost of sales accounting in the ‘New FI-GL.’
However, the following functions are not yet supported in the ‘New FI-GL’:
• Transfer Price
• SKF (Statistical Key Figure)
• Euro Translation
• AIS (Audit Information System)
• Archiving
• Data Retention Tool
The ‘New FI-GL’ needs to be activated in the system before you start using the IMG Menu Path:>Financial Accounting (New)->Financial Accounting Global Settings (New)/General Ledger Accounting (New).
In the standard system, the tables from ‘classic general ledger accounting’ (GLT0) are updated as well as the tables in ‘New FI-GL’ during the activation. This enables you to perform a ‘ledger comparison’ during the implementation of ‘New FI-GL’ to ensure that your ‘new GL accounting’ has the correct settings and is working correctly. To compare ledgers, in Customizing choose Financial Accounting Global Settings (New)->Tools->Compare Ledgers.
It is recommended that you ‘deactivate’ the update of tables for ‘classic GL accounting’ once you have established that ‘New FI-GL’ is working correctly. To do this, in Customizing choose Financial Accounting Global Settings (New)-> Tools->Deactivate ‘Update of Classic General Ledger.’
Figure 39: New FI-GL
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.
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.’
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.’
191. Explain ‘Revenue Account Determination’ in SD.
The billing documents created during the sales cycle results in automatic postings to GL accounts on the FI side. In general, ‘Account Determination’ is based on the following five factors:
1. Chart of accounts
2. Sales organization
3. Account assignment group of the customer
4. Account assignment group of the material
5. Account key
The system determines the ‘chart of accounts’ from the company code in the ‘billing document,’ and the ‘sales organization’ is determined from the corresponding ‘sales order.’ The ‘account assignment group’ is taken from the respective masters of customer/material. The ‘account key’ helps the user to define the various GL accounts, and this key is assigned to the ‘condition type’ (KOFI) in the ‘pricing procedure.’
These GL accounts are automatically determined when you make the following configuration in the system:
1. Assigning an ‘account determination procedure’ to a ‘billing document type’
2. Assigning this ‘account determination procedure’ to a ‘condition type’
3. Assigning this ‘condition type’ to an ‘access sequence’
4. Configuring the ‘condition tables’
Table Description
001 Customer /Material Grp./AccKey
002 Cust. Grp/AccKey
003 Material Grp/Acc Key
004 General
005 Acc Key
Application Condition Type Chart of a/c Sales Org AcctAsg Grp Acc Asgmnt A/c Key GL a/c
001 Customer grp/Material Grp./AccKey: Details
V KOFI COMP 1000 01 10 ERL 5012100000
V KOFI COMP 1000 01 10 ERS 5012100000
V KOFI COMP 1000 02 10 ERL 5012200000
V KOFI COMP 1000 02 10 ERS 5012200000
V KOFI COMP 2000 01 20 ERL 5013100000
V KOFI COMP 2000 01 20 ERS 5013100000
V KOFI COMP 2000 02 20 ERL 5013200000
V KOFI COMP 2000 02 20 ERS 5013200000
005 Acc Key: Details
V KOFI COMP 1000 MWS 2470000000
V KOFI COMP 2000 MWS 2470000000
Figure 47: Revenue account determination
192. Outline ‘Credit Management’ in SAP.
‘Credit Management’ helps to determine credit limits of customers, aids in the creation of ‘credit check’ policies, as well as helps companies monitor and evaluate their customers. This is a cross-functional responsibility in SAP, covering both the Sales and Distribution and Financial Accounting modules.
As in the case of any automated process such as dunning, payment, etc., credit management in SAP requires certain prerequisites be defined beforehand:
1. Customer master data has been created both in SD and FI.
2. Credit control area has been defined and assigned to a Company Code.
SAP makes use of the concept ‘credit control area’ for credit management. As explained elsewhere, the credit control area is an organizational element defined to which one or more Company Codes are attached. In the case of customers defined under more than one Company Code, they may fall under different credit control areas. But note that:
• A Client can have more than one credit control area, but the converse is not true: one credit control area cannot be assigned to more than one Client.
• A credit control area can be assigned to more than one Company Code, but the converse is not true: one Company Code cannot be assigned to more than one credit control area.
Figure 48: Client—Credit Control Area—Company Code—Customer
While defining the credit limit for a customer:
• You will define a maximum limit per credit control area (Example: Credit Control Area AAAA->USD 500,000, Credit Control Area BBBB ->USD 200,000)
• You will define a global maximum limit for all credit control areas put together (USD 600,000)
3. Credit data (per credit control area ‘maximum limit’ as well as the ‘total’ for all areas, in the control data screen) for the customer has been created.
4. Risk categories have been defined and assigned to customers.
5. Credit groups (document credit group) for document types have been defined. Document credit groups combine order types and delivery types for credit control.
6. Defined, in SD, at what time (when order is received or when a delivery is made, etc.) the credit check should happen.
The credit management process starts when a sales order is entered in SD. Imagine that this results in exceeding the credit limit defined for the customer. Now:
a. The system creates three comparison totals considering (1) open receivables, (2) sales order values, value of goods to be delivered and the billing document value from SD, and (3) special GL transactions (e.g., ‘down payments’ and ‘bills of exchange’).
b. Based on (a) above the system throws an (1) error message and prevents saving the order or (2) a warning message, and the system does not prevent saving, but the order is ‘blocked.’
c. The Credit representative, using information functions (SD information system, FI information system, credit overview, credit master list, early warning list, oldest open item, last payment, customer master, account analysis, etc.), processes this blocked order either (1) from the ‘blocked SD documents list’ or (2) the mailbox, and releases the order, if necessary.
d. Delivery is created, the billing document is generated and posted, and A/R is updated.
e. Customer pays the invoice and A/R is posted.
193. What is a ‘Credit Check?
A ‘Credit Check’ is defined for any valid combination of the following:
• Credit control area
• Risk category
• Document credit group
194. Differentiate ‘Static Credit Check’ from ‘Dynamic Check.’
Under ‘Static Credit Check,’ the system calculates the credit exposure of a particular customer as the total of:
• Open order (delivery not yet done)
• Open delivery (value of deliveries yet to be invoiced)
• Open billing documents (not transferred to accounting)
• Open items (AR item not yet settled by the customer)
Customer’s credit exposure is not to exceed the established credit limit.
The ‘Dynamic Credit Check’ is split into two parts:
• Static limit: Total of open items, open billing, and open delivery values.
• Dynamic limit (Open Order Value): The value of all undelivered and partially delivered orders totalled and stored on a time-scale in the future (10 days, 1 week, etc.) known as a ‘horizon date.’
During the ‘dynamic credit check,’ the system will ignore all orders beyond the ‘horizon date.’ The sum total of ‘static’ and ‘dynamic’ limits should not exceed the credit limit established for the customer.
195. List the Reports in ‘Credit Management.’
SAP provides you with the following Reports in Credit Management:
• RFDKLI10 Customers with missing Credit Data
• RFDKLI20 Re-organization of Credit Limit for Customers
• RFDKLI30 Short Overview of Credit Limit
• RFDKLI40 Overview of Credit Limit
• RFDKLI41 Credit Master Sheet
• RFDKLI42 Early Warning List (of Critical Customers)
• RFDKLI43 Master Data List
• RFDKLI50 Mass change of Credit Limit Data
• RVKRED06 Checking Blocked Credit Documents
• RVKRED08 Checking Credit Documents which reach the Credit Horizon
• RVKRED09 Checking the Credit Documents from Credit View
• RVKRED77 Re-organization of SD Credit Data
196. How does ‘Partial Payment’ differ from ‘Residual Payment’?
When processing the ‘incoming payment’ to apply to one or more of the ‘open items’ of a customer, there may be a situation where the incoming payment is more than the ‘tolerances’ allowed. In this case, you can still go ahead and process the payment by resorting either to a Partial Payment or a Residual payment.
A Partial payment results in posting a credit to the customer’s ‘open item,’ but leaves the original item intact. As a result, no open item is cleared. During partial payment, the system updates the ‘invoice reference’ and ‘allocation’ fields.
In contrast to a partial payment, the Residual payment clears the particular ‘open item’ against which the payment is applied. However, since there are not enough amounts to clear the entire open item, the system creates a new open item, which is the difference between the original invoice item and the payment applied. Note that the new invoice/open item created by the system will have the new document date and new baseline date though you can change these dates.
197. What is ‘Payment Advice’?
‘Payment Advice’ helps in the automatic searching of ‘open items’ during the ‘clearing’ process to find a match for an ‘incoming payment.’ This is possible because you can use the ‘payment advice’ number instead of specifying parameters in the ‘selection screen.’ A typical payment advice may contain details such as document number, amount, currency, reason for underpayment, etc. The payment advices are of various categories; the first 2 digits of the payment advice number help to differentiate one payment advice from another:
• Bank advice
• EDI advice
• Lockbox advice (created during the clearing process, available in the system whether clearing was successful or not)
• Manual advice
• Advice from a bank statement
Most of the payment advices are deleted as soon as the clearing is successful in the system.
198. Describe ‘Lockbox’ Processing.
‘Lockbox’ processing (configured in the FR-TR module) of incoming payments is used predominantly in the United States. Here, the bank receives the checks from customers as incoming payments, creates payment advice for each of these customer check payments, and informs the payee of the payment, in BAI file format. This lock box file is sent to the payee who imports the details into the system using this electronic file. The system updates the payments into the GL by way of ‘batch input’ processing.
199. How can ‘Reason Codes’ Help with Incoming Payment Processing?
‘Reason Codes’ configured in the system help to handle the ‘payment differences’ of individual open items in an invoice (either using payment or advice or in the normal course). To each of the reason codes, you will define the ‘posting rules’ and the GL accounts in the IMG.
Once done, when there is a payment difference against a particular open item, the system looks for the reason code:
• When the ‘charge-off indicator’ has been set for that reason code, then the system posts the payment difference to a GL account. When this indicator is not set, then a new open item is created for the payment difference.
• When ‘disputed item indicator’ has been set, then the system ignores these line items when counting for the customer’s credit limit.
200. What is ‘Dunning’ in SAP?
The SAP System allows you to ‘dun’ (remind) business partners automatically. The system duns the open items from business partner accounts. The dunning program selects the overdue open items, determines the dunning level of the account in question, and creates dunning notices. It then saves the dunning data determined for the items and accounts affected. You can use the dunning program to dun both customers and vendors. It may be necessary to dun a vendor in the case of a debit balance as a result of a credit memo.
Dunning is administered through a Dunning Program, which uses a dunning key (to limit the dunning level per item), a dunning procedure, and a dunning area (if dunning is not done at the Company Code level).
Figure 49: Dunning Key
A ‘Posting Period Variant’ is useful in ‘opening/closing’ posting periods across many Company Codes at one time. You define a posting period variant and assign it to various Company Codes. Since the posting period variant is cross-Company Code, the opening and closing of the posting period is made simple. Instead of opening and closing individually for different Company Codes, you just need to open or close the posting period variant.
102. Can You Selectively ‘Open’ and ‘Close’ accounts?
Yes. It is possible to selectively control the ‘opening’ and ‘closing’ for various types of accounts. Usually, a ‘+’ is mentioned in the top-most entry indicating that all the account types are allowed for posting. Now, for the GL(S) accounts, you will need to specify the period which needs to be opened. This ensures that all the account types are open for the current period, indicated by ‘+,’ and only the GL accounts are open for the previous period.
Select account types can also be opened or closed for a specific period; select accounts within an account type can also be opened or closed.
103. Why is it not Possible to Post to a Customer A/C in a Previously Closed ‘Period’?
When you want to selectively ‘close’ or ‘open’ the posting period of some accounts (account range), there will be no problem with that if you are doing it for GL accounts. But, if it is a subledger account (such as the customer), it has to be achieved via opening or closing the account interval of the ‘reconciliation account’ of that account type.
104. Can You Open a ‘Posting Period’ only for a Particular User?
Yes. SAP allows you to open or close the posting period only for specific users. This can be achieved by maintaining an authorization group at the document header level.
105. What is a ‘Special Period’? When do You Use it?
Besides the normal posting periods, SAP allows for defining a maximum four more posting periods, which are known as ‘Special Periods’ as these are used for year-end closing activities. This is achieved by dividing the last posting period into more than one (maximum four) period. However, all the postings in these special periods should fall within the last posting period.
The special periods cannot be determined automatically by the system based on the posting date of the document. The special period needs to be manually entered into the ‘posting period’ field in the document header.
106. What is the Maximum Number of ‘Posting Periods’ in SAP?
Under GL accounting, you can have a maximum of 16 posting periods (12 regular plus 4 Special Periods). However, you can have up to a maximum of 366 posting periods as is the case in ‘special purpose ledgers.’
107. What is a ‘Special Purpose Ledger’?
‘Special Purpose Ledgers’ (FI-SL) are used in reporting. These are basically user-defined ledgers, which can be maintained either as GL or subsidiary ones with various account assignment objects (with SAP-dimensions such as cost center, business area, profit center, etc., or customer-defined dimensions such as region, area, etc.).
Once defined, this functionality helps you to report at various levels. Ideally you collect the information, combine it, and create the totals. This is something such as an additional reporting feature, and use of this feature will have no effect on the regular functionalities of SAP.
108. What Variations are Possible when Defining a ‘Fiscal Year’?
The Fiscal Year is the same as a Calendar Year
The fiscal year starts on January 1 and there are 12 posting periods; the posting periods correspond to the calendar months; there is no need to define each of the posting periods.
The Fiscal Year is NOT the same as a Calendar Year
In this case, you need to specify how many posting periods you want and how the system should derive the posting period. Since the posting period does not correspond to the calendar month, the start and end date of each of the posting periods need to be maintained.
109. What is known as ‘Year Shift/Displacement’ in a Fiscal Year?
When the fiscal year is not the same as the calendar year, we need to define a ‘displacement factor’ for each of the posting periods to correctly identify the number of posting periods.
For example, consider the fiscal year variant V3 (Figure 25). The fiscal year starts on April 1st and ends on March 31st of the next calendar year so the displacement factor or year shift from April to December is ‘0,’ and for January to March, it will be ‘−1’. By defining it this way, the system is able to recognize the correct posting period. A posting made on January 25th, 2006 will then be interpreted as the 10th posting period in fiscal year 2005.
Figure 25: Year shift/displacement in Fiscal Year Variant
110. Can You have ‘non-Calendar’ Months as ‘Periods’ in a ‘non-Calendar’ Fiscal Year?
Yes. The ‘non-calendar fiscal year’ can either correspond to calendar months or to non-calendar months.
In the case of non-calendar months as the posting periods, you need to specify the start and end date of these posting periods. Consider a fiscal year starting on April 16th, 2005 and ending on April 15th, 2006. Here, the posting period-1 starts on April 16th and ends on May 15th and so on. Note that the posting period-9 will have 2 displacements (0 and −1) as indicated below in the Table:
As a result, a posting made on December 27th, 2005, as well as the posting made on January 14th, 2006 are correctly identified as postings corresponding to period-9.
111. What is a ‘Year-dependent’ Fiscal Year?
A calendar year fiscal variant, when defined as ‘year-dependent,’ is relevant and valid only for that year.
112. What Precautions should you Take while Defining a ‘Shortened Fiscal Year’?
Note that the ‘Shortened Fiscal Year’ is always year-dependent. This has to be followed or preceded by a full fiscal year (12 months). Both the shortened and the full fiscal year, in this case, have to be defined using a single fiscal year variant.
113. Tell me more about a ‘Shortened Fiscal Year.’
As mentioned already, a ‘Shortened Fiscal Year’ is one containing less than 12 months. This kind of fiscal year is required when you are in the process of setting up a company, or when you switch over one fiscal year (e.g., calendar year) to another type of fiscal year (non-calendar).
114. How do You Open a new ‘Fiscal Year’ in the System?
You do not need to ‘open’ the new fiscal year as a separate activity. Once you make a posting into the new fiscal year, the new fiscal year is automatically opened. Or, the new fiscal year is automatically opened when you run the ‘balance carry-forward’ program.
However, you need to have (1) the relevant posting period already open in the new fiscal year, (2) completed the document number range assignment if you are following a year-dependent number range assignment, and (3) defined a new fiscal year variant if you follow the year-dependent fiscal year variant.
115. How do you ‘Carry-Forward’ Account Balances?
If you have already posted into the new fiscal year, you do not need to ‘carry-forward’ the balances manually. But you can use the various ‘carry-forward’ programs supplied by SAP for this task.
116. Can You Explain how ‘Carry-Forward’ Happens in SAP?
Sure. For all the Balance Sheet items, the balances of these accounts are just carried forward to the new fiscal year, along with account assignments if any. This also true for customer and vendor accounts.
In the case of Profit & Loss accounts, the system carries forward the profit or loss (in the local currency) to the Retained Earnings account, and the balances of these accounts are set to ‘0.’ No additional account assignments are transferred.
117. Is there a Prerequisite for ‘Carry-Forward’ Activity?
Yes, for Profit & Loss accounts, you should have defined the Retained Earnings account in the system. Additionally, you should have also specified the ‘Profit & Loss Account Type’ in the master record of each of these for Profit & Loss accounts.
There are no such requirements for GL accounts, customer and vendor accounts.
118. How many ‘Retained Earnings’ A/C can be Defined?
You can define as many ‘Retained Earnings Accounts’ as you need. But normally, companies use only one retained earnings account. Remember, to define more than one, you should use the profit & loss account type.
119. Can You have Multiple ‘Retained Earnings’ A/C?
Normally it is sufficient if you use one ‘retained earnings’ account. However, if you are configuring for a multinational company where the legal requirements require treating some of the tax provisions differently from other countries, then you will need more than one retained earnings account.
120. How do You Maintain ‘Currency’ in SAP?
‘Currency’ (the legal means of payment in a country) in SAP is denoted by a 3-character Currency Code, maintained per ISO standards. Example: USD (U.S. Dollars), INR (Indian Rupee), GBP (Great Britain Pound), etc. Each currency code in the system will have a validity defined.
A currency is defined in SAP using the IMG path: General settings>Currencies >Check exchange rate types.
121. What is a ‘Local Currency’?
When you define a Company Code, you also need to mention in which currency you will be maintaining the accounts/ledgers in financial accounting. This currency is called the ‘Local Currency.’ This is also known as ‘Company Code Currency.’
122. What is a ‘Parallel Currency’?
When defining the currencies for a Company Code, it is possible to maintain, for each of these company Codes, two more currencies in addition to the ‘Local Currency.’ These two currencies are called the ‘Parallel Currencies,’ which can be the:
• Group Currency
• Hard Currency
• Global Company Currency
• Index-based Currency
To translate the values from one currency to the other, you will need to maintain an exchange rate for each pair of the defined currencies in the system. When parallel currencies are defined, the system maintains the accounting ledgers in these currencies as well, in addition to the local currency.
123. What is a ‘Group Currency’?
This is the currency defined at the Client level.
124. What is the ‘Global Company Code Currency’?
The currency defined for the Company (or the Consolidated Company) is called the ‘Global Company Code Currency.’
125. What is an ‘Account Currency’?
When defining the GL accounts in the system, you are required to define a currency in which an account will be maintained, and this is called the ‘Account Currency.’ This is defined in the ‘Company Code’ area of the GL master record, and is used for postings and account balance display.
126. What are all the Prerequisites for Posting in a ‘Foreign Currency’?
The following are the prerequisites you need to consider before posting in a foreign currency:
• Local currency already defined for the Company Code (in the global parameters)
• Foreign currency defined in the currency code Table
• Exchange rate defined for the foreign currency and the local currency
• Translation Ratio maintained for the local and foreign currency
127. How are ‘Exchange Rates’ Maintained in SAP?
An ‘Exchange Rate’ is defined for each pair of currencies, and for each ‘exchange rate type’ defined in the system. The exchange rate is defined at the document header level.
128. What is an ‘Exchange Rate Type’? List some of them.
The ‘Exchange Rate Type’ is defined according to various purposes such as valuation, translation, planning, conversion, etc. The commonly used exchange rate types include:
Figure 26: Exchange Rate Types
129. What is known as the ‘Translation Factor’?
The relation between a pair of currencies per ‘exchange rate type’ is known as the ‘Translation Factor.’ For example, the translation factor is 1 when you define the exchange rate for the currencies USD and INR:
130. Is there an Easy Way to Maintain Exchange Rates in SAP?
SAP offers a variety of tools to maintain exchange rates on an on-going basis. The tools include:
• Exchange Rate Spreads
• Base Currency
• Inversion
Use the SAP supplied program, RFTBFF00, for populating the exchange rate table automatically from an input file in a multi-cash format from a commercially available input file.
131. What is known as an ‘Exchange Rate Spread’?
The difference between the ‘bank-buying rate’ and the ‘bank selling rate’ is known as the ‘Exchange Rate Spread,’ which remains almost constant. When you maintain the exchange rate spread, it is sufficient if you maintain the ‘average rate’ for that currency in question in the system as you will be able to deduce the buying/selling rate by adding/subtracting the spread to/from the average rate.
132. Explain the use of ‘Direct’ or ‘Indirect Quotations.’
It is possible to maintain the exchange rates, in SAP, by either of these two methods. What determines the use of a particular type of quotation is the business transaction or the market standard (of that country).
SAP adopts two prefixes to differentiate direct and indirect quotes during entering/displaying a transaction:
• ‘’—Blank, no prefix. Used in Direct Quotation
• ‘/’—Used in Indirect Quotation
When there is no prefix entered, (blank), the quotation is construed as the ‘direct quote’ by the system. Possible scenarios include:
• The company in question is mainly using the ‘Indirect Quotation.’
Use ‘’ (blank) as the prefix for default notation for indirect quotation. Use ‘*’ as the prefix for the rarely used direct quotation. If someone tries entering a transaction using direct quotation, but without the ‘*’ in the exchange rate input field, the system will issue a warning.
1. The company in question is mainly using the ‘Direct Quotation.’
You do not need any specific settings as the default is the ‘’ (blank) prefix for the direct quotation, and ‘/’ for the indirect quotation. So, unless you make a transaction entry with ‘/’ prefix, the system takes all the entries as that of direct quotation.
2. There could be instances where you are required to configure in such a way that a prefix is mandatory irrespective of the type of quotation. In this case, define the direct quotation prefix as ‘*’, and the indirect one as the system default ‘/’ prefix. This necessitates a prefix each of the entries either by ‘*’ or ‘/.’ Otherwise, the user will get a warning to correct the entry.
133. Explain how ‘Taxes’ are Handled in SAP.
SAP takes care of tax calculation, tax postings, tax adjustments, and tax reporting through the three FI components; namely GL, AP, and AR. The processing of the following kinds of taxes is possible:
1. Tax on Sales and Purchases
a. Input Taxes (Purchase Tax)
b. Output Taxes (Sales Tax)
2. Additional Taxes (these are country specific and in addition to the tax on sales and purchases)
3. Sales Tax
4. Withholding Tax
a. Classic Withholding Tax
b. Extended Withholding Tax
SAP allows taxation at three levels:
1. National level or federal level (Europe, South Africa, Australia, etc.)
2. Regional or jurisdiction level (USA)
3. National and Regional level (India, Canada, Brazil etc.)
134. How is Tax Calculated in SAP?
SAP uses a technique called ‘Condition Method’ to calculate taxes (except Withholding Tax) in the system. The system makes use of ‘Tax (Calculation) Procedures’ defined in the system together with the Tax Codes for calculating the quantity of tax.
1. The Tax Code is the starting point in the tax calculation. The tax code is country specific, with every country having a country specific Tax Procedure defined in the standard system, which is used as the template for defining various tax codes. The system uses the tax code to verify the following:
Figure 27: Condition Type (Tax Processing)
a. Tax type
b. Amount of tax calculated/entered
c. GL account for tax posting
d. Calculation of additional tax portion, if any
2. Tax Rates are defined for each of the tax codes. The tax rates are then associated with Tax Types, which are included in the tax procedures. (Because of this relationship, it is technically possible that a single tax code can have multiple tax rates for various tax types.)
3. The tax code is assigned to a Tax Procedure, which is tagged to a GL master record. A particular tax procedure is accessed whenever that GL account is used in document processing.
Figure 28: Steps in Tax processing
A Tax Procedure contains the following:
• Steps— To determine the sequence of lines within the procedure.
• Condition Types— Indicates how the tax calculation model will work (whether the records are for fixed amount or percentages and whether the records can be processed automatically, etc.)
• Reference Steps— Where the system obtains the amount/value it uses in its calculation (for example, the base amount)
• Account/Process Keys— Provide the link between the tax procedure and the GL accounts to which tax data is posted. This helps in automatic tax account assignments. To enable that these keys have the necessary information for automatic assignment, you need to define the following:
o Posting keys (unless you have a specific requirement, it will be sufficient to use the GL posting keys: Debit: 40, Credit: 50)
o Rules to determine on which fields the account determination is to be based (such as the tax code or country key)
o Tax accounts to which the postings need to be made
SAP comes with a number of predefined account/process keys, and it is recommended that the standard keys be used.
4. The Access Sequence helps in identifying the sequence of Condition Tables to be used and identifying which field contents are the ‘criteria’ for reading the Condition Tables (a group of Condition Types).
5. The tax amount so calculated is normally posted to the same side as the GL posting that contains the tax code. When exchange rate differences occur (due to tax adjustments in foreign currencies) these differences are generally posted to the specific account(s) for exchange rate differences. However, it is possible to specify (per Company Code) that the exchange rates for tax items can also be entered manually or determined by the posting or the document date, and the resulting differences posted to a special account.
Figure 29: Account/Process Key for tax processing
6. R/3 has a number of predefined account keys, and it is recommended that the standard keys be used.
135. Explain the Configurations Required for Taxes in SAP.
You need to define the following to customize SAP for this purpose:
1. Base Amount for Tax Calculation
For each Company Code you need to define whether the Base Amount includes the cash discount as well. If the base amount includes the discount, then the tax base is called ‘Gross,’ otherwise, it is ‘Net.’ You may also define a similar base amount for calculating the ‘Cash Discount.’ This also has to be maintained for each of the Company Codes.
2. Tax Codes
The Tax Code is a 2-digit code specifying the percentage of tax to be calculated on the base amount. While defining the tax code, you will also specify the ‘Tax Type’ to classify a tax code relating to either ‘Input Tax’ or ‘Output Tax.’ The tax types are country specific and determine how a tax is calculated and posted.
3. Tax Rate
The Tax Rate is the percentage of tax to be calculated on a base amount. You will be able to define tax rates for one or more tax types when you define a single tax code.
4. Check Indicators
By using the check indicators, you configure the system to issue Error/Warning Messages when the tax amount entered manually is incorrect.
136. What is a (Tax) ‘Jurisdiction Code’?
A ‘Jurisdiction Code,’ used in countries such as the United States, is a combination of the codes defined by tax authorities. It is possible to define up to four tax levels below the federal level. The four levels can be the:
• Sub-city level
• City level
• Country level
• State level
Before you can use the jurisdiction codes for tax calculation, you need to define the following:
1. Access Sequence (to include the country/tax code/jurisdiction fields)
2. Condition Types (which references the access sequence as defined above)
3. Jurisdiction Codes
The tax rates are defined in the tax code by jurisdiction. When posting taxes with a jurisdiction code, note that the taxes may be entered per jurisdiction code or per tax level.
137. Tell me about the ‘Tax Reports’ in SAP.
SAP comes delivered with country-specific default ‘Tax Reports’ to meet your tax-reporting requirements. However, it is not uncommon to use third-party software for the same purpose. As a process, it is recommended that the ‘closing operations’ are completed before running the tax reports. This will ensure that the system makes relevant adjustment entries (between payables and receivables, exchange rate differences, etc.) so that the correct tax amounts are reported.
138. How is ‘Master Data’ different from ‘Transaction Data’?
There are three kinds of data residing in any SAP system:
1. Table Data
2. Transaction Data
3. Master Data
Table Data refers to the customized information for a particular Client. This includes data such as payment terms, discounts, pricing, tolerance limits, etc., which you do not normally change on a day-to-day basis.
Transaction Data is the day-to-day recording of business information such as purchase orders, sales returns, invoices, payments, collections, etc. This includes both system-generated data (tax, discount, etc., automatically calculated by the system during document posting) as well as user-generated data.
Master Data is the control information required to decide how transaction data gets posted into various accounts (such as customers, vendors, GL, etc.). The master data is usually shared across modules (for example, customer master records are common both to FI and SD in SAP) obviating the need for defining it in various application areas. The master data remains in the system for fairly a long period.
In the case of GL Master Records, the data is created in two areas:
1. Chart of Accounts Area (common to all Company Codes: Chart of accounts, GL account number, account name (short and long text), B/S or P&L indicator, account group, etc.).
2. Company Code Area (specific to that particular Company Code: Company Code, tax code, currency, open item management, line item display, sort key, etc.).
In the case of the Customer/Vendor Master Record, the data is created in two areas:
1. Client Specific (general data such as account number, name, telephone, bank information, etc., which is common to all the Company Codes using this master).
2. Company Code Specific (valid only for the Company Code, this includes: terms of payment, dunning procedure, reconciliation account, sort key, sales area, purchasing information, etc.).
139. Can You Post an A/C Document if the ‘Credit’ is not Equal to the ‘Debit’?
In general, unless the ‘debits’ equal the ‘credits’ in a document, you will not be able to post the document. However, the system allows you to post some of the documents, even if this not true, which includes the following:
• Noted items: this will contain only a debit or credit. Since there is no updating of accounting entries, the system will allow you to go ahead with the posting of these items.
General Ledger Accounting
140. What is a ‘Document’ in SAP?
SAP is based on the ‘document principle’ meaning that a document is created out of every business transaction in the system. The Document is the result of a posting in accounting in SAP, and is the connecting link between various business operations. There are two types of documents:
1. Original Documents: these documents relate to the origin of business transactions such as invoices, receipts, statement of accounts from bank, etc.
2. Processing Documents: These include ‘accounting documents’ generated from postings in the system, ‘reference documents,’ ‘sample documents,’ etc. The processing documents other than the accounting ones are also known as ‘special documents’ and they aid in the simplification of document entry in the system.
Every document consists of:
• A Document Header
• Two or more Line Items
Before attempting to enter a document, call up the relevant document entry function as the system provides a variety of ready-made document entry templates suited to different transactions such as regular GL entry, customer invoice posting, etc. The details entered in a document can be simulated and displayed before the document is actually posted in the system. You may also choose to ‘park’ the document and post it later.
141. What is a ‘Document Header’?
The ‘Document Header’ contains information that is valid for the whole document such as:
• Document Date
• Document Type (Control Information)
• Document Number
• Posting Date
• Posting Period
• Company Code
Besides the above, the document header also has information (editable, later on) such as (a) trading partner, (b) document header text, (c) reference, (d) cross-Company Code number, etc.
142. What is a ‘Document Type’?
SAP comes delivered with a number of ‘Document Types,’ which are used in various postings. The document type helps to classify an accounting transaction within the system, and is used to control the entire transaction and determine the account types a particular document type can post to. For example, the document type ‘AB’ allows you to post to all the accounts, whereas type ‘DZ’ allows you to post only the customer payments. Every document type is assigned a number range.
The common document types include:
143. How is ‘Account Type’ Connected to ‘Document Type’?
The ‘Document Type’ is characterized by a 2-character code such as AA, DG, etc., whereas an ‘Account Type’ is denoted by a 1-character code such as A, D, etc., specifying which accounts a particular document can be posted to. The common account types include:
• A Assets
• D Customer (Debtor)
• K Vendor (Creditor)
• M Materials
• S GL
Figure 30: Document and Account Types
144. What do You mean by ‘Net’ Postings’?
Usually, when a transaction is posted, for example, a vendor invoice (document type: KR), the system posts the ‘Gross’ amount with the ‘tax’ and ‘discount’ included. However, SAP provides you the option of posting these items as ‘Net.’ In this case, the posting excludes ‘tax’ or ‘discounts.’ Remember to use the special document type KN. (Similarly, you will use the document type DN for ‘customer invoice-Net’ compared to the normal invoice postings for the customer using the document type DR.) For using this ‘net method’ of posting you should have activated the required settings in the customization.
145. Explain the Various ‘Reference Methods.’
SAP recommends ‘Reference Methods’ as a ‘document entry tool’ to facilitate faster and easier document entry into the system, when you are required to enter the same data time and again. Besides making the document entry process less time-consuming, this also helps in error-free document entry.
The various Reference Methods used in SAP include:
1. Reference Documents
2. Account Assignment Models
3. Sample Documents
146. What is the ‘Document Change Rule’?
The functionality ‘Document Change Rules’ configured in the system maintains the information relating to ‘what fields can be changed?’ and ‘under what circumstances?.’ As you are already aware, SAP’s document principle does not allow changing the ‘relevant’ fields once a document is posted; any changes can only be achieved through ‘Reversal’ or additional postings. Fields such as company code, business area, account number, posting key, amount, currency, etc., can never be changed once the document is posted. However, SAP allows changing some of the fields in the line items such as payment method, payment block, house bank, dunning level, dunning block, etc. These can be changed document by document or by using ‘mass change’ for a number of documents in a single step.
The changes to ‘master data’ are tracked and stored per user for an ‘audit trail.’
147. Differentiate between ‘Account Assignment Model,’ ‘Recurring Entries,’ and ‘Sample Document,’
‘Account Assignment Model’ is a ‘reference method’ used in document entry when the same distribution of amounts to several Company Codes, cost centers, accounts, etc., is frequently used. Instead of manually distributing the amount among accounts or Company Codes, you may use equivalence numbers for distributing both the credit and debit amounts. A cross-Company Code account assignment model can also be created.
The account assignment model may contain any number of GL accounts. The GL account items need not be complete. The model can be used across several Company Codes, and can even include Company Codes from non-SAP systems.
Figure 31: Account Assignment Model
• You can use the account assignment model while ‘parking’ a document (but you cannot use a ‘reference document’ for ‘parking’).
• The use of account assignment models is limited to GL accounts.
Unlike a ‘Sample Document,’ an account assignment model may be incomplete and can be completed during document entry by adding or deleting or changing the data already saved in the model.
The ‘Recurring Entry’ original document is used by the system as a ‘reference document’ for enabling posting of periodically recurring postings such as loan repayments, insurance premium payments, rent, etc. Since this document is not an accounting document, the account balances are not affected. In a recurring entry original document, you will not be able to change the (a) posting key, (b) account, and (c) amount. The recurring entry documents are defined with a special number range (X1). Unlike an account assignment model, these documents cannot be used for cross-Company Code postings.
The recurring entry document does not update transaction figures, per se, but acts only as a reference and as the basis for creating accounting documents. The SAP program SAPF120 creates the accounting documents from the recurring entry original document. There are two ways to set the exact date when this document should be posted to:
• Posting frequency: enter the day of the month and the period (in months) between two postings.
• Scheduled run: configure the ‘run schedule’ specifying the calendar days on which the program should post these documents.
A Sample Document is like a template, which is created and stored so that the information contained therein can be easily copied into new documents and posted in the system. But once a sample document is created note that you will not be able to change the ‘line items’ already contained in that document; all you can do is change the amounts in that sample document. But you can overcome this by defining a new sample document that can contain other line items or you may add new line items to the FI document, which is created by copying from the original sample document.
Sample documents have separate number ranges (X2).
148. What is a ‘Line Item’?
The ‘Line Items’ contain information relating to account number, amount, debit/ credit, tax code, amount, etc. SAP allows a maximum of 999 line items in a single document. Besides the one entered by you during an document entry, the system may also create its own line items called ‘system generated line items,’ such as tax deductions, etc. Irrespective of the number of line items entered, ensure that the total of these is always zero (that is, total debits should equal total credits). Otherwise, the system will not allow you to post the document.
149. What is a ‘Posting Key’?
A ‘Posting Key’ in SAP is a 2-digit alphanumeric key that controls the entry of line items. SAP comes with many posting keys for meeting the different business transaction requirements: 40 (GL debit), 50 (GL credit), 01 (customer invoice), 11 (customer credit memo), 21 (vendor credit memo), 31 (vendor payment), etc.
The posting key determines:
1. What account can be posted to
2. Which side of the account (debit or credit) to be posted to, and
3. What ‘layout’ screen needs to be used for that particular transaction.
It is a normal practice not to change any of the default posting keys in the system, as you would very rarely require additional posting keys.
150. Differentiate between the ‘Parking’ and the ‘Holding’ of Documents.
The ‘Parking of a Document’ in SAP is one of the two preliminary postings (the other being the ‘Holding’ of documents) in the system and refers to the storing of incomplete documents in the system. These documents can later be called on for completion and posting. While ‘parking’ a document, the system does not carry out the mandatory ‘validity checking.’ The system does not also carry out any automatic postings (such as creating tax line items) or ‘balance checks.’ As a result, the transaction figures (account balances) are not updated. This is true in the case of all financial transactions except in the area of TR-CM (Cash management) where ‘parked’ documents will update the transactions.
The parking of documents can be used to ‘park’ data relating to customers, vendors, or assets (acquisition only). When a cross-Company Code document is ‘parked,’ only one document is created in the initial Company Code; when this ‘parked’ document is posted all other documents relevant for all other Company Codes will also be created. However, it is to be noted that substitution functionality cannot be used with document ‘parking,’ as substitution is activated only on transaction processing.
The added advantage is that a document ‘parked’ by an accounting clerk can be called on for completion by someone else. The ‘parked’ documents can be displayed individually or as a list from where the required document can be selected for completion and posting. The number of the ‘parked’ document is transferred to the posted document. The original ‘parked’ document, if necessary, can be displayed even after it has been posted to.
During a transaction when you do not have a piece of required information, you can ‘Hold the Document’ and complete it later. As in the case of ‘parked’ documents, here also the document does not update the transaction figures.
The essential difference between these two types of preliminary postings can be summarized as follows:
151. What is an ‘Automatic Posting’?
When you post documents in SAP, there are instances where the system also adds some more line items (such as tax, cash discount, gain/loss from foreign exchange transactions, etc.) besides the ones you have entered in the document. This helps to reduce your work as the system calculates these automatically. However, you need to define accounts you want the system to automatically post to; this will ensure that no manual posting is allowed to any of these accounts.
152. What is ‘Clearing’?
‘Clearing’ in SAP refers to squaring-off open debit entries with that of open credit entries. Clearing is allowed in GL accounts maintained on an ‘open item’ basis and in all customer/vendor accounts. The clearing can either be manual or automatic. In the case of manual clearing, you will view the open items and select the matching items for clearing. In the case of automatic clearing, a program determines what items need to be cleared based on certain pre-determined open item selection criteria and proposes assignments before clearing these assigned items. Whatever the type of clearing, the system creates a clearing document with the details and enters the ‘clearing number’ against each of the cleared open items. The clearing number is derived from the document number of the clearing document.
You will also be able to do a ‘partial clearing’ when you are unable to match open items exactly; in this case, the balance amount not cleared is posted as a new open item. You may also configure clearing tolerance and also define rules on how to tackle the situation where the net amount after clearing is not zero (such as, writing off, posting the difference to a separate ‘clearing difference’ account, etc.).
In the case of customers who are also vendors, you will be able to clear between these two provided it is duly configured in the relevant master data (by entering the customer number in the vendor master record and the vendor number in the customer master record).
153. Explain ‘Reversal of Documents’ in SAP.
If you need to change some of the accounting information relating to an already posted document, you can only achieve this by ‘Reversing’ the original document and posting a new one with the correct information. However, reversal is possible only when:
• The origin of the document is in FI (not through SD or MM, etc.)
• The information such as business area, cost center, etc., is still valid (that you have not deleted these business objects)
• The original document has no cleared items
• The document relates only to the line items of customer/vendor/GL
While reversing, the system automatically selects the appropriate document type for the reversal, and defaults the relevant posting keys. (Remember that the document type for the reversal document would have already been configured when the document type was defined in the configuration.) Also note that if you do not specify the posting date for the reversal document, the system defaults to the posting date of the original document.
154. Explain ‘True Reversal,’ How is it different from regular ‘Reversal’?
As you are aware, any reversal results in opposite postings to the credit/debit sides of the original posting, leading to an increase in the account balances and the ‘trial balance’ is automatically inflated on both the sides. This is against the law in some countries such as France where it is required that even after reversal, there should not be an increased account balance. As a result, SAP came out with ‘True Reversal’ which overcomes this problem by ‘negative postings’ to the same line item(s) during reversal. The account balance, which was originally increased, is restored to the actual balance during the reversal:
155. What is ‘Fast Entry’?
Instead of the regular document entry screens, SAP provides ‘Fast Entry’ screens for facilitating a quick way of entering repetitive line items in a transaction. For achieving this, you need to define a Fast Entry Screen Layout, which will specify what fields you will require for data entry, and in what order. You may configure these fast entry screen layouts for GL account line items, credit memos, and customer/vendor invoices. Each of these fast entry screen layouts will be denoted by a 5-character screen variant in the system. Fast entry screens are used in complex (general) postings.
SAP’s enjoy postings are also meant for similar data entry screens, but the difference is that in the case of ‘fast entry’ you will start from scratch when identifying the fields, positioning them in the line item, etc., whereas in enjoy postings, the system comes with all the fields activated and you will select the fields that you do not want to be made available for data entry.
156. How do You Create ‘GL Account Master Data’?
‘GL Account Master Data’ can be created using any one of the following methods:
1. Manually
2. Creating with reference
3. Through Data Transfer Workbench
4. Copying from existing GL accounts
The Manual Creation of GL account master records is both laborious and time consuming. You will resort to this only when you can’t create master records using any of the other methods listed above.
You will follow the second method, Creating With Reference, when you are already in SAP and have an existing Company Code (Reference Company Code) from which you can copy these records to a new Company Code (Target Company Code). You will be able to do this by accessing the Menu: ‘General Ledger Accounting>GL Accounts>Master Data>GL Account Creation> Create GL Accounts with Reference.’ While doing this, you can copy the ‘account assignments’ as well ensuring that the integration of GL with other applications is intact. SAP facilitates so that you can (i) limit the number of GL records thus copied to the target Company Code, (if) create new records if necessary, and (iii) change the account number/name.
When your GL accounts are in a non-SAP system and you feel that these accounts will meet your requirements you will then use the ‘Data Transfer Workbench’ of SAP to transfer these records into SAP, and change them to suit the SAP environment. Since this will not have ‘Account Assignment’ logic as defined in SAP, you need to be careful when defining these assignments.
You will resort to the last option of Copying from Existing GL Accounts only when you feel that there is a Chart of Accounts in the system that meets your requirements 100%. Otherwise, follow the second method described above.
157. What is ‘Collective Processing’ of GL Accounts?
‘Collective Processing’ helps you to make systematic changes to a number of GL accounts in a single step. For example, you have used the ‘creating with reference’ method to create GL accounts in a new Company Code and you want to change the account names as well as the ‘GL account type’ (P&L or B/S). Then you will use the mass processing method. You can make changes to:
1. Chart of accounts data
2. Company Code data
Use Menu Path: ‘Accounting>Financial accounting>General ledger accounting>Master records>Collective processing.’ This can be achieved in IMG through: ‘Financial Accounting>General Ledger Accounting>GL Accounts> Master Data>GL Account Creation>Change GL Accounts Collectively.
Remember that the ‘collective processing’ helps only to edit and you cannot use this method if you need to create new master records.
158. What is ‘Individual Processing’ of GL Accounts?
In contrast to the ‘collective processing’ of GL accounts where you edit a number of accounts in a single step, Individual Processing helps to edit or create GL account master records one at a time. Here you can edit (including display, change, block, unblock, and delete) or create a new GL account in three different ways:
1. Centrally: You will be editing or creating a GL account master record in both the Chart of Accounts area and Company Code area in one step. This is also known as ‘one-Step’ GL creation.
2. In the Chart of Accounts area: you first edit or create the record here before doing it in the Company Code area.
3. In the Company Code area: you edit or create the record here after it has been done in the Chart of Accounts area.
Put together, steps 2 and 3 relate to the ‘step-by-step’ creation of GL account master records.
159. Is it Possible to Change an Existing B/S GL A/C to the P&L Type?
Technically, you will be able to change all the fields, except the account number, of a GL account in the Chart of Accounts area. However, in this particular instance when you change the ‘GL account type’ from ‘B/S’ to ‘P&L,’ make sure that you again run the ‘balance carry-forward’ program after saving the changes so that the system corrects the account balances suitably.
160. Why doesn’t the System allow You to Change the ‘Tax Category’ in a GL A/C Master?
You will be able to change the ‘Company Code’ related fields such as tax category, currency, etc., provided that there has not been any posting to these accounts. Pay attention to the following:
1. If you need to denote an existing GL account to later be managed on an ‘open item basis’ or vice versa, then make sure that the account balance is zero in either case.
2. If you are trying to change an existing ‘reconciliation account’ (to a regular GL), then make sure that the account has not been posted to.
3. If you are attempting to denote an existing ordinary GL account into a ‘reconciliation account,’ ensure that the account has a zero balance.
161. What is an ‘Account Group’?
The ‘Account Group’ (or GL Account Group), a 4-character alphanumeric key, controls how the GL account master records are created in the system. This helps to ‘group’ GL accounts according to the ‘functional areas’ to which they must belong. Account group is mandatory for creating a master record. The same account groups can be used by more than one more Company Code if they all use the same Chart of Accounts. Each GL account is assigned to only one account group.
The Account Group determines:
1. The number interval that is to be used while creating the master record.
2. The screen layout that is to be used while creating the master record in the Company Code area.
While defining the account groups in the system, you also need to define the corresponding field status for each of these groups. Otherwise, you will not be able to see any fields as all these would be hidden by default.
SAP comes delivered with a number of ‘account groups’ such as:
• SAKO (GL accounts general)
• MAT. (Materials Management accounts)
• FIN. (Liquid Funds accounts)
Figure 32: GL Account Group
In most situations, you will not require additional groups other than the ones already available in the standard system. However, if you need to create a new one, it is easier to copy an existing one and make modifications to it instead of creating one from scratch.
162. Describe ‘Number Range Interval.’
A ‘Number Range’ refers to a number interval defined in the system so that when documents are posted, the system assigns a number from this range. You will define different number ranges for different document types. Each document in SAP is uniquely identified by the combination of (a) document number, (b) company code, and (c) fiscal year.
The number range for a document type can be defined:
1. Per fiscal year or
2. Until a fiscal year in future.
If defined to last only one fiscal year, then the number range needs to be defined every year. When number ranges are defined every year, the system starts from the first number in the range for that particular year, which helps to prevent reaching the upper limit too fast.
Figure 33: Document Number Range
If you specify the fiscal year as ‘9999,’ then the document number range is valid forever (well, almost!) and you do not have to do this exercise of maintaining number ranges every fiscal year. But every year the system starts from the last number used up in the previous year and if a small number range is defined for a document type, you could easily run out of the number range fast.
The document numbers can either be:
1. Internally assigned by the system or
2. Externally input when the same is created.
The number ranges can be defined in such a way that the system generates the number automatically when a document is created. This is known as ‘internal number assignment.’ Under this, the system stores the ‘last number’ used for a document in the ‘Current Number’ field and will bring up the next number when another document is created.
If ‘external numbering’ is used, the user needs to input a document number every time a document is created in the system. Since the user supplies the number every time, the subsequent numbering may not be sequential. Unlike an internal numbering, the system does not store the ‘last number’ in the ‘Current Number’ field.
The numbers in a number range can either be numeric or alphanumeric. If numbers are numeric, the system will prefix the number with the required zeros to make the number length uniform at 10 digits. If you are using alphanumeric numbering, then the number is padded with zeros from the right. If you are following ‘year-specific’ numbering, it is better not to mix numeric and alphanumeric numbering for a particular document type in various fiscal years.
The system creates a minimum of one document when a transaction is created/completed. SAP recommends ‘filing’ original documents (under the number of the processing document (the document generated in SAP)). The best practice is to enter the (external) number of the ‘original document’ in the ‘Reference’ field of the document created in the SAP system. For easy cross-reference, the SAP document number thus created needs to be noted on the ‘original document.’
The following are the activities you need to complete for configuring the number ranges properly in the system:
1. Defining the number ranges
2. Copying the number ranges to Company Code(s)
3. Copying the number ranges to fiscal year(s)
163. What is a ‘Screen Layout’?
The ‘account group’ determines which ‘Screen Layout’ should be used while creating a GL account master record. For each of the account groups, you can define different screen layouts, which essentially determine the ‘Field Status’ of a field.
The field status refers to whether the field is:
1. Suppressed (field is invisible, hidden from display)
2. Required (display on, entry mandatory)
3. Optional (display on, entry not mandatory)
Figure 34: Field Status
All the above three are shown as ‘radio buttons’ against each of the fields in the screen layout, and you should select any one to set the status to that field; by default all the fields are ‘suppressed.’
There are two levels of controls of field status:
1. Field status at the account group level
2. Field status at the activity (create/change/display) level (i.e., at the transaction level).
You may also have the field status defined for posting keys (40-debit and 50-credit for the GL account postings). Also remember to define the field status for ‘reconciliation accounts’ as you will not be able to define any such status in the subledger accounts (for example, customer or vendor).
SAP has built-in rules, called link rules, to link these two levels and to decide the final status of a field in the ‘screen layout.’ The link rules also help to overcome the field-status setting differences arising out of different settings at the Client level (field status for posting keys) and the Company Code level (field status settings at the account group level).
164. What is a ‘Field Status Group’?
The ‘field status’ of an individual field or a group of fields is marked in a ‘Field Status Group,’ which is then assigned to individual GL account master records. You may attach field status groups to a field status variant so that the ‘field status groups’ are used in various Company Codes.
Figure 35: Field Status Variant (FSV)
The Field Status Variant is named similar to the Company Code. For example, if your Company Code is 1000, the field status variant is also named 1000, and it is assigned to the Company Code.
Figure 36: Assign a FSV to Company Code
165. What do You mean by ‘Balances in Local Currency’ Only?
When you create GL account master records, it is necessary to decide whether you want an account to have the transactions updated only in local currency. You will set this indicator accordingly in the ‘Company Code area’ of the master record. Make sure to set this indicator for clearing accounts such as:
• Cash discount clearing accounts
• GR/IR clearing accounts
Note that you need to set this indicator ‘on’ for all the ‘clearing accounts’ where you use the local currency to clear the line items in various currencies so that the transactions are posted without posting any exchange rate difference that otherwise might arise.
Example: Consider an invoice for USD 1,000, which on that day translates into an amount of INR 45,000 with an exchange rate of I USD=INR 45. Imagine that when the goods are received, the exchange rate was 1 USD=INR 44.
• If the indicator is set, the system ignores the exchange rate as if the line items have been maintained only in the local currency (INR), and the items are cleared.
• If the indicator is NOT set, the system makes a posting for the ‘exchange rate difference’ (INR 1, 000) before clearing the two line items.
166. What is ‘Line Item Display’?
To display line items of an account, you need to set the indicator ‘Line Item Display’ to ‘on’ in that account’s master record. This is mandatory for customer and vendor accounts. The line items can be displayed using the classical display or the SAP List Viewer (ALV). You can also use several ‘display variants’ to display various fields when you feel that the Standard Variant is not meeting your requirements.
167. What is ‘Archiving’? How does it differ from ‘Deletion’?
‘Archiving’ refers to deleting data from the documents in the database and storing the data in a file, which can be transferred to an ‘archiving system’ later on. Archiving does not physically delete the documents. ‘Deletion’ actually removes the documents from the database. To proceed with archiving and deletion you need to:
1. Block posting to these archived master records.
2. Mark (the master records) for deletion: Mark for deletion at the ‘Chart of Accounts area’ to delete the records from all the Company Codes. However, if you do not want to delete from all the Company Codes, but only from one or more Company Codes then do the same in the ‘Company Code area’ of the master record(s).
3. Archive all the transaction figures from the relevant documents.
4. Call up a special program to ‘delete’ the records: The program will check whether that particular document could be deleted. If yes, it will proceed to ‘archive’ and then to ‘deletion.’
168. Tell me the Two uses of ‘Blocking’ an Account.
You may use ‘Blocking’ to:
• Block an account from further postings.
• Block the creation of the account itself (at the Company Code level or Chart of Accounts area).
169. How do You Configure the GL A/C for the ‘House Bank’?
A ‘House Bank’ is defined using transaction code FI12. A ‘bank key’ represents the bank. The house bank can contain several accounts; for each of these accounts you need to maintain a GL account. The bank determination, for an automatic payment program, is configured using the Transaction Code FBZP.
170. What is an ‘Intermediate Bank’?
‘Intermediate Banks’ are used in SAP in addition to the house banks and partner banks for making or receiving payments from business partners abroad. The payment processing, involving an intermediate bank, makes use of the ‘bank chain,’ which may consist of a house bank, a partner bank, and a maximum of intermediate banks.
171. Explain ‘Intercompany Postings.’
‘Intercompany Postings’ arise when a Company Code, for example, in a centralized procurement, pays for itself and on behalf of other Company Codes. When posted, the transaction results in three documents: (1) one for the paying Company Code (say, 1111) (2) one for the other Company Codes (say, 2222 and 4444), and (3) one for the intercompany transaction itself.
Before making intercompany transactions, you need to configure both ‘intercompany payables’ and ‘intercompany receivables.’ For each combination of these Company Codes, you will be required to maintain a ‘clearing account,’ which must be referenced in each of these Company Codes. You will also be able to configure whether you manually input the transaction number or allow the system to automatically assign the numbers. In the case of system-generated transaction numbers, this 16-digit number consists of (1) a 10-digit document number (1222222222) of the paying Company Code, followed by (2) 4 digits representing this paying Company Code (1111), and (3) 2 digits representing the last two digits of the financial year (07) (for example, 1222222222111107).
172. How can You Manually ‘Clear’ ‘Open Items’? When?
Under ‘Manual Clearing,’ you will select the open items, based on the incoming payment so that the selected ‘open items’ are ‘cleared’ (knocked-off). In cases like refunds from a vendor or transactions involving bank sub-accounts and clearing accounts, etc., you will use manual clearing. When cleared, the system flags these line items as ‘cleared,’ creates a clearing document, and enters the clearing document number and clearing date in these open items. Besides the clearing document, the system may also generate ‘additional documents’ in cases such as partial or residual processing, and for posting the loss/gain to the assigned GL account.
While doing this, if there is a payment difference, it can be treated the way it is configured in the system:
• If the difference is within the tolerance limit, defined in the system using the tolerance groups (defined at the Company Code level), the cash discount is adjusted or the system automatically posts the difference to a gain/loss GL account.
• When the payment difference exceeds the limits of defined tolerance, then the incoming amount may be processed as a partial payment (the original open item is not cleared, but the incoming payment is posted with a reference to that invoice) or the difference is posted as a residual item (the original open item is cleared and a new open item is created by the system for the difference amount) in the system.
You may also use the Menu Path: Accounting>Financial Accounting> Account Receivable>Document entry>Incoming payment>Post or Accounting >Financial Accounting>GL>Document entry>Incoming payment>Post
173. How do You Perform ‘Period Closing’ in SAP?
You do a ‘(Period) Closing’ in SAP in three steps:
• Completing the Pre-closing activities
• Financial Closing
• Managerial Closing
174. What is ‘Pre-closing’?
You need to ensure the following as part of the ‘Pre-closing’ activities:
1. Post all the Recurring Entries for expenses and accruals.
2. Ensure that all the interfaced programs have been run so that the required data have been transferred to the system.
3. Post all the depreciation, material receipts, invoices, salaries, etc. In short, ensure that all the transactions for the period in question have been duly recorded and posted into the system.
175. Explain ‘Financial Closing.’
‘Financial Closing’ involves completing the following activities and taking out the financial statements for the period concerned:
1. Revaluate/Regroup:
• Revalue Balance Sheet items managed in foreign currencies—use the report RFSBEW00 to valuate GL Balance Sheet Accounts managed in a foreign currency. (The report generates a Batch Input session to post the revenue or expense resulting from any exchange rate differences.)
• Clear Receivables or Payables with the ‘exchange rate difference.’
• Valuate all the Open Items using the report SAPF100. This is used to valuate all the open receivables and payables, using the period-end exchange rates. Here also, the report generates a Batch Input session to post the entries resulting from any exchange rate differences.
• Regroup GR/IR using the program RFWERE00 to allocate the net balance (depending on whether the balance is a net debit or credit) in the GR/IR Account to one of two GL Accounts (created to actually depict the net effect of the balance in the GR/IR Account).
2. Ensure accounting accuracy:
• Use the program SAPF190 to compare the totals created by the system in the (1) indexes (customers, vendors, and GL) and documents (customers, vendors, and GL) with that of the (2) account balances (customers, vendors, and GL) to ensure the transaction accuracy.
3. Run required reports:
• Generate the financial statements (balance sheet and profit & loss account) using the financial statement versions. You may also generate the key figure/ ratio reports (use the GL account information system).
176. What is a ‘Financial Statement Version’?
A ‘Financial Statement Version’ helps to define the Financial Statements (both the Balance Sheet and Profit & Loss statements). When you copy the settings from an existing Company Code to a new one, you will also be copying the financial statement version defined for the ‘source’ Company Code.
Figure 37: Financial Statement Versions
You may also define a new financial statement version and build the financial statements from scratch. You may create the financial statements both for external reporting (Company Code financial statements) and internal reporting (business area financial statements).
You may also create the balance sheets for a group of Company Codes using FI-SL (Special Purpose Ledgers). The financial statements may be defined to provide information from a period accounting point of view (GL account groups wise) or a cost of sales point of view (functional area financial statements).
All the above statements can be configured and defined to provide different levels of detail:
Figure 38: Financial Statement Version—BAUS
A financial statement version can have a maximum of 10 hierarchy levels, with each level assigned with an item (account category). As you go down the hierarchy, you define the account categories in more detail, with the lowest level being represented by the GL accounts. The system displays the relevant amount for each of these items.
177. What Items are Required in a ‘Financial Statement Version’?
Irrespective of the details you require in a ‘Financial Statement Version,’ it is mandatory that you have, at least, the following items defined:
1. Assets
2. Liabilities
a. Net Result: Profit
b. Net Result: Loss
3. P/L result (during annual closing, when you run the program RFBILA00, the system calculates the profit or loss by subtracting the ‘total liabilities’ from ‘total assets’ and updates the relevant Net Result item—Profit or Loss).
4. Not assigned (posted amounts but not yet assigned to any of the account groups).
178. How do You Ensure ‘Correct’ Balances in the ‘Financial Statement Version’?
In order to have a balanced statement (Profit & Loss and Balance Sheet) you need to ensure that the accounts are correctly and completely assigned to the nodes of the Financial Statement Version. You may do this by resorting to the necessary assignments at the account balance level or node balance level.
At the account balance level, you need to ensure that the account is shown in two different nodes, but you will turn “ON” the ‘debit indicator’ of the account on one node and turn “ON” the ‘credit indicator’ on the other node. Imagine that you have a bank current account 10001000. When you turn “ON” the debit indicator, this account shows only the debit balances and is construed as the asset. On the other hand, when the credit indicator is turned “ON,” the balances on this node now indicate that you owe to the bank (overdraft).
You may also use the node-level assignment. In this case, the system uses the ‘debit/credit shift’ and shows only the ‘effective’ balance at the node and not at the individual account level.
179. How do You Perform ‘Annual Closing’ in SAP?
‘Annual Closing’ is like any other ‘period closing’ and you will be performing all the activities that are required for a period-end-close. In addition to those activities, you will also:
• Carry forward Vendor and Customer accounts
• Carry forward the GL account balances of all the Balance Sheet items
• Close the Profit & Loss Accounts and carry forward the balance (profit or loss) to the retained earnings account(s)
For a GL account ‘carry forward,’ use the program SAPF011.
180. Explain ‘Managerial Closing.’
In ‘Managerial Closing’ you will:
• Do a preliminary Controlling period closing
• Settle/re-allocate costs across Controlling organization
• Draw and review internal reports
• Re-open the Controlling period
• Correct and adjust the accounting data, if required
• Reconcile FI and CO by running the FICO Reconciliation Ledger
• Run re-adjustment programs to ensure that the Business Areas and the Profit Centers are balanced
• Draw reports and analyze
181. What is the ‘New FI-GL’ in FI in ECC?
The traditional or ‘Classic FI-GL accounting’ in FI has been focused on providing comprehensive external reporting by recording all business transactions in the system. However, to meet modern-day requirements, this has now been enhanced, called the ‘New FI-GL,’ and includes the following:
• Parallel accounting: Maintaining several parallel ledgers to meet different accounting principles.
• Integrated legal and management reporting: Unlike the traditional GL, the ‘New FI-GL’ enables you to perform internal management reporting along with legal reporting. So you are in a position to generate Financial Statements for any dimension (for example, profit center) in the business.
• Segment reporting: With the introduction of the Segment dimension, SAP now enables you to produce Segment Reports based on IFRS (International Financial Reporting Standards) and the GAPP (Generally Accepted Accounting Principles) accounting principles.
• Cost of sales accounting: It is now possible to perform cost of sales accounting in the ‘New FI-GL.’
However, the following functions are not yet supported in the ‘New FI-GL’:
• Transfer Price
• SKF (Statistical Key Figure)
• Euro Translation
• AIS (Audit Information System)
• Archiving
• Data Retention Tool
The ‘New FI-GL’ needs to be activated in the system before you start using the IMG Menu Path:>Financial Accounting (New)->Financial Accounting Global Settings (New)/General Ledger Accounting (New).
In the standard system, the tables from ‘classic general ledger accounting’ (GLT0) are updated as well as the tables in ‘New FI-GL’ during the activation. This enables you to perform a ‘ledger comparison’ during the implementation of ‘New FI-GL’ to ensure that your ‘new GL accounting’ has the correct settings and is working correctly. To compare ledgers, in Customizing choose Financial Accounting Global Settings (New)->Tools->Compare Ledgers.
It is recommended that you ‘deactivate’ the update of tables for ‘classic GL accounting’ once you have established that ‘New FI-GL’ is working correctly. To do this, in Customizing choose Financial Accounting Global Settings (New)-> Tools->Deactivate ‘Update of Classic General Ledger.’
Figure 39: New FI-GL
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.
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.’
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.’
191. Explain ‘Revenue Account Determination’ in SD.
The billing documents created during the sales cycle results in automatic postings to GL accounts on the FI side. In general, ‘Account Determination’ is based on the following five factors:
1. Chart of accounts
2. Sales organization
3. Account assignment group of the customer
4. Account assignment group of the material
5. Account key
The system determines the ‘chart of accounts’ from the company code in the ‘billing document,’ and the ‘sales organization’ is determined from the corresponding ‘sales order.’ The ‘account assignment group’ is taken from the respective masters of customer/material. The ‘account key’ helps the user to define the various GL accounts, and this key is assigned to the ‘condition type’ (KOFI) in the ‘pricing procedure.’
These GL accounts are automatically determined when you make the following configuration in the system:
1. Assigning an ‘account determination procedure’ to a ‘billing document type’
2. Assigning this ‘account determination procedure’ to a ‘condition type’
3. Assigning this ‘condition type’ to an ‘access sequence’
4. Configuring the ‘condition tables’
Table Description
001 Customer /Material Grp./AccKey
002 Cust. Grp/AccKey
003 Material Grp/Acc Key
004 General
005 Acc Key
Application Condition Type Chart of a/c Sales Org AcctAsg Grp Acc Asgmnt A/c Key GL a/c
001 Customer grp/Material Grp./AccKey: Details
V KOFI COMP 1000 01 10 ERL 5012100000
V KOFI COMP 1000 01 10 ERS 5012100000
V KOFI COMP 1000 02 10 ERL 5012200000
V KOFI COMP 1000 02 10 ERS 5012200000
V KOFI COMP 2000 01 20 ERL 5013100000
V KOFI COMP 2000 01 20 ERS 5013100000
V KOFI COMP 2000 02 20 ERL 5013200000
V KOFI COMP 2000 02 20 ERS 5013200000
005 Acc Key: Details
V KOFI COMP 1000 MWS 2470000000
V KOFI COMP 2000 MWS 2470000000
Figure 47: Revenue account determination
192. Outline ‘Credit Management’ in SAP.
‘Credit Management’ helps to determine credit limits of customers, aids in the creation of ‘credit check’ policies, as well as helps companies monitor and evaluate their customers. This is a cross-functional responsibility in SAP, covering both the Sales and Distribution and Financial Accounting modules.
As in the case of any automated process such as dunning, payment, etc., credit management in SAP requires certain prerequisites be defined beforehand:
1. Customer master data has been created both in SD and FI.
2. Credit control area has been defined and assigned to a Company Code.
SAP makes use of the concept ‘credit control area’ for credit management. As explained elsewhere, the credit control area is an organizational element defined to which one or more Company Codes are attached. In the case of customers defined under more than one Company Code, they may fall under different credit control areas. But note that:
• A Client can have more than one credit control area, but the converse is not true: one credit control area cannot be assigned to more than one Client.
• A credit control area can be assigned to more than one Company Code, but the converse is not true: one Company Code cannot be assigned to more than one credit control area.
Figure 48: Client—Credit Control Area—Company Code—Customer
While defining the credit limit for a customer:
• You will define a maximum limit per credit control area (Example: Credit Control Area AAAA->USD 500,000, Credit Control Area BBBB ->USD 200,000)
• You will define a global maximum limit for all credit control areas put together (USD 600,000)
3. Credit data (per credit control area ‘maximum limit’ as well as the ‘total’ for all areas, in the control data screen) for the customer has been created.
4. Risk categories have been defined and assigned to customers.
5. Credit groups (document credit group) for document types have been defined. Document credit groups combine order types and delivery types for credit control.
6. Defined, in SD, at what time (when order is received or when a delivery is made, etc.) the credit check should happen.
The credit management process starts when a sales order is entered in SD. Imagine that this results in exceeding the credit limit defined for the customer. Now:
a. The system creates three comparison totals considering (1) open receivables, (2) sales order values, value of goods to be delivered and the billing document value from SD, and (3) special GL transactions (e.g., ‘down payments’ and ‘bills of exchange’).
b. Based on (a) above the system throws an (1) error message and prevents saving the order or (2) a warning message, and the system does not prevent saving, but the order is ‘blocked.’
c. The Credit representative, using information functions (SD information system, FI information system, credit overview, credit master list, early warning list, oldest open item, last payment, customer master, account analysis, etc.), processes this blocked order either (1) from the ‘blocked SD documents list’ or (2) the mailbox, and releases the order, if necessary.
d. Delivery is created, the billing document is generated and posted, and A/R is updated.
e. Customer pays the invoice and A/R is posted.
193. What is a ‘Credit Check?
A ‘Credit Check’ is defined for any valid combination of the following:
• Credit control area
• Risk category
• Document credit group
194. Differentiate ‘Static Credit Check’ from ‘Dynamic Check.’
Under ‘Static Credit Check,’ the system calculates the credit exposure of a particular customer as the total of:
• Open order (delivery not yet done)
• Open delivery (value of deliveries yet to be invoiced)
• Open billing documents (not transferred to accounting)
• Open items (AR item not yet settled by the customer)
Customer’s credit exposure is not to exceed the established credit limit.
The ‘Dynamic Credit Check’ is split into two parts:
• Static limit: Total of open items, open billing, and open delivery values.
• Dynamic limit (Open Order Value): The value of all undelivered and partially delivered orders totalled and stored on a time-scale in the future (10 days, 1 week, etc.) known as a ‘horizon date.’
During the ‘dynamic credit check,’ the system will ignore all orders beyond the ‘horizon date.’ The sum total of ‘static’ and ‘dynamic’ limits should not exceed the credit limit established for the customer.
195. List the Reports in ‘Credit Management.’
SAP provides you with the following Reports in Credit Management:
• RFDKLI10 Customers with missing Credit Data
• RFDKLI20 Re-organization of Credit Limit for Customers
• RFDKLI30 Short Overview of Credit Limit
• RFDKLI40 Overview of Credit Limit
• RFDKLI41 Credit Master Sheet
• RFDKLI42 Early Warning List (of Critical Customers)
• RFDKLI43 Master Data List
• RFDKLI50 Mass change of Credit Limit Data
• RVKRED06 Checking Blocked Credit Documents
• RVKRED08 Checking Credit Documents which reach the Credit Horizon
• RVKRED09 Checking the Credit Documents from Credit View
• RVKRED77 Re-organization of SD Credit Data
196. How does ‘Partial Payment’ differ from ‘Residual Payment’?
When processing the ‘incoming payment’ to apply to one or more of the ‘open items’ of a customer, there may be a situation where the incoming payment is more than the ‘tolerances’ allowed. In this case, you can still go ahead and process the payment by resorting either to a Partial Payment or a Residual payment.
A Partial payment results in posting a credit to the customer’s ‘open item,’ but leaves the original item intact. As a result, no open item is cleared. During partial payment, the system updates the ‘invoice reference’ and ‘allocation’ fields.
In contrast to a partial payment, the Residual payment clears the particular ‘open item’ against which the payment is applied. However, since there are not enough amounts to clear the entire open item, the system creates a new open item, which is the difference between the original invoice item and the payment applied. Note that the new invoice/open item created by the system will have the new document date and new baseline date though you can change these dates.
197. What is ‘Payment Advice’?
‘Payment Advice’ helps in the automatic searching of ‘open items’ during the ‘clearing’ process to find a match for an ‘incoming payment.’ This is possible because you can use the ‘payment advice’ number instead of specifying parameters in the ‘selection screen.’ A typical payment advice may contain details such as document number, amount, currency, reason for underpayment, etc. The payment advices are of various categories; the first 2 digits of the payment advice number help to differentiate one payment advice from another:
• Bank advice
• EDI advice
• Lockbox advice (created during the clearing process, available in the system whether clearing was successful or not)
• Manual advice
• Advice from a bank statement
Most of the payment advices are deleted as soon as the clearing is successful in the system.
198. Describe ‘Lockbox’ Processing.
‘Lockbox’ processing (configured in the FR-TR module) of incoming payments is used predominantly in the United States. Here, the bank receives the checks from customers as incoming payments, creates payment advice for each of these customer check payments, and informs the payee of the payment, in BAI file format. This lock box file is sent to the payee who imports the details into the system using this electronic file. The system updates the payments into the GL by way of ‘batch input’ processing.
199. How can ‘Reason Codes’ Help with Incoming Payment Processing?
‘Reason Codes’ configured in the system help to handle the ‘payment differences’ of individual open items in an invoice (either using payment or advice or in the normal course). To each of the reason codes, you will define the ‘posting rules’ and the GL accounts in the IMG.
Once done, when there is a payment difference against a particular open item, the system looks for the reason code:
• When the ‘charge-off indicator’ has been set for that reason code, then the system posts the payment difference to a GL account. When this indicator is not set, then a new open item is created for the payment difference.
• When ‘disputed item indicator’ has been set, then the system ignores these line items when counting for the customer’s credit limit.
200. What is ‘Dunning’ in SAP?
The SAP System allows you to ‘dun’ (remind) business partners automatically. The system duns the open items from business partner accounts. The dunning program selects the overdue open items, determines the dunning level of the account in question, and creates dunning notices. It then saves the dunning data determined for the items and accounts affected. You can use the dunning program to dun both customers and vendors. It may be necessary to dun a vendor in the case of a debit balance as a result of a credit memo.
Dunning is administered through a Dunning Program, which uses a dunning key (to limit the dunning level per item), a dunning procedure, and a dunning area (if dunning is not done at the Company Code level).
Figure 49: Dunning Key
No comments:
Post a Comment