JinJin48

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

July 15, 2026 · 10 min read

SAP FSM Address

Address is FSM’s master record for a physical location associated with a Business Partner (Customer) — the registered billing site, the location where Equipment is installed, or any other site a technician might be dispatched to. It is always a child record of a Business Partner: a single Business Partner can carry any number of Address records, each distinguished by Address Type and resolved to a geolocation for routing, and Address itself has no further sub-objects of its own. This article maps every field FSM consultants configure and maintain when creating an Address record, and how those fields connect Address back to the Business Partner and Contact masters that sit alongside it in Phase 1 (Customer Management), and forward to Equipment in Phase 2.

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

1.1 What Is Address?#

Address represents a specific physical location tied to a customer — not the customer organization itself (that is Business Partner), and not a named individual (that is Contact). It exists so that FSM always has a geocoded, resolvable location on file whenever a technician needs to be routed somewhere, or whenever billing/correspondence needs a mailing site, rather than relying on a single generic company address for every purpose.

1.2 Address Type#

A single Business Partner in FSM commonly has more than one Address on file — a billing office, a site where Equipment is installed, a warehouse dock for parts delivery. The Address Type field is what lets dispatchers and back-office staff tell these apart, and getting it wrong risks routing a technician to the wrong site or mailing an invoice to an empty lot.

Design principle: Address Type is a configurable field, not a fixed SAP-delivered picklist — a Business Partner with multiple physical sites should carry one Address record per site/purpose rather than overloading a single Address record with conflicting details.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example (Zone A · Customer Management — tenant-level; FSM has no Company Code / Plant scoping above Business Partner)

Client (FSM Tenant)
   │
   ├── Business Partner BP-001 — ABC Corp (Customer)
   │      │
   │      ├── Contact CT-A — Taro Tanaka, Facility Manager
   │      └── Address AD-A — 1-1 Marunouchi, Tokyo
   │
   └── Business Partner BP-002 — XYZ Ltd (Customer)
          │
          ├── Contact CT-B — Hiro Suzuki, Ops Lead
          └── Address AD-B — 2-2 Umeda, Osaka

Design principle: Address is a tenant-level (client-level) child record of Business Partner — there is no Company Code / Plant hierarchy involved. Address and Contact are siblings under the same Business Partner; they do not reference each other directly, they are simply both filed under the same parent.

1.4 Integration with Other Master Data Objects#

Address does not stand alone — it is filed under a Business Partner and is picked up whenever FSM’s other objects need a resolved, geocoded location.

Part 2: FSM-Specific Field Details#

2.0 Scope of FSM Ownership#

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

2.1 Core Identification & Business Partner Assignment#

These fields establish what this location is for and which Business Partner the Address record is filed under — every other field on Address only makes sense once these two are set.

2.2 Address Details#

These are the human-readable postal fields that form the actual mailing or site address — the raw input that geocoding (2.3) converts into a routable location.

2.3 Geolocation & Routing#

These fields are what actually make an Address usable for dispatch — Planning & Dispatching (FSM-B04) plans routes and estimates travel time from the coordinates here, not from the postal text alone.

2.4 Status & Access Notes#

These fields round out the Address record with lifecycle and practical on-site context that doesn’t fit cleanly into identification, address details, or geolocation.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction