Explanation:

B. By using the Check Tool
The Check Tool is the primary diagnostic utility in SAP SuccessFactors to identify data inconsistencies. Under the Compensation category, it runs specific validations to find "orphaned" users or invalid manager assignments. It provides a clear list of users whose hierarchy path is interrupted, which would otherwise prevent form creation or lead to routing errors.

D. By using the Rollup Hierarchy report
Located within the Manage Worksheets section of a specific Compensation plan, the Rollup Hierarchy report allows administrators to see exactly how employees roll up to their managers. If a manager's hierarchy is broken or an employee is missing a valid path to a top-level head, they will appear as "unassigned" or simply not appear in the rollup, making it a functional way to spot gaps in the UDF (User Data File) structure.

Why the Other Options are Incorrect

Option A:
The "Define Planners" screen is used to select the hierarchy type (Standard, Second Manager, etc.). While you can export a list of planners, there is no specific "troubleshooting information" export designed to highlight structural breaks in the hierarchy.

Option C:
Changing the "Method of Planner" simply tells the system which field to use for planning (e.g., switching from the MANAGER field to a custom COMP_MANAGER field). It does not scan for or report on breaks; it only changes the logic the system follows.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Validating the Hierarchy" and "Using the Check Tool for Compensation."

Explanation:

Field-based permissions (FBP) in SAP SuccessFactors Compensation allow you to define who can view or edit specific columns on a worksheet based on Role-Based Permissions (RBP) groups.

By configuring FBP, you can set the "Lump Sum" field to Read Only for the standard "Planner" role and Read/Write for a specific permission group containing only the "Reward Team" members. This ensures that while a manager can see the field (if permitted), only the specialized team can actually input or modify values. This is managed via Compensation Home > Plan Setup > Design Worksheet > Define Standard/Custom Fields.

Why the Other Options are Incorrect

Option A:
Mass actions in Executive Review are used to apply changes to many employees at once (like a 3% increase for everyone). While the Reward Team might use Executive Review, mass actions do not restrict entry or editability of a specific field for certain roles; they are a functional tool, not a security restriction.

Option B:
Hard stops in guidelines prevent any value outside of a specific range from being saved. Setting all values to 0 would essentially disable the field for everyone, including the Reward Team, making it impossible for anyone to award a lump sum. It is a data validation tool, not a permissioning tool.

Option D:
Setting the field to Read-only in the field configuration is a "global" setting. If the field is set to read-only at the template level, it becomes uneditable for everyone, including the Reward Team. It lacks the granularity required to allow one group access while restricting another.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Field-Based Permissions."
SAP Help Portal: "Controlling Field Visibility and Editability" within the Compensation Worksheet.

Explanation:

B. Enable Planner Currency mode
This is the foundational setting for multi-currency global templates. When Planner Currency is enabled in the plan setup, the system allows the worksheet to toggle between the functional currency (GBP) and the local currency of the employee or planner. Without this mode enabled, the system defaults to the functional currency for budget calculations, which would force US or German planners to see their budgets in GBP.

A. Use budget grouping group on the local currency code
To actually separate the budget pools so they reflect the local currency values, you must configure Budget Grouping. By grouping the budget based on the localCurrencyCode field, the system calculates and displays the budget "pot" in the specific currency assigned to that group. For example, the German group will have a budget calculated and displayed in EUR, while the US group will see USD.

Why the Other Options are Incorrect

Option C:
Disable Functional Currency mode. This is not a standard configuration step for this requirement. Functional currency is the "base" for the entire system and is required for reporting and currency conversion (via the Currency Conversion Table). You don't disable it; you simply layered Planner/Local currency views on top of it.

Option D:
Have four separate templates, one for each country. While technically possible, this is considered bad practice in SAP SuccessFactors. Maintaining four templates creates massive administrative overhead for year-end reporting and configuration changes. A single global template using currency conversion and budget grouping is the standard "Best Practice" approach.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Budget Grouping" and "Currency Views."

Explanation:

B. Map TC to the standard Current Salary field; Use Merit for TC update; Publish finSalary back and use EC Business Rules to split the components.
This approach is the "best practice" for Total Cash (TC) planning when integrating with Employee Central (EC). By mapping the Pay Component Group (TC) to the curSalary field, the system automatically pulls the sum of Salary, Car, and House allowances into the worksheet.
Since the allowances are fixed based on employee grade, the worksheet can recalculate those specific values upon promotion. However, rather than trying to perform complex split-logic inside the Compensation XML, you publish the final Total Cash amount (finSalary) back to EC. Upon arrival in EC, Business Rules (Triggered on onSave or onPost) can automatically subtract the fixed allowances from the new TC to derive the remaining base salary. This keeps the Compensation template clean and leverages the robust logic engine in Employee Central.

Why the Other Options are Incorrect

Option A:
While custom columns could calculate the components, publishing multiple derived custom fields back to EC is significantly more complex to maintain than using a single "Total Cash" value and letting EC rules handle the math.

Option C:
Manual exports and imports represent a break in integration. This fails the requirement of "maximizing integration" and introduces a high risk of manual data entry errors.

Option D:
Mapping SALARY to curSalary while mapping TC to meritTarget creates a confusing user experience. Planners would be looking at different fields to understand the total package, and updating allowances manually in custom fields bypasses the automated grade-based logic the customer requested.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Integration with Employee Central: Pay Component Groups."

Explanation:

In SAP SuccessFactors Compensation, the lookup() function is designed to return a String (text) value by default, even if the value stored in the table is a number (like 5, 3, or 2).

The Problem: When the worksheet initially loads, the system performs a one-time calculation. However, when a user changes a Merit value, the worksheet triggers a dynamic recalculation. During this live recalculation, the formula tries to perform a mathematical operation (multiplication/division) between a Number (curSalary) and a String (the result of the lookup).

Why the Other Options are Incorrect

Option A:
Surrounding curSalary with toString would turn the salary into text. You cannot multiply text by a lookup value, which would break the formula entirely from the start.

Option C:
Changing the column to an Amount type (which is essentially the same as Money in terms of data handling) does not solve the underlying data type mismatch between the lookup string and the numeric salary.

Option D:
The parentheses in the current formula are mathematically sound. Removing them would not fix the data type conflict between the String output of the lookup and the Numeric requirements of the division/multiplication.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Custom Field Formulas" and "Lookup Tables."

Explanation:

B. HR Manager hierarchy
This method uses the HR Manager field (typically the HR column in the User Data File or the designated HR Representative in Employee Central) to build the planning structure. This is often used when HR Business Partners, rather than people managers, are responsible for allocating compensation.

D. Standard Suite hierarchy
This is the most common hierarchy type. It follows the standard reporting line defined in the "Manager" field of the User Data File (UDF). In this model, every manager plans for their direct reports, and the forms route up through the organizational chain.

E. Compensation hierarchy (Second Manager)
This is a flexible option that allows for a "Matrix" or "Secondary" management structure. It uses the "Second Manager" field (represented by SECOND_MANAGER in the UDF) to determine the planner. This is ideal for organizations where a functional manager or project lead handles compensation instead of the administrative manager.

Why the Other Options are Incorrect

Option A & C (Including Inactives):
While it is a common point of confusion, "Including Inactives" is not a Hierarchy Type itself. The ability to include inactive employees is a configuration setting or a filter applied to a hierarchy (found in the "Advanced Settings" or during the "Create Worksheet" process), but it is not a distinct "Method of Planner" option in the dropdown.

"Rollup" (Option A):
The Rollup is a report or a display mode for managers to see their entire downline, but the method for defining the planner is still based on the Standard, HR, or Compensation Manager fields.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Defining the Planning Hierarchy."

Explanation:

C. Export from Executive Review
Executive Review is a powerful tool for data extraction because it allows administrators or high-level managers to see data across all worksheets for a specific plan. By filtering the Executive Review by the divested entity (using department, division, or location filters), you can see every employee's merit, bonus, and adjustment data. The Export to Excel feature in Executive Review captures all visible columns, including custom fields and calculations, making it a reliable way to get a "snapshot" of a specific planning cycle.

D. Run an Ad Hoc report (Report Table)
Ad Hoc Reporting (now often managed via Report Center) is the standard way to extract bulk data from the Compensation module. You can create a "Compensation Planning" domain report that includes multiple years of data, specific templates, and all associated fields. This is the most robust method for a divestiture because you can select exactly which fields (standard and custom) you need for the legal transfer of data and filter specifically for the employees being moved.

Why the Other Options are Incorrect

Option A:
Run the Rollup report. The Rollup report is a functional tool used during the planning cycle to see how budgets are being spent and how many forms are complete. It provides high-level summaries and a list of employees, but it is not designed for bulk historical data extraction or detailed record-keeping for a divestiture.

Option B:
Export from the employee history file. The "Employee History" file in SuccessFactors generally refers to the Background Elements or the Growth/Trend data. While some compensation data can be published there, it often only contains a subset of the data (like final salary). It does not contain the granular planning details (like specific manager comments, multiple custom planning fields, or guideline deviations) found in the actual compensation plan templates.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Reporting and Data Extraction."

Explanation:

A. Providing budget percentage by country
Logic: Budgets are often allocated based on geographic location rather than a flat percentage. Since EC stores the employee’s country, a lookup table can map that country code (e.g., USA, DEU) to a specific budget percentage (e.g., 4% for USA, 3% for DEU). This allows for dynamic budget calculations without hard-coding values into the XML.

C. Converting a code into its text equivalent for display
Logic: EC often stores data as "Option IDs" or short codes (e.g., "P1" for "High Performer"). To make the worksheet user-friendly for managers, a lookup table can take the code from EC and return a descriptive string (the "text equivalent") to be displayed in a custom column.

E. Determining appropriate car allowance by grade
Logic: Car allowances are frequently "flat-rate" benefits tied to a Pay Grade or Job Level. By using the employee’s Grade from EC as the input, the lookup table can return the specific currency amount for the allowance. This ensures that if an employee is promoted to a new grade on the worksheet, the car allowance updates automatically.

Why the Other Options are Incorrect

B. Holding previous year's salary by Employee ID:
While technically possible, this is highly discouraged. Lookup tables have a row limit (typically 10,000 to 12,000 rows). Storing data indexed by Employee ID for a large organization would quickly exceed this limit and cause performance issues. Historical salary should be pulled from the Salary History portlet in EC or a custom background element.

D. Converting money values from functional to local currency:
This is handled by the Currency Conversion Table, which is a dedicated system table in Compensation. You do not use a standard lookup table for currency conversion because the system has a built-in engine specifically designed to handle exchange rates and "Planner/Functional" currency views.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Lookup Tables" and "Referencing EC Fields in Formulas."

Explanation:

In SAP SuccessFactors Compensation, the system typically expects an Annual Salary to calculate compa-ratio and range penetration correctly. However, when Employee Central (EC) stores pay components in a non-annual frequency (like monthly), the unitsPerYear column acts as the conversion factor.

Why the Other Options are Incorrect

Option B:
Creating two different pay components in EC just for compensation planning is a poor data architecture choice. It creates redundant data entry in Employee Central and complicates payroll integration, which the prompt specifically mentions as a constraint.

Option C:
Using two separate templates is considered bad practice. It doubles the administrative effort for reporting, cycle management, and configuration changes. SuccessFactors is designed to handle multiple regions within a single global template using field visibility and functional currency settings.

Option D:
Mapping meritTarget to a divided value is a "workaround" that breaks standard functionality. meritTarget is intended for bonus/variable pay targets, not for storing a modified base salary. This would lead to incorrect budget calculations and confusing "Current Salary" displays for the managers.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Standard Columns: unitsPerYear."

Explanation:

A. Process Setup $\rightarrow$ Manager Planning $\rightarrow$ Next Level Manager Review $\rightarrow$ Final Review $\rightarrow$ CompleteSAP SuccessFactors recommends a workflow that balances preparation, execution, and oversight. This sequence follows the standard Route Map logic used in most successful implementations:


Why the Other Options are Incorrect

Option B:
Includes HR Manager Planning as a separate stage before completion. While HR is involved, having them as a separate planning step after a Compensation Admin review is redundant and doesn't follow the typical upward approval flow.

Option C:
Lists Third Level Manager Review. While some companies use this, it is not the "recommended leading practice" because it often adds unnecessary bureaucracy. Leading practice favors a leaner "Manager $\rightarrow$ Second Level $\rightarrow$ HR/Admin" approach.

Option D:
Skips the Process Setup and Final Review stages. Without Process Setup, there is no formal phase for data validation, and without a Final Review, there is no gatekeeper before the cycle is finalized.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Route Maps in Compensation."

Explanation:

A. Employees who have an RSU grant get a statement, but those without an RSU grant do NOT get a statement.
Logic: This is a classic use case for the "Suppress Statement if value is 0" logic. If the template is specifically for Restricted Stock Units (RSUs), you can configure the statement to be suppressed for any employee whose stockUnits or grantAmount is zero. This ensures that employees who received nothing don't get a confusing, empty notification.

B. Employees who were hired after a certain date do NOT get a statement.
Logic: While eligibility rules usually handle who appears on a worksheet, some customers prefer to keep everyone on the worksheet for visibility but only issue statements to those who are "award-eligible." By creating a hidden custom field that flags "New Hires" based on their hire date, you can use that field as the trigger to suppress the statement.

Why the Other Options are Incorrect

Option C:
If employees in different countries need statements at different times, you do not use "Suppress Statement." Instead, you use Statement Groups or simply manage the Release process by filtering by country in the "Manage Personal Compensation Statements" tool. Suppression is about whether they get one, not when.

Option D:
If an employee needs a different statement, you use Conditional Statement Groups. This allows you to assign Template A to high performers and Template B to those on a performance plan. Suppression would simply hide the statement entirely, which isn't the goal here.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Personal Compensation Statements" -> "Suppressing Statements."
SAP Help Portal: "Defining Conditions for Statement Generation."

Explanation:

C. Create a standard validation of type "disallow" action "exceed" with the Threshold at 125.
Logic: Standard validations are built-in features for the Merit, Adjustment, and Promotion columns. By setting the validation type to "disallow", the system provides a "Hard Stop." If a planner enters an amount that pushes the employee's compa-ratio above 125%, the system will display an error message and prevent the manager from saving the worksheet until the value is lowered.

D. Create a custom validation of type Error to ensure that the column compaRatio is less than 125.
Logic: Custom validations allow you to write specific formulas for any column on the worksheet. By creating a validation on the finCompaRatio (Final Compa-Ratio) or compaRatio field, you can set the message type to "Error." Unlike a "Warning," an "Error" prevents the form from being saved or moved to the next step if the condition ($compaRatio > 125$) is met.

Why the Other Options are Incorrect

Option A:
While it looks similar to Option D, curRatio (Current Compa-Ratio) is a read-only field representing the employee's status before the planning cycle begins. Validating against the current ratio won't stop a manager from giving a raise that pushes the final ratio over 125%.

Option B:
The "splitOrDisallow" type is specifically designed for scenarios where a portion of the raise is allowed as a salary increase and the excess is automatically moved to a Lump Sum field. Since the client explicitly stated they do not award lump sums, this setting is inappropriate for their requirement.

References
SAP SuccessFactors Compensation Implementation Guide: Section on "Guidelines" and "Hard Limits."