Designing Pricing Rules
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. 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.
Meet GadgetSphere
GadgetSphere Sdn Bhd wants four things live in the same price book before the year-end sale:
- Accessories: 5% off at 10 units, 10% off at 50.
- A two-week promotion on one laptop model.
- Members get 8% off everything, all the time.
- The Penang branches price one category slightly lower.
All four are price sets in one book. Here is how they coexist.
How a line gets priced — the whole decision, in order
When you add a line to a sales invoice, order, quotation or POS bill, BigLedger:
- Loads one price book — the one named in that applet’s Default Pricebook setting. One book, not several.
- Keeps only the ACTIVE price sets in it. Inactive ones are skipped entirely.
- Sorts them by Priority Level, highest number first.
- 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.
- Then checks the line rules — which items. The first matching line rule wins, along with its minimum quantity, minimum amount and maximum quantity.
- Applies the treatment — the discount, the price, or the points.
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.
Scenario 1: Volume tiers
Tiers are not one rule with three bands. They are three price sets, ordered so the biggest threshold is checked first.
| Price set | Priority | Line rule | Treatment |
|---|---|---|---|
| Accessories 50+ | 300 | Category = accessories, Min Quantity 50 | 10% discount |
| Accessories 10+ | 200 | Category = accessories, Min Quantity 10 | 5% discount |
| (no tier) | — | — | — |
A line of 60 units hits priority 300 first, matches the minimum of 50, discounts 10% and stops. A line of 20 fails the 50 test at priority 300, drops to priority 200, passes 10, and gets 5%.
Get the order backwards and the tiers silently collapse. If the 10+ rule had the higher priority, a 60-unit line would match it first and only ever get 5%. Nothing would tell you.
Min Quantity and Min Amount both default to 0, which means no threshold. You can use them together — “10 units and at least RM 2,000”.
Scenario 2: A two-week promotion
Rules - Doc Hdr tab > Create > Valid Date Range
Choose Absolute Period and set the From and To dates.
The dates are compared against the current date, from 00:00 on the From date to 23:59:59 on the To date. Give the promotion a high priority so it beats the standing rules while it runs, and set its status to Inactive when it is over — or just leave it; once the To date passes it stops matching.
Scenario 3: Member pricing
Rules - Doc Hdr tab > Create > Member Class
Pick the member classes that qualify. Member classes come from the Membership Admin applet, so they have to exist there first.
Two neighbouring rule types behave differently and it matters:
- Member Class is evaluated. Use it.
- Member Label is not — the calculator treats it as satisfied whatever it says, so a price set gated only on a member label applies to everybody.
If members should get 8% off on top of nothing else, give this set a middle priority so a live promotion can outrank it.
Scenario 4: Branch-specific pricing
Rules - Doc Hdr tab > Create > Branch
Pick the Penang branches. Branch rules are evaluated properly.
Company rules are not. A rule on Company is treated as satisfied, so a price set you meant to limit to GSO will apply in GS and GSD too. Where you need per-company pricing, the reliable route is a separate price book per company, pointed at from each company’s applet settings — not a Company rule.
Choosing a treatment
Treatment tab
- Discount Treatment takes an amount off. Default priority 2.
- Sales Treatment sets a price instead of discounting one. It is hidden unless your company has enabled it, and it is not offered at all in the editor you reach from Price Book → Pricing Set.
- Point Treatment awards membership points, with its own points currency, validity period, decimal precision and rounding mode.
Each one takes a Price Source (what it calculates from — standard amount, net amount, transaction amount, unit cost, or a pricing scheme), an Operator (multiply, add, subtract, absolute, or a formula), a Value, and an Apply Treatment To target (net unit price, net amount or transaction amount).
Where a price set carries both a Sales and a Discount treatment, the one with the lower Priority number wins, and a tie goes to the discount. The screen refuses to save equal priorities.
The 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 POS, Sales Invoice, Sales Order or Sales Quotation:
| Rule | Status |
|---|---|
| Item Category | Never matches — use Category 1-10 instead |
| Item Name Regex | Never matches — use Item Code Regex |
| Category Code Regex, Category Name Regex | Never match |
| Company, Member Label, Currency, Settlement Method, OCR Company | Not evaluated — treated as satisfied, so they widen the rule instead of narrowing it |
| Valid Date Range, Relative Period | Never matches — use Absolute Period |
| Anything on the Rules - Multi Line tab | Not read at all |
What does work: 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 quantity and amount thresholds.
How to test a rule before you trust it
- Set the price set’s status to Active and make sure the applet’s Default Pricebook names its book.
- Reload the applet. The book is read when the applet starts.
- Raise a draft sales invoice for a qualifying customer and add a qualifying line.
- 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.
- Change one thing — the quantity, the customer, the date — and check it stops matching when it should.
Then discard the draft.
What success looks like
With all four of GadgetSphere’s rules live, four two-minute tests:
- An accessory line of 60 units for an ordinary customer shows the Accessories 50+ name and 10%.
- The same line at 20 units shows Accessories 10+ and 5%.
- A line of the promoted laptop shows the promotion’s name — and stops doing so the day after the To date.
- The Penang rule fires at a Penang branch and not at
GS-KV-01.
If each test names the price set you expected, the priorities are right.
Common mistakes
| What goes wrong | What you see | The fix |
|---|---|---|
| Volume tiers in the wrong priority order | Everybody gets the smallest discount | Highest threshold gets the highest priority number |
| Priorities numbered 1, 2, 3 | No room to insert a rule later | Number in hundreds |
| Using Relative Period | The rule never fires | Absolute Period with From and To dates |
| A rule on Company or Member Label | The price set applies far more widely than intended | Use Branch and Member Class; use separate books per company |
| Expecting Or across rule types | The price set is narrower than you designed | Every evaluated header rule must pass |
| Editing rules and navigating away | The rules vanish | Rules live in memory until you Save the price set |
| No way to tell which rule fired | Guesswork | The price set’s name appears beside the discount on the line — name your sets accordingly |