JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 15, 2026 · 11 min read

SAP FSM Absence

Absence is FSM’s master record for a single technician’s planned or unplanned unavailability window — a holiday, a sick day, a training course, or an emergency callout that removes the technician from the pool of dispatchable candidates for the recorded period. Like Crew, Absence has exactly one true prerequisite: a Person/Technician (FSM-A04-04) record must already exist before an Absence can be registered against it — Absence stores no fields of its own beyond identification, the affected Person, and the date window itself. Absence is flagged as an optional master, used only when the business actually manages leave and unavailability inside FSM rather than in a separate HR or scheduling tool; a tenant that assumes every registered technician is always available has no need to configure it. Absence is the sixth object in the Technician Management domain (Phase 3, Zone C) covered in this series, alongside Skill (FSM-A04-01), Work Time Pattern (FSM-A04-02), Region (FSM-A04-03), Person/Technician (FSM-A04-04), Crew (FSM-A04-05), and Skill Requirement (FSM-A04-07). This article maps every field FSM consultants configure on an Absence record, and how those fields connect back to the Person/Technician record they block and the Planning Board that reads them.

Part 1: Absence — Core Concepts (All Modules)#

1.1 What Is Absence?#

An Absence represents a single, dated window during which one named technician is unavailable for dispatch — registered once, by an administrator or the technician themselves, and read automatically by every subsequent scheduling decision that falls inside that window. It is a deliberately thin master: it carries no Skill, Region, or Work Time Pattern fields of its own, because those properties belong to the Person/Technician record the Absence is attached to, not to the Absence record itself.

1.2 Absence Types#

Absence carries a single Absence Type field, and getting this classification right matters because it is what a dispatcher or a rescheduling report reads to judge whether an overlapping Service Call was foreseeable weeks in advance or needs an urgent same-day reassignment.

Design principle: Absence Type is a single classification field, not a workflow trigger — the type itself does not change how the Planning Board blocks capacity, but it is the field consultants and dispatchers rely on to distinguish foreseeable gaps from urgent same-day rescheduling work.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example (Zone C · Technician Management — tenant-level; FSM has no Company Code / Plant scoping above these objects)

Client (FSM Tenant)
   │
   ├── Skill SK-ELEC — Electrical Work L3                 (configured independently; tenant-level catalog)
   ├── Work Time Pattern WTP-STD — Mon–Fri 09:00–18:00     (configured independently; tenant-level catalog)
   ├── Region RG-KAN — Kanto (Asia/Tokyo)                   (configured independently; tenant-level catalog)
   │
   └── Person / Technician P-001 — Hanako Yamada (Plannable = Yes)
          │
          └── Absence ABS-P001 — Annual Leave, 2024-08-10–2024-08-16   (1:N — true containment; owned entirely by this Person, has no meaning without it)

Crew CR-TOK-A — Tokyo Team A (reference; Absence is NOT attached to the Crew record):
   Crew CR-TOK-A ── led by ──▶ Person / Technician P-001
   (An Absence registered against P-001 as Lead reduces the crew's available headcount for that period, but the
   Absence record itself remains attached only to P-001 — never to Crew CR-TOK-A.)

Planning Board / Assisted Scheduling (Transaction domain, FSM-B04):
   Planning Board ── reads ──▶ Absence ABS-P001
   (At dispatch time, an open Absence window for P-001 removes that technician from the pool of dispatch
   candidates for the overlapping period — a run-time exclusion check, not a stored flag on the Service Call
   or a change to the Person/Technician record's own Plannable field.)

Skill Requirement SR-EQ001 — Requires a Skill on an Equipment (cross-zone; unrelated to Absence):
   Skill Requirement SR-EQ001 ── requires ──▶ Skill SK-ELEC
   Skill Requirement SR-EQ001 ── applies to ──▶ Equipment EQ-001 (Zone B)
   (Shown here only to confirm Absence has no relationship to Skill Requirement — the two objects share a
   Zone but never reference one another.)

Design principle: Absence is true one-to-many containment, not a reference relationship — an Absence record belongs to exactly one Person/Technician and has no independent existence, unlike Crew, which references multiple Person/Technician records at once. Absence’s only real consumer is the Planning Board’s dispatch-time availability check; it carries no direct link to Crew, Skill, Region, Work Time Pattern, or Skill Requirement, and registering one never changes the Person/Technician record’s own Plannable flag.

1.4 Integration with Other Master Data Objects#

Absence does not stand alone. Every field on it exists to answer one question for the Planning Board: is this specific technician available during this specific window?

Part 2: FSM-Specific Field Details#

2.0 Scope of FSM Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Core Identification#

These two fields establish which technician an Absence record belongs to — every other field on the record only makes sense in relation to them.

2.2 Absence Window#

These three fields are the substance of an Absence — together they tell the Planning Board exactly what kind of unavailability this is and exactly which days it covers.

2.3 Status & Approval#

An Absence only reliably blocks Planning Board capacity once it has moved past a tenant’s approval step — these fields are what a dispatcher checks when a schedule gap looks unexplained.

Prerequisite: An Absence cannot be created until its Person/Technician (FSM-A04-04) record already exists — the same dependency pattern as Crew (FSM-A04-05).

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction