JinJin48

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

July 15, 2026 · 11 min read

SAP FSM Service History

Service History is the read-only record of a completed service event tied to a specific Equipment (FSM-A03-01) — a log entry generated automatically the moment a linked Service Call or Activity reaches closed status, not created directly the way Equipment or Equipment Hierarchy records are. It closes out the Equipment Management domain (Zone B) by turning every past visit into a queryable trail: what happened, when, who performed it, and what it links back to for warranty, audit, and technician-preparation purposes. This article maps every field FSM surfaces on a Service History record, and how those fields connect back to Equipment, Equipment Hierarchy, the originating Service Call, and — where ERP Integration is active — the corresponding S/4HANA Service confirmation.

Part 1: Service History — Core Concepts (All Modules)#

1.1 What Is Service History?#

Service History represents a single completed service event against a serviceable asset — a snapshot of what was done, when, and by whom, kept for as long as the asset itself is tracked. It is not independently authored data like a customer or asset master; it is a derived, read-only reflection of a Service Call or Activity at the moment that work was closed.

1.2 Service History Record Types#

Service History has no independent lifecycle status of its own — it either exists (the underlying Activity has closed) or it does not yet exist (the Activity is still open). What does vary is where the underlying Service Call originated, and that origin shapes which reference fields get populated on the resulting record.

Design principle: Classify Service History by where the underlying Service Call originated, not by a status on Service History itself — the object has no status field of its own to maintain.

1.3 Organizational Levels and Data Hierarchy#

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

Client (FSM Tenant)
   │
   ├── Equipment EQ-001 — AC Unit A (Serial SN-2024-001)
   │      ↗ references Business Partner BP-001 — ABC Corp (Zone A)
   │      ↗ references Address AD-A — 1-1 Marunouchi, Tokyo (Zone A)
   │      │
   │      └── Equipment Hierarchy EQ-001-01 — Sub-unit of EQ-001 (Hierarchy Level 2)
   │
   ├── Equipment EQ-002 — Pump B (Serial SN-2024-002)
   │      ↗ references Business Partner BP-002 — XYZ Ltd (Zone A)
   │      ↗ references Address AD-B — 2-2 Umeda, Osaka (Zone A)
   │      │
   │      └── Equipment Hierarchy EQ-002-01 — Sub-unit of EQ-002 (Hierarchy Level 2)
   │
   └── Equipment EQ-003 — Chiller C (Serial SN-2024-003)
          ↗ references Business Partner BP-002 — XYZ Ltd (Zone A)
          │
          └── Equipment Hierarchy EQ-003-01 — Sub-unit of EQ-003 (Hierarchy Level 2)

Service History (reference log — points back to whichever Equipment node was actually serviced, never nested under it):
   Service History SH-001 — Filter replacement, 2026-03-01 ── refers to ──▶ Equipment EQ-001
   Service History SH-002 — Seal leak repair, 2026-04-12 ── refers to ──▶ Equipment EQ-002
   Service History SH-003 — Annual inspection, 2026-05-20 ── refers to ──▶ Equipment Hierarchy EQ-003-01 (sub-unit of EQ-003)
          ↗ references Service Call SC-3007 (FSM-B03) and Technician T-014 — Jane Tanaka

Design principle: Service History is never rendered as a child node of Equipment or Equipment Hierarchy in the landscape — it is drawn as a reference log with an arrow pointing back to whichever Equipment node, top-level or hierarchy sub-unit, was actually serviced. It carries no Company Code / Plant scoping of its own; it simply inherits whichever tenant-level Equipment record it refers to.

1.4 Integration with Other Master Data Objects#

Service History has no meaning on its own — every one of its fields exists to point back at the Equipment that was serviced and the Service Call that generated the record.

Part 2: FSM-Specific Field Details#

2.0 Scope of FSM Ownership#

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

2.1 Core Identification & Linkage#

These fields establish which record this is and exactly what it points back to — Service History carries no editable content of its own beyond these references and the event metadata in 2.2.

Prerequisite: A Service History record only exists once the linked Service Call / Activity has reached closed status — an open or in-progress Activity produces no Service History entry until it closes.

2.2 Service Event Details & Outcome#

These fields carry the substance of what happened during the visit — the detail a technician preparing for a follow-up visit, or a manager reviewing an SLA dispute, actually needs to read.

2.3 Source & Reference Traceability#

Beyond what happened, Service History also carries the pointers a consultant needs to pull the full supporting evidence for a given visit — the signed report, the parts consumed, the customer’s feedback, and, where relevant, the ERP-side confirmation.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction

Zone crop source: 04-fsm-a01-master-landscape.png (mtime: Jul 15 11:04)