SAP tableObjectPA2001ModuleHCM_SUCCESSFACTORS

PA2001 table — PA2001 Absences Infotype Table

PA2001 holds absence records for infotype 2001 (Absences) - sick leave, vacation, unpaid leave and similar events, one row per absence period per employee per absence type. It is the transparent reporting copy of records whose master storage for time infotypes is the payroll time cluster, kept in sync automatically when the record is saved through the standard infotype maintenance transactions.

Covers what a row in PA2001 represents, the fields consultants actually query, how it joins to organizational assignment, planned working time and quota tables, and the specific trap of treating this table as the sole source of truth for absence data. Aimed at anyone chasing a discrepancy between what a manager reports and what payroll or time evaluation actually processed.

Published 15 Sept 2026· 1,103 words

What it stores

A row in PA2001 represents one absence record for one employee: a single continuous period, of one absence type, recorded under infotype 2001. Typical absence types stored here are illness, planned vacation, unpaid leave, maternity leave, jury duty, and any other customer-defined absence subtype. Each record carries a start and end date, the number of calendar days and payroll-relevant days the absence spans, and administrative fields such as who last changed it and when. Because infotype 2001 supports multiple records per day in some configurations (partial-day absences, different absence types on the same date), a single calendar day for one employee can appear across more than one row, distinguished by a sequence number. The table feeds time evaluation, payroll absence valuation, quota deduction, and absence reporting used by HR and line managers.

Key fields

  • MANDT - client
  • PERNR - personnel number the absence belongs to
  • SUBTY - absence type (the AWART value), e.g. sickness, vacation, unpaid leave
  • BEGDA - start date of the absence record
  • ENDDA - end date of the absence record
  • ABWTG - number of calendar days the record covers
  • ABRTG - number of payroll-relevant days derived for the record
  • SEQNR - sequence number distinguishing multiple records on the same start date
  • HISTO - history indicator, set when a record has been delimited or historicized
  • ITXEX - flag indicating a long text exists for the record
  • AEDTM - date of last change
  • UNAME - user who made the last change

How it joins the data model

  • PA2001-PERNR = PA0000-PERNR - confirm the employee's employment status was active for the absence period
  • PA2001-PERNR = PA0007-PERNR - compare the absence against the planned working time record to derive SOLL (target) days
  • PA2001-PERNR = PA2002-PERNR - the attendances counterpart table, same key structure, used to reconcile overlapping records
  • PA2001-PERNR = PA2006-PERNR - quota records consumed or generated as a consequence of the absence posting
  • PA2001-PERNR = TEVEN-PERNR - clock-in/clock-out time events that may overlap or conflict with a posted absence period

How to read it safely

Always restrict by MANDT and PERNR first; the table grows across the entire absence history of every employee, so an unrestricted select on a productive system is expensive and usually unnecessary. Add a date range filter on BEGDA/ENDDA rather than pulling full history when the question is about a specific period. SUBTY narrows to a single absence type when the question is scoped to, for example, sickness only. Do not assume one row equals one calendar day off; a record can span weeks, and partial-day or split records show up as separate rows with the same BEGDA. Check HISTO before trusting a record as current - a historicized row remains in the table for audit purposes.

How to prove it in the data

Symptom: an employee disputes the number of vacation days payroll or a report shows as taken. Select PA2001 for that PERNR with SUBTY restricted to the vacation absence type and a wide BEGDA/ENDDA window covering the disputed year, sum ABWTG across the returned rows, and compare against the quota consumption shown in PA2006 for the same period. A mismatch between the two points to a quota transfer, correction, or an absence posted but not yet processed by time evaluation, rather than a data entry error in PA2001 itself.

ECC vs S/4HANA

In S/4HANA on-premise with classic time management, PA2001 continues to exist and behaves the same way, including the underlying redundant-storage relationship with the time cluster. Where employee master data has moved to the newer HR data model or where SuccessFactors Employee Central owns absence data with replication into ECP or on-premise payroll, PA2001 may be populated by inbound replication rather than direct PA30 entry, and its role shifts from primary entry table to a landing/reporting table for replicated absence data. Consultants should verify which system is the system of record for absences before treating PA2001 content as authoritative.

Common pitfalls

  • Treating PA2001 as the single source of truth for time infotypes is the most common mistake. Absence and other time infotypes are stored redundantly: the payroll and time evaluation processes read the time management cluster, and PA2001 is a synchronized reporting copy. If the synchronization has not run or fails silently, PA2001 can lag behind what PA30 shows on screen or what payroll actually processed.
  • Summing ABWTG blindly overstates absence duration when partial-day records exist; ABWTG can be a fraction of a day, and multiple fractional records on the same date need careful aggregation, not a simple row count.
  • Ignoring HISTO leads to double-counting delimited and current versions of the same absence period after a correction was made.
  • Assuming a missing PA2001 row means the employee was present ignores that some absences are entered directly through time evaluation results or interfaces and may not appear as a standard infotype record until a batch process writes it back.
  • Comparing PA2001 across employee groups without checking the absence type customizing (counting rules, deduction rules) leads to false conclusions - the same SUBTY value can be configured to behave differently for different employee subgroups or countries.
  • Reading PA2001 without checking PA0000 status invites conclusions built on absence records that predate an employee's active employment window or occurred during an inactive period that should be excluded from current reporting.

Whose problem this is

Time management or HR administration owns absence master data quality; the payroll or time evaluation team owns disputes about how an absence was valuated once posted. When SuccessFactors Employee Central is in scope, the integration or replication team owns discrepancies between EC absence records and the PA2001 copy on the receiving system.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tables/pa2001ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.