A stakeholder in a fresh S/4HANA system asks for a report showing profit-center-level balances on every FI document in real time, including balance-sheet items like receivables and cash. Before agreeing, which configuration prerequisite is the SINGLE most decisive one to verify?
- A. That the leading ledger 0L has a parallel currency configured for the group currency
- B. That document splitting is active with Profit Center as a splitting characteristic and zero-balance clearing is set for the profit center ✓
- C. That the Universal Journal (ACDOCA) is being used instead of the classic totals table GLT0
- D. That real-time integration between CO and FI (variant assignment) is switched on for the company code
Correct answer: B. Document-level, balance-sheet-complete profit center reporting requires active document splitting with Profit Center as a splitting characteristic and zero-balance clearing so every document balances by profit center.
During a brownfield conversion, SI checks flag customer/vendor masters not yet mapped to Business Partners. A team member proposes just running the customer/vendor tables forward untouched to save effort. What is the accurate consequence of skipping the BP conversion (Customer/Vendor Integration) before the technical conversion?
- A. The conversion completes but FI postings to those customers/vendors will silently post to a default reconciliation account
- B. The system conversion (SUM/DMO) is blocked because CVI/BP is a mandatory pre-conversion activity in S/4HANA ✓
- C. Nothing breaks initially, but new sales orders cannot be created until BP is retrofitted post go-live
- D. Only the CO side is affected because the BP model replaces cost-center-linked partner functions
Correct answer: B. In S/4HANA the Business Partner is the single point of entry for customer/vendor master data, so CVI synchronization is a mandatory pre-conversion prerequisite that blocks the conversion if incomplete.
A custom ABAP report loops over 50,000 sales order headers (VBAK) and inside the loop issues a SELECT SINGLE against VBAP for each. ST05 shows tens of thousands of identical-shaped DB accesses. Which rewrite gives the biggest, most correct performance improvement on HANA?
- A. Add an index hint to the inner SELECT so HANA uses the primary key
- B. Buffer VBAP as a fully-buffered table in SE11 so accesses hit the table buffer
- C. Replace the loop-driven singles with a single SELECT ... FOR ALL ENTRIES IN @vbak_itab (or a CDS view with a JOIN) and read the internal table ✓
- D. Wrap the inner SELECT in a PACKAGE SIZE cursor to reduce memory pressure
Correct answer: C. The classic SELECT-in-loop antipattern is fixed by set-based access — one FOR ALL ENTRIES / JOIN / CDS view — which pushes the work to the database and eliminates thousands of round trips.
A live sales order shows an incorrect net price because a newly created condition type was placed with the wrong access sequence in the pricing procedure. You must fix pricing for NEW orders without disturbing net values on existing, already-saved orders. Which approach is production-safe?
- A. Correct the access sequence/pricing procedure config, then let existing orders keep their stored condition values since pricing is only re-read on a manual new pricing (carry-out) action ✓
- B. Run report to mass-update the condition records, which automatically reprices all open and closed orders
- C. Delete the faulty condition type from the pricing procedure so all documents recalculate cleanly on next display
- D. Change the condition record validity dates, which retroactively corrects saved order values
Correct answer: A. Pricing results are persisted on the document; fixing the procedure/access sequence affects only newly created or explicitly repriced orders, leaving existing saved values untouched unless a new pricing type is triggered.
You define a CDS analytical query and need row-level authorization enforced so users only see their own controlling area's data, without coding AUTHORITY-CHECK in every consumer. Which mechanism is the correct, framework-native way?
- A. Add @Consumption.filter annotations on the controlling area field
- B. Implement a DCL (Data Control Language) source with a PFCG_AUTH grant on the CDS entity ✓
- C. Set @AccessControl.authorizationCheck: #NOT_REQUIRED and rely on OData scopes
- D. Use a @VDM.viewType: #CONSUMPTION annotation which auto-applies S_TABU_DIS checks
Correct answer: B. CDS row-level authorization is declared in a separate DCL source that binds authorization objects (PFCG_AUTH) to the entity, enforced automatically whenever the view is queried.
A goods issue for a delivery (movement type 601) posts the material document but the accounting document fails with 'account determination error'. Tracing the config, where does the missing entry most precisely live, and which transaction points to it?
- A. Missing GL account in the pricing procedure; check V/08
- B. Missing account assignment for the transaction key GBB (offsetting entry for goods movement) in OBYC ✓
- C. Missing cost element for the consumption account in KA01
- D. Missing movement type-to-schedule-line linkage in VOV6
Correct answer: B. A 601 goods issue triggers automatic account determination via OBYC, and the offsetting/consumption posting is driven by transaction key GBB (with the relevant account grouping), so a missing GBB entry causes the account determination error.
When would an AMDP (ABAP Managed Database Procedure) be the correct choice OVER a CDS view for pushing logic to HANA?
- A. When the logic is a simple filtered projection with an association to another entity
- B. When you need imperative, multi-step SQLScript logic with intermediate table variables, loops, or procedural control that declarative CDS cannot express ✓
- C. When you want the result automatically exposed as an OData service for Fiori
- D. When you need the data model to be transportable and consumable across ABAP and analytics layers
Correct answer: B. CDS is declarative; AMDP is chosen when you need imperative SQLScript — intermediate result sets, procedural steps, or algorithmic logic — that a single declarative CDS view cannot represent.
Two questions into a migration discussion, a candidate keeps saying 'we handled the split.' Technically, in New GL document splitting, what distinguishes ACTIVE splitting from PASSIVE splitting?
- A. Active splitting occurs in real time while passive splitting runs during month-end batch
- B. Passive splitting inherits account assignments from a referenced/cleared document (e.g., a payment inheriting the invoice's split), while active splitting derives them via configured splitting rules on the original document ✓
- C. Active splitting applies only to P&L accounts and passive only to balance-sheet accounts
- D. Passive splitting requires zero-balance clearing whereas active splitting does not
Correct answer: B. Passive split propagates account assignments from the originally split (referenced) document such as a clearing/payment, whereas active split newly derives them from configured splitting rules based on item categories.
An iFlow in Cloud Integration (CPI) receives orders via HTTPS, maps to IDoc, and posts to S/4HANA. Intermittent mapping failures must NOT halt the whole flow; failed messages should be logged and routed to an error queue while good messages continue. Which iFlow design element implements this correctly?
- A. A Router step with a default route to a Content Modifier
- B. An Exception Subprocess containing an Error Start event that catches the fault and routes to the error queue ✓
- C. A JMS receiver adapter with automatic retry and dead-letter handling only
- D. A Groovy script wrapped in try/catch that swallows the exception and returns null
Correct answer: B. CPI handles faults declaratively via an Exception Subprocess triggered by an Error Start event, which catches the exception and lets you log/route the failed message without aborting the integration process.
A client with heavy custom Z-code, 15 years of historical data they must retain, and limited appetite for process re-engineering is deciding between greenfield and brownfield. Which reasoning most correctly favors brownfield (system conversion) for THIS client?
- A. Greenfield is impossible when custom code exists, so brownfield is the only option
- B. Brownfield preserves historical transactional data and existing configuration/custom code in place, avoiding re-implementation, which fits low re-engineering appetite and data-retention needs ✓
- C. Brownfield automatically remediates all custom code to clean-core standards during SUM
- D. Greenfield is cheaper here because it discards the Z-code, so brownfield only wins on speed
Correct answer: B. System conversion (brownfield) carries forward historical data, configuration, and custom code in the same system, matching a client that must retain history and does not want to re-engineer processes.