Infotype Record Cannot Be Delimited

HR administration reports that they are trying to end-date a record, most often an organizational assignment, a cost center, or an address, and the system will not let them save the delimitation. The screen throws a red message and refuses to proceed, or the record appears to save but reverts to its original dates the next time it is opened. Sometimes the complaint arrives as a payroll problem instead: the employee moved cost centers on a certain date but the old cost center is still being charged, and when the administrator tries to correct it directly in the infotype, the delimit action fails. In a landscape where Employee Central feeds the ERP or ECP system, the complaint is often phrased as 'we changed it in the SuccessFactors system and it still shows the old record in payroll'.

In PA20, pull the full infotype history for the employee showing begin and end dates end to end with no gaps, then attempt the delimit and record the exact message. Cross-check IT0003 for the earliest retroactive accounting date against the intended delimitation date. If Employee Central is in scope, pull the integration log timestamp for the last inbound message against that infotype and personnel number and compare it to the time the manual change was attempted.

If the cause is a time-constraint-1 gap, this is a data fix: insert or extend the adjacent record with a delimit-and-insert action in PA30/PA40 so no gap exists, rather than delimiting in isolation. If the cause is a retroactive accounting limit, this is a data and authorization decision: either move the change to a date within the allowed retro window, or have someone with the appropriate authorization override the earliest retro date on IT0003, understanding this reopens prior payroll periods. If the cause is a lock, this resolves itself once the blocking session or batch job ends; if it persists, the lock entry needs to be cleared by Basis. If the cause is a time constraint configuration error, this is a config fix requiring a transport to correct the infotype attribute table entry, tested in a non-production client first because it affects every employee using that infotype. If the cause is Employee Central ownership, the fix is procedural: the delimitation must be performed in Employee Central and allowed to replicate down, not made directly against the replicated record; if the replicated record needs different handling, the integration mapping or business rules need review by the integration team, which is a config change on the middleware or EC side.

The reflex fix is to bypass the delimit action entirely and change the validity dates directly through table maintenance (SM30 or SE16N) or to force a delete of the record. This skips every consistency and time-constraint check the infotype framework enforces, and it does not touch the dependent infotypes that were the actual reason the delimit was blocked. The result is a gap in a time-constraint-1 infotype that surfaces later as a payroll run failure for that employee, or a record that Employee Central overwrites again on the next replication because the underlying integration issue was never addressed.

Data fixes within time constraint rules belong to HR administration with functional support. Retroactive accounting limit overrides and time constraint configuration belong to the HCM payroll functional consultant, and any config change needs a transport through the normal landscape. When Employee Central is the source of the record, the integration or EC functional team owns the fix, and the handover note should state which system is authoritative for that infotype.