How portal data is organised

Overview

Every product begins with a Master Product and a unique PartLogic SKU. A Site can store its own site-level SKU, description and local product information against that Master Product. A stock location can then store an additional location SKU and location-specific information. These local identifiers do not replace the identifiers above them; they create a linked hierarchy from Master Product to Site to stock location.

The hierarchy is Master Product → Site → stock location. The structure is deliberately one-to-many: one primary product record connects to many sites and many warehouse locations, all sharing the same core data while allowing site-specific labels where your teams already work. If fragmented naming across ERP, WMS, and supplier catalogues is the underlying problem, start with Product identifier fragmentation.

Portal labels: documentation prefers Site and stock location. Some screens still show Customer Site / Customer, and stock locations as Device or Storeroom. Pricing plans also count sites and devices (see pricing).

The three levels

Pricing counts: subscription plans use sites and devices for the Site and stock-location tiers (see pricing).

Master Product

The Master Product level holds your organisation's primary product definition—the fields you want consistent everywhere. PartLogic automatically assigns a unique PartLogic SKU when the Master Product is created:

• PartLogic Part Number / SKU — your governed stock-keeping identifier in PartLogic
• GTIN — GS1 global trade identifier where available
• Attributes — descriptions, categories (GPC, UNSPSC, or custom), and other structured fields
• Manufacturer and supplier — names, part numbers, and sourcing references
• Sourcing information — how and where the item is procured

When you import or improve catalogue data, most of these fields belong at master level. See Good data practices and GTIN check & categories for preparation and validation workflows.

Customer Site

The Customer Site level marks a physical building or location—a factory, depot, hospital estate, or other place where the same Master Product may appear with site-specific context. In the portal UI this tier is sometimes labelled Customer (for example in Edit Site Details).

At Customer Site level you can store a Customer Site SKU, Part Name, and Part Alias while retaining a direct link to the Master Product. Portal dialogs may still show a Stock Code field label—treat that as the Customer Site SKU for that location. You might operate one master catalogue across several Sites so engineering, stores, and integrations all resolve to the same GTIN and PartLogic SKU while still knowing which site owns which stock and labels.

Device / Storeroom

The lowest level is labelled Device or Storeroom in the portal—both refer to a warehouse or stock location within a Customer Site. You can store a Device SKU, description, and local terms (nicknames, legacy codes, bin labels) while retaining a direct link to the Customer Site record, without overwriting the master PartLogic SKU or GTIN.

Stock quantities, min/max levels, pack size, and location-specific detail are typically scoped at this level. When you import a CSV, the Storeroom or Location columns in the import template often align with Device / Storeroom records in the portal.

How records link together

Think of the hierarchy as a tree anchored on one Master Product:

Master Product (1)
├── Customer Site — Factory A
│   ├── Device / Storeroom — Main warehouse
│   └── Device / Storeroom — Tool crib
└── Customer Site — Factory B
    └── Device / Storeroom — Central stores

Example: one Master Product for a bearing with a fixed GTIN and PartLogic SKU. Factory A's main warehouse might use Device SKU BRG-12A; Factory B's stores might use STORES/4421. Both devices still point at the same Master Product (via their Customer Site), so reporting and integrations see one product identity.

Local aliases vs master fields

PartLogic is designed to govern shared product data while preserving local aliases—site and channel names that map back to one master record. Device-level fields are for identification and operations at that location; master-level fields are what you want aligned across ERP, WMS, spreadsheets, and the Stock API.

PartLogic acts as a data mastering and integration layer above systems you already run—it does not replace every ERP or WMS, and teams should still review matches and imports where quality matters.

API and integrations

The Stock API returns rows per DeviceName (device or location). When you create an API key, you choose which devices the key may access—stock is filtered to those devices only. That permission model follows the same hierarchy: devices sit under Sites, all tied to master catalogue data.

• Portal API key — select devices when generating a key
• API Reference — authentication and stock response fields
• Glossary → Stock API fields — including DeviceName and SKU
• Zapier and Google Sheets — pull device-scoped stock into other tools