Common terms used in PMP.
Each term has two parts: the general definition, and how Part Manager Pro uses it.
Disassembly & intake
4 termsA category of operational software centered around the controlled disassembly of complex objects into trackable, reusable, serviceable, or sellable components. SDM systems preserve and manage the relationships between source objects, extracted parts, inventory locations, compatibility data, operational workflows, and downstream sales channels. The category combines inventory operations, compatibility mapping, workflow management, and product information management for teardown, repair, refurbishment, recovery, and resale operations.
In PMP, SDM is the core system model: every operational surface — catalog, ledger, scanner workflows, inventory movement, compatibility mapping, and marketplace synchronization — is organized around the disassembly workflow as the primary unit of work. PMP formalizes and operationalizes the SDM category as a dedicated software discipline.
The end-to-end sequence of recording a unit being taken apart and the parts that result from it: receive the unit, tear it down, capture each part, build cross-references, shelve, list, sell, pick, ship.
In PMP, the disassembly workflow is the spine of the platform. Each step writes to the ledger; the audit trail follows the object from intake to shipment, so the history of any part is always linked back to the unit it came out of.
The act of taking a unit apart to capture its individual parts as inventory — common in dismantling, refurbishment, electronics repair, and salvage operations.
In PMP, teardown is the starting move of the disassembly workflow. The system records the donor unit, then the parts captured from it, then the locations they land in — every part traces back to the unit it came out of.
A vehicle, appliance, or piece of equipment received specifically to be taken apart, with its parts going into inventory for resale or repair use.
In PMP, donor units are first-class records with their own audit history. The catalog cross-references every part back to the donor unit it came from — useful for warranty, returns, and verifying fitment against the source unit.
Catalog & cross-reference
10 termsA category of software focused on managing product records — names, attributes, images, descriptions — and syndicating them out to sales channels. PIM systems start with "here is a product."
In PMP, PIM capabilities are integrated into the platform but they're downstream of the disassembly workflow. PMP starts with the object moving through real operations, not with a product record that already exists. PMP has PIM capabilities; PMP is not, in itself, a PIM.
A structured record of the parts an operation handles, organized into sections, categories, and types so similar parts share fields, behavior, and search structure.
In PMP, the catalog is what you build as you work — every part you record on a teardown becomes a catalog entry tied to the donor unit, the location it landed in, and the source assemblies it fits. The catalog is yours; export it to CSV anytime.
Stock Keeping Unit — a unique identifier for a specific product or part, used to track and reference inventory across systems.
In PMP, each SKU is normalized (whitespace trimmed, case enforced) and unique per account. SKUs drive every join in the system — they're how part records find their locations, their listings, their orders, and their audit history.
The vehicle, appliance, or piece of equipment a part fits or was pulled from — captured as a normalized record of its year, make, model, trim, engine, and other fitment attributes. The thing a part "fits."
In PMP, source assemblies are stored as structured data, not free text. A single part links to every source assembly it fits; a single source assembly links to every part that fits it. This is the engine behind Part ↔ Source Assembly cross-reference.
A search pattern where the relationship between two record types is queryable in either direction — given one side, you can list all of the other side, and vice versa.
In PMP, the Part ↔ Source Assembly cross-reference is the named capability of the catalog. Search a source assembly and see every part that fits it; open a part and see every source assembly it fits. The relationship is structured data — no manual tag maintenance.
The set of vehicles, appliances, or equipment a part is verified to install on. Expressed as a combination of year, make, model, trim, and option attributes.
In PMP, fitment is captured as links between parts and source assemblies — not as free-text strings. Cross-references come from the teardowns you record and the fitments you verify yourself.
A structured list of every component, sub-assembly, and part that goes into a finished product, showing how they relate. A multi-level (indented) BOM shows the parent-child hierarchy: parts roll up into sub-assemblies, which roll up into the next higher assembly, up to the top-level product.
PMP isn't a manufacturing BOM tool, but it models the same parent-child idea: a part belongs to the source assemblies it fits, and the Part ↔ Source Assembly cross-reference lets you look it up either direction — every part in an assembly, or every assembly a part fits.
In a multi-level bill of materials, the assembly directly above a component — the parent it gets installed into. The hierarchy runs parts → sub-assembly → next higher assembly → top-level assembly. A standard term in aerospace, automotive, and manufacturing BOMs.
It's the same parent/child relationship the Part ↔ Source Assembly cross-reference models: a source assembly is a part's next higher assembly. PMP lets you trace it both ways — find every part in an assembly, or every assembly a part fits.
The discipline of designing part numbers before going live in a system: prefix conventions, length, character set, reservation patterns, and how SKUs encode (or refuse to encode) meaning.
In PMP, the SKU strategy guide walks through the trade-offs and the conventions we recommend. It's the call you make once and live with forever — PMP enforces uniqueness and normalization, but the structure itself is yours to define.
The process of standardizing a value before storing or comparing it — trimming whitespace, enforcing case, removing invisible characters — so equivalent inputs compare as equal.
In PMP, normalization runs on every SKU, location code, and identifier as it's entered or imported. "ABC-123 " and "abc-123" become the same SKU before they hit storage — preventing duplicate records that look different to a human but identical to the system.
Inventory & warehouse
10 termsA category of software focused on receiving, putaway, picking, and shipping for SKUs that already exist as catalog records. WMS starts with "here is a box in a bin."
In PMP, WMS functions — locations, scanner-first picking, batch fulfillment — are one band of a wider system. They operate on the catalog the disassembly workflow built, rather than on records that arrived from somewhere else.
The count of a part that's actually orderable right now — total on hand minus anything held back by reservations, allocations, or holds.
In PMP, available quantity is computed from the snapshot minus active reservations. Marketplace listings push from available quantity, not from raw on-hand — so a part already reserved for one buyer can't be promised to another.
A per-part threshold that flags a part when its on-hand quantity drops to a level you set, so you can restock before you run out.
In PMP, you set the threshold per part; when the count reaches it, the part is flagged. The trigger reads the same ledger-backed counts the rest of the system uses, so the flag reflects real stock.
A scheduled or ad-hoc recount of stock for a specific subset of inventory — a location, a section, a category — rather than a full warehouse-wide count.
In PMP, cycle counts open a count session against the chosen scope; pickers scan and confirm; any differences write inventory adjustments to the ledger with the actor and reason recorded.
A correction to a count that's outside the normal add/remove/transfer flow — a damaged part written off, a recount difference, a found unit added back.
In PMP, every adjustment is a ledger entry with a required reason and an attributed actor. Adjustments never bypass history — they're part of it.
A targeted, frequent recount of the parts that sell or move the most — the inventory most likely to drift between physical count and recorded count.
In PMP, high-turn checks are surfaced from sales velocity data so the cycle-count rotation focuses where it matters. Same flow as a cycle count; different selection.
A temporary hold placed on stock to prevent it from being promised to more than one buyer or process at the same time.
In PMP, reservations are written when an order allocates a part. Available quantity drops accordingly. If the order is cancelled before pick, the reservation releases back to available; if picked, the reservation converts to an outbound ledger entry.
The accumulated difference between two records of the same thing that have diverged over time without anyone noticing — physical count vs. recorded count, or one system's view vs. another's.
In PMP, drift surfaces in two places: cycle counts (physical vs. recorded), and listing coverage (PMP's quantity vs. what a marketplace shows). Both are visible inside PMP, so you can act on a difference rather than discover it from outside.
A defined physical place a part can be stored — an aisle, a section, a shelf, a slot — identified by a code that humans and scanners can both read.
In PMP, every part is assigned to a location, and every location gets a printed barcode label. The location code is what the picker scans first; PMP confirms it matches the assigned location for the part being picked.
A structured identifier for a storage location — often a hierarchical code like G-02-07-03 (aisle-section-shelf-slot) — printed on a label and used to identify a specific spot in the warehouse.
In PMP, location codes are the addressable unit of storage. PMP prints them as scannable labels and validates them on every pick — scan the wrong location, the screen tells you before you reach for the part.
Ledger & audit
11 termsA category of software that runs a company's core business processes — accounting, procurement, HR, inventory, and reporting — from one shared database. An ERP starts with the transaction.
In PMP, ERP-style functions like accounting and procurement live outside the system. PMP is the operational record for the parts — catalog, inventory, fitment, fulfillment — and exports clean data to the finance tools you already run. PMP is not, in itself, an ERP.
A permanent, append-only record of events. New entries are added; existing entries are not modified or deleted. The full record is authoritative; any current state is derived from it.
In PMP, the ledger records every inventory event — receive, transfer, pick, pack, adjust — with the actor, timestamp, quantity delta, and reason. Counts are a cache built from the ledger; the ledger itself is the record.
A cached or materialized view of current state, derived from an underlying record of events. Fast to read; not the system of record.
In PMP, the snapshot is the current-count table. It's rebuildable from the ledger at any time. When a count looks wrong, the answer is always in the ledger — the snapshot just reflects what the ledger says.
The system or record set that a workflow treats as authoritative for a given piece of data — the place to look when two systems disagree.
In PMP, the system of record for inventory, parts, and orders is PMP itself. Marketplace mirrors feed in as inputs; outbound updates from PMP are deliberate actions, never invisible side-effects. That's why connecting a marketplace doesn't silently overwrite what you've recorded.
A record of every change made to data in a system — what changed, when, by whom — kept for compliance, investigation, and reconstruction.
In PMP, the audit log captures field-level changes for every record: the field name, the previous value, the new value, the actor, and the timestamp. It's available for every record you can edit.
A single entry in an audit log — one specific change at one specific moment by one specific actor.
In PMP, every activity record is attributable. There's no "system did this" entry without a process name; there's no anonymous edit. If something changed, PMP can show you what, when, and by whom.
A label attached to an event indicating where it originated — which system, which user, which channel, which import.
In PMP, every ledger entry and activity record carries a source tag. Scanner-driven pick? Tagged. CSV import? Tagged with the import batch ID. Marketplace webhook? Tagged with the channel. Source tags make audit lookups much faster.
The authenticated identity credited with making a change — a user, a service account, or a named background process.
In PMP, every write carries an actor. Pickers, managers, and admins are real users; sync jobs and imports are named system actors. Nothing happens anonymously.
A step in a bulk-import workflow that parses an uploaded file, shows what each row will do (create, update, skip, error), and waits for confirmation before applying.
In PMP, CSV preview is required for every bulk import. Errors are highlighted up front (capped at 50 in the preview for review); modes include create-only, update-only, upsert, and replace. Nothing writes until you confirm.
A private workspace inside a software service — separate data, separate users, separate billing — so one customer's records don't mix with another's.
In PMP, every customer has their own account. Your inventory, team, marketplace connections, and history are kept separate from every other account.
A permissions model where each user is assigned a role (admin, manager, picker, read-only, etc.) and the system grants permissions based on that role rather than per-user.
In PMP, role-based access governs what each team member can see and do. Pickers see the picking surface; managers see workflow and reports; admins see billing and account settings. Switching a user's role updates their interface immediately.
Marketplace sync
12 termsThe action of updating a marketplace listing's available count from an internal inventory system — sending the new number out so the channel reflects current stock.
In PMP, quantity push fires when available quantity changes — order allocation, pick, adjustment. The push is idempotent: repeating the same update is safe; nothing double-counts.
A sync operation that reads or writes the entire dataset between two systems — used to seed a new connection or recover from a known divergence.
In PMP, full sync is a deliberate operation, not the default. The default mode is delta sync (only what changed). Full sync is available when you connect a new marketplace or after a known incident.
A sync operation that transfers only what has changed since the last successful sync — much faster than a full sync, but it relies on a reliable bookmark to know where the last sync left off.
In PMP, delta sync is the default mode for marketplace integrations. The bookmark is the marker of the last successful sync; everything modified after that point is in the next pass.
A saved point inside a stream of events that says "everything before here has been handled." The next pass picks up from the bookmark instead of starting over.
In PMP, every marketplace integration carries a bookmark per sync direction. The delta sync reads everything since the bookmark, processes it, and advances the bookmark only when the batch commits successfully. This is the customer-facing name for what sync engineering literature calls a "watermark."
In sync engineering, a marker tracking the last successfully processed point in a stream of events — so the next pass picks up from there instead of starting over. Common term in technical documentation.
In PMP, the customer-facing name for this concept is Bookmark. The two terms describe the same thing; we use Bookmark across the product and the marketing site because it's the clearer word for what it does.
A minimum interval enforced between two operations of the same kind — to prevent overwhelming a third-party API, hitting a rate limit, or compounding a known race condition.
In PMP, cooldowns govern outbound writes to marketplace APIs. If a listing was updated five seconds ago and the count changes again, the next push respects the cooldown rather than firing immediately.
A local, read-only copy of data owned by another system — kept up to date through sync — so the internal system can read it directly instead of asking the source every time.
In PMP, marketplace mirrors hold listings, orders, and statuses as PMP saw them at last sync. PMP's authoritative records are computed from operations, not from the mirror; the mirror is input to processing, never output.
A read-only summary of how well a set of marketplace listings line up with the inventory that should back them — specifically, whether the stock you have matches the stock the marketplace shows.
In PMP, Listing coverage surfaces inside the Marketplace hub. It flags listings where the marketplace quantity differs from PMP's quantity, and listings that don't have a SKU mapping back to a part record — so you can act on the gap inside the same workflow.
The link between an internal part record and one or more external listings — typically by SKU — so that updates to one can be reflected in the other.
In PMP, SKU mapping is the hinge for every sync action. A part with no SKU mapping doesn't push; a part with multiple mappings pushes to each of them. Mappings are explicit and visible in the listing coverage view.
A way for one system to notify another that something has changed — a small HTTP callback sent in real time, as opposed to the receiver polling on a schedule.
In PMP, marketplace webhooks (order created, listing updated, etc.) feed the delta sync and can shorten the latency between a marketplace event and PMP reacting. PMP also runs scheduled delta syncs as a backstop in case a webhook is missed.
The background subsystem of an application that runs scheduled and event-driven jobs — imports, syncs, reports, cleanups — without a human triggering each one.
In PMP, the automation engine handles recurring marketplace syncs, scheduled cycle-count reminders, and queued quantity pushes. Every run writes an activity record, so background work is as auditable as user actions.
In commerce and SEO, the body of low-volume, high-specificity terms or products that together outweigh the few high-volume ones at the head of the distribution.
In PMP, long-tail describes the kinds of parts most catalogs ignore: older models, niche equipment, vintage gear. The catalog you build captures these because you tore the unit down yourself — and they're where most parts businesses make their margin.
Picking & fulfillment
12 termsA reusable, stackable container used to hold and carry items as they move through a warehouse or fulfillment process.
In PMP, a tote is the holder a picker drops parts into as they work through a pick list. Parts leave their storage location, pass through a tote during fulfillment, and end up packed into an outbound order — the tote is the workflow holder, not the long-term home. PMP prints a scannable tote label for each one.
A wheeled transport used to move multiple totes (or other containers) through a warehouse during picking and fulfillment.
In PMP, a cart is labeled and scannable like everything else on the floor — it carries the totes a picker fills on a pick run. PMP prints cart labels at the same 2"×1" size as tote labels.
A mobile barcode-scanning device — most commonly a Zebra TC2x or similar Android-based scanner — used by warehouse staff to read codes and update systems from the floor.
In PMP, the handheld is a supported first-class surface. The picking, receiving, and cycle-count flows are built scanner-first; the same screens also run on a phone or tablet — the camera reads QR codes and barcodes directly, so you can start with no dedicated hardware, and a paired Bluetooth scanner is optional.
The format a barcode uses to encode its data — the rule set that decides how the bars and spaces (or the squares, on a 2D code) stand in for letters and numbers. CODE128, CODE39, UPC-A, and QR are each a different symbology; a scanner has to recognize the symbology before it can read the code.
In PMP, QR is the default for part and location labels. A QR code is compact and holds far more data than a 1D barcode like CODE128 — the trade-off is that it needs a 2D-capable reader, though most phone and tablet cameras qualify. PMP's free label generator prints the same format, and lets you switch symbology if your scanners expect a 1D code.
A picking workflow built around scanning a location, scanning a part, and confirming the action — no menus, no typing — so the picker keeps both hands on the part and the device.
In PMP, scanner-first picking is the default flow on /picking. Scan a location, scan a part, confirm; the ledger writes, the marketplace sync queues, the next pick loads.
A bounded run of pick actions — start to finish — attributed to a single picker, with its own progress state and recoverability if interrupted.
In PMP, picking sessions are independently recoverable. If a handheld dies mid-pick, the next sign-in resumes exactly where the last confirmed scan left off. All session actions are attributed in the audit log.
A set of orders or order lines grouped for combined pick/pack/ship — by destination, carrier, or batch — so the floor handles them in one pass.
In PMP, fulfillment groups are built from open orders and routed to the picking handheld as a single session. Reduces travel time on the floor and printer touches at the pack station.
Grouping multiple orders to pick, pack, and ship in a single shop-floor pass instead of one order at a time.
In PMP, batch fulfillment uses fulfillment groups to coordinate the pass. Labels and packing slips print in batch order; the picking handheld walks through the parts in a route that minimizes backtracking.
The defined stages an order moves through from arrival to completion — typically received, allocated, picked, packed, shipped, closed.
In PMP, every transition writes a row to the order's audit history with actor and timestamp. Reservations are placed on allocation, drawn down on pick, and resolved on ship.
A Zebra-specific Android service that captures input from the device's scanner and forwards it to the active application as keyboard input — making barcode scans look like very fast typing.
In PMP, the picking handheld supports DataWedge out of the box. PMP ships a recommended DataWedge profile (JSON) you import once on the device; from then on, every scan lands in the picking screen as if you'd typed it. The Action Key Character and Carriage Return settings matter.
A non-printable character a barcode scanner emits to signal "the scan is complete" — most commonly a tab or a carriage return — so the receiving application knows when to act on the input.
In PMP, the recommended DataWedge profile uses a Carriage Return as the Action Key Character. The picking screen reads input until it sees the CR, then validates and confirms in one step.
A control character (\r, ASCII 13) that historically returned a typewriter carriage to the start of the line. In modern applications, it's often used to signal "end of input."
In PMP, the DataWedge profile sends a Carriage Return after every successful scan. PMP's picking screen treats CR as the commit signal — scan complete, validate, confirm.