JinJin48

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

July 15, 2026 · 13 min read

SAP FSM 欠勤

欠勤は、FSMにおける、計画済みまたは計画外の特定の技術者の不在期間（休暇、病欠、研修コース、緊急呼出など、記録された期間中に技術者を派遣対象候補から除外するもの）を管理するマスタレコードです。クルーと同様に、欠勤には厳密に1つの前提条件があります。それは、欠勤を登録する前に、担当者/技術者（FSM-A04-04）レコードが既に存在している必要があることです。欠勤は、識別情報、影響を受ける担当者、および日付範囲自体以外に独自のフィールドを保持しません。欠勤はオプションのマスタとしてフラグ付けされており、休暇や不在を別のHRツールやスケジューリングツールではなく、FSM内で実際に管理する場合にのみ使用されます。登録されたすべての技術者が常に利用可能であると想定するテナントは、これを設定する必要はありません。欠勤は、本シリーズで扱う技術者管理ドメイン（フェーズ3、ゾーンC）の6番目のオブジェクトであり、スキル（FSM-A04-01）、勤務時間パターン（FSM-A04-02）、地域（FSM-A04-03）、担当者/技術者（FSM-A04-04）、クルー（FSM-A04-05）、スキル要件（FSM-A04-07）と並んでいます。この記事では、FSMコンサルタントが欠勤レコードに設定するすべてのフィールドと、それらのフィールドがどのようにブロック対象の担当者/技術者レコード、およびそれらを読み取るプランニングボードに接続されるかをマッピングします。

パート 1: 欠勤 — 中核概念（全モジュール共通）#

1.1 欠勤とは#

欠勤は、特定の技術者が派遣不可となる単一の日付指定の期間を表します。これは、管理者または技術者自身によって一度登録され、その期間内に該当する以降のすべてのスケジューリング判断によって自動的に読み取られます。これは意図的にシンプルなマスタとして設計されており、スキル、地域、勤務時間パターンのフィールドを独自に保持しません。これらのプロパティは、欠勤レコード自体ではなく、欠勤が紐づく担当者/技術者レコードに属するためです。

1.2 欠勤タイプ#

欠勤には単一の「欠勤タイプ」フィールドがあり、この分類を正しく行うことが重要です。なぜなら、これはディスパッチャーや再スケジュールレポートが読み取って、重複するサービスコールが数週間前に予見可能であったか、緊急の当日再割当が必要かを判断するためです。

設計原則: 欠勤タイプは単一の分類項目であり、ワークフロートリガーではありません。タイプ自体はプランニングボードの能力ブロック方法を変更しませんが、コンサルタントやディスパッチャーが予測可能なギャップと緊急の当日再スケジュール作業を区別するために依存する項目です。

1.3 組織レベルとデータ階層#

データ階層と具体例（ゾーンC · テクニシャン管理 — テナントレベル；FSMにはこれらのオブジェクトより上位の会社コード/プラントスコーピングはありません）

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.)

設計原則: 欠勤は真の一対多包含関係であり、参照関係ではありません。欠勤レコードは厳密に1人の担当者/テクニシャンに属し、Crew（複数の担当者/テクニシャンレコードを同時に参照する）とは異なり、独立した存在を持ちません。欠勤の唯一の実質的な消費者は、プランニングボードのディスパッチ時の可用性チェックです。欠勤はCrew、スキル、地域、勤務時間パターン、スキル要件への直接的なリンクを持たず、欠勤を登録しても担当者/テクニシャンレコード自身のPlannableフラグは変更されません。

1.4 他のマスタデータオブジェクトとの統合#

欠勤は単独で存在するものではありません。そのすべてのフィールドは、プランニングボードに対して「この特定のテクニシャンは、この特定の時間枠で利用可能か？」という1つの質問に答えるために存在します。

パート 2: FSM固有のフィールド詳細#

2.0 FSM 所有権の範囲#

凡例: ◎ = オーナー / 重要, ○ = 直接関与

2.1 コア識別#

これらの2つのフィールドは、不在レコードがどのテクニシャンに属するかを確立します。レコード上の他のすべてのフィールドは、これらとの関連でのみ意味を持ちます。

2.2 欠勤ウィンドウ#

これら3つのフィールドは欠勤の実体を構成します。これらを組み合わせることで、プランニングボードはこの不在がどのような種類のものであり、正確にどの日をカバーしているかを把握できます。

2.3 ステータスと承認#

欠勤が計画ボードの能力を確実にブロックするのは、テナントの承認ステップを通過した後です。これらのフィールドは、スケジュールのギャップが説明不能に見える場合にディスパッチャーが確認するものです。

前提条件: 不在レコードを作成するには、その担当者/テクニシャン (FSM-A04-04) のレコードが既に存在している必要があります。これは、クルー (FSM-A04-05) と同じ依存関係パターンです。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction