JinJin48

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

July 8, 2026 · 8 min read

SAP Fieldglass Location

The Location is a dependent, optional master in SAP Fieldglass Company Structure — it exists only under an already-created Site and exists solely to add sub-building granularity (a floor, wing, or leased area) where a single Site record cannot carry enough address or tax-jurisdiction precision on its own. Unlike Site, Location is not required for every tenant: many single-building or single-jurisdiction implementations never create one. Where it is used, Location inherits its baseline attributes from the parent Site and lets an administrator override only the delta — typically address detail and tax code. This article maps Location’s core concepts across all Fieldglass capability areas (Part 1), then details every field an administrator configures when creating and maintaining Location records (Part 2).

Part 1: Location — Core Concepts (All Modules)#

1.1 What Is the Location?#

The Location represents a sub-unit of a Site — a specific floor, wing, or leased area within a building — used when the Site alone cannot express the address or tax distinction a client’s operations require. It is the second object created in the Phase 1 Company Structure setup sequence, and it has exactly one upstream dependency: it cannot exist without an already-active parent Site.

1.2 Location Scope Dimensions#

Like Site, Location does not carry a formal “Location Type” field — its influence shows up as a narrow set of override dimensions layered on top of what the parent Site already establishes. Getting the adoption decision wrong (creating Locations reflexively for every floor rather than only where jurisdiction or address genuinely diverges) is a common source of unnecessary admin overhead.

Design principle: Create a Location only when a Site’s granularity is materially insufficient — treating Location creation as a structural habit (one per floor, regardless of need) adds administrative overhead without adding compliance or reporting value.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Tenant "WorkingNet" (client-level scope)
│
├── Business Unit "BU-ENG" — Network Engineering
│      └── Business Unit "BU-NETDESIGN" — Network Design (child of BU-ENG)
│
├── Cost Center "CC-1001" — flat financial-tracking master (not hierarchical)
│
└── Site "SITE-CHI" — Chicago, US
       └── Location "LOC-CHI-01" — Chicago HQ Floor 3  ◄── this article

Location sits directly under Site, as its only child (1:N from Site) — it does not sit under Tenant directly, and it is not a sibling of Business Unit or Cost Center the way Site is. A Location has no further organizational children of its own: nothing nests underneath it. Business Unit and Cost Center, shown alongside Site in this same Zone A branch, are unrelated to Location’s own containment path; they attach to a requisition independently, as described in Section 1.4.

Every Location resolves to exactly one Site (N:1), and that Site must already be active before the Location can be created — there is no cross-zone reference from Location outward the way Site is itself referenced from Zone C’s Rate Grid. Location’s scope is fully contained within Zone A.

1.4 Integration with Other Master Data Objects#

The Location record’s relationships are narrower than Site’s — it exists to refine one parent, not to anchor a web of downstream objects.

Part 2: FG-Specific Field Details#

2.0 Scope of FG Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Basic Identification & Site Linkage#

These fields uniquely identify a Location and tie it to exactly one Site before it can be referenced anywhere downstream.

2.2 Address & Tax Configuration#

These two fields carry only the delta detail that distinguishes a Location from its parent Site — Location inherits the Site’s base address and tax jurisdiction by default.

Prerequisite: Site must exist and be Active before any Location can be created under it.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction