Location master data should be the easiest domain in the catalog. A company has a countable number of physical places: sites, plants, warehouses, stores, offices. The whole list rarely runs past a few hundred records, it changes a handful of times a year, and everyone can agree that a building either exists or it does not. Yet I keep meeting companies with twelve physical sites, sixteen plants in the ERP, nineteen warehouses in the WMS, and a BI analyst maintaining the spreadsheet that maps them onto each other.
That spreadsheet is the tell. Locations sit under more processes than almost any other domain, and nobody governs them, because every system arrived with its own location concept already built in.
Every system ships with its own location list
The ERP has plants, storage locations, and shipping points. The WMS has warehouses and zones. The transport system has ship-from codes that the carrier dictated. HR records a work location per employee, and finance has cost centers that secretly encode buildings. None of these modules were designed to share a list, so each one grew its own, and each list drifted in its own direction.
Nobody notices until something has to join across them. And a lot of things have to join across them:
Each of those needs to know which physical place a record points at. When four systems hold four codes for the same building, that question has no reliable answer, and every consumer either builds its own mapping or picks one system and hopes.
Where it actually breaks
Four failures cover most of what goes wrong in this domain. Each looks like an operations mishap when it happens. Each is a data problem that was sitting there for years first.
The warehouse with four names
The ERP calls it PLNT-0400. The WMS calls it AMS-DC1. The carrier integration knows it as NLAMS04, and finance books its costs against CC-4410. The BI team cannot join any of these, so one analyst keeps a mapping spreadsheet on a shared drive. It works until she changes jobs.
The site that closed but kept receiving
A distribution center closes in March. Someone flags it inactive in the ERP. The transport system never hears about it, so replenishment orders keep routing there for six more weeks. The first signal anyone gets is a carrier calling about pallets at a locked gate.
The rollup with two EMEAs
Finance counts the UK sites in EMEA. The supply chain network model puts them in a separate region. Two dashboards, both labelled EMEA, disagree by eleven percent, and leadership spends part of every quarterly review arguing about which one is wrong. Neither is. They are different rollups wearing the same name.
The move that changed the tax
A warehouse relocates forty kilometers, across a jurisdiction boundary. Someone updates the ERP address the same week. The tax engine and the carrier contracts read older copies, so invoices carry the wrong VAT treatment for a quarter. The correction costs more than governing the location list for a decade would have.
One list of places, more than one way to roll them up
The instinct, once a team decides to fix this, is to build the one true location hierarchy. There is no such thing. Finance rolls sites into legal entities and regions. Supply chain rolls the same sites into a distribution network. Facilities thinks in buildings and floors. Same leaves, different trees, and the EMEA story above is what happens when two of those trees borrow each other's names.
The workable shape is one flat, governed list of physical places with stable identifiers, plus a separate parent reference for each rollup that consumers need. MDS users solved this with derived hierarchies built from domain attributes, and whatever replaces MDS needs the same separation: the list of places is master data, the rollups are views over it.
What to actually govern
Like the employee domain, this is a small model. One entity, a dozen attributes, two or three reference lists:
One identifier per physical place
Not the ERP plant code. Those encode decisions from an implementation fifteen years ago, and they will not survive the next ERP. A neutral key that persists through renames, re-organizations, and system swaps.
Type and lifecycle status with effective dates
Planned, open, closing, closed. The closing date is the one that matters: it has to reach every system that routes goods or people before the gate is locked, not after.
Address and jurisdiction as governed attributes
Street address, and country as a reference to your governed country list rather than free text. Add tax jurisdiction where it drives invoicing. This is the slice the failure stories above all run through.
One parent reference per rollup
An operational parent for site, building, zone. A separate finance region. A separate network assignment if supply chain needs one. Three small attributes beat one overloaded hierarchy that three departments fight over.
A cross-reference for every local code
PLNT-0400, AMS-DC1, NLAMS04, and CC-4410 all map to one governed record. The mapping spreadsheet finally gets a home with an owner, an approval step, and an audit trail.
The country reference comes straight from your governed reference data, and the local-code mapping is a textbook cross-reference table. Nothing here is exotic. The domain stays ungoverned because every department assumes its own system's list is the real one.
At a few hundred records and a few changes a month, locations are the cheapest domain in the multi-domain lineup to govern, and one of the better candidates for a first domain: small enough to load in a week, referenced widely enough that people notice the improvement.
Common questions
What is location master data?
The governed list of your physical places: sites, plants, warehouses, stores, offices. Each carries a stable ID, type, lifecycle status, address, and hierarchy. It rarely exceeds a few hundred records, and it is referenced by inventory, shipping, tax, HR, and nearly every report with a regional axis.
Why not just manage locations in the ERP?
The ERP governs its own plants and storage locations well, but the WMS, TMS, HR system, and BI platform never read those tables. Each keeps its own list. A governed location entity distributes one consistent list to all of them, and the ERP code becomes one cross-reference among several.
How many hierarchy levels do locations need?
As few as consumers need. Site, building, zone covers most operational cases. Finance regions and network assignments belong in separate parent attributes, not in extra levels of one deep tree.
Is this the same as address validation?
No. Address validation proves a string is deliverable. Location master data decides which places exist, what they are called, and how they roll up. Every address can validate perfectly while the same warehouse still lives in your systems under four different codes.
One list of places, governed
In Primentra, locations are a hierarchical entity: the sample model ships with branches, areas, and zones. Domain attributes point at your country and region lists, an approval step sits in front of every change, and each edit lands in the audit trail. Downstream systems read the governed list through integration views or the REST API. It runs on your SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial includes everything.