Posted on 13/03/2026 14:11:09
Hi Adrian
Here are a couple of ideas:
Answer 1 --- Custom PriceProvider
The recommended approach is to implement a custom PriceProvider that reads a price list identifier stored on the cart/order (e.g. in a custom order field), then uses that to filter prices.
How it works:
- Extend PriceProvider and register it via the AddIn system
- In FindPrice(PriceContext context, PriceProductSelection selection), inspect the current order/cart to find which price list has been applied by the sales rep
- Use the price list identifier (stored as a custom field on the Order, or via Order.Comment, a secondary customer number field, etc.) to look up the correct prices from the price matrix
- Return a PriceRaw with the appropriate price
Storing "which price list": Since PriceContext only carries Customer, Currency, Shop, and Country, you'd store the selected price list on the Order itself --- e.g. using a custom order field or by setting Order.CustomerNumber (or a dedicated field) to the price list identifier before the sales rep saves the quote.
public class QuotePriceListProvider : PriceProvider
{
public override PriceRaw? FindPrice(PriceContext context, PriceProductSelection selection)
{
// Read the price list key from the current cart context
var order = ...; // fetch current cart
var priceListKey = order.GetCustomField("QuotePriceList"); // e.g. "BIDDING_TIER_A"
if (string.IsNullOrEmpty(priceListKey)) return null; // fall through to default
// Lookup price against your custom price matrix using priceListKey
return new PriceRaw(...);
}
}
Pros: Clean, fully decoupled from customer identity, survives recalculations, extensible per quote. Cons: Requires a custom price storage/lookup mechanism alongside the standard price matrix.
Answer 2 --- CustomerGroupId / GroupCustomerNumber hack
The quick approach the partner already suspected: define each "order price list" as a User Group with a specific CustomerNumber (e.g. "PRICELIST_A", "PRICELIST_B"), enter prices in the price matrix tagged with CustomerGroupId = "PRICELIST_A", and then set the cart's customer to a user that belongs to the matching group --- or temporarily override the lookup.
The CustomerGroupPriceFilter in DefaultPriceProvider matches Price.CustomerGroupId against the user's group CustomerNumber. So:
- Create User Groups: "PRICELIST_A", "PRICELIST_B" with those as CustomerNumber
- Enter prices in the price matrix with CustomerGroupId set to the relevant code
- When the sales rep applies a price list to a quote, assign the quote's customer to the matching group (or switch CustomerAccessUserId to a "proxy user" pre-assigned to that group)
Pros: No custom code, works within standard Dynamicweb price matrix tooling. Cons: Conflates "price list selection" with user group membership, creates awkward data modeling, fragile if the customer already belongs to groups with other purposes, and the "assign user to group" step may not be easily exposed in the UI for sales reps.
Bottom line: For a proper quote/bidding workflow, Answer 1 (custom PriceProvider) is the right long-term architecture. Answer 2 can work as a no-code workaround for simpler scenarios, but it will become unwieldy as the number of price lists grows. A hybrid is also possible: store the selected price list key as a custom field and use it within the standard price matrix via CustomerGroupId --- the PriceProvider then temporarily impersonates the right "price list group" context.
