SAP SF 法人
SAP SF 法人
Legal Entity(法的エンティティ)は、SuccessFactors Employee Central における最上位レベルの組織マスタデータオブジェクトです。これは、従業員を雇用し、その下位の組織階層のすべてのレベルを支える、法的・税務登録されたエンティティ(通常は企業または子会社)を表します。コンサルタントが設定するすべての Business Unit(事業単位)、Division(事業部門)、Department(部門)、および Cost Center(原価センタ)は、最終的に1つの Legal Entity に割り当てられ、すべての Employment(雇用)レコードは、従業員の法的雇用主として Legal Entity を参照します。この記事では、Legal Entity とは何か、それがより広い階層内でどのように位置づけられるか、そして Employee Central コンサルタントが設定するすべてのフィールドについて説明します。
パート1: 法人 — 中核概念(全モジュール)
1.1 法的エンティティとは

Legal Entity(法的エンティティ)はファンデーションオブジェクトであり、SuccessFactorsの組織構造における最上位レベルです。これは報告ラインやチームを表すものではなく、従業員が雇用され、給与が支払われ、当局に報告される実際の法的/法定登録を表します。その下位にあるもの(事業部門、部門、部署、原価センタ)はすべて、Legal Entityが定義する境界内で人員とコストを整理するために存在します。
| 項目 | 詳細 |
|---|---|
| ロール | 組織階層のルート。すべての雇用レコードが参照する法的/法定雇用主の境界 |
| 使用するモジュール | エンプロイーセントラル(所有者 — ファンデーションオブジェクトフレームワーク)、エンプロイーセントラル給与(法定報告のために法定雇用主ごとに給与計算実行をグループ化)、リクルーティング/オンボーディング(求人票と新規採用者は通常、採用組織の法的エンティティを継承) |
| トランザクション | 管理センター → 「組織、給与、ジョブ構造の管理」(ファンデーションオブジェクトレコードの作成/編集)、「データのインポートとエクスポート」(CSVによる一括ロード)。ビジネスルールにより、他の雇用フィールドから法的エンティティを自動導出可能 |
| 主要テーブル | OData API エンティティ FOLegalEntity(ファンデーションオブジェクト)— SuccessFactors には従来のABAPテーブルはありません。各レコードはテーブル行ベースではなく、有効期限日ベースです |
| S/4HANA 注記 | 法的エンティティは通常、S/4HANA FI 会社コードに1:1でマッピングされます。SuccessFactors でネイティブに作成するか、S/4HANA からインバウンド同期できます。同期の方向はブループリントの決定事項です(1.2 参照) |
1.2 法的エンティティ設定パターン

法的エンティティは、購買伝票タイプのように固定のSAPタイプコードから選択されるわけではありません。しかし、すべての導入プロジェクトでは、本稼働前に2つの独立した次元を決定する必要があります。すなわち、レコードがどこでマスタ管理されるか、そしてそのエンティティが実際に従業員を雇用しているかどうかです。
| パターン | マーカー | ユースケース | 主要な動作 |
|---|---|---|---|
| S/4HANA同期済み法人 | 外部同期 | クライアントがS/4HANA/ECCでFI会社コードを既に運用している | 法人はS/4HANAからのインバウンド統合により作成・管理される。SuccessFactorsでの手動編集は通常制限されるか、次回同期実行時に上書きされる |
| SuccessFactorsネイティブ法人 | ネイティブ | 純クラウド型HR導入、またはHR目的のみで存在するエンティティ(例:FI対応のないHR共有サービス会社) | 法人はEmployee Central管理センターで直接作成・管理される。下流のFI依存関係はなし |
| 事業法人 | 事業 | 法人が直接従業員を雇用する | その法人に対して有効な雇用記録が存在する。給与の国/法グループ分けおよび法定報告を駆動する |
| 非事業/持株法人 | 持株 | 法人は企業/法務構造の完全性のためにのみ存在する(例:直接従業員数のない持株会社) | 選択リストで設定されるが、雇用記録で参照されることはほとんどない。組織図が実際の法務構造を反映するためにのみ使用される |
設計原則: 同期方向(S/4HANA同期 vs. SFネイティブ)は、ブループリント時に一度決定します。既存の法的エンティティを後からネイティブから同期に切り替えるには、データ整合性プロジェクトが必要です。なぜなら、外部コード/会社コードのマッピングが、今後システム・オブ・レコードのキーとなるからです。
1.3 組織レベルとデータ階層

具体的な例を用いたデータ階層
Client (SuccessFactors Instance)
│
└── Legal Entity "LE_JP01" — Japan Legal Entity, Company Code JP01
│
├── Business Unit "BU_Sales" — Sales HQ, of LE_JP01
│ │
│ └── Division "DIV_East" — East Japan, of BU_Sales
│ │
│ └── Department "DEPT_S01" — Sales Team 1, of DIV_East
│ │
│ └── Cost Center "CC_1000" — Sales cost center, of DEPT_S01
│
└── (external sync) ──> S/4HANA FI Company Code "JP01"
Location "LOC_TKY01" — Tokyo HQ, Asia/Tokyo TZ
(independent tenant-level master — not nested under Legal Entity)
Employment "EMP_000001" (Employee Central) ── assigned to ──> Legal Entity "LE_JP01"
(every hire's Employment record references exactly one Legal Entity as legal employer)設計原則: 法人 → 事業単位 → 事業部門 → 部門 → 原価センタは、厳格な単一親チェーンです。法人より下位のすべてのオブジェクトは、最上位の1つの法人に解決されなければならず、エンティティ間の共有は許可されません。
1.4 他のマスタデータオブジェクトとの統合

法的実体は単独で存在するわけではありません。それは、他のすべての組織オブジェクトおよび従業員データオブジェクトが、直接的または間接的に最終的に参照するアンカーです。
| オブジェクト | 関係性 | 実務上の注意点 |
|---|---|---|
| ビジネスユニット | 直接の子 (1:N) — すべてのビジネスユニットは、必ず1つの法的エンティティに属する | ビジネスユニットが有効な場合、法的エンティティの下で最初で唯一の必須ステップ。ビジネスユニットを使用しない場合、事業部/部門は1階層上のレベルにアタッチされる |
| 雇用 | 雇用レコードは法的エンティティを法的雇用者として参照する | 法定報告グループを決定し、Employee Central Payroll 導入環境では、従業員の給与国グループ化を決定する |
| S/4HANA FI 会社コード | 外部同期ソース/ターゲット — 法的エンティティは通常、S/4HANA 会社コードと1:1でミラーリングされる | HRの法的エンティティ構造をFI会社コードと整合させ、これは人員コスト配分や連結法定報告に影響する |
| ロケーション | 独立したテナントレベルのマスタで、同じ従業員に頻繁に相互参照される | 従業員は通常、法的エンティティ(雇用経由)とロケーション(職務情報経由)の両方が割り当てられる。この2つのディメンションは別々に管理され、「誰がこの人を雇用しているか」と「どこで物理的に働いているか」という異なる質問に答える |
| 原価センタ | 間接的 — ビジネスユニット → 事業部 → 部門 → 原価センタのチェーン経由 | 法的エンティティは原価センタを直接所有しないが、すべての原価センタは最終的に組織階層を通じて1つの法的エンティティにロールアップされる。これは、法的エンティティ別にセグメント化された人員コストレポートを作成する際に関連する |
パート 2: SF 固有のフィールド詳細
2.0 SFの所有範囲

| データセクション | SF関与 | 備考 |
|---|---|---|
| 基本識別情報 | ◎ オーナー | 外部コード、名称、有効開始日 |
| 会社・国割当 | ◎ オーナー | 会社コード、国/地域 |
| 通貨・レポートデフォルト | ◎ オーナー | 報酬および予算デフォルトに使用されるデフォルト通貨 |
| ステータス・ライフサイクル | ◎ オーナー | アクティブ/非アクティブステータス、有効日付による変更履歴 |
| S/4HANA 会社コード統合 | ○ FI/ベーシスと共有 | 外部コードマッピング、同期方向、同期頻度 |
凡例: ◎ = オーナー / クリティカル、○ = 直接関与
2.1 コア識別

Core Identification(コア識別)は、法的エンティティが存在するために最低限必要なレコードです。他のすべてのファンデーションオブジェクトが法的エンティティを「上位」参照する際に参照するものです。
| フィールド | 説明 | 実務上の使用 |
|---|---|---|
| 外部コード | 法的エンティティの一意識別子 | 下流のすべての参照(ビジネスユニット、雇用、統合ペイロード)が指すキー値。統合チームと一度決定する必要があります。稼働後に変更すると、古い値にキー設定されたミドルウェアマッピングがすべて壊れます。 |
| 名称 | 法的エンティティの表示名 | グローバルインスタンスでは言語パックごとにローカライズ可能。同期時にFI会社コードのショートテキストと命名規則を統一し、HR部門と財務部門がシステム間で同じエンティティを認識できるようにします。 |
| 有効開始日 | このバージョンのレコードが有効になる日付 | すべてのフィールド変更は上書きではなく、新しい有効日付行として記録されます。これにより、特定日付時点の組織図クエリで過去の構造を再構築できます。監査や年度末レポートに不可欠です。 |
| 有効日付履歴 | この法的エンティティレコードの以前のバージョンの連鎖 | 「日付Xにおけるこのエンティティのステータス/名称/通貨は何か」という質問に答えるために使用されます。コンサルタントは履歴行を削除せず、新しい有効日付エントリで前方修正する必要があります。 |
2.2 会社コードと国割当

このセクションは、法的エンティティレコードを、それが活動する法令/規制のコンテキストに結び付け、S/4HANA に対して最も頻繁に照合されるフィールドペアです。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| 会社コード | 会社/法的エンティティコード。通常、S/4HANA FIの会社コードを反映します。 | S/4HANA同期デプロイメントにおいて最も重要な統合フィールドです。ブループリント作成時に、このフィールドがS/4HANAからの受信専用か、ネイティブに管理されるかを確認してください。両方を混在させると、更新の競合が発生します。 |
| 国/地域 | 登録上の法定国 | この法的エンティティに割り当てられた従業員に適用される、国固有のEmployee Centralビジネスルール、ピックリスト、および(Employee Central Payrollデプロイメントの場合)給与国グループを決定します。 |
2.3 通貨とレポートのデフォルト設定

法人格レベルで設定された通貨は、その下位に割り当てられた報酬、予算、レポーティングオブジェクトのフォールバックデフォルトとなります。ただし、階層の下位で上書きされた場合は除きます。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| デフォルト通貨 | 法人の基準通貨 | この法人に属する従業員/部門の報酬情報および予算レコードにおけるデフォルト通貨の提案として使用されます。複数国対応のインスタンスでは、部門レベルまたは雇用レベルで現地通貨への上書きが必要かどうかを報酬チームと確認してください。 |
2.4 ステータスとライフサイクル

ステータスは、法的エンティティが新しい割当に利用可能かどうかを制御します。このセクションでは、コンサルタントがエンティティの閉鎖、合併、および再編成を処理します。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| ステータス | 有効/無効フラグ | 法人を無効に設定しても、既存の雇用記録は終了されません。新しいレコードで今後その法人が選択できなくなるだけです。無効化は、管理者がシステム上で変更を行った日付ではなく、実際の法的閉鎖/合併日に合わせて有効日付を設定する必要があります。 |
| 無効化の影響 | 無効な法人の下流への影響 | 無効化する前に、その法人を指している事業部門、部門、または未処理の雇用記録がないか確認してください。M&Aや再編のシナリオでは、これらを先に存続法人に付け替える必要があります。 |
2.5 S/4HANA 会社コード統合

S/4HANA FI と SuccessFactors Employee Central を併用しているお客様の場合、法人(Legal Entity)が通常、両システム間で調整される最初のファンデーションオブジェクトとなります。これは、会社コードが FI 転記の必須前提条件であるためです。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| 外部コードマッピング | SuccessFactorsの外部コードとS/4HANAの会社コード値との相互参照 | ブループリント時に、2つのコードが同一の文字列か、明示的なマッピングテーブルが必要かを確認する。値が同一であれば、下流のすべての統合(給与計算、原価配賦、レポーティング)が大幅に簡素化される。 |
| 同期方向 | S/4HANAがマスタシステム(SFへのインバウンド)か、SuccessFactorsがマスタシステム(S/4HANAへのアウトバウンド)か | ほとんどの導入プロジェクトでは、法定エンティティの作成は人事主導ではなく財務主導のイベントであるため、S/4HANA FIを会社コード/法人のマスタシステムとして扱う。両方のチームが同じエンティティを独立して管理しないよう、所有権を明確に確認する。 |
| 同期頻度 | バッチ(スケジュール) vs. ニアリアルタイムレプリケーション | 通常、SAP提供の統合コンテンツ(例:Employee CentralからS/4HANAへのマスタデータレプリケーション)またはカスタムミドルウェアを介して提供される。バッチ同期のみの場合、新しく作成されたS/4HANA会社コードはEmployee Centralですぐに使用できない。本番移行時には、同期スケジュールに合わせて採用日を計画する。 |
次に読むべきもの
L1) Big Picture
| ID | Category | Title |
|---|---|---|
| sf-001 | Overview | SAP SuccessFactorsとは何ですか? |
L2-A) Master Data
| ID | Category | Title |
|---|---|---|
| sf-a01 | Overview | SAP SuccessFactors マスタデータ:概要、階層、関係性 |
| sf-a02-01 | Master Data | SAP SF 法人 📍 |
| sf-a02-02 | Master Data | SAP SF ビジネスユニット |
| sf-a02-03 | Master Data | SAP SF 事業部門 |
| sf-a02-04 | Master Data | SAP SF 部門 |
| sf-a02-05 | Master Data | SAP SF 原価センタ |
| sf-a02-06 | Master Data | SAP SF ロケーション |
| sf-a02-07 | Master Data | SAP SF ジョブファミリー |
| sf-a02-08 | Master Data | SAP SF ジョブコード |
| sf-a02-09 | Master Data | SAP SF 給与グレード |
| sf-a02-10 | Master Data | SAP SF ポジション |
| sf-a03-01 | Master Data | SAP SF 権限グループ |
| sf-a03-02 | Master Data | SAP SF 権限ロール |
| sf-a03-03 | Master Data | SAP SF 休日カレンダー |
| sf-a03-04 | Master Data | SAP SF 勤務スケジュール |
| sf-a03-05 | Master Data | SAP SF タイムタイプ |
| sf-a03-06 | Master Data | SAP SF 時間プロファイル |
| sf-a03-07 | Master Data | SAP SF 評価尺度 |
| sf-a03-08 | Master Data | SAP SF 目標計画テンプレート |
| sf-a03-09 | Master Data | SAP SF パフォーマンスフォームテンプレート |
| sf-a03-10 | Master Data | SAP SF ルートマップ |
| sf-a03-11 | Master Data | SAP SF 報酬計画 |
| sf-a04-01 | Master Data | SAP SF 担当者 |
| sf-a04-02 | Master Data | SAP SF エンプロイメント |
| sf-a04-03 | Master Data | SAP SF 従業員プロファイル |
L2-B) Transaction
| ID | Category | Title |
|---|---|---|
| sf-b01 | Overview | SAP SuccessFactors トランザクション:プロセスフロー、階層、関係性 |