A B2B catalogue answers two questions: what does this buyer see, and what does this buyer pay. In xMatix the first is a merchandising layer — store catalogues presented through the Product Catalogue surface — and the second is the Sales pricing machinery: price lists and discount groups scoped down to the individual account. This page covers both halves and how they meet.
The item master and the store catalogue
Items are the commercial records: units of measure, SKUs, lot types, package flags and classifications live on the item, and every document line ultimately references one. Merchandising sits in a separate layer so the same item can be presented differently per audience. A Store (Commerce app → Stores) carries a name, currency and an optional partner account or partner account group; its Related tab holds the browse tree and the links that decide who resolves to it.
- Store categories nest under a parent, may belong to a Product Catalogue (a filter-configuration record that decides which facets and price bands the browse surface offers), and carry Show in Catalog, which decides whether buyers see the category at all.
- Store category items are the catalogue entries: each wraps an item with its selling content — a marketing name and description, highlights and usage notes, images, a display price and MRP, and an optional component hierarchy for composite products, with an assembly image whose regions map to components.
- Partner Store links tie a dealer account (and optionally a branch) to the store it buys from; a store can also name a partner account or partner account group directly. Resolution is most-specific-first: the store naming the partner, then a partner-store link (branch-specific before branch-less), then the account group.
Keeping merchandising separate from the item master means the catalogue can be reworked — renamed, reorganized, re-imaged — without touching the records that drive pricing, stock and accounting. The public storefront adds one more layer on top: a published snapshot of the store's range, described in Direct-to-consumer selling.
Browsing: the Product Catalogue surface
The Product Catalogue action — in the record header of orders, purchase orders and service orders, and on the order-line and purchase-order-line toolbars — opens the store's catalogue against the open document. The store is resolved from the document's partner account through the links above. The surface presents entries as a card grid with search, sorting, collection tabs (Focused, Frequently Ordered, New Items, Schemes, All), a barcode path and a filter rail whose facets come from the data and the store's Product Catalogue configuration, and enriches each card from the item's own records:
- Units — quantities are entered per unit of measure from the item's unit ladder (case, box, piece), not as a bare number.
- Prices — card prices come from price list rules, the same rules that price order lines.
- Offers — trade scheme hints appear on qualifying items, as prompts rather than applied discounts.
- Stock — availability and reorder levels are shown from live stock.
- History — the buyer's frequently ordered items and likely reorders, from their past orders.
Each enrichment is independent, so a missing facet degrades that facet rather than blocking the catalogue; only the item read itself gates the screen. A rep's selling scope is applied on top, so the catalogue is never a way around entitlements. Two empty states differ: a store that curates nothing shows "No products in this catalogue" (or "No products match the current search and filters"), while a document whose partner account resolves to no store at all falls back to the whole item master with a visible warning — "Showing all products, not this account's range" — so a plausible full range is never mistaken for the account's. Fix the second by linking a store to the partner account.
Add to document writes the chosen lines to the open document immediately, and each line then runs the normal line handlers for price, discount and derived values. What happens next is covered in Dealer ordering.
Per-account price lists
A price list is scoped, and the scoping is what makes pricing customer-specific. A list can be pinned to any combination of:
| Scope | Meaning |
|---|---|
| Customer account | One named buyer |
| Customer account group | Buyers in a Price-type account group — a customer tier |
| Selling company (partner account) | The company doing the selling |
| Partner account group | A group of selling companies |
| Branch | The selling branch |
One list can be marked default, and every list carries a sequence number. Two resolvers read these scopes, and they differ:
- On documents (orders, invoices, the Product Catalogue cart), the resolver first keeps active lists whose selling company, branch, partner group and — on sales documents — customer group match the document, then sorts by descending sequence before the scoped fields and the default flag. Treat sequence as the primary precedence control; do not assume a narrower list automatically beats a broader one with a higher sequence. The document resolver does not select a list from the direct customer-account scope.
- In storefront carts, the cart pricer ranks lists strictly by entitlement: a list naming this customer first, then one for a customer group they belong to, then a general list with neither, and it never prices from a list scoped to someone else. Sequence is not used; ties go to the newest effective date. A price already snapshotted on the cart line from the published catalogue wins over all of this.
Within the selected list, an eligible rule must match the item, effective date and any SKU, lot-type or service-type scope. Service-type-specific rules are considered first, followed by the newest effective date and then the remaining dimensions, so a newer generic rule can beat an older specific one — test overlapping rules explicitly. The Reprice action and the handling of manually entered prices are documented in Pricing, discounts and taxes.
So "dealer-specific pricing" is modelled, not typed: put the dealer (or its tier group) on a price list, and every order for that dealer prices from it automatically.
Discount groups: contract terms per account
Contract discounts resolve separately from prices. A discount group has a Discount Type of Sale Price or Purchase Price, carries dated discount rules — each targeting an item or an item group with a discount percent — and is scoped by customer account group, selling company, partner account group and branch. A sales document's discount group defaults from the customer's account groups of type Discount, narrowed by selling company and branch; the matching rule fills each line's contract discount, and an item no rule covers simply gets none. A group can also be marked claimable with a claimable percentage, which feeds trade claims. Trade schemes stack their own scheme discounts and free lines on top of contract discounts — the two are independent, which is what lets a negotiated margin and a promotional offer coexist on one line.
Common questions
Can two dealers pay different prices for the same item?
Yes. Put dealers into distinct Price-type customer account groups and scope price lists to those groups, or separate them through the selling-company and branch scopes. Set sequence deliberately when more than one active list can match a document. The same account-group pattern applies independently to contract discounts through Discount-type groups.
Where should a negotiated price live?
As a dated price-list rule on the list selected for that customer's group, selling company and branch — not as an informal hand-typed unit price. A manually owned rate can be preserved by the line's manual-rate behaviour, while an explicit Reprice uses the matching rule again. Test the exact document context and overlapping effective dates before relying on the result.
Why does a catalogue card show an offer the order didn't get?
Card offers are hints: they signal that a scheme covers the item. Whether it actually applies is decided by the scheme engine when the document is saved — conditions, slabs, account scoping and budgets all weigh in then. See Schemes and credit.
Why does the storefront show one price when the dealer's price list says another?
The published catalogue shows one displayed price per listing, snapshotted at publish time. The dealer's own terms are applied when the cart is priced — the cart pricer prefers a list named for the signed-in customer or their group — and the checkout freeze uses that priced total. Republish the store when displayed prices should change.