Setting up ERP-controlled price lists
In many setups, prices are maintained in an external system — an ERP, PIM, or pricing tool — and pushed into Norce via integration. This article covers the common setup where a child price list with Fixed price receives prices from the ERP and inherits everything else from a standard parent. The step-by-step section focuses on this scenario.
Common ERP pricing scenarios
There are two equally common approaches, and which one you use depends on what the ERP controls.
Scenario A: ERP controls everything — standalone price list
The ERP is the single source of truth for all pricing data. The integration pushes recommended price, sale price, cost, and everything else directly into Norce. There is no parent price list — the price list stands alone.
This is typical when the ERP acts as a full pricing engine and Norce just needs to reflect its output faithfully. No inheritance or calculation is needed in Norce; the ERP handles it all.
Scenario B: ERP controls sale prices — child inherits the rest
A child price list with Fixed price inherits its assortment, recommended price, catalog price, and cost data from a standard parent. The ERP integration only pushes the sale price per product. Everything else comes automatically from the parent.
This is the most common setup for standard ERP-integrated price lists, and is what the step-by-step below covers.
A common variant of this scenario is customer agreement pricing: the ERP holds pre-negotiated prices for a specific customer covering a subset of their full assortment. In this case, a small child price list is created for the customer — it inherits the full standard assortment from the parent but only has fixed prices for the products where the agreement differs. For all other products, the parent price applies via best-price evaluation.
Step-by-step setup (Scenario B)
1. Create the price list
Go to Pricing > Tools > New.
| Field | Value |
|---|---|
| Name | e.g. ERP Prices — SE or Agreement — Customer X |
| Parent Price List | Your standard base price list |
| Currency | Same as the parent (or the market currency if this is market-specific) |
| Price Rule | Fixed price |
| Public | Depends on your setup — see below |
With Fixed price selected, no automatic price calculation is done. Each product's sale price must be explicitly set by the integration.
Products on a Fixed price list without an explicitly set price will have no price and will not appear in price calculations for that list. For customer agreement lists that only cover part of the assortment, this is expected — those products fall back to the parent's best price.
2. Decide on Public vs non-public
- Public — the price list automatically participates in best-price evaluation for all requests. Suitable for a general ERP-controlled standard price list.
- Non-public — the price list only participates when explicitly passed via
PriceListSeedin the API call. Suitable for customer-specific agreement lists that should only apply in the right customer context.
3. Connect the ERP integration
The ERP integration pushes prices to Norce via the price API. The minimum required fields for a Fixed price list are:
| Field | Description |
|---|---|
PartNo | The product's part number |
PriceListCode | The code of the target price list |
PriceSale | The sale price (VAT exclusive) |
The integration typically runs on a schedule or is triggered by price changes in the ERP. Norce processes and applies price updates immediately when received.
4. What is inherited from the parent
Even though the sale price is controlled by the ERP, the child price list inherits the following from the parent:
- Standard price — automatically inherits the sale price from the parent price list.
- Recommended price — inherited from the parent's recommended price.
- Catalog price — inherited from the parent.
- Cost (purchase/unit) — inherited via the parent's connected supplier price lists.
This means the integration only needs to manage the sale price. All other pricing metadata is kept up to date automatically via the parent.
Assortment and population rules
Population rules on the child price list determine which products from the parent are active on the child. This interacts with the ERP integration in an important way that can cause confusion.
By default, population rules are set to exclude all products from the parent — products must be explicitly opted in by category, manufacturer, or flag. If a product's category or flag no longer matches the population rules, it will be deactivated on the child price list even if the ERP integration has a price for it.
A common issue is: the ERP sends in a price for a product, but the product gets deactivated on the child price list anyway because the population rules do not include it. In this case, the product's category or flag must be updated to satisfy the population rules — or the population rules must be adjusted to include it.
Integration-controlled assortment
There is a specific setup for integrations that need to control the active assortment directly:
If the child price list has its population mode set to exclude all (the default) and has no population rules defined at all, Norce will not automatically deactivate products based on the parent's assortment. Instead, a product's active status on the child price list is determined solely by whether the integration has set a price record for it.
This means:
- Sending a price for a product activates it on the child price list.
- Removing the price (or setting it to inactive) deactivates it.
- No population rules intervene.
This is useful when the ERP owns the assortment for a customer agreement and Norce should not apply any additional filtering on top.
As soon as any population rule is added — even one — Norce resumes managing assortment based on those rules. Only a completely rule-free setup gives full integration control over the assortment.