SAP Accounts Payable Interview Questions and Answers
Q1. What is SAP ACCOUNT PAYBLE?
Ans: Accounts Payable (FI-AP) is a foundation of FI and MM Purchasing. Kick off your setup of merchants, conveyances, solicitations, and installments with SAP FIAccounts Payable in this E-Bite. Set up FI-AP to oversee merchants by keeping up with installment terms, characterizing cash rebate bases, and delivering solicitations.
Q2. Make sense of 'client/seller Master Records?
Ans: There are three classes of information kept up with in a regular expert record for a client:
Organization Code Data
Deals Area Data (for clients)/Purchasing Organization Data (for merchants)
General Data incorporates general data, for example, account number, name, phone, bank data, exchanging accomplice, merchant (on the off chance that the client is likewise a seller), bunch key, bank key, ledger, substitute payee, and so on, which are normal to all the Company Codes utilizing this expert. Organization Code Data contains terms of installment, installment strategies, resilience bunch, clearing with seller, dunning information (dunning technique, dunning beneficiary, dunning block, dunning agent, and so forth), compromise account, sort key, deals region (buying association on account of merchant ace), head office, and so on. Aside from deals (buying) related data, any remaining subtleties are typically kept up with for the money individuals who can likewise get to the deals information when the expert is kept up with 'halfway.'
Deals Area Data in the Company Code region of a Customer ace record contains the accompanying:
Request related information (deals region, deals office, deals bunch, client bunch, and so on.)
Cost related information (estimating bunch, valuing technique, and so forth.)
Transporting information (transporting procedure, conveyance need, and so on.)
Charging information (installment terms (not the same as the installment terms kept up with at the Company Code level), account task bunch, and so on.)
Buying Organization Data in the Company Code region of a Vendor ace record contains the accompanying:
Conditions (request cash, installment terms, Incoterms, least request esteem, and so on.)
Deals information (a/c with Vendor)
Control information (as in the screen shot underneath)
During production of an expert record, the framework checks for 'copies' for a similar client which is accomplished by the framework through the 'Search-Id' (Match Code) designed on the client's location data.
As on account of the GL account ace record, the production of the client/merchant ace record is likewise constrained by the 'Record Group,' which is called 'Client Account Group/Vendor Account Group' (CPD/CPDL/KREDI/LIEF) and controls the numbering of client/seller ace records, field status, whether a record is a standard one or a 'One Time' account, and so on.
Open table as calculation sheet Activity in Accounting Centrally Customer Vendor Customer Vendor
Make FD01 FK01 XD01 XK01
Change FD02 FK02 XD02 XK02
Show FD03 FK03 XD03 XK03
Block/Unblock FD05 FK05 XD05 XK05
Mark for Deletion FD06 FK06 XD06 XK06
Q3. Who is an 'substitute Payee'?
Ans: A client who pays in the interest of one more client is known as an 'Substitute Payee' (or Alternate Payer). However the other payee pays for the benefit of another, the framework keeps up with all the exchange subtleties in the record of the first client. Assigning 'substitute payee' doesn't vindicate the client of his/her commitment for installment.
The 'substitute payee' can be kept up with in Client-explicit information or in the Company Code region. At the point when kept up with in the Company Code region you can utilize that payer just in that Company Code; whenever characterized at the Client level you can utilize it across all Company Codes. There are three different ways to 'choose' the other payee when a receipt is handled:
1. The other payee (say, 1000) entered in the client ace record is the one chosen by the framework as the default.
2. At the point when there is more than one substitute payer (say, 1000, 1900, 2100, and so on) characterized for a solitary client in the expert record (you will do this by tapping on the 'permitted payer' button and make more than one payer), you might choose a payer (say, 2100) (other than the default, 1000) while handling the receipt. Presently the framework will disregard the other payer (1000) coming from the expert record.
3. In the event that you have put a mark in the 'individual passages' check enclose the 'substitute payer in report' segment in the client ace record, then this will permit you to propose another other payer, say, 3000 (other than those generally characterized in the framework). Presently, subsequent to characterizing this other payer you can utilize it to deal with the receipt. For this situation, the substitute payer (3000) outweighs the payers (1000 and 2100) in sync 1 and 2 above.
Q4. What Is The 'exchanging Partner' Concept?
Ans: The 'Exchanging Partner' idea is utilized to settle and accommodate 'between organization exchanges,' the two deals and buys. This is by and large accomplished by entering the Company-ID (not the Company Code) to which a client has a place in the 'exchanging accomplice' field under the tab 'Record Control' in the client ace record. You can do a comparative section in the seller ace record.
Q5. Make sense of 'resilience' In Transaction Processing?
Ans: 'Resiliences' are characterized in the framework to work with managing the distinctions emerging out of bookkeeping exchanges and to train the framework on the most proficient method to continue further. Typically, you characterize resistances (either in 'outright terms' or in 'rates') past which the framework won't permit you to post a record should there be a distinction.
In SAP, resistances are characterized per Company Code and there are a few kinds:
GL account clearing resistance
You will characterize an 'worker resilience bunch' in the framework and allocate the representatives to these gatherings.
While characterizing the resistance bunch you will indicate:
Maximum cutoff points for different posting systems
Sum per archive
Sum per open record thing
Cash markdown, in rate
Allowed installment contrasts
How much finished or under installment a worker is permitted to process. This is characterized both in outright qualities and in rates. Other than characterizing the over two, at the Company Code level, you will likewise characterize comparative resistances for client/merchant resilience bunch. Once characterized, every one of the clients (sellers) is appointed to one of these gatherings. Here likewise, you characterize the 'allowed installment contrasts':
While handling, the framework looks at the resistance of a representative against the client resilience (or merchant resistance or the GL) and applies the most prohibitive of the two.
Q6. What Is 'double Control' In Master Records?
Ans: 'Double Control' assists with forestalling unapproved changes to the significant and 'delicate' fields in the expert records in the framework. (All such touchy fields are characterized in the Table T055F while altering the application. Furthermore, these fields are characterized per Company Code and per Client.) Consider, for instance, a delicate field, for example, 'installment block' in a merchant ace record. At the point when a client changes this field's substance, the framework requires another client (generally of more significant position) to support this change and a review trail is kept up with of every such change. Except if ' the change is supported, in this model, this specific expert is impeded by the framework for considering a similar in the following 'installment run.'
Open table as calculation sheet Activity Customer Vendor
Show changes (bookkeeping region) FD04 FK04
Show changes (midway) XD04 XK04
Affirm changes, independently FD08 FK08
Affirm changes, in a rundown FD09 FK09
Q7. What Is A 'bank Director' In Sap?
Ans: SAP stores the expert information (subtleties, for example, bank key, bank name, bank country, bank address, etc) connecting with the banks in the 'Bank Directory' (Table: BNKA). Keep in mind, the 'bank bosses' are not made in the application but rather in the execution side utilizing the IMG. (Obviously, you can likewise make the bank ace in the application side in FI-TR and not in FI-GL or AP or AR.) However, in the event that you are currently making an expert record for a merchant or a client and you enter some bank subtleties, which the framework doesn't track down in the 'Bank Directory,' then, at that point, the framework consequently gets the significant screens for you to keep up with and update the bank subtleties in the bank catalog.
You might make the bank catalog in two ways:
Physically (IMG way: Financial Accounting>Bank Accounting>Bank Accounts>Define 'House Banks')
Consequently (by bringing in the bank subtleties utilizing an extraordinary program)
Q8. What Is A 'house Bank'?
Ans: 'House Bank' is the bank (or monetary establishment) in which the Company Code being referred to keeps its cash and does the exchanges from. A house bank in SAP is distinguished by a 5 person alphanumeric code. You can have quite a few house banks for your Company Code, and the subtleties of every one of these house banks are accessible in the 'bank registry.'
Each 'house bank' in the framework is related with a nation key (U.S., IN, and so forth) addressing the nation where the bank is found, and an extraordinary country explicit code called a 'bank key.' The framework utilizes both the 'country key' and the 'bank key' to distinguish a 'house bank.'
For every one of the 'house banks,' you can keep up with more than one financial balance; each such record is recognized by a record ID; i.e., Chek1, Check2, Pybl1, and so on. Here, 'Chek1' may indicate Checking account 1, 'Pybl1' may signify Payables account 1, etc. You might name the records such that it is effectively understandable. The 'Record ID' is referred to in the client/seller ace record and it is utilized in the installment program by the framework.
For each 'account ID' you will likewise determine the ledger number (most extreme length of this identifier is 18 characters). You might name this so that it is likewise effectively conceivable.
For each 'ledger number' so characterized in the 'house bank,' you really want to make a GL account ace record, and keeping in mind that doing so you will consolidate the 'house bank id' and the 'account id' in that specific GL ace record.
Q9. Make sense of A 'business Cycle' In Sap?
Ans: 'Deals Cycle' involves movements of every kind including citation/request, deals request, conveyance, charging, and assortment.
Coming up next are the different cycles inside SAP that total a deals cycle:
Regularly, coming up next are the records made during a deals cycle:
Q10. Make sense of 'programmed Account Assignment' In Sd?
Ans: During merchandise issue in the deals cycle, the framework is typically designed to refresh the significant GL accounts naturally and to make the important bookkeeping archives. This customization in IMG is likewise called material record task and is accomplished through various strides as point by point beneath:
Decide 'valuation level' (Company Code or plant).
Enact 'valuation gathering code' and connection it with the 'outline of records' for every 'valuation region.'
Interface 'valuation class' with 'material sort' (FERT, HAWA, HALB, and so forth) with the 'account class reference' (blend of valuation classes).
Keep up with 'account alteration codes' for 'development types.'
Connect 'account change codes' with 'process keys' (exchange/occasion keys).
Keep a GL represent a given mix of 'graph of accounts'+ 'valuation gathering code '+' account change code '+' valuation classes.'
The course of Automatic Account Determination is as per the following:
Contingent upon the 'plant' entered during products issue (GI), the 'Organization' not set in stone by the framework which thus decides the important 'Diagram of Accounts.'
The plant subsequently entered in products issue decides the 'valuation class' and afterward the 'valuation gathering code.'
The 'valuation not entirely set in stone from the 'material expert.'
Since the 'account change code' is relegated to a 'cycle key' which is now connected to a 'development type,' the 'exchange key' (DIF, GBB, AUM, BSX, and so on) decides the 'GL account' as posting exchanges are predefined for every 'development type' in 'stock administration.'
Q11. What number of 'dunning Levels' Can Be Defined?
Ans: You might characterize up to nine dunning levels. In the event that there is only one dunning level, it is known as a 'installment update.'
Q12. What Is A 'credit Check?
Ans: 'Credit Check' is characterized for any legitimate mix of the accompanying:
Credit control region
Archive credit grouP
Q13. Separate 'static Credit Check' From Dynamic Check?
Ans: Under 'Static Credit Check,' the framework computes the credit openness of a specific client as the complete of:
Open request (conveyance not yet finished)
Open conveyance (worth of conveyances yet to be invoiced)
Open charging reports (not moved to bookkeeping)
Open things (AR thing not yet settled by the client)
Client's credit openness isn't to surpass the laid out credit limit.
The 'Unique Credit Check' is parted into two sections:
Static breaking point: Total of open things, open charging, and open conveyance values.
Dynamic cutoff (Open Order Value): The worth of all undelivered and to some degree conveyed orders totalled and put away on a period scale from now on (10 days, multi week, and so on) known as a 'skyline date.' During the 'powerful credit check,' the framework will overlook all orders into the great beyond 'date.' The whole of 'static' and 'dynamic' cutoff points shouldn't surpass as far as possible laid out for the client.
Q14. List The Reports In Credit Management?
Ans: SAP furnishes you with the accompanying Reports in Credit Management:
RFDKLI10 Customers with missing Credit Data
RFDKLI20 Re-association 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 difference in Credit Limit Data
RVKRED06 Checking Blocked Credit Documents
RVKRED08 Checking Credit Documents which arrive at the Credit Horizon
RVKRED09 Checking the Credit Documents from Credit View
RVKRED77 Re-association of SD Credit Data
Q15. How Does 'fractional Payment' Differ From 'leftover Payment'?
Ans: When handling the 'approaching installment' to apply to at least one of the 'open things' of a client, there might be a circumstance where the approaching installment is more than the 'resistances' permitted. For this situation, you can in any case feel free to handle the installment by turning either to a Partial Payment or a Residual installment.
A Partial installment brings about presenting a credit on the client's 'open thing,' however leaves the first thing in one piece. Thus, no open thing is cleared. During halfway installment, the framework refreshes the 'receipt reference' and 'assignment' fields. Rather than a halfway installment, the Residual installment clears the specific 'open thing' against which the installment is applied. Nonetheless, since there are insufficient sums to clear the whole open thing, the framework makes another open thing, which is the distinction between the first receipt thing and the installment applied. Note that the new receipt/open thing made by the framework will have the new record date and new standard date however you can change these dates.
Q16. What Differentiates One 'dunning Level' From Another?
Ans: The 'Dunning Level' decides the 'dunning text' and (on the off chance that one is required) a 'unique dunning structure.' The 'dunning program' figures out what 'dunning level' ought to be utilized in the 'dunning run.' The dunning level so resolved is put away in the expert record of the record while the 'dunning letter' is printed. The dunning level may likewise decide if there will be some 'dunning charges.'
Q17. Portray 'lockbox' Processing?
Ans: 'Lockbox' handling (arranged in the FR-TR module) of approaching installments is utilized dominatingly in the United States. Here, the bank gets the checks from clients as approaching installments, makes installment guidance for every one of these client really look at installments, and advises the payee regarding the installment, in BAI document design. This lock box record is shipped off the payee who brings the subtleties into the framework utilizing this electronic document. The framework refreshes the installments into the GL via 'clump input' handling.
Q18. How Might 'reason Codes' Help With Incoming Payment Processing?
Ans: 'Reason Codes' designed in the framework help to deal with the 'installment contrasts' of individual open things in a receipt (either utilizing installment or exhortation or in the typical course). To every one of the explanation codes, you will characterize the 'posting rules' and the GL accounts in the IMG. Once finished, when there is an installment distinction against a specific open thing, the framework searches for the explanation code:
At the point when the 'charge-off marker' has been set hence code, then, at that point, the framework presents the installment distinction on a GL account. At the point when this marker isn't set, then, at that point, another open thing is made for the installment contrast.
At the point when 'questioned thing marker' has been set, then the framework disregards these details while counting for the client's credit limit.
Q19. What Is 'dunning' In Sap?
Ans: The SAP System permits you to 'dun' (remind) colleagues naturally. The framework duns the open things from colleague accounts. The dunning program chooses the past due open things, decides the dunning level of the record being referred to, and makes dunning takes note. It then saves the not set in stone for the things and records impacted. You can utilize the dunning project to dun the two clients and sellers. It very well might be important to dun a merchant on account of a charge balance because of a credit notice. Dunning is regulated through a Dunning Program, which utilizes a dunning key (to restrict the dunning level per thing), a dunning method, and a dunning region (in the event that dunning isn't finished at the Company Code level).
Q20. What Is A 'dunning Procedure'?
Ans: SAP comes furnished with a number or 'Dunning Procedures,' which you can duplicate, or you can make your own:
A dunning technique controls:
Elegance days/least days in arrear
Number of dunning levels (something like one level)
Exchanges to be dunned
Interest to be determined on the late things
Known or arranged leave, if any, which should be considere
Is dunning per 'dunning region'?
Is dunning per 'dunning level'?
Reference Company Code,
Dunning Company Code, and so on.
Dunning structures/media to be chosen for the dunning run
Q21. What Is The 'dunning Area'?
Ans: The 'Dunning Area' is discretionary and is required provided that dunning isn't finished at the Company Code level. The Dunning region can relate to a deals division, deals association, and so forth.
Q22. Will You 'dun' Customers Across 'clients' In A Single 'dunning Run'?
Ans: No. Every one of the information handling is done per Client.