Price lists, discount lists and price calculation

What it does

Price lists set what a product costs, per unit, in one currency. Price list items pin a product and unit to a pricing method, discount lists apply volume breaks, and the pricing engine recalculates opportunity, quote, order and invoice lines from those inputs.

Key facts

One price list holds one currency. You need at least one price list per currency the organisation trades in, and units and products have to exist before you can create price list items.
The Price List table inherits privileges from the Product table — read/write on Product means read/write on Price List. There's no separate security handle.
Price lists carry Start Date and End Date, but nothing enforces them at selection time.
Price list items are per product and unit. Same product, different unit, second price list item.
Six pricing methods: Currency Amount (a fixed figure that ignores the product's list price), Percent of List, Percent Markup — Current Cost, Percent Markup — Standard Cost, Percent Margin — Current Cost, Percent Margin — Standard Cost. Margin methods use cost + [(cost × pct) / (100% − pct)]; markup methods use cost × (100% + pct).
Rounding applies to every method except Currency Amount: policy of None, Up, Down or To Nearest, with an option of Ends in or Multiple of and a rounding amount.
Quantity Selling Option on the price list item controls whole, partial, or both quantity types.
A discount list attaches to a price list item. Discount lists are Percentage or Amount, with tiers defined by Begin quantity and End quantity.
Volume discounts recalculate only when quantity changes, and use the discount list on the price list item even if that list is inactive.
Manual discount arithmetic depends on Organization.DiscountCalculationMethod: 0 = Line Item (default, kept for backward compatibility), 1 = Per Unit. Price 100, quantity 200, discount 10 gives 19,990 on line item and 18,000 per unit.
With Use system pricing calculation on (Organization.OOBPriceCalculationEnabled = 1, the default), prices recalculate when an opportunity, quote, order or invoice is opened, created or updated, and when lines are added, updated or deleted.
Set OOBPriceCalculationEnabled to 0 and a plug-in registered on the CalculatePrice message runs instead, every time one of those records is created or modified. That message has no other purpose.
Price lists can be defaulted by territory through a connection on the price list's Territory Relationship tab; the Allow selection of default pricelist setting (off by default) drives that automatic selection on opportunities.
Make price lists optional (App Settings > Product Catalog > Product Catalog Settings) lets sellers add products and price them ad hoc with no price list.

When to use / skip

You can't skip price lists if you're using product lines — one exists whether you designed it or not. The decision is how many, and whether the pricing methods do real work or every item is just a Currency Amount.

Use cost-based methods when the client actually maintains current cost and standard cost and wants margin protected centrally. Most don't maintain those fields, in which case percent-of-list and currency amount are the honest choice — say so rather than building a margin engine on empty data.

Use discount lists when volume breaks are published and standard. Skip them when discounting is negotiated deal by deal; manual discount on the line is the right tool there.

Turning off system pricing entirely is a serious commitment: a plug-in on CalculatePrice that has to handle every product, currency, discount and rounding case, forever. Do it when pricing genuinely can't be expressed in price lists — usage-based, contract-specific, property-driven — not because a few edge cases were awkward.

Configuration decisions

How many price lists, and on what axis: currency, region, channel, customer tier. Every axis multiplies the maintenance.
Which pricing method per item, and whether the client will really keep cost fields current if you pick a cost-based one.
Line item versus per unit discount calculation. It's an organisation-wide setting and the two produce very different numbers.
Whether price list selection is manual, defaulted from the account, or driven by territory rules with Allow selection of default pricelist.
Whether Make price lists optional is on. It's the difference between controlled pricing and sellers typing numbers.
Whether to stay on system pricing or move to a CalculatePrice plug-in, decided before the first sprint rather than after the first exception.

Gotchas

Deactivating a discount list doesn't stop it applying; you have to remove it from the price list item.
Volume discounts only recalculating on quantity change means editing price or swapping the price list can leave a stale discount sitting on the line.
Price list start and end dates don't stop anyone selecting an expired list. If date-limited pricing matters, that's custom logic.
Missing price list items present as "the product isn't in the list" rather than anything about pricing. Every product/unit pairing sellers need must exist on the list.
Inheriting security from Product means you can't give someone product read access without price list read access.
Changing the discount calculation method after go-live changes totals on records that recalculate afterwards. Historic closed records stay as they were, so reports show a step change.
Switching OOBPriceCalculationEnabled off with no plug-in registered means nothing calculates. Lines sit at whatever was typed.
Percent-margin methods with a percentage approaching 100 blow up mathematically, and nothing stops someone entering it.

Consultant notes

Build a small pricing test matrix during the build — a couple of products, each pricing method, a discount tier, both calculation methods — and keep it as a regression pack. Pricing bugs are expensive to trace without one.
Ask directly whether current cost and standard cost are maintained anywhere. If the answer is vague, take cost-based pricing methods off the table.
Show the client the line item versus per unit worked example with their own numbers. It's a one-minute conversation that prevents a month of arguing about totals.
If anyone proposes custom pricing, make them cost the plug-in properly. It fires on every create and update across four transaction types, so performance is part of the design.
Before go-live, run a completeness check that every sellable product has a price list item on every price list sellers can pick, in every unit they'll use.

Worth another look if a new trading currency appears, or if anyone starts talking about a custom pricing plug-in.