JinJin48

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

July 19, 2026 · 17 min read

SAP SF 勤務タイプ

時間タイプは、年次休暇、病気休暇、無給休暇など、休暇または欠勤のカテゴリを定義するマスタデータオブジェクトであり、それ自体には未消化ルールを持たない再利用可能なラベルです。時間アカウントタイプは、時間タイプに紐付く子オブジェクトで、実際の付与、消費、繰越ルールを保持し、カテゴリを運用可能にします。これら2つは、フェーズ2（権限とシステム設定）の時間設定グループにおける3つの並列かつ独立したチェーンのうち、3番目を構成します。すなわち、休日カレンダー → 勤務スケジュール（SF-A03-03/04）が従業員がいつ働くことが期待されるかを定義するのに対し、時間タイプ → 時間アカウントタイプはどのような種類の勤務外時間が存在し、従業員がそれぞれをどれだけ取得できるかを定義します。この記事では、時間タイプと時間アカウントタイプの概要、それらの休暇カテゴリの動作（付与あり vs. 付与なし、有給 vs. 無給、繰越対象 vs. 非対象）、同じランドスケープゾーン内で並行する権限管理チェーンおよび休日カレンダー/勤務スケジュールチェーンとの関係、そして管理センターのコンサルタントが両方のオブジェクトに対して設定するすべてのフィールドについて説明します。

パート1: 時間タイプ — 基本概念（全モジュール共通）#

1.1 時間タイプとは#

Time Typeはクライアントレベルの設定オブジェクトであり、それ自体に未払い計上や消費のロジックは一切含まれません。単に欠勤の名前付きカテゴリ（例：「年次休暇」「病気休暇」）と、カテゴリを定義する少数のフラグ（有給/無給、出勤日数にカウントするかどうか）を設定するものです。その価値は、1つ以上のTime Account Typeレコードが紐づく親となる点にあります。各Time Account TypeはTime Typeからカテゴリの識別情報を継承し、その上で具体的な未払い計上額、頻度、繰越上限を追加します。これらは最終的にTime Profileが従業員割当のためにバンドルします。

1.2 勤怠タイプ / 勤怠勘定タイプカテゴリの動作#

休暇区分ごとに、休暇取得ルールが適用された後の動作は異なります。未付与区分をあたかも付与されるかのようにモデル化したり、その逆を行ったりすることは、休暇残高の不一致の一般的な原因であり、これはビルド時のエラーではなく、従業員からのエスカレーションとして表面化します。

設計原則: 有給/無給、発生対象/非発生対象、繰越対象/非対象といったカテゴリの動作は、勤怠タイプレベルで一度定義します。これにより、その下に構築されるすべての勤怠勘定タイプが一貫したポリシー意図を継承します。単一の勤怠タイプの下で矛盾する発生ロジックを混在させると、後日休暇分類を監査する際に、カテゴリの意味が不明瞭になります。

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

具体的な例を用いたデータ階層

Time Typeは、Permission Group / Permission Role（SF-A03-01/02）やHoliday Calendar / Work Schedule（SF-A03-03/04）と同じく、SuccessFactorsマスタデータランドスケープのテナントレベルの「Permission & Time」ゾーンに位置しています。このゾーンには、3つの並行かつ独立したクライアントレベルの設定チェーンがバンドルされており（Permission Management、Holiday Calendar → Work Schedule、Time Type → Time Account Type（Time Profileで結合））、本記事のオブジェクトは3番目のチェーンに該当します。他の2つのチェーンは同じランドスケープゾーンに存在しますが、関連記事に属しています。

Client (SuccessFactors Instance)
   │
   ├── Permission Group "PG_Manager" — Managers, Direct Reports  (see SF-A03-01)
   │      │
   │      └── Permission Role "PR_ESS" — Employee Self-Service, of PG_Manager  (see SF-A03-02)
   │
   ├── Holiday Calendar "HC_JP2024" — Japan 2024, 16 holidays  (see SF-A03-03)
   │      │
   │      └── Work Schedule "WS_JP_Std" — JP Standard, 40H/week, of HC_JP2024  (see SF-A03-04)
   │
   └── Time Type "TT_Annual" — Annual Leave, category
          │
          └── Time Account Type "TAT_Annual" — 20 days, 5-day carryover, of TT_Annual

Time Profile "TP_JP_Std" — JP Standard, Work Schedule + Time Account Type bundle  (see SF-A03-06)
   ├── assigned to ──> Work Schedule "WS_JP_Std"
   └── assigned to ──> Time Account Type "TAT_Annual"

【必須】ランドスケープ検証に関する注意事項: モジュールMaster.mdの階層構造では、Time TypeがTime Account Typeの直接の親としてリストされています（“レベル7: Time Type └── Time Account Type”）。また、ER図ではこれを1:Nの関係として描いています — 単一のTime Type（例: “年次休暇"をカテゴリとして）に、集計ルールが母集団によって異なる複数のTime Account Typeレコードが紐づくことができ（例: 同じ休暇カテゴリの下で、特定の国や従業員層に対して異なる年間付与額が設定される）、その逆はありません。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンC）では、これを単一の実線の親子コネクタ — TT_Annual → TAT_Annual — として描いており、これはその1:N関係の1つのインスタンスを表しています。下流側では、ER図は Time Profile ←── Time Account Type を示しており、ランドスケープではこれを、TP_JP_Std から TAT_Annual へと伸びる紫色の破線の「割り当て済み」矢印（動詞「使用する」）としてレンダリングしています — Time ProfileはTime Type自体ではなく、Time Account Typeを直接参照します。この2層構造が実際にどのように機能するかについては、セクション1.4および2.4を参照してください。

設計原則: タイプ区分自体には組織的な下位レベルはなく、フラットなカテゴリラベルです。このデータ構造におけるすべての階層的な深さは、1つ下のレベルである「タイプ区分 → 勤怠勘定タイプ」の親子関係に存在し、さらにその1つ下のレベルである各勤怠勘定タイプの独自の積増フィールド設定（パート2）に存在します。

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

時間タイプのカテゴリラベルは、時間勘定タイプがそれに未払ルールを紐付けて初めて有効になり、その時間勘定タイプもまた、タイムプロファイルにバンドルされて初めて従業員に到達します。

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

2.0 SFの所有範囲#

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1 勤怠タイプ定義（中核識別）#

Time Type Definition（勤怠タイプ定義）は、勤怠タイプが存在するために必要な最小限のレコードであり、すべての勤怠勘定タイプの親カテゴリ参照、およびシステム内の他の場所でカテゴリを参照するすべての参照が、最終的に解決される対象です。

2.2 カテゴリ動作フラグ#

カテゴリ動作フラグは、休暇カテゴリが給与計算および勤怠計算でどのように扱われるかを決定し、第1.2節で紹介した、付与対象/非対象および有給/無給の区別を制御するフィールドグループです。

2.3 時間勘定タイプ定義#

時間勘定タイプ定義は、時間タイプカテゴリをタイムプロファイルが実際にバンドルできるものに変換する子オブジェクトです。すべてのタイムプロファイルの勘定タイプ選択画面（SF-A03-06）は、時間勘定タイプに解決され、時間タイプに直接解決されることはありません。

2.4 見越しおよび繰越ルール#

Accrual and Carryover Rules（未消化繰越ルール）は、Time Account Type（勤怠勘定タイプ）の実際のペイロードであり、Time Off（休暇管理）が従業員の実際の残高を計算するために読み取る具体的な数値です。セクション2.1～2.3のすべては、これらのルールを整理・識別するために存在します。このデータこそが、従業員の休暇申請において何が発生するかを決定するものです。

前提条件: 給付額と繰越上限額は給与計算および休暇残高の計算に直接影響を与えるため、アクティブな勤務管理プロファイルや従業員割当ですでに参照されている既存の勤務管理勘定タイプへの変更は、発効日付で給与計算に影響を与えるコンフィギュレーション変更として扱う必要があります。適用する前に確認および周知を行い、適用後に行わないでください。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction