Which price set wins, and why the answer moves — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever writes GadgetSphere’s promotions and has had two of them collide. In about thirteen minutes you will be able to say, before you save, which price set a line will get — and you will recognise the three shapes of price set that can never fire, one of which is surprisingly common.

Step 1 — Learn the rule that decides everything

After this step you will know the whole of the selection algorithm. Every engine does the same two things. It takes the price sets of the one loaded book that are Active, sorts them by priority with the highest number first, and walks the list. For each one it checks the header rules, then the item rules, and the first price set whose item rules match is applied. The rest are never looked at. That is the entire contest: there is no combining, no stacking of two price sets on one line, and no best-price comparison. Priority is not a hint about importance. It is the running order, and the first finisher takes the line.

Reference: Pricebook — Which engine prices your line

Step 2 — Give every price set a priority, on purpose

After this step you will have removed a source of results nobody can explain. The priority the engines sort on lives in the price set’s stored properties, and when it is missing the comparison returns a non-number. A sort with a comparator like that does not raise an error; it simply leaves the list in whatever order the server sent it. So two price sets that both match, both without a priority, will pick a winner that can change between one page load and another. Most active price sets across the fleet do carry a priority, but a meaningful minority carry zero or nothing at all. Set a distinct number on every price set in a book, even the ones you think can never collide.

Reference: Pricebook — Which engine prices your line

Step 3 — Write item rules for the screen that will read them

After this step you will avoid the trap that makes a promotion work on one screen and not another. On the Single Line tab, a sales invoice, order or quotation takes the first item rule that matches — the rules behave as or. The till requires every item rule on that tab to match — they behave as and. So a price set with an Item rule and a Category rule discounts a flagship handset on an invoice and discounts nothing at the counter, because the handset is not in both. Very few price sets across the fleet carry more than one item rule, which is why this is rare and why it is so hard to diagnose when it happens. Keep one item rule per price set.

Reference: Pricebook — Which engine prices your line

Step 4 — Recognise the price set that can never fire

After this step you will know the commonest silent failure on this surface. A price set with no rule on the Single Line tab never matches anywhere — the sales engines find no matching rule, and the till’s engine returns false on an empty list by construction. Roughly a quarter of the active price sets in production have none. Most of those are not mistakes: they carry rules on the Multi Line tab instead, and the Multi Line tab is read only by the server-side engine that awards points from scanned cash bills. Those price sets are working, on the surface they were written for. If yours was meant for a till, put at least one rule on Single Line.

Reference: Pricebook — Which engine prices your line

Step 5 — Treat the header tab as an unconditional and

After this step you will stop expecting the And/Or control to do anything on a sales document. On the Doc Hdr tab, every rule the engine understands must pass, whatever Rules Logic says — there is no or. Negation Logic does work, and inverts the whole tab. The important half is the rules the engine does not understand: Company, Currency, Settlement Method, Member Label and OCR Company are skipped, and a skipped rule is a rule that passed. Adding a Company rule to confine a promotion to the distribution company therefore widens it rather than narrowing it. A small number of price sets in a handful of tenants carry one of those today. Use Branch, Entity Type, Member Class or a category rule instead.

Reference: Pricebook — Which engine prices your line

Step 6 — Run the diagnosis in this order

After this step you will have a routine for “my promotion did not apply”. First, does the applet’s Default Pricebook name this book. Second, is the price set Active and does it have at least one Single Line rule. Third, does any header rule fail — remembering that a Branch rule fails outright on a document that carries no branch, and that a Relative Period date rule can never match. Fourth, is there a higher-priority price set that matched first and quietly took the line. Only when all four are clear is it worth looking at the treatment itself, which is the next lesson and where the genuinely surprising behaviour lives.

Reference: Pricebook — Troubleshooting

How the steps fit together

    flowchart TD
  A["Active price sets<br/>of the one loaded book"] --> B["Sort by priority<br/>highest first"]
  B --> C{"Header rules pass?<br/>always AND<br/>unknown types = pass"}
  C -- no --> B
  C -- yes --> D{"Single Line rules?"}
  D -- "none" --> E["never matches<br/>anywhere"]
  D -- "sales doc: first rule matches" --> F["this price set wins"]
  D -- "till: every rule matches" --> F
  F --> G["treatment applied<br/>— the rest are never checked"]
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: When the book and the scheme disagree · Back to the series · Play this as a presentation