SAP SF Employee Central common mistakes
SAP SF Employee Central · Understand the traps and how to avoid them.
Selects 'Foundation Object' for any configurable corporate data object, including custom objects created in Configure Object Definitions.
Both Foundation Objects and MDF Generic Objects have code/name fields and associations, so candidates memorize screens instead of the object architecture.
What to do instead
Memorize the delivered Foundation Object catalogue (Legal Entity, Business Unit, Division, Department, Location, Job Code, Pay Group, Frequency, Event Reason, Employee Class, etc.) and the rule that custom objects are MDF Generic Objects; if the question says 'custom fields' or 'created by the customer', answer Generic Object.
Assumes every Foundation Object has one fixed parent and picks the parent from a single implementation instead of the object's configured associations.
EC Foundation Objects can have multiple associations (for example Department has a parent Department and a Business Unit association), and some associations are optional.
What to do instead
For each Foundation Object, learn the standard associations and which are mandatory vs optional; when unsure, reason from Configure Object Definitions associations rather than from a remembered hierarchy.
Places fields such as employee class, pay group, work schedule, or time profile in Compensation because the names sound pay-related.
Exam items use realistic field names and candidates group by semantics rather than by the EC object that stores the field.
What to do instead
Map by object: Job Information holds job, position, org unit, location, pay group, work schedule, time profile, employee class/type, FTE and manager; Employment holds start/end dates, probation, seniority and benefits eligibility; Compensation holds pay components, pay rate, frequency and compa-ratio.
Uses 'Insert' when the scenario describes correcting an existing Job Information record, producing overlapping or gapped effective-dated records.
Candidates conflate editing a record with creating a new effective-dated record and do not track the record's start and end dates.
What to do instead
Learn the actions: Insert creates a new record or future change, Correct changes an existing record from its start date, Delete removes a record; after any change, verify contiguity in Job Information history and check for overlaps or gaps.
Expects a Leave Type to define accrual and balance creation, and selects Leave Type when the question asks where accrual rules are configured.
Time Account Type and Leave Type both appear in Time Off configuration and both have eligibility, so candidates treat them as interchangeable.
What to do instead
Time Account Type defines account creation, accrual method, posting frequency and units; Leave Type defines booking rules, eligibility and which time account it draws from; the Time Account is the employee's balance instance.
Assumes mid-year hires, leave of absence, or unpaid leave automatically prorate or pause accrual without checking the Time Account Type accrual settings.
Accrual behavior is configurable, and candidates apply one client's setup as universal EC behavior.
What to do instead
Know the accrual methods (period-based, anniversary, calendar year, work anniversary), the proration settings, and the rules that pause or adjust accrual during leave; read the question for the configured accrual rule before choosing an outcome.
Creates a business rule and assumes it validates data or drives workflow simply because the rule exists and is active.
Business rules are reusable objects and remain inert until attached to a rule scenario, object, and trigger event.
What to do instead
Identify the scenario and trigger first (Manage Data, On Save, On Change, Workflow routing, Time Off eligibility), associate the rule with that scenario, and test it in the rule tester or by simulating the transaction.
Assigns a permission role to a user and assumes the user can see all employees, ignoring permission groups and target population.
Role-Based Permissions separate functional permission (what) from permission group and target population (who), and candidates memorize role names instead of the model.
What to do instead
Separate the three layers: Manage Permission Roles for functional permissions, Permission Groups for user grouping, Target Population for which employees are in scope; also check MDF object permissions and dynamic groups when the question involves visibility.
Assumes Employee Central calculates payroll and that assigning a pay group and frequency is sufficient to run payroll in EC.
EC is the master data system; Employee Central Payroll is a separate payroll engine fed by replication, so candidates conflate master data with payroll processing.
What to do instead
Know that payroll master data (employee data, pay components, org data) is replicated from EC to Employee Central Payroll, that payroll system configuration maps pay groups and frequencies, and that payroll results reside in the payroll system, not in EC.
Defaults to Integration Center for every inbound/outbound integration and to Report Center for every reporting question.
EC offers several integration and reporting tools, and candidates pick the most familiar tool rather than matching the tool to the use case.
What to do instead
Map the use case: scheduled simple outbound = Integration Center; real-time = OData API; full employee extract = Compound Employee/SFAPI; multi-object custom report = Query Manager or Online Report Designer; embedded operational list = Report Center.