JinJin48

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

July 19, 2026 · 14 min read

SAP SF ロケーション

Location（ロケーション）は、SuccessFactors Employee Central における物理的/地理的な勤務場所のマスタデータオブジェクトであり、フェーズ1（組織・ジョブ基盤）において、法的エンティティ → 事業部 → 部門 → 部署 → 原価センタというチェーンと共に設定されます。しかし、このチェーンからは意図的に外れており、組織が運営するすべての物理的拠点の住所、タイムゾーン、休日カレンダー割り当てを記述する、独立した横断的な基盤オブジェクトとして、ポジションおよびジョブ情報が直接参照します。この記事では、Location とは何か、その横断的な位置づけが組織階層チェーンとどのように異なるのか、そして Employee Central コンサルタントが設定するすべてのフィールドについて説明します。

第1部: ロケーション — 中核概念（全モジュール）#

1.1 ロケーションとは#

ロケーションは、物理的または地理的な作業拠点（オフィス、プラント、倉庫、リモートワーク指定など）を、その拠点に対してスケジュールまたは報告されるすべてのものに依存する住所、タイムゾーン、および休日カレンダーと結び付けるマスタデータオブジェクトです。部署が「どのチームか」に答えるのに対し、ロケーションは「どの物理的な場所か」に答えるものであり、この2つは意図的に独立しています。単一の部署の従業員が複数のロケーションにまたがって勤務することもでき、単一のロケーションに多くの異なる部署の従業員が所属することもできます。

1.2 ロケーションタイプ#

Location Typeは、Legal Entityの国やCost Centerのカテゴリのような構造コードではありません。これは、クライアントがレポートを区分し、特定のサイトがどの休日カレンダーや施設パターンを保持すべきかを示すために設定する、記述的な分類です。タイプを誤ると、主にレポートの明確さを損なうことになり、データモデルが破損するわけではありませんが、ブループリント時点で一貫して決定しておく価値はあります。

設計原則: ロケーションタイプは動作スイッチではなく、説明的なメタデータです。データモデル内でロケーションレコードの機能を変更するものではありませんが、ロケーションが保持すべき休日カレンダーとレポートセグメントを決定します。そのため、タイプリストは短く保ち、すべてのロケーションで一貫して適用してください。

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

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

Client (SuccessFactors Instance)
   │
   ├── Legal Entity "LE_JP01" ── Business Unit ── Division ── Department ── Cost Center
   │      (organizational hierarchy chain — see SF-A02-01 through SF-A02-05)
   │
   └── Location "LOC_TKY01" — Tokyo HQ, Asia/Tokyo TZ
          (independent tenant-level master — not a level in the chain above)
          │
          ├── assigned to ──> Location Group "LG_JP" — Japan Locations (grouping/classification)
          ├── assigned to ──> Holiday Calendar "HC_JP2024" — Japan 2024 holidays
          └── referenced by <── Position "POS_SalesMgr01" — Sales Manager (default work location)

設計原則: ロケーションは、法人 → 事業部 → 部門 → 部署 → 原価センタというチェーンの中に位置づけられるものではありません。これは独立した横断的なファンデーションオブジェクトであり、ポジションとジョブ情報が従業員が所属する部署や原価センタとは無関係に直接参照します。共有の地域オフィスなどの単一のロケーションは、多くの異なる部署や原価センタに所属する従業員によって同時に参照されるのが一般的です。

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

Locationは組織階層のチェーン外に位置するため、他のマスタデータとの関係はすべて親子階層リンクではなく直接参照となります。つまり、下位のすべてのオブジェクトがLocationを指すか、Locationがそれらを指す形で、中間レベルは存在しません。

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

2.0 SFの所有範囲#

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

2.1 コア識別#

Core Identificationは、ロケーションが存在するために必要な最小限のレコードであり、すべてのポジション、ジョブ情報オーバーライド、およびロケーショングループの参照が指し示すものです。

2.2 住所と地理#

住所 & 地理フィールドは物理的な拠点そのものを表し、法定報告、施設/メールルーティング、およびPeople Analytics上に構築される位置情報ベースのダッシュボードにデータを提供します。

2.3 タイムゾーンと休日カレンダー#

これらのフィールドにより、ロケーションはコンサルタントが一度だけ設定するサイトとなり、承認、通知、未払金計算など、下流のすべての時間関連プロセスが間接的に参照することになります。

2.4 ロケーショングループと分類#

Location Group（ロケーショングループ）とLocation Type（ロケーションタイプ）は、コンサルタントが大規模なロケーションリストをレポートや選択リストで利用可能にするために設定する2つの分類軸であり、組織階層チェーンに依存しません。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction