PA0007 table — PA0007 Planned Working Time Infotype

Each row in PA0007 is one time-sliced version of an employee's planned working time setup: which work schedule rule applies, what percentage of a full-time role the employee is contracted for, whether the employee is flagged as part-time, and whether time recording or time evaluation is relevant for that person during that period. Rows are delimited by BEGDA/ENDDA so a full employment history shows as a stack of consecutive, non-overlapping periods for the same personnel number and subtype. The record is created at hire and re-created on every change to work schedule, FTE percentage, or part-time status, which means a long-serving employee with several schedule changes will have many rows, not one.

PA0007 is client-dependent, so MANDT is implicit in every read. It is not a huge table by row count compared to time or payroll clusters, but it is still wrong to read it without restricting by PERNR or by a date range plus personnel area, because a company-wide selection on SCHKZ or EMPCT alone will scan the full active workforce history. Always filter on BEGDA/ENDDA against the date of interest, not just today's date, since the current row is only one slice of the employee's history. When comparing across employees, join through PA0001 first to restrict by personnel area or employee group before touching PA0007, rather than filtering PA0007 directly on organizational attributes it does not carry.

Symptom: an employee's payroll result shows a different FTE factor than expected. Select PA0007 for that PERNR with ENDDA >= payroll period end date and BEGDA <= period start date, order by BEGDA descending. The top row gives the EMPCT and SCHKZ actually in force for that period. If there are two rows overlapping the period boundary with different SEQNR, the record was changed mid-period and payroll correctly split the factor across both slices, which is not a data error.

PA0007 continues to exist as a physical table on S/4HANA on-premise in classic HR/HCM deployments and is exposed through the standard CDS-based reporting layer used for time and workforce analytics. In an SAP SuccessFactors Employee Central deployment integrated with SAP for Payroll or on-premise time evaluation, the planned working time data originates in Employee Central's work schedule and job information objects and is replicated into PA0007 via the standard employee data replication process, so the table becomes a target of integration rather than the point of direct maintenance.

In a project with on-premise HCM, the time management or payroll consultant owns discrepancies here, since PA0007 feeds time evaluation schemas and payroll factoring directly. In a SuccessFactors Employee Central landscape, the first question is whether the record was replicated correctly from Employee Central job information, which puts the integration consultant in the loop before assuming a schema or configuration defect on the SAP side.

PA0000 (actions) and PA0001 (organizational assignment) provide the employment and org context that PA0007 does not carry itself. PA0002 supplies personal data occasionally cross-checked during audits of the same PERNR. PA2001 and PA2002 hold the absences and attendances measured against the plan in PA0007, and TEVEN holds the raw time events reconciled against it. Maintenance in on-premise systems runs through the standard infotype maintenance transactions for infotype 0007; in Employee Central integrated landscapes the source object sits in job information and is written to PA0007 by the replication job rather than by direct infotype entry.