SKU mapping: the listing is not the product
A marketplace listing has its own identifier, its own title and sometimes its own barcode. The warehouse has a SKU. Until the two are tied together on record, every order from that listing is a guess.
Verified in code 2026-09-04 · v2.0.0 to v2.19.0
What it looks like on the floor
An order arrives for “Blue, Large, 2-pack.” The picker knows which box that is. The next picker does not. A month later the listing is renamed and now nobody knows, and the order that shipped last Tuesday was the wrong variant because two listings shared a title and someone chose.
Why it happens
Channels and warehouses name things for different reasons. A listing is named to sell: title, variant, bundle size. A SKU is named to pick: one code, one physical unit. A marketplace may also print its own fulfillment barcode on the unit, so the box now carries a code the warehouse never issued.
When the tie between listing and SKU lives in someone’s head, or in a spreadsheet column, it breaks the first time a listing is renamed, a variant is added, or the person is on holiday.
What DockingWare does
The tie is a record. Every channel listing is either mapped to exactly one warehouse product or it is not, and the difference is visible on the order. An order with an unmapped line is accepted, flagged, and blocked from fulfillment until every line points at a real product. No pick is ever generated against a title.
Mapping is suggested, not imposed. When listings come in, the system proposes a match from the identifiers it can see and parks it as a draft. A person approves it. If a suggestion would map a listing that is already mapped elsewhere, it is marked as a conflict and left for a decision, not applied. Products that are still in draft in the catalog are excluded from suggestions, because a draft cannot be sold.
Codes are additive. Register the marketplace fulfillment barcode, the vendor label and the legacy code as alternate barcodes on the product. Each one is unique across the tenant; registering a code that already belongs to another SKU is refused by name. When any of those codes is scanned at receiving, packing or returns, the alias resolves and the ledger records the real SKU.
For a large catalog, mapping runs from a CSV with a dry run first, so you see what would change and what would conflict before anything is written.
What it does not do
It does not decide which product a listing is. That is a human call with money attached, and the system’s job is to make the call once, keep it, and refuse to ship until it has been made.
What you can verify
Every rule above is enforced in code and covered by a test that fails first, then passes. The changelog names the version each one shipped in.
Questions
- What happens to an order whose listing is not mapped?
- It comes in and is flagged as needing mapping. It cannot be fulfilled until every line points at a warehouse product. Nothing is guessed and nothing is picked against a listing title.
- Does the system map listings for me?
- It suggests. Each listing gets a draft suggestion based on the identifiers it carries. A person approves it. A suggestion that would collide with an existing mapping is flagged as a conflict instead of applied. Products still in draft are never suggested.
- Can one product answer to several codes?
- Yes. A product has its own barcode and any number of alternate codes: a marketplace fulfillment sticker, a vendor label, an old code from a previous system. Each code is unique across the catalog. When one is scanned, the ledger names the real SKU, never the alias.
- Can I map in bulk?
- Yes. A CSV run can be executed as a dry run first, which reports what would change and what would conflict, and then committed.
Related
See how DockingWare handles this →
Ready to see it on your floor?
Early access. We onboard a small number of operations at a time.
Start Early Access