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 easy to build without noticing.

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. So open each price set in a book and read its priority; a blank or a zero is the one to fix. 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. Nothing warns you when a price set carries two item rules, which is why this 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 silent failure that looks like a broken price set and is not. A price set with no rule on the Single Line tab is never matched by any calculator — the sales engines find no matching rule, and the till’s calculator returns false on an empty list by construction. But a price set carrying rules on the Multi Line tab instead is not dead. That tab is read by the server-side engine which awards points from scanned cash bills, and it is read by a second pass the till runs over the whole bill after every line change, which can discount the cheapest matching line. What no calculator will do is price the line you just scanned from a Multi Line rule. So if this price set was meant to discount a line as it is rung up, 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. So check your existing price sets for any of those five rules. 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["no calculator matches it<br/>(a till may still read it<br/>on the multi-line pass)"]
  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