Deterministic module
Product Catalog & MDM (Catalog Engine)
The buyer looks for a part, does not find it, and buys from a competitor. In complex B2B that is a catalog problem, not a storefront problem. Missing technical attributes, incomplete application tables and poorly mapped equivalences produce costly returns and lost sales, and no campaign fixes that.
What it is
The module that treats catalog data as a critical operational asset. It ties the product into an integrity chain that runs from product to SKU, from SKU to inventory and from inventory to warehouse, and it supports the four selling compositions: unitary, pair, kit and set. Each SKU is identified by manufacturer, part code, composition and origin, and each stock of that SKU in a warehouse gets its own identifier. Variations of the same product are grouped into a size or variant grid, show up as a single search result and keep their own price and stock. An item with no price or no stock can stay in the store as a quote request, and anyone looking for an unavailable item can ask to be notified when it is back: a stockout becomes an opportunity, not an empty page. Price, availability and orders all rest on those records afterwards. A bad catalog does not stay a catalog problem — it becomes a wrong order.
Catalog Engine in 1 minute
The capability nobody replicates
Component-level traceability in compositions
A kit is not a façade SKU. The platform knows every component in it, with the quantity of each, and the kit balance is not typed in: it is recalculated from the lowest balance among its components. If a part is missing, the kit offer is suspended instead of becoming an order that the warehouse discovers later. Integrity applies at the sale, not at the picking bench.
Cross-brand equivalence and application tables
Cross-reference links competing codes, and the application links the SKU to the vehicle or equipment it fits. This is what a B2C-origin storefront does not model: it indexes products, and the auto parts aftermarket, from a distributor to a dealer portal, needs to index compatibility. Search works as a ladder: it first matches the code (manufacturer, EAN or internal code), then looks for all the words typed, and only then widens, with the default set per profile for customer, sales rep and buyer.
The catalog ladder, and why it is commercial
Richer records are not a master-data indulgence. They decide whether the item is findable. The ladder below gives the catalog a measurable axis, and moving from one rung to the next is an operational goal with a direct effect on sales.
- N1 The code The item exists and carries the manufacturer code. This is the floor: it can be ordered, but almost nobody finds it without knowing the code by heart.
- N2 Name and dimensions The item gains a readable name, a spec sheet and filterable attributes. It starts showing up in search and in filters, not only in direct lookup.
- N3 Application and image The item gains an image, an application and equivalences. It becomes findable by people who do not know the code, which is most of the demand.
In practice a catalog starts concentrated at N1 and thins out toward the top. Lifting the bulk from N1 to N2, and the fast movers to N3, is the catalog work CWS Platform delivers alongside the technology.
The assortment arrives structured, not stacked
The category with 148 products, facets carrying the count for each option, the filters already applied visible above the grid, and stock status item by item.
- The count comes before the clickEach brand, size or price-range option shows how many items sit behind it, so filtering is not a gamble.
- Applied filters stay in sightThe six active filters sit above the grid, each removable on its own, with no need to reopen the column.
- Availability is a facetReady-to-ship, store pickup and made-to-order are filters, not a surprise at the shipping step.
A large catalog is no advantage on its own — it becomes a problem the moment the buyer cannot find anything. What the module delivers is the structure that makes the assortment navigable, and it is all here: every facet states how many items sit behind it, so the buyer knows the size of the choice before clicking. Applied filters stay visible and individually removable, and availability is a facet like any other.
Persona · Portal owner
I no longer keep the same catalog twice: branches inherit the master data.
With Product Catalog & MDM (Catalog Engine), branches and sellers inherit the product master data and extend it with their regional offer.
Persona · Parts buyer
I no longer need to know the code by heart: I find the part by vehicle.
Product Catalog & MDM (Catalog Engine) links each SKU to the vehicle through the application table and cross-references equivalent codes across manufacturers.
In operation
Imdepa · auto parts distribution
about 23,000 SKUs
in a portfolio serving roughly 16,000 corporate customers across 9 states, in the agricultural, industrial and automotive segments.
With the catalog intact, the buyer assembles an order of more than 250 SKUs in a single cart, unassisted. What holds that order up is not the screen — it is the records behind it.
Read the Imdepa case →APIs for this module
What this module does in the panel can also be done by your system. These are its groups in the public API reference.
SKU Priority
Endpoints to manage the display priority of products (SKUs) in search results.
Frequently asked questions
Our records have missing attributes and inconsistent part names. Can we go live like that?
Yes, and that is how nearly every operation starts. The catalog comes in as it is and improves by level: first the manufacturer code, then name and dimensions, then application and image. Each additional level raises the chance the item is found and bought, so improving the catalog becomes an operational goal with visible progress, not a prerequisite that stalls the project. Inconsistent part names do not have to be fixed in the ERP first either: synonym tables for manufacturer name, product code and composition make the ERP records match the catalog, and name synonyms resolve in search the regional nicknames buyers actually type.
Does the platform know that one brand's part replaces another's?
Yes. Cross-reference links equivalent codes across manufacturers, and the application table links the SKU to the vehicle or equipment it fits. The buyer arrives with the code they already know, with a serial number, or through the exploded view of an assembly, and still lands on the right item. Customers can filter by vehicle (type, make, model and year) and save their own garage, and the product page shows similar items from other brands next to the one they searched for.
Do headquarters and branches have to maintain the same catalog twice?
No. Under global versus local governance, the portal owner chooses the catalog strategy: use the CWS Platform global catalog and enrich it, have the manufacturers in their sector feed that global catalog, keep an exclusive proprietary catalog identified by an internal code, or let each seller list its own items. Headquarters chooses which catalogs the portal displays, and branches and sellers inherit the product master data (manufacturer code, name, composition, tax classification, dimensions) and extend it with what is theirs: internal code, price, quote option, warehouse and stock, in other words the regional offer. A new partner captures the catalog that already exists instead of re-entering it from scratch, which shortens their go-to-market.