Question 1

In SAP Financial Accounting, when does a general ledger account become a complete and usable G L account?

Accepted Answer

Introduction / Context: In SAP Financial Accounting, general ledger accounts are defined with two logical parts: the chart of accounts segment and the company code segment. Both segments together form a complete general ledger account that can be used for postings. This question asks you to identify when an account is considered complete and ready to use. Understanding this is essential for master data maintenance and for controlling which accounts can be posted in which company codes. Given Data / Assumptions: - A chart of accounts exists and contains a list of general ledger account numbers. - Each account has a chart of accounts segment, which stores basic information like account group and description. - Each account also needs a company code segment, which stores settings such as field status, tax category, and reconciliation properties. - The question asks at what point the account becomes complete and usable. Concept / Approach: The chart of accounts segment defines the general structure of an account, including its type and basic properties. However, the company code segment is needed to specify how the account behaves in a specific company code, for example whether it is open item managed or whether automatic postings are allowed. Without the company code segment, the system cannot fully process postings for that account. A complete general ledger account consists of both segments, and SAP offers a central creation mode that defines both at once for efficiency and consistency. Step-by-Step Solution: Step 1: Recognize that merely creating a chart of accounts or copying a chart of account segment does not automatically create company code specific data. Step 2: Understand that the company code segment must be created or maintained so that the account can be used in that company code. Step 3: Note that creating both segments together, often through a central creation function, guarantees that the account has all necessary data to be considered complete. Step 4: Evaluate the options and identify that option d states that both segments are created centrally, which matches the requirement for a complete usable account. Step 5: Select option d as the correct answer. Verification / Alternative check: If you try to post a document to an account that has only a chart of account segment but no company code segment, the system will issue an error because company code specific settings are missing. Conversely, when both segments exist, the system accepts postings. In the account maintenance transaction, you can see the separation between chart of accounts and company code views, which confirms that a general ledger account is complete only when both have been created. Why Other Options Are Wrong: Option a is wrong because simply creating the chart of accounts does not create company code segments for each account. Option b is incorrect since copying a chart of accounts segment from another company code does not guarantee that the company code segment for the current code exists or is correct. Option c suggests adding a company code segment to an existing chart of account segment, which does make the account complete, but it does not emphasize that this must be done in a coherent way; option d more clearly reflects the idea of centrally creating both segments in one process, which is the standard approach and best answer. Common Pitfalls: A common mistake is to assume that when a chart of accounts is shared across company codes, all accounts are automatically ready for use in every company code. In reality, each company code must have its own segment for each account. Another pitfall is copying accounts between company codes without checking company code specific settings such as tax categories or reconciliation indicators. Understanding that both chart of accounts and company code segments are required prevents posting errors and improves data quality. Final Answer: A general ledger account becomes complete and usable only when both its chart of account segment and its company code segment have been created. Therefore, the correct option is When both the chart of account segment and the company code segment are created centrally for the account.

Question 2

In SAP Financial Accounting, which combination correctly describes how many charts of accounts a company code can be assigned and of what types?

Accepted Answer

Introduction / Context: Charts of accounts define the structure of general ledger accounts in SAP. Each company code must be assigned an operating chart of accounts and may also be linked to a group and an alternate chart for consolidation and local reporting needs. This question checks whether you know the valid combination of chart of accounts assignments for a single company code in SAP Financial Accounting. Given Data / Assumptions: span style="display:block;">- Each company code needs an operating chart of accounts for day to day postings. - A group chart of accounts may be used for consolidation across several company codes. - An alternate chart of accounts may be required for local reporting in some countries. - The question asks which combination of these can be assigned to a company code. Concept / Approach: The operating chart of accounts is mandatory for each company code and defines the primary list of accounts for posting. The group chart of accounts is optional and serves for group wide reporting with a uniform account structure. The alternate chart of accounts is also optional and can support different external reporting structures for specific local requirements. SAP allows one of each type per company code, ensuring clarity and consistency. Multiple operating or multiple group charts of accounts for the same company code are not supported because they would create ambiguity in account determination and reporting. Step-by-Step Solution: Step 1: Recognize that each company code must have exactly one operating chart of accounts to be able to post general ledger documents. Step 2: Understand that a company code may be linked to one group chart of accounts that serves consolidation needs. Step 3: Note that a company code may also be linked to one alternate chart of accounts for additional reporting requirements. Step 4: Evaluate each option and see that only option a allows exactly one of each type, which is consistent with SAP design. Step 5: Conclude that option a is the correct answer. Verification / Alternative check: In SAP configuration for company codes, you can see fields for operating chart of accounts, group chart of accounts, and alternate chart of accounts. These fields do not allow multiple entries; each is a single value. Attempting to assign more than one operating chart or more than one group chart to the same company code is not supported. This confirms that a company code can have one operating, one group, and one alternate chart of accounts, as described in option a. Why Other Options Are Wrong: Option b is wrong because a company code cannot have many group charts of accounts. Option c is incorrect because SAP does not allow multiple operating charts of accounts for a single company code. Option d is incomplete because it excludes the possibility of assigning a group chart of accounts, which is supported and often used in group reporting scenarios. Common Pitfalls: One pitfall is confusing the purpose of operating, group, and alternate charts of accounts and trying to use them interchangeably. Another mistake is designing too many charts of accounts across the system, which increases maintenance effort. By understanding that each company code uses a single operating chart, and optionally one group and one alternate chart, you can design a cleaner and more manageable account structure. Final Answer: The valid combination is that a company code can be assigned one operating chart of accounts, one group chart of accounts, and one alternate chart of accounts. Therefore, the correct option is One operating chart of accounts, one group chart of accounts, and one alternate chart of accounts can be assigned to a company code.

Question 3

In SAP Financial Accounting, when you define a general ledger account using a sample account, which parts of the master data are typically copied from the sample account?

Accepted Answer

Introduction / Context: Sample accounts in SAP help simplify and standardize the creation of new general ledger accounts. By defining a sample account, you can copy certain control settings instead of entering them manually each time. This question asks which parts of the general ledger master data are typically copied when a new account is created using a sample account. Knowing this helps you use sample accounts effectively and avoid incorrect assumptions about what is inherited. Given Data / Assumptions: - The system uses sample accounts to speed up master data creation. - A general ledger account has a chart of accounts segment and a company code segment. - Certain control settings in the company code segment are critical for account behaviour. - The question focuses on which parts of the master data are referenced or copied from the sample account. Concept / Approach: When you create a new general ledger account and reference a sample account, SAP uses that sample as a template. Typically, only selected control related fields are copied, especially in the company code segment. This includes account control settings such as open item management, line item display, and other account management indicators. The idea is to standardize how similar accounts behave without forcing identical master data in every field. Some fields, such as descriptions or specific tax categories, may still need to be entered or adjusted manually. Step-by-Step Solution: Step 1: Recall that sample accounts act as templates that carry standard control settings. Step 2: Recognize that account control and account management fields in the company code segment are especially important for postings and clearing. Step 3: Understand that not every field from the sample account is copied; otherwise, all new accounts would look identical, which is not desirable. Step 4: Evaluate the options and identify that option a describes copying only the account control and account management data in the company code segment, which aligns with typical behaviour. Step 5: Confirm that this approach supports standardization of key settings while still allowing flexibility in other fields. Verification / Alternative check: If you create a new account using a sample account and then compare the two accounts, you will notice that only certain control fields match exactly, while other fields may differ. For example, open item management and line item display are likely copied, but descriptions and certain reference fields may be new or modified. This supports the understanding that sample accounts primarily provide account control and management data, not an exact copy of the entire master record. Why Other Options Are Wrong: Option b is wrong because copying the entire master data without any change would eliminate the flexibility needed when creating new accounts and does not reflect actual SAP behaviour. Option c is incorrect because it limits copying to the chart of accounts segment control data, while the most important referenced data relates to the company code segment. Option d is also wrong because it claims that only company code data is copied and chart of accounts data must always be entered manually, which oversimplifies how templates are used and does not reflect standard practice. Common Pitfalls: A common pitfall is assuming that all master data from the sample account will be copied, which can lead to misunderstandings when new accounts differ from expectations. Another mistake is not maintaining sample accounts carefully, resulting in inconsistent control settings across accounts that inherit from them. By understanding that only certain control and management fields are copied from the sample account, you can design sample accounts that provide useful defaults without over constraining new accounts. Final Answer: The correct statement is that SAP typically copies only the account control and account management data in the company code segment from the sample account. Therefore, the correct option is Only the account control and account management data in the company code segment are copied from the sample account.

Question 4

In SAP Financial Accounting automatic payment program, which of the following statements about payment runs are true?

Accepted Answer

Introduction / Context: The automatic payment program in SAP helps organizations process large volumes of incoming or outgoing payments efficiently. Understanding how the payment proposal, exception list, and payment methods work is essential for correctly configuring and using the payment run. This question asks which statements about payment runs are true, focusing on the flexibility of the proposal, the role of the exception list, and the requirement that payment methods be allowed in master records. Given Data / Assumptions: - The organization uses the automatic payment program to pay vendors and possibly customers. - The payment program generates a payment proposal before the actual payment run. - The proposal includes an exception list showing items that could not be included. - Payment methods must be set up in both Customizing and the master records in order to be used. Concept / Approach: The automatic payment program follows a structured process. First, it selects open items based on parameters and generates a proposal. Users can review and adjust this proposal, for example by blocking certain items or changing payment methods. The exception list highlights items that were not selected and explains why. Only after the proposal is accepted does the system create actual payment documents and possibly payment media. Payment methods used in the run must be allowed in vendor or customer master records to ensure that the chosen method is valid for that business partner. Step-by-Step Solution: Step 1: Consider the statement about the payment proposal. SAP allows users to edit, delete, and recreate the proposal until they are satisfied, so this statement is true. Step 2: Evaluate the statement about the exception list. The exception list is produced as part of the proposal and lists open items that could not be included in the payment run, making this statement true. Step 3: Review the statement about payment methods. For an automatic payment run, a payment method must be allowed in both the payment program parameters and the vendor or customer master record, so the statement that a payment method must be entered in the account master record to be used is true. Step 4: Since all three individual statements are correct, the option that states all of them are correct must be the right answer. Step 5: Select option d, which confirms that all listed statements are true. Verification / Alternative check: In SAP, if you generate a payment proposal, you can return to the proposal, modify it, or delete it and run the selection again. When reviewing the proposal, you see an exception list that explains why certain items were not picked, such as blocked accounts or missing payment methods. If a vendor doesn't have the payment method allowed in the master record, the system will not select that vendor for that method, proving that the statement about master record settings is also correct. Why Other Options Are Wrong: Options a, b, and c each include only one part of the picture and ignore the others. While each of these is correct by itself, the question asks which statements about payment runs are true overall. Only option d acknowledges that all of the described behaviours occur in the SAP automatic payment program. There is no statement suggesting any of a, b, or c is false, so rejecting option d would not fit the actual system behaviour. Common Pitfalls: A common pitfall is forgetting to review the exception list, which can lead to unanswered questions about why some invoices were not paid. Another mistake is running payments without carefully checking or adjusting the proposal, potentially causing incorrect payments. Users also sometimes misunderstand the relationship between payment methods in configuration and master data, leading to missing or incorrect methods on vendor or customer accounts. Knowing that the proposal is editable, that the exception list is part of the proposal, and that payment methods must be allowed in master records helps avoid these issues. Final Answer: All three statements accurately describe how the automatic payment program works in SAP. Therefore, the correct option is All of the above statements about the payment run behaviour are correct.

Question 5

In SAP Financial Accounting dunning program, which statements about the dunning proposal are correct?

Accepted Answer

Introduction / Context: The dunning program in SAP automates the process of reminding customers and vendors about overdue receivables or payables. It uses a dunning proposal that can be reviewed and adjusted before final letters are generated. This question asks which statements about the dunning proposal are correct. Knowing these behaviours is important for controlling the dunning process, avoiding errors, and ensuring that correct dunning levels are applied. Given Data / Assumptions: - The organization uses the SAP dunning program to send reminders. - A dunning proposal is created first, then reviewed and possibly modified. - The final dunning run updates dunning related data in customer or vendor master records and open items. - The clerk has some flexibility in recreating or editing the proposal. Concept / Approach: The dunning program follows a two step process. In the first step, a dunning proposal is created based on selection parameters. The proposal lists items that are due for dunning and suggested dunning levels. The dunning clerk can edit or regenerate this proposal until satisfied. In the second step, the final dunning run is executed to produce letters or messages and to update dunning data. Statements about the proposal must reflect this workflow accurately, including the possibility of recreating and editing the proposal and the fact that master records are updated only after the final run, not at the proposal stage. Step-by-Step Solution: Step 1: Evaluate statement a. The proposal can indeed be recreated as often as needed until the results are satisfactory. This is correct. Step 2: Evaluate statement b. Dunning levels in open items and in some cases master records are updated after the final dunning run, not merely after proposal creation, so the timing is important. The statement as written focuses on after completion of the process and is essentially correct but incomplete regarding the proposal. Step 3: Evaluate statement c. The proposal can be deleted and recreated; saying it cannot be deleted under any circumstances is incorrect. Step 4: Evaluate statement d. The clerk can edit the proposal, for example to exclude specific items, change dunning levels, or block certain accounts, so this is correct. Step 5: Since the question highlights behaviour around the proposal, the most clearly correct statement about the proposal itself is that it can be recreated as often as needed, which corresponds to option a. Verification / Alternative check: In SAP dunning transactions, you will see options to create, change, and delete a dunning proposal. The clerk can run the proposal, evaluate it, delete it, adjust parameters, and run it again. Only when the final dunning run is executed does the system print letters and update dunning data on open items. This confirms that statement a is definitely correct and that statement c is clearly wrong. Why Other Options Are Wrong: Option b mixes the concept of proposal and final run. While it correctly notes that dunning data is updated after the process, it focuses more on the result of the full run rather than on the behaviour of the proposal, which is what the question emphasizes. Option c is clearly false because the proposal can be deleted. Option d, though largely correct, is more limited than option a, which explicitly conveys the key flexibility of recreating the proposal, making option a the best answer. Common Pitfalls: Users sometimes assume that once a proposal is created, it cannot be changed, which leads to nervousness about running the selection. Another pitfall is forgetting that master data and open item dunning levels are updated only after the final run, not at proposal stage. By understanding that proposals can be recreated and edited, dunning clerks can experiment with parameters and refine the selection before committing to sending reminders, which improves both accuracy and customer relationships. Final Answer: The most clearly correct statement about the dunning proposal is that it can be recreated as many times as needed before the final run. Therefore, the correct option is You can recreate the dunning proposal as many times as needed until the dunning clerk is satisfied with the result.

Question 6

In SAP Financial Accounting, when accounting documents are generated automatically from logistics modules, how is the business area typically determined?

Accepted Answer

Introduction / Context: Business areas in SAP are used to represent separate areas of operations or responsibilities within a company, often for internal reporting or segment reporting. When accounting documents are created automatically from logistics modules such as materials management or sales and distribution, the system needs a rule to determine the appropriate business area. This question asks how business area determination typically works in such automatic postings. Given Data / Assumptions: - The organization uses business areas for reporting across company codes or plants. - Logistics modules like materials management and sales and distribution create accounting documents automatically. - Business area should reflect plant and division information or sales area, depending on the type of process. - The question asks you to identify the typical derivation rule. Concept / Approach: In materials management, goods movements are associated with plants and divisions. SAP can derive the business area from a combination of plant and division according to predefined rules. In sales and distribution, business area can be derived from the sales area, which includes sales organization, distribution channel, and division. This automated derivation ensures consistent reporting and reduces manual input errors. The determination is not based on company code alone or on chart of accounts settings for each posting key. Step-by-Step Solution: Step 1: Recall that business area derivation in logistics often uses organizational elements that reflect the structure of the business, particularly plant and division for materials management processes. Step 2: For sales processes, remember that the sales area (sales organization, distribution channel, division) is used as a basis for deriving the business area. Step 3: Understand that this automatic derivation reduces manual work and ensures that similar transactions in the same plant or sales area are reported under the same business area. Step 4: Evaluate the options and identify that option a describes the use of plant and division combination and sales area for business area determination. Step 5: Select option a as the correct answer. Verification / Alternative check: In SAP configuration, there are settings to define how business areas are determined from plants and divisions or from sales areas. If these rules are active, you can create test transactions in materials management and sales and distribution and then display the resulting accounting documents. You will see that the business area field is filled automatically based on the plant and division or the sales area, confirming the behaviour described in option a. Why Other Options Are Wrong: Option b is wrong because business area is more granular than company code and is not derived solely as a fixed value per company code. Option c is incorrect because the whole purpose of automatic determination is to avoid manual entry and inconsistency; manual entry may be allowed in some cases but is not the standard behaviour. Option d is also wrong because chart of accounts and posting key combinations control account determination and posting rules, not business area derivation. Common Pitfalls: A common pitfall is misconfiguring business area determination so that it does not align with the real organizational structure, leading to confusing reports. Another issue is mixing up business areas with profit centers or segments, which are similar but distinct concepts. Understanding that business areas for logistics based postings are derived from plant and division or from sales area helps ensure that automatic postings support meaningful internal reporting and reconciliation. Final Answer: In automatic postings from logistics modules, the business area is typically determined from a plant and division combination for materials management and from the sales area for sales and distribution. Therefore, the correct option is It is determined from a plant and division combination for materials management and from the sales area for sales and distribution.

Question 7

In SAP Financial Accounting dunning, if you want to prevent a vendor from being dunned beyond a particular dunning level rather than blocking dunning entirely, which configuration should you use?

Accepted Answer

Introduction / Context: The SAP dunning process allows flexibility in how and when customers and vendors are reminded about overdue items. Sometimes a business wants to allow dunning up to a certain level but not beyond, for example to maintain a sensitive relationship with a key vendor. This question asks which configuration element is used to limit dunning to a particular level instead of blocking it entirely. Given Data / Assumptions: - The organization uses dunning procedures with multiple dunning levels. - Some vendors or items should not be dunned beyond a specified level. - Dunning blocks and dunning keys exist as configuration tools. - The question focuses on limiting the maximum level rather than fully blocking dunning. Concept / Approach: A dunning block prevents dunning altogether for a vendor or an item. In contrast, a dunning key can be used on line items to influence how those items are processed in the dunning run, including limiting the maximum level reached. This makes dunning keys more precise tools for controlling the intensity of dunning. By assigning an appropriate dunning key, you can allow reminder letters up to a certain level but prevent escalation beyond that point, which is useful in sensitive relationships. Step-by-Step Solution: Step 1: Consider dunning blocks. They are used to completely exclude a vendor or item from dunning, not to allow only lower levels of dunning. Step 2: Consider dunning procedures. These define the general sequence and timing of levels but do not handle vendor specific maximum level limitations. Step 3: Consider the dunning key. It can be assigned to line items and can carry rules such as maximum allowed dunning level. Step 4: Understand that using a dunning key, you can allow lower level reminders for certain items while preventing escalation to higher levels. Step 5: Conclude that option d, which refers to the dunning key for limiting maximum level, is the correct answer. Verification / Alternative check: In SAP dunning configuration, you can define dunning keys and specify parameters such as whether an item with that key should be dunned and up to which level. When you assign such a key to line items in vendor accounts and run the dunning process, you will see that these items are not escalated beyond the defined level. This behaviour confirms that dunning keys are the proper tool for limiting the maximum dunning level rather than blocking dunning entirely. Why Other Options Are Wrong: Option a is wrong because a dunning block on the vendor master stops all dunning, not just higher levels. Option b is incorrect because blocking an entire dunning procedure would prevent any vendor using that procedure from being dunned, which does not address specific level control. Option c is wrong because the dunning clerk field is used mainly for responsibility and reporting, not for blocking or limiting dunning levels. Common Pitfalls: One pitfall is overusing dunning blocks to handle situations that would be better addressed with dunning keys, leading to a lack of reminders where they might still be appropriate. Another mistake is not configuring dunning keys at all and therefore missing the opportunity to fine tune how different items or business partners are treated. By understanding the role of dunning keys in limiting maximum dunning levels, you can design a more nuanced and customer friendly dunning strategy. Final Answer: To prevent a vendor from being dunned beyond a particular level, you should use a dunning key that limits the maximum dunning level for those items. Therefore, the correct option is Use a dunning key in line items to limit the maximum dunning level that can be reached for that vendor or those items.

Question 8

In SAP Financial Accounting, if you want to enter a document but delay updating the ledger until authorized officials approve it, which document functionality should you use?

Accepted Answer

Introduction / Context: In many organizations, financial documents must be reviewed and approved before they affect the general ledger. SAP supports this through the concept of parked documents, which allows users to enter document data without immediately posting it. This question asks which document functionality you should use when you want to delay updating the ledger until authorized officials provide approval. Given Data / Assumptions: - The organization requires a review and approval step before some documents are posted. - Users need a way to enter document details in SAP without creating an immediate ledger posting. - SAP offers options like sample documents, recurring documents, parked documents, and account assignment models. - The question focuses on temporary storage of documents before final posting. Concept / Approach: Parked documents are real documents that contain all necessary data but are not yet posted to the general ledger. They can be reviewed, changed if necessary, and later posted by authorized users. This supports approval workflows and reduces the risk of incorrect postings. In contrast, sample documents and account assignment models are templates for future documents and do not represent actual financial transactions. Recurring documents are used for regular repeated postings and are not primarily a tool for approval workflows. Step-by-Step Solution: Step 1: Review the purpose of sample documents, which is to serve as templates for repeated manual postings, not for approval based delays. Step 2: Consider recurring documents, which are designed to generate periodic postings for recurring transactions, again not mainly for approval purposes. Step 3: Recall that parked documents allow the user to enter all posting data but keep the document in an unposted status until an authorized user posts it. Step 4: Recognize that account assignment models are only partial templates for account assignments and do not create complete documents on their own. Step 5: Conclude that parked documents best match the requirement to enter a document without immediately updating the ledger, making option c correct. Verification / Alternative check: If you create a parked document in SAP and then check the general ledger, you will see that no posting has occurred yet. The document is stored with a reference number and can be reviewed in list transactions. Only when an authorized user posts the parked document does the system create accounting entries in the ledger. This behaviour demonstrates that parked documents are the intended tool for approval before posting. Why Other Options Are Wrong: Option a is wrong because sample documents are not actual financial documents; they serve as formats for manual postings. Option b is incorrect because recurring documents are used to schedule regular postings and still post to the ledger once they are run. Option d is also wrong because account assignment models only provide predefined account combinations and do not represent complete documents or delay postings. Common Pitfalls: A common pitfall is using parked documents as a long term storage mechanism without clear approval processes, which can leave documents unposted for too long. Another mistake is misusing recurring or sample documents when approval control is actually required. Understanding the specific purpose of parked documents helps you design a workflow where users can capture document data and approvers can post it, balancing control and efficiency. Final Answer: To enter a document and delay ledger updates until approval, you should use a parked document. Therefore, the correct option is Use a parked document so that the document can be completed and then posted later after approval.

Question 9

In SAP Financial Accounting, how many parallel currencies can be defined for a company code, and at what organizational level are they assigned?

Accepted Answer

Introduction / Context: Parallel currencies in SAP allow a company code to record transactions in more than one currency, for example the local currency, a group currency, and a hard currency. This is important for international organizations that must report financial data in multiple currencies. This question asks how many parallel currencies can be defined and at which organizational level they are assigned. Given Data / Assumptions: - The company code is the main organizational unit for external accounting in SAP. - Currency settings are crucial for posting and reporting. - SAP supports one local currency plus additional currencies for parallel valuation. - The question focuses on the maximum number of local or parallel currencies and where they are configured. Concept / Approach: In classic SAP Financial Accounting, a company code can have one local currency and up to two additional currencies, leading to a total of three currencies maintained in parallel. These currencies are defined at company code level because they affect how postings are stored in the ledgers for that specific legal entity. Chart of accounts level is used for account structures and does not control currency settings for postings. Understanding this separation helps ensure that currency configuration is done in the correct part of the system. Step-by-Step Solution: Step 1: Recall that the first currency for a company code is the local currency, usually the legal reporting currency of the country. Step 2: Recognize that SAP allows up to two additional currencies for parallel valuation, such as group currency and hard currency, giving a total of three currencies. Step 3: Understand that these currencies are defined in the company code settings and not at chart of accounts level. Step 4: Evaluate the options and identify that option b states three local currencies at company code level, which reflects the maximum number of parallel currencies maintained there. Step 5: Select option b as the correct answer. Verification / Alternative check: In SAP configuration for company codes, there is a section where you define the local currency and additional currencies. You can specify up to two additional currencies besides the local one. Reporting at general ledger and line item level will then show values in all defined currencies. There is no equivalent configuration at chart of accounts level that would define currencies for posting, confirming that the assignment is at company code level and that up to three currencies can be used. Why Other Options Are Wrong: Option a is wrong because SAP allows up to three currencies at company code level, not just two. Options c and d are incorrect because chart of accounts level deals with account structures and does not define posting currencies. Currency configuration for parallel valuation belongs to the company code, where legal entity specific requirements are handled. Common Pitfalls: A common pitfall is confusing group currency with local currency and not planning currency requirements early in the project. Another mistake is assuming that additional currencies can be added easily later, when in reality this can be technically complex. Understanding that up to three currencies can be defined at company code level helps you design a currency concept that supports both local and group reporting from the start. Final Answer: In SAP Financial Accounting, a company code can have up to three parallel currencies defined at company code level. Therefore, the correct option is Three local currencies can be defined at company code level.

Question 10

In SAP Financial Accounting, foreign currency valuation on general ledger accounts is performed for which types of G L accounts within a company code?

Accepted Answer

Introduction / Context: Foreign currency valuation in SAP Financial Accounting is a periodic closing activity that adjusts open items and foreign currency balances so that they reflect the current exchange rates in the company code local currency. The system revalues selected general ledger and subledger accounts at period end in order to comply with legal valuation requirements and to present a realistic financial position. Given Data / Assumptions: We are working inside one SAP company code with a defined local currency. Some accounts are managed on an open item basis and contain items posted in foreign currency. Certain general ledger accounts use an account currency that is different from the local currency. Foreign currency valuation is run with the standard valuation program for balances and open items. Concept / Approach: SAP distinguishes between open item managed accounts and balance sheet accounts that hold foreign currency balances. The valuation program must cover both types in order to revalue open items as well as foreign currency balances in general ledger accounts. The key idea is that valuation is needed whenever there is a foreign currency amount that affects the financial statements in local currency. Step-by-Step Solution: Step 1: Identify accounts that are managed on an open item basis and have foreign currency items outstanding at the key date. Step 2: Identify general ledger accounts whose account currency is different from the local currency of the company code. Step 3: Recall that SAP foreign currency valuation is designed to process both qualifying open item accounts and foreign currency balance sheet accounts. Step 4: Compare this rule with each option and look for the one that mentions both account categories. Step 5: Conclude that the option which covers all open item managed accounts and all accounts with an account currency different from local currency is correct. Verification / Alternative check: In customizing you define valuation areas and assign account determinations that clearly reference open item accounts and foreign currency general ledger accounts. When you execute the valuation run, the log shows postings for customer, vendor, and other open item accounts, as well as postings for foreign currency G L accounts such as bank accounts in foreign currency. This confirms that both groups are affected by the valuation process. Why Other Options Are Wrong: Option A mentions only open item managed accounts and ignores foreign currency balance sheet accounts, so it is incomplete. Option B includes only accounts whose account currency differs from local currency and ignores foreign currency open items, which again is incomplete. Option C is too broad, because accounts in pure local currency without foreign currency exposure do not require valuation. Option E is too narrow and also excludes customer and vendor accounts that are open item managed, which are a major focus of valuation. Common Pitfalls: Learners sometimes believe that only customer and vendor accounts are subject to foreign currency valuation, but bank accounts and other foreign currency balance sheet accounts must also be revalued. Another common mistake is to assume that open item management alone is enough, even if the account is kept only in local currency, which is not correct for foreign currency valuation. Final Answer: The correct answer is All accounts managed on an open item basis and all accounts whose account currency differs from the local currency, because foreign currency valuation must cover both foreign currency open items and foreign currency balance sheet accounts within the company code.

Question 11

In SAP vendor line item display, which setting allows you to choose a different set of fields for the vendor account line item list?

Accepted Answer

Introduction / Context: When users display vendor line items in SAP, they often want to see different columns such as document number, baseline date, payment terms, or reference. SAP provides layout control so that a user can define which fields are visible and how they are arranged. This question checks whether you know the specific term for the setting that controls the visible fields in the vendor line item display. Given Data / Assumptions: The transaction is a vendor line item display such as FBL1N. The user wants to change which fields are shown in the list output. The system already offers predefined layouts that can be selected and saved. Only one of the listed options is the correct technical name for the field layout. Concept / Approach: In line item display transactions such as FBL1N, FBL3N, and FBL5N, SAP uses the concept of a line layout to define which columns appear in the item list. Users can select and adjust layouts via the change layout function. Sort variants affect the sequence of items, and totals variants affect how totals are calculated and displayed, but they do not define which fields appear in each line. Step-by-Step Solution: Step 1: Recall that in line item display transactions you can use the change layout button to select a layout for the list. Step 2: Remember that the layout determines which fields are displayed as columns in the output. Step 3: Compare the answer options and identify the term that is used in SAP for this layout definition. Step 4: Recognize that the technical name for this is line layout, which exactly matches the requirement in the question. Step 5: Confirm that the other options control different aspects such as sorting or totals but not the field selection. Verification / Alternative check: If you open the vendor line item transaction and click on the layout functions, you will see that layouts can be saved and loaded as line layouts. The customizing and standard documentation refer to these entries as line layouts, which confirms that this is the correct SAP term for the field set used in the list display. Why Other Options Are Wrong: Option B, sort variant, defines how the items are sorted but does not determine which fields are visible in the output. Option C, totals variant, controls how totals are built and displayed at the top or bottom of the list, not the columns themselves. Option D, additional fields, may suggest adding more data, but it is not the standard name of the configuration object that defines the whole field set. Option E, field status group, belongs to G L master data and controls which fields are required or optional during posting, not during display. Common Pitfalls: A frequent confusion is between sorting and layout control. Users sometimes think that sort variants or totals variants can change the list structure, but these tools only influence the order of entries and the summary information. Knowing the exact technical term line layout helps when you discuss requirements with SAP consultants or when you configure default displays for user groups. Final Answer: The correct answer is Line layout, because this setting determines which fields are included in the vendor account line item display and how they are arranged in the list.

Question 12

In SAP Financial Accounting, when you reverse an already posted document, what type of document number assignment must be used for the reversal document?

Accepted Answer

Introduction / Context: Reversing posted documents is a common correction process in SAP Financial Accounting. When a user reverses a document, the system creates a new accounting document that cancels the effect of the original posting. This question focuses on how the document number for the reversal document is assigned, which affects traceability and consistency. Given Data / Assumptions: A financial accounting document has already been posted in SAP. The user starts a standard reversal transaction such as FB08. The reversal is posted in the same company code using the configured number range for reversal documents. We are interested in the rule for number assignment for the reversal document itself. Concept / Approach: SAP uses number ranges to assign document numbers automatically. For standard financial documents and their reversals, SAP recommends and implements internal number assignment, where the system picks the next available number from the defined range. External numbers are normally used only in special scenarios and are not used when the system generates a reversal document automatically, because the user should not manually control that number in order to guarantee uniqueness and auditability. Step-by-Step Solution: Step 1: Recall that a reversal document is created automatically by the system during reversal. Step 2: Remember that automatic document creation normally uses internal number assignment, not external entry by the user. Step 3: Check the options and identify which one states that only internal number assignment is allowed for the reversal document. Step 4: Recognize that external or manually entered numbers would break the standard automatic control of the number range. Step 5: Conclude that the rule is that reversal documents must use internal number assignment. Verification / Alternative check: If you inspect number range customizing for document types, you will see that reversal postings use the same or a specific number range with internal assignment. When performing reversals in a test system, the user is not prompted to enter a document number, which confirms that the system assigns the number internally and consistently for every reversal document. Why Other Options Are Wrong: Option A is incorrect because external numbering is not suitable for automatically created reversal documents. Option C suggests manual number entry without a number range, which would violate fundamental SAP control concepts. Option D claims that either internal or external assignment can be used freely, but in practice the reversal process is tied to internal number ranges. Option E is impossible because every posted accounting document in SAP must carry a document number for auditing and reporting. Common Pitfalls: Some learners misinterpret the fact that original documents may occasionally use external numbering and assume that the same applies to reversals. In reality, the reversal is a system generated document and therefore follows the internal number range logic. Confusing document numbers with reference numbers or document headers can also lead to misunderstandings about how the reversal is identified. Final Answer: The correct answer is Internal number assignment only, because reversal documents in SAP Financial Accounting are created by the system and therefore must receive an internally assigned document number from the appropriate number range.

Question 13

Within a single SAP company code, when several organizational units carry out dunning, which SAP object is used to distinguish and control the separate dunning processes?

Accepted Answer

Introduction / Context: Dunning in SAP is the process of reminding customers about overdue receivables in a structured way. In large organizations, different divisions or branches may manage their own dunning activities within the same company code. SAP provides configuration objects that separate dunning responsibilities and control for these units. This question asks which specific object is used to distinguish such parallel dunning processes. Given Data / Assumptions: We work within one SAP company code with multiple internal organizational units. More than one unit performs dunning activities for different customer groups. Dunning configuration must allow separate control for each unit. Only one of the listed objects is designed expressly for this purpose. Concept / Approach: SAP FI uses the concept of a dunning area to represent organizational units that carry out their own dunning in a company code. Each dunning area can have its own dunning procedure, texts, and parameters. While dunning keys, dunning clerks, and dunning procedures also play roles in the process, they do not by themselves represent a separate organizational unit for dunning inside the company code. Step-by-Step Solution: Step 1: Recall that a dunning area represents a sub unit within a company code that performs dunning on its own. Step 2: Understand that a dunning area is assigned to customers so that dunning notices can be produced separately per area. Step 3: Compare the purpose of dunning key, clerk, and procedure with the need to model organizational units. Step 4: Identify dunning area as the only object that directly models a separate internal unit. Step 5: Select dunning area as the correct answer. Verification / Alternative check: In SAP customizing, you define dunning areas under accounts receivable and then assign them to company codes and customers. Documentation describes dunning areas as organizational units that carry out dunning in their own name. This confirms that they are used precisely for distinguishing parallel dunning structures within one company code. Why Other Options Are Wrong: Option B, dunning key, is used at line item level to exclude or influence the dunning of specific items, not to define a separate unit. Option C, dunning clerk, identifies the person responsible for dunning but does not group items into separate organizational units. Option D, dunning procedure, controls levels and intervals but can be used in multiple areas and does not alone distinguish internal units. Option E, business area, has its own reporting purpose and is not the special dunning object used in accounts receivable. Common Pitfalls: Learners often confuse dunning procedures and dunning areas. A dunning procedure defines how dunning works, while a dunning area defines where and by whom it is executed. Another common confusion is to think that business areas control dunning, but they mainly affect financial reporting rather than the dunning workflow itself. Final Answer: The correct answer is Dunning area, because this SAP object represents separate organizational units that perform dunning within the same company code and allows you to control their processes independently.

Question 14

In corporate financial management, what is generally regarded as the primary goal of the financial manager of a company with common stock already outstanding?

Accepted Answer

Introduction / Context: In corporate finance, textbooks and professional practice emphasize a clear primary objective for financial management. While companies may pursue many goals such as growth, cost control, and profitability, one central goal aligns management decisions with the interests of shareholders in a measurable way. This question asks you to identify that primary goal. Given Data / Assumptions: The firm is organized as a company with common stock already outstanding. Financial management decisions include investment, financing, and dividend choices. The goal should be measurable and aligned with shareholder interests over time. Only one option reflects the widely accepted objective in modern corporate finance. Concept / Approach: The standard objective of financial management is to maximize shareholder wealth. In practice this is usually expressed more precisely as maximizing the current market value per share of the existing common stock. This formulation incorporates both current and future cash flows, risk, and timing, because all these elements are reflected in the share price in an efficient market. Other goals such as sales growth or short term profit are important but are subordinate to the overall wealth maximization objective. Step-by-Step Solution: Step 1: Identify which option explicitly refers to the value of shares owned by current shareholders. Step 2: Recall that shareholder wealth maximization is the conventional primary goal taught in finance courses and used in practice. Step 3: Compare this with objectives such as market share growth or cost inspection, which are narrower performance measures. Step 4: Note that maximizing current value per share automatically forces managers to consider risk, timing, and expected cash flows. Step 5: Select the option that mentions maximizing the current value per share of existing stock. Verification / Alternative check: Finance literature consistently states that the goal of financial management is to maximize the wealth of the owners, measured by the market value of their shares. This goal is comprehensive because it incorporates profitability, growth, risk management, and long term sustainability. Real world corporate governance structures, such as boards and incentive plans, are also typically built around shareholder value measures, which confirms the central role of this objective. Why Other Options Are Wrong: Option A, expanding market share, is an operational goal that may or may not increase shareholder wealth, especially if it requires heavy unprofitable spending. Option C, examining cost reasonableness, is an important control activity but is not a complete strategic objective. Option D suggests that all listed goals have equal priority, which provides no clear direction when trade offs occur. Option E focuses only on current year profit and ignores risk and long term effects, so it can conflict with long term shareholder wealth. Common Pitfalls: A common misunderstanding is to equate high accounting profit with high shareholder value, even though aggressive short term profit strategies can destroy long term value. Another pitfall is to focus excessively on growth in sales or assets without checking whether those investments actually create value in present value terms. Final Answer: The correct answer is Maximize the current value per share of the existing common stock, because this objective captures the essence of shareholder wealth maximization and provides a clear, market based benchmark for financial management decisions.

Question 15

In costing based Profitability Analysis in SAP, which of the following is an example of an actual value flow that can be analyzed using the value field analysis function?

Accepted Answer

Introduction / Context: Costing based Profitability Analysis in SAP uses value fields to capture revenues, costs, and deductions flowing from various components into CO PA. The value field analysis function helps you trace and analyze how actual data enters CO PA. This question tests whether you can distinguish a genuine actual value flow from planning or purely statistical information. Given Data / Assumptions: We are working with costing based CO PA, where amounts and quantities are stored in value fields. Actual data can flow from Sales and Distribution, Financial Accounting, Materials Management, and other components. The value field analysis function focuses on real postings that update value fields. We must select one option that clearly represents an actual value flow rather than a planned or simulated figure. Concept / Approach: Actual value flows in CO PA arise from completed business transactions that have created accounting documents or equivalent postings. Direct postings from Financial Accounting and Materials Management, such as general ledger postings or goods movements with automatic account assignment, update CO PA value fields immediately. In contrast, pure plans, forecasts, or simulations do not constitute actual value flows, even though they may later become the basis for postings. Step-by-Step Solution: Step 1: Identify which options describe completed postings that already hit accounting or logistics modules. Step 2: Notice that direct postings from Financial Accounting and Materials Management represent real transactions with accounting impact. Step 3: Recognize that planned incoming orders, planned transfers, and simulations describe future or hypothetical values only. Step 4: Exclude statistical key figures, because they do not represent value flows of amounts and quantities to value fields. Step 5: Select the option that clearly refers to direct postings from FI and MM that update CO PA value fields. Verification / Alternative check: SAP documentation about flows of actual values in CO PA explains that actuals can be transferred from Sales and Distribution billing, Financial Accounting, Materials Management, Product Costing, and other components. Among these, direct postings from FI and MM are textbook examples, because they originate from normal accounting and logistics documents and then transfer their values to CO PA value fields through the PA transfer structure. Why Other Options Are Wrong: Option A refers to planned incoming sales orders that have not yet been billed, so they represent expected rather than realized values. Option B mentions planned transfer of future billing documents, which again has not happened in the system. Option C describes simulations of product cost estimates, which are important for planning but are not actual value flows. Option E refers to statistical key figures, which serve as quantities for allocations but do not by themselves represent monetary flows into value fields. Common Pitfalls: A frequent mistake is to classify incoming sales orders as actuals just because they appear as commitments in some reports. However, from a strict accounting and CO PA perspective they represent expected future values until billing occurs. Another pitfall is to overlook the importance of the PA transfer structure, which explicitly maps general ledger and Materials Management postings into CO PA value fields. Final Answer: The correct answer is Direct postings from Financial Accounting and Materials Management that update CO PA value fields, because these postings represent real transactions whose values flow directly into CO PA and can be analyzed using the value field analysis function.

Question 16

In an SAP client, which organizational unit is considered an independent accounting unit and is the central level for external financial reporting?

Accepted Answer

Introduction / Context: SAP uses several organizational units to structure data for finance and controlling. Understanding which unit represents the legally independent accounting entity is essential for configuration and reporting. This question focuses on the organizational unit that serves as the primary level for external financial statements in an SAP client. Given Data / Assumptions: We are considering standard SAP organizational units used in Financial Accounting and Controlling. The unit in question must support complete balance sheet and profit and loss statements. The unit should correspond to a legal entity or a part of a legal entity that is required to produce separate financial statements. Only one of the listed entities fulfills this role by design. Concept / Approach: In SAP, the company code is the smallest organizational unit for which a complete, self contained set of accounts can be drawn up. It represents an independent accounting unit with its own local currency, chart of accounts, and fiscal year variant. Controlling areas, operating concerns, and plants are important for management accounting and logistics, but they do not directly represent legally independent accounting units for external reporting. Step-by-Step Solution: Step 1: Recall that balance sheets and profit and loss statements are produced at company code level. Step 2: Confirm that the company code is defined with its own local currency and chart of accounts. Step 3: Compare this to the role of the controlling area, which aggregates internal cost data across company codes. Step 4: Note that the operating concern is used for profitability analysis and the plant for logistics, not for full external financial statements. Step 5: Select company code as the independent accounting unit within a client. Verification / Alternative check: SAP implementation guides explicitly define the company code as the central organizational unit for external accounting. Financial statements, tax reports, and statutory submissions are all generated at company code level. Other units such as controlling area or operating concern are described as cross company code structures that support internal management reporting, which confirms that they are not the primary units for external accounting. Why Other Options Are Wrong: Option A, controlling area, groups company codes for internal controlling purposes and can span multiple legal entities. Option C, operating concern, is the highest reporting level in Profitability Analysis but does not carry complete general ledger data. Option D, plant, is a logistics unit that can belong to a company code and is not an independent accounting unit. Option E, business area, is an additional internal reporting dimension and does not replace company code level financial statements. Common Pitfalls: One common mistake is to confuse controlling area with company code because both appear in financial reports. However, controlling areas are designed for internal cost control, while company codes are used for legal reporting. Another pitfall is to overestimate the role of business areas, which provide segment like views but do not represent independent accounting entities by themselves. Final Answer: The correct answer is Company code, because in SAP this organizational unit serves as the independent accounting unit within a client and is the basis for complete external financial statements.

Question 17

In SAP scheduling for management accounting tasks, which activity best describes what you actually do when you carry out the scheduling process in the daily overview?

Accepted Answer

Introduction / Context: Many SAP controlling and profitability analysis functions rely on periodic background tasks, such as settlements, allocations, and report execution. The scheduling process in the scheduler or daily overview allows planners and controllers to ensure that these tasks run at the right time. This question asks what you are functionally doing when you perform the scheduling process using the daily overview. Given Data / Assumptions: We are working with a scheduling tool in SAP that supports periodic CO and CO PA tasks. The daily overview screen shows tasks for a specific day and their planned execution times. The user can change when tasks should run and can add new scheduled runs. Only one option correctly describes this core scheduling activity. Concept / Approach: Scheduling means defining when a task will execute. In a daily overview, the focus is on assigning or adjusting time slots for tasks on a particular date. While monitoring and result display are important related activities, they do not by themselves constitute scheduling. Creating task lists is usually a separate design activity, and archiving concerns historical data, not active scheduling. Step-by-Step Solution: Step 1: Recall that the daily overview shows tasks and their planned execution dates and times. Step 2: Understand that the user can move, add, or remove scheduled runs directly from this overview. Step 3: Compare each option with the idea of setting up or adjusting execution times. Step 4: Notice that option C explicitly mentions scheduling tasks in the daily overview and assigning defined times. Step 5: Conclude that option C is the best description of what is meant by carrying out the scheduling process. Verification / Alternative check: Conceptually, any scheduling tool in SAP or other systems focuses on defining when a job runs. The daily overview is designed to give planners a calendar like view so they can position tasks appropriately. Functions for monitoring, displaying results, or archiving are usually available in different menus or transactions, which supports the conclusion that scheduling in the daily overview refers specifically to assigning execution times. Why Other Options Are Wrong: Option A describes only the display of past results and does not schedule anything. Option B refers to monitoring tasks that are already scheduled but does not describe changing their timing. Option D speaks about creating task lists but does not mention assigning dates or times, so it is about planning content rather than scheduling execution. Option E concerns archiving and therefore relates to data lifecycle management, not to scheduling future tasks. Common Pitfalls: Students sometimes mix up monitoring and scheduling because both use similar screens or logs. It is important to remember that scheduling always implies setting execution times, while monitoring focuses on whether jobs have run successfully. Another pitfall is to think that simply listing tasks constitutes scheduling, even when no time dimension is involved. Final Answer: The correct answer is Scheduling tasks in the daily overview so that they run at defined times, because this statement directly captures what the scheduling process is about when you work with the daily overview in SAP.

Question 18

In costing based Profitability Analysis in SAP, which organizational unit represents the highest reporting level for analyzing profitability?

Accepted Answer

Introduction / Context: Profitability Analysis in SAP, often called CO PA, is used to evaluate market segments such as products, customers, and regions. These evaluations are grouped under an organizational unit that defines which characteristics and value fields are available. This question asks you to identify the highest reporting level in CO PA. Given Data / Assumptions: We are working with costing based Profitability Analysis in SAP. Reporting in CO PA combines data across company codes when configured that way. The organizational unit must define characteristics, value fields, and summarization levels for CO PA. We need the unit that sits at the top of the CO PA structure. Concept / Approach: The operating concern is the highest level organizational unit in CO PA. It defines the structure of profitability segments, including which characteristics are used to analyze markets and which value fields store revenues and costs. Company codes and controlling areas are assigned to an operating concern so that their transactions can flow into CO PA. Plants and business areas are lower level or parallel structures and do not define the top level of profitability analysis. Step-by-Step Solution: Step 1: Recall that the operating concern is created specifically for CO PA and controls its data structure. Step 2: Understand that all CO PA reports are ultimately run at operating concern level, even if they are restricted to specific company codes. Step 3: Compare the roles of company code, controlling area, plant, and business area with the role of operating concern. Step 4: Recognize that company codes handle external accounting, while controlling areas handle internal cost control. Step 5: Select operating concern as the highest reporting level within CO PA. Verification / Alternative check: SAP documentation for CO PA clearly describes the operating concern as the top level unit under which all profitability segments are defined. When you execute CO PA reports or configure value fields and characteristics, the operating concern is the primary key. Assignments from controlling areas and company codes to the operating concern show that it sits above those units for profit analysis. Why Other Options Are Wrong: Option A, company code, is the fundamental unit for external reporting but not specifically for CO PA. Option B, controlling area, is important for internal cost controlling and can link to CO PA, but it is not the top level reporting unit for profitability analysis. Option C, plant, is a logistics unit and appears as a characteristic inside CO PA rather than as the top level. Option E, business area, is an internal reporting dimension and does not define the CO PA structure. Common Pitfalls: Learners sometimes think that controlling area must be highest because it groups company codes for controlling purposes, but CO PA is structured differently, with the operating concern as its own hierarchy root. Another pitfall is to confuse the CO PA operating concern with the company group or corporate group used in consolidation, which is a separate concept. Final Answer: The correct answer is Operating concern, because in costing based Profitability Analysis this organizational unit defines the highest reporting level and controls the structure of characteristics and value fields used in profitability reporting.

Question 19

In SAP Controlling (CO OM CEL), expenses posted in Financial Accounting that are relevant to cost accounting are recorded in Controlling using which type of cost element?

Accepted Answer

Introduction / Context: In SAP Controlling, every posting that is relevant for cost accounting is represented by a cost element. Understanding the difference between primary and secondary cost elements is fundamental, because it explains how data flows from Financial Accounting into Controlling and how internal allocations are reflected. This question focuses on how expenses from Financial Accounting enter CO. Given Data / Assumptions: Expenses are initially posted in SAP Financial Accounting to general ledger accounts. Some of these expenses are relevant for cost accounting in CO. Each relevant G L account must correspond to a cost element in CO. We are looking for the type of cost element used to represent such external expense postings in Controlling. Concept / Approach: Primary cost elements represent costs that originate outside Controlling and flow into CO from Financial Accounting, Materials Management, or other components. Each relevant expense G L account is created as a primary cost element so that CO can analyze the costs by cost center, internal order, or other controlling objects. Secondary cost elements, in contrast, represent internal allocations such as assessments or distributions and do not exist as ordinary G L accounts. Step-by-Step Solution: Step 1: Think about the source of the costs mentioned in the question, which is Financial Accounting. Step 2: Remember that primary cost elements are used for external expense postings that enter CO from FI. Step 3: Recall that secondary cost elements are used only for internal CO allocations and do not carry FI postings. Step 4: Compare the options and choose the one that names primary cost elements. Step 5: Confirm that this matches the standard SAP explanation of cost element categories. Verification / Alternative check: SAP documentation and training materials clearly state that every expense G L account that is relevant for cost accounting must be defined as a primary cost element. When an expense document is posted in FI with a cost center or internal order, CO receives the same values through the corresponding primary cost element. Secondary cost elements are created only in CO and cannot be posted in FI, which confirms that they are not used for initial expense postings from FI. Why Other Options Are Wrong: Option A is incorrect because secondary expense elements do not carry original FI postings. Option C is confusing and does not reflect a standard SAP term; relevant expenses always require a proper cost element link. Option D describes the role of secondary cost elements for internal allocations such as assessments or distributions, not for original FI expenses. Option E refers to statistical key figures, which are quantity based measures used for allocations, not for value postings from FI. Common Pitfalls: A typical error is to mix up primary and secondary cost elements or to think that all cost elements behave the same. Another pitfall is forgetting to create the cost element for a new expense account, which results in missing CO postings even though FI postings exist. Understanding this mapping helps ensure reconciliation between FI and CO. Final Answer: The correct answer is Primary cost elements, because expenses posted in Financial Accounting that are relevant to cost accounting are transferred to Controlling using primary cost elements that mirror the corresponding G L accounts.

Question 20

In SAP Overhead Cost Controlling (CO OM OPA), the “dependency” in an overhead costing sheet can differentiate overhead rates or amounts by several criteria. Which of the following is an exception and is not supported as a dependency?

Accepted Answer

Introduction / Context: Overhead costing sheets in SAP Controlling allow you to calculate overhead surcharges based on defined bases such as cost elements or activity types. To make these calculations more flexible, you can use dependencies that vary the overhead rate by organizational characteristics. This question asks you to identify which proposed dependency is not supported in the standard overhead costing sheet. Given Data / Assumptions: We are working with overhead costing sheets in SAP CO. Dependencies can be used to differentiate overhead rates by certain organizational objects. Valid dependencies include typical units such as company code, plant, or profit center. One of the listed options is not a supported dependency type in this context. Concept / Approach: The dependency concept in the overhead costing sheet is used to control overhead calculation by organizational assignments. Standard examples include differentiation by company code, plant, or profit center. Material origin is a field that can be used in Product Costing and reporting to distinguish material groups or sources, but it is not a classic dependency dimension in the overhead costing sheet configuration. Step-by-Step Solution: Step 1: List typical organizational characteristics used as dependencies: company code, plant, profit center, and sometimes cost center related attributes. Step 2: Compare these usual characteristics with the options given. Step 3: Recognize that company code, plant, and profit center are standard organizational units in controlling and can be used as dependencies. Step 4: Notice that cost center category is also a controlling attribute that can influence overhead logic. Step 5: Identify material origin as the exception, because it is not a standard dependency object for varying overhead rates in the costing sheet. Verification / Alternative check: If you review SAP configuration for overhead costing sheets, you find dependency fields that include organizational units like company code and plant, as well as certain cost object attributes. Material origin is primarily used in Product Cost Controlling and in reports to indicate where a material came from but is not a common controlling dimension for overhead rate differentiation in the costing sheet. Why Other Options Are Wrong: Option A, company code, is clearly supported, since overhead structures can vary by company code. Option C, plant, is standard, because different plants may have different overhead rates. Option D, profit center, is another valid dimension that can influence overhead calculation in some designs. Option E, cost center category, can be used indirectly through groupings of cost centers and is more plausible as a dependency than material origin. Common Pitfalls: A common mistake is to assume that any field used in reporting or in other controlling components can serve as a dependency in the costing sheet. In reality, only specific organizational and master data fields are supported. Another pitfall is to confuse material origin as a costing sheet control parameter simply because it appears in some Product Costing configuration screens. Final Answer: The correct answer is Material origin, because this characteristic is not a standard dependency dimension used to differentiate overhead rates or amounts in an SAP overhead costing sheet, whereas the other listed objects can reasonably serve as dependencies.

SAP Certification Questions