How portal data is organised

Overview

The PartLogic portal organises product information in three linked levels. At the top is a single master record with governed identifiers and attributes. Beneath it sit one or more Sites—each representing a physical location such as a factory—and under each Site, one or more Devices or store rooms where stock is held and local naming applies.

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 uses Site and Device (matching pricing and API terminology). In some portal screens the Site level appears as Customer—for example the Edit Site Details dialog. Both refer to the same middle tier in the hierarchy.

The three levels

Sites & devices in pricing: subscription plans use the same terms—sites and devices (see pricing). A Device or Store Room is the warehouse level under each Site.

Master

The master level holds your organisation's primary product definition—the fields you want consistent everywhere:

• 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.

Site (Customer)

The 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 Site level you typically see a Part Id, Stock Code (aligned with the master PartLogic number), Part Name, and Part Alias for labels that differ from the governed master fields. 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 / store room

The lowest level is labelled Device or Store Room in the portal—both refer to a warehouse or stock location within a Site. This is where teams often enter local terms (nicknames, legacy codes, bin labels) to match how people talk on the floor, without overwriting the master 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 / store room records in the portal.

How records link together

Think of the hierarchy as a tree anchored on one master row:

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

Example: one master line for a bearing with a fixed GTIN and PartLogic SKU. Factory A's main warehouse might use local code BRG-12A; Factory B's stores might use STORES/4421. Both devices still point at the same master record, 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