How the pieces fit together

There is one chain running through the whole platform. Once you can see it, you can work out where almost any task lives without hunting through menus.

The chain

product data  →  prices  →  customers  →  orders  →  storefront
                     ↑           ↑           ↓
                  markets    segments      ERP

Read it left to right. Each link needs the one before it to exist.

Product data comes first. A product is a record with a code (4711-A), a family that decides which fields it has, and values for those fields — thread_size, material, pressure_rating. This lives in the catalog, the platform's PIM. Nothing downstream works without it: you cannot price an article that does not exist, and a buyer cannot find an article whose attributes are free text. See How PIM works.

Prices are a separate layer, deliberately. A price is not a field on a product. It is an entry in a price list, and a product can appear in many price lists at once — a standard list, a list for a customer segment, a list for one large account under contract. Which price a given buyer sees is the result of resolving those layers in order. This separation is what makes B2B pricing possible at all; see How pricing works.

Customers are organisations, not people. The record that matters is the company: Max Müller GmbH, with its payment terms, its credit situation, its delivery addresses. People — contacts — belong to that organisation and carry roles that say what each of them may do. A price list is assigned to an organisation or to a segment of organisations, which is the mechanism that makes "our A-customers see different prices" work. See The B2B customer model.

Orders are the output. An order references products, resolves prices against the buyer's organisation, applies whatever approval rules that organisation has, and then goes somewhere — usually your ERP. Orders do not only come from the storefront: they arrive by punchout, by import, and increasingly from your own Innendienst placing them on a customer's behalf. See The order lifecycle.

The storefront is the last link, not the first. It is a rendering of everything above it. This is why building the shop design first is a mistake people make once: a beautiful storefront over an unstructured catalog has no filters that work, no prices that resolve and nothing to search.

What actually decides the price

"Which number does this buyer see" used to be answered by the price list alone. It no longer is. Six layers resolve in a fixed order, and each one can only be beaten by the one after it: the list price for the market, a segment price for a group of organisations, a contract price negotiated with one account, a scale price at the quantity break, a quoted price frozen on an accepted quote for as long as that quote is valid, and finally a promotion applied on top of whatever won. The last two are the additions most teams have not thought about: a quote overrides a contract price for the lines it covers, and whether a promotion may stack on a contract price at all is a decision you make rather than a default you inherit. See Promotions vs. contract prices, and use Check a price whenever the answer surprises you.

Where markets and segments cut across

Two things sit sideways to the chain rather than in it.

Markets are business contexts — country, currency, language, tax treatment. One catalog, several markets. A price entry belongs to a market, so "the same article, 14.90 EUR in Germany and 16.20 CHF in Switzerland" is one product with two price entries, not two products.

Segments are groupings of customer organisations. They are how you avoid maintaining anything per-customer that you could maintain per-group. Contract prices for one account are legitimate; a hand-maintained price list for each of 400 accounts is a maintenance problem waiting to happen.

Where the integrations sit

Integrations are not a separate world. They are how the chain gets fed and where its output goes.

Two things follow from this table. First, an integration is only as good as the decision behind it: for every field, exactly one system must own it, and the other must not overwrite it. Second, punchout is not a small feature — it is your catalog leaving your building and being rendered somewhere far less forgiving than a web browser. See Integration patterns and Punchout explained.

Guessing where a task lives

The Cockpit's Commerce Studio has four sidebar sections that map onto the chain almost exactly: PIM, CRM, Order Management and Configuration. That gives you a reliable rule of thumb.

The first eleven rows name a Cockpit screen. The last nine name a Manual area instead, because those areas are newer and where their menu entry sits depends on which apps you have installed — open the area and the article will name the screen.

When you are unsure, ask which link in the chain the thing belongs to and work from there. It is right far more often than searching the menu.

Why the order matters

The chain is also the order in which you should build. Prices need products. Customer-specific prices need customers. The storefront needs all three. Every project that starts with the storefront ends up rebuilding it once the data model settles down.

Next

• B2B commerce basics — why this chain looks nothing like a B2C shop.
• Your first week — the same order, as a plan.