JinJin48

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

July 19, 2026 · 20 min read

SAP SF 報酬プラン

報酬プランは、報酬サイクルのトップレベルのパラメータ（プランタイプ、有効日、全体の予算ポスチャ（例：「CP_Merit2024、メリットサイクル、3%予算」））を定義するマスタデータオブジェクトです。1つ以上の報酬テンプレートがそのコンポーネント計算ルールのためにバインドし、下流のエリジビリティルールが各テンプレートが適用される特定の従業員母集団にさらに絞り込みます。これは、フェーズ2（権限とシステム設定）の報酬設定サブブロック内で最初に設定されるオブジェクトであり、フェーズ3の従業員データオブジェクトの前の、そのフェーズにおける最後の設定チェーンです。この記事では、報酬プランとは何か、その一般的なプランタイプのバリエーション、ランドスケープのタレント＆報酬ゾーンにおいて報酬テンプレート/エリジビリティルールチェーンの先頭に位置する方法（予算はネストされた子オブジェクトではなく、個別の相互参照する兄弟オブジェクトとして存在する）、および管理者がプラン、そのテンプレート、エリジビリティルール、予算配分のために設定するすべてのフィールドについて説明します。

パート1: 報酬プラン — 中核概念（全モジュール共通）#

1.1 報酬プランとは#

報酬プランは、クライアントレベル（テナントレベル）のファンデーションオブジェクトであり、それ自体には従業員データは一切保持されません。これは、その下にコンポーネントレベルの計算ルールや従業員の資格条件が定義される前に、報酬サイクルにその識別情報（プランタイプ、有効日）と全体的な予算状況を提供する、純粋に最上位のコンテナとして存在します。単一の報酬プランは通常、1回の年次または臨時の報酬イベントに対して再利用され、同じプランを毎年再開するのではなく、その後のサイクルごとに新しいプランが作成されます。

1.2 報酬プランバリアント（プランタイプパターン）#

報酬プランのタイプは単なる外観上の選択ではありません。バインドされた報酬テンプレートが計算できるコンポーネント、意味を持つ資格条件、そして予算の配分率がどのように解釈されるか（基本給のアップ率か、一時金か）を決定します。設計段階で誤ったプランタイプを選択すると、不一致が発見された時点で、報酬テンプレートの計算ルールと予算の配分基準の両方を再構築する必要が生じます。

設計原則: 任意の従業員に対して報酬明細書が生成される前に、報酬プランのタイプとそれにバインドされた報酬テンプレートのコンポーネント構造をロックする必要があります。マネージャーに明細書が発行された後にプランタイプやコンポーネント定義を変更すると、マネージャーが実際に確認している内容と、システムが実際に計算して支給する内容との間で同期が取れなくなります。

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

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

Compensation Planは、SuccessFactorsマスタデータランドスケープのテナントレベルの「人材・報酬」ゾーンに位置し、そのゾーンにバンドルされた2つの独立したクライアントレベルチェーンのうち、2番目のチェーン（SF-A03-07/08/09でカバーされる人材チェーンと、本記事の報酬チェーン）の先頭にあります。

Client (SuccessFactors Instance)
   │
   ├── Rating Scale "RS_5pt" — 5-level, 1 = Below Expectations – 5 = Outstanding  (Talent chain, see SF-A03-07)
   │
   └── Compensation Plan "CP_Merit2024" — Merit 2024, 3% budget  ← this article
          │
          └── Compensation Template "CT_Merit" — Merit, 0-6% guideline range, of CP_Merit2024
                 │
                 └── Eligibility Rule "ER_FT1Y" — Full-time, 1+ year tenure, of CT_Merit

Budget "BDG_Sales2024" — Sales Dept 2024, 3.5% allocation
   │
   ├── ── based on ──> Compensation Plan "CP_Merit2024"  (purple dashed cross-reference, Zone D-internal)
   └── ── references ──> Department "DEPT_S01" — Sales Team 1  (Zone A cross-zone chip, see SF-A02-04)

必須のランドスケープ検証注記: モジュールMaster.mdのセットアップフローでは、予算の前提条件を真の二重依存関係「25. 予算 ← (報酬プラン, 部門)」としてリストし、そのER図では予算を報酬プランの直接の1:N兄弟子として、報酬テンプレートと並べてネストしています（「報酬プラン → [報酬テンプレート, 予算 ← 部門]」）。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンD、本セッションでHTML/SVGソースに対して直接検証済み、SF-A03-07/08/09/10で既に記録された独立検証と一致）は、これを異なる方法で解決しています。SVG内のすべての<line>要素をスキャンすると、ゾーンD列Bの実線チェーン（x=1360）はCP_Merit2024 → CT_Merit → ER_FT1Yのみを実行し、2番目の実線セグメントはy=1150（Eligibility Ruleの上端）で終了しています。予算ノード（行4、top:1295px）に到達する実線コネクタはありません。予算のコネクタは、(1) 左側のx=1230に迂回し、y=895まで上昇し、報酬プランの左端に矢印で終端する紫色の破線で、「based on」という動詞ピルでラベル付けされているもの（ゾーンCのタイムプロファイル→勤務スケジュール/勤務時間タイプの相互参照に使用されるのと同じ紫色破線・動詞ラベル付きの規則）、および(2) 予算自身のカード内にある別個の↗ DEPT_S01参照チップで、ゾーンAの部門を指しているもの、の2つだけです。したがって、報酬プラン自身の実線階層は報酬テンプレートとEligibility Ruleにのみ及びます。予算はゾーンDの相互参照兄弟オブジェクトであり、報酬プランの構造上の子ではありません — この「based on」参照が実際にどのように使用されるかについては、セクション1.4およびセクション2.4を参照してください。これは、SF-A03-10でルートマップについて既に確認された、ER図のネストとランドスケープの相互参照パターンと同じものです。

設計原則: 報酬プラン自体には従業員データや独自の組織サブレベルが存在しないため、その階層上の位置は意図的に浅く設定されています（クライアントレベル、単一ノード）。コンサルタントにとって重要な構造的な複雑さは、1つまたは2つ下のレベル、つまり報酬テンプレートが計算コンポーネントを定義する方法（セクション2.2）と、資格ルールが対象母集団を絞り込む方法（セクション2.3）にあり、プランオブジェクト自体にはありません。

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

報酬プランは、自身が所有する報酬チェーンと、より広範なタレント＆報酬ゾーンの両方を締めくくります。直接の構造上の子（報酬テンプレート）が1つ、2階層下に到達する間接的な子孫（資格ルール）が1つ、それを参照する兄弟オブジェクト（予算）が1つ、そしてランドスケープ内で直接接続しないタレントチェーンからのビジネスプロセスのみの入力（完了した評価の結果）が1つあります。

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

2.0 SFの所有範囲#

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

2.1 報酬プランの定義（コア識別）#

報酬プラン定義は、報酬プランが存在するために最低限必要なレコードです。これは、バインドされたすべての報酬テンプレートと、予算オブジェクトの「基準」参照が最終的に解決される対象です。

2.2 報酬テンプレートの設定#

報酬テンプレート設定は、繰り返し可能な子レコードであり、プランごとに1つ以上のテンプレートが存在します。これは、マネージャーが報酬ワークシート上で実際に目にする報酬コンポーネントと、各コンポーネントのガイドライン計算ロジックを定義します。

2.3 資格ルールの設定#

適格ルールの設定は、「このテンプレートの実際の適用対象者」を定義する場所です。ルールが紐付いていない報酬テンプレートは事実上全員を対象としますが、それが意図された動作であることはほとんどありません。

2.4 予算配賦#

予算とは、報酬プランの全体パーセンテージ（例：CP_Merit2024 の「3%予算」）を、組織単位ごとの実際の割当額に変換するオブジェクトです。これは、全体構成（セクション1.3）において報酬プランの相互参照的な兄弟関係にあり、構造上の子要素ではありませんが、当該モジュールが報酬プラン／テンプレート／対象条件／予算を1つの設定チェーンとしてグループ化しているため、本記事の対象範囲に含まれます。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction