SAP SF Employee Central: The Cost Center Reorg That Rewrote 1,400 Employee Records

The Cost Center Reorg That Rewrote 1,400 Employee Records

Northwind Retail runs six legal entities across four countries on Employee Central. Finance maintains cost centers centrally and HR consumes them in Job Information. Historically, cost centers were entered as a picklist option, and last quarter Finance merged 60 centers, retiring codes such as CC-100 in favour of CC-1450 while describing the same physical location. After the change, HR reported roughly 1,400 employees whose Job Information now points to a retired option, and an equal number of new Job Information records created the same night. Separately, the Business Unit hierarchy was renamed at its top node and 120 employees dropped out of every hierarchy-based report. Payroll asked HR to simply backdate the new codes to January so reports look clean. Nobody can explain why the overnight import produced one new record per employee.

1. What most likely produced the ~1,400 new Job Information records, and how do you confirm it before touching anything?

Read the worked answer

The ratio is the clue: ~1,400 new records for ~1,400 affected employees means one new effective-dated record per employee, not a data corruption. In an effective-dated object like Job Information, any save that changes a value writes a new dated record. That pattern appears when:

The import file carried no effective-date column, so the system stamped the run date.
The run used 'overwrite/update' against current records and re-saved every row even where the value did not change.
A rule fired on save and re-wrote the record a second time.

Confirmation order: pull the import execution log for that night (row count, effective date used, operator), then compare the startDate of new records against the run timestamp, and check lastModifiedBy/lastModifiedDate on a sample of 20 records. If start dates equal the run date, it is an import-date problem, not a Finance data problem. Do not delete the records; a save to correct them creates yet another dated record, so the fix must be a single well-dated correction.

2. Should cost centers be a picklist, a generic object, or a hierarchy node? Recommend a model and justify it in terms of the reorg you just lived through.

Read the worked answer

Recommendation: model Cost Center as a generic (MDF) object associated to Job Information, with a surrogate stable external code and a separate, editable 'Finance code' field.

Reasoning:

A picklist option is keyed by its option ID. When Finance retires CC-100, you cannot silently re-key it; you either leave stale options referenced forever or move every record. That is exactly the failure mode observed.
A generic object lets the object survive business re-keying: externalCode stays stable (e.g. NW-CC-0042), while financeCode moves from CC-100 to CC-1450 in one effective-dated object record. Employee records still point at the same association, so no mass rewrite.
If cost centers are only meaningful within a Legal Entity, make the association valid-when scoped to Legal Entity so users cannot pick another entity's centre; otherwise the field will drift during transfers.
Use a hierarchy (with parent) only if Finance needs roll-up reporting on the object itself; a flat object with a parent field is enough for most payroll and headcount roll-ups and is far cheaper to maintain.

The deciding test is not 'which object type is standard' but 'can the business re-key this code without me writing 1,400 dated records?'

3. HR wants the new codes backdated to January. Evaluate that request and prescribe what to do instead.

Read the worked answer

Splitting the request into two distinct problems:

1. The 120 hierarchy dropouts. Almost certainly the top-node rename changed the node's identifier or its association, so the hierarchy evaluation no longer resolves those employees' assignments. This is a configuration fault with a present-day fix; correcting the node and re-evaluating the hierarchy is safe and does not require backdating. Verify by checking whether the affected employees' Business Unit assignments still exist as records but fail to resolve to a parent chain.

2. Backdating the codes to January. Reject as stated. Backdating would:

Rewrite history that payroll, finance, and auditors already consumed for multiple closed periods.
Not actually 'clean' the reports, because the original retired options remain referenced in the historical dated records.

Instead: set the Finance-code change effective on the correct business date (do not force January unless January is genuinely when Finance re-keyed), correct the affected Job Information records with a single dated correction rather than 1,400 ad hoc saves, and fix reporting at the report layer using an effective-dated join or an 'as of today' filter on the object rather than touching employee history. If Finance genuinely needs January restated, handle it as a reporting mapping (old code → new code) in the reporting layer, not in the transactional data.