Which price wins when an item is in more than one rule? Designing pricing rules

“Which price wins when an item is in more than one rule?” The active price set with the highest Priority Level number whose rules the line meets: BigLedger checks the price sets in the one price book the applet loads from the highest number down, the first that matches stops the search, and the order you created them in plays no part. Two overlapping price sets with the same number are the exception, and the section When two price sets tie below explains why you should never leave one.

You have built a price book and one simple rule — that page is here if you have not. Now you want the real thing: volume tiers, a fortnight’s promotion, member prices, one branch cheaper than the others, and all of them in the same book without fighting each other.

This page is about how BigLedger decides, and about what happens behind the scene once it has: what the line keeps, what is worked out again later and what never is (what the line keeps). Get that right and the rules write themselves; get it wrong and you will spend an afternoon staring at a line that did not discount. If you are here because my price rule does nothing, go straight to Pricing rules that never match below.

Designing pricing rules, at a glance

1. Learn the order BigLedger checks price sets in, and why two sets on the same number are a gamble — Pricing rules in order, on this page.
2. Build each rule from the case it matches — volume tiers, a two-week promotion, member pricing, branch pricing — on Pricing rules: four scenarios.
3. Choose the treatment, and know what the line keeps once it is priced — on Pricing rules: treatments and what the line keeps.
4. Avoid the rules that never match — Pricing rules that never match, on this page.
5. Test a rule before you trust it — How to test a rule, on this page.

Meet GadgetSphere

GadgetSphere Sdn Bhd wants four things live in the same price book before the year-end sale:

1. Accessories: 5% off at 10 units, 10% off at 50.
2. A two-week promotion on one laptop model.
3. Members get 8% off everything, all the time.
4. The Penang branches price one category slightly lower.

All four are price sets in one book, and the same book is read by the tills at all 22 branches and by the back office. Here is how they coexist.

Pricing rules in order: how a line gets priced

The price book does not set a line’s starting price. The pricing scheme does that first — the branch’s or the buyer’s price list puts, say, RM 129 on a pair of wireless earbuds — and the price book then works on the price already on the line (how the scheme chooses that price). So “8% off” always means 8% off whatever the scheme said.

When you add a line to a sales invoice, order, quotation or POS bill, BigLedger then:

1. Uses the one price book that applet loaded when it started — the one named in that applet’s Default Pricebook setting. One book, not several, and the copy the applet read at start-up, not the book as it is now.
2. Keeps only the ACTIVE price sets in it. Inactive ones are skipped entirely.
3. Sorts them by Priority Level, highest number first.
4. For each, in that order, checks the header rules — who qualifies. Every header rule it evaluates must pass; there is no “any of these” across rule types, whatever the Rules Logic dropdown suggests.
5. Then checks the line rules — which items. On a sales invoice, order or quotation the first matching line rule is enough, along with its Min Quantity and Min Amount. At the till every line rule on the price set must match — the counter carries its own copy of this engine, and it reads a second rule as and, not or. Max Quantity is honoured on a sales order only; the invoice, the quotation and the till ignore it.
6. Applies the treatment of the first price set that passes — the discount, the price, or the points — and stops looking.

Two consequences fall straight out of that, and they are the two you will use constantly:

• Highest priority number wins. Number your rules 100, 200, 300 with gaps, so a new rule can slot between two existing ones without renumbering everything.
• A price set that matches stops the search. Design your most specific rule with the highest number and your general fallback with the lowest. A line gets one price set’s treatment, never two sets added together.

    flowchart TD
  SCH["Pricing scheme<br/>puts the starting price on the line"] --> PB["The one price book the applet loaded<br/>its Default Pricebook setting"]
  PB --> ACT["ACTIVE price sets only<br/>highest Priority Level first<br/>a tie has no fixed order"]
  ACT --> HDR{"Header rules<br/>who qualifies"}
  HDR -->|"pass"| LN{"Line rules: which items<br/>back office: first match<br/>till: every rule"}
  HDR -->|"fail"| NX["Next price set"]
  LN -->|"fail"| NX
  NX -->|"another set"| HDR
  NX -->|"no set left"| NONE["No treatment:<br/>the price the scheme put<br/>on the line stands"]
  LN -->|"pass"| TR["Apply that set's treatment<br/>and stop looking"]
  TR --> SN["Snapshot stored on the line<br/>invoice and till also record<br/>the price set's name"]
  

All of this runs in the browser of the person keying the line, not on the server. The POS till, the Sales Invoice and the Sales Quotation applets each carry their own copy of the calculator, and the Sales Order applet uses a shared one. They agree on the order above and differ in the details this page calls out — which is why the same price book can give a different answer at the counter and on an invoice. The dates in a Valid Date Range are compared with the clock of the computer doing the pricing. The Pricebook applet reference has the full engine-by-engine table.

When two price sets tie

Nothing checks that two price sets in a book have different Priority Levels. When two sets that both match a line share a number, the winner is whichever one the server happened to list first — and the server returns a book’s price sets in no fixed order. You did not choose that winner, and nothing guarantees it stays the same after either set is edited. Give every pair of price sets that can match the same line a different number.

The one place a tie is settled by a person is the till with the POS General applet’s manual promotion selection switched on (POS_MANUAL_PROMOTION_SELECTION): the automatic pass is skipped when a line is added, and the cashier picks from every price set that matches in the Item Details panel. That is worth knowing in its own right — it lets you run overlapping promotions as a menu the cashier offers, rather than a rule you must rank.

Pricing rules that never match

This is the list that saves the afternoon. At the current build, these can be configured, saved and displayed, and never match anything in Sales Invoice, Sales Order or Sales Quotation — and three of them do match at the POS till, which is worse than never matching, because the counter and the invoice then price the same customer differently:

What does work everywhere: Valid Date Range (absolute), Branch, Entity Type, Member Class, Employee Category, Customer Category, Item, Item Code Regex, and the numbered Category 1-10 rules with their Min Quantity and Min Amount thresholds (at the till, set both thresholds or neither).

How to test a rule before you trust it

1. Set the price set’s status to Active and make sure the applet’s Default Pricebook names its book.
2. Reload the applet. The book is read when the applet starts.
3. Raise a draft sales invoice for a qualifying customer and add a qualifying line.
4. Look at the Unit Discount on the line, and at the description beside it — it carries the price set’s name. That name is how you tell which of four rules fired.
5. Change one thing — the quantity, the customer, the date — on a new line, and check it stops matching when it should. Editing the old line’s quantity is not a fair test: the old discount can stay.
6. If the rule is meant for the counter too, repeat at one till. The counter’s engine differs (all line rules must match, both thresholds needed), and this is the step that finds it.

Then discard the draft.

What BigLedger does not do for you here. It never warns about two price sets that overlap, share a priority or contradict each other — a book can hold all three and save cleanly. So keep a one-page priority map beside the book: each set’s number, who it is for, its dates and what it overlaps. Whoever adds a set checks the map first; someone else runs the six steps above before the set goes live. That is the same separation of duties you would want on any change that alters what customers pay across 22 branches.

What success looks like

With all four of GadgetSphere’s rules live, five two-minute tests:

1. An accessory line of 60 units for an ordinary customer shows the Accessories 50+ name and 10%.
2. The same item as a new line of 20 units shows Accessories 10+ and 5%.
3. A line of the promoted laptop shows the promotion’s name — and stops doing so the day after the To date.
4. The Penang rule fires at a Penang branch and not at GS-KV-01.
5. One accessory rung up at a till at GS-PEN-01 shows no tier discount. If it shows Accessories 50+, the tier is missing its Min Amount.

If each test names the price set you expected, the priorities are right.

Common mistakes

The tier and promotion mistakes (tiers in the wrong order, Min Amount as a line total, a tier with Min Quantity only, a promotion edited while tills are open) are with the four scenarios. Reducing the quantity on an invoice line after a tier matched leaves the old discount: delete the line and add it again (why).

Related documentation