How do I give members, retail and wholesale different prices for the same item? Setting up pricing schemes
“How do I give members, retail and wholesale different prices for the same item?” With a pricing scheme for each: the same item carries a standard price in every scheme, and the branch, the applet and the customer decide which scheme a document line opens with, so nobody types a price on the document.
A pricing scheme is how the same item carries more than one standard price — one for walk-in retail, one for members, one for wholesale — without anybody typing a price on a document. This page sets one up and, more importantly, explains which scheme a given line will use, because that is where the surprises live.
Budget twenty minutes for the first scheme. Copying prices into a second one takes two.
Meet GadgetSphere
GadgetSphere Sdn Bhd prices three ways: Retail in the 22 branches, Member for its loyalty customers, and Wholesale for the distribution company’s corporate clients. Same 5,200 items, three price lists.
Pricing schemes, price books, and which one you want
Both change the price on a line, and they are not the same tool.
| Pricing scheme | Price book | |
|---|---|---|
| What it is | A standard price list — this item costs this much in this scheme | A set of conditional rules — if the customer, the item and the date look like this, adjust the price |
| Where the number lives | On the item, per scheme | In the price set’s treatment |
| Good for | Retail vs member vs wholesale price lists | Promotions, volume tiers, prices for one group of customers |
| Guide | This page | Setting up a price book |
They work together. A line starts at its pricing-scheme price and a matching price set can then discount it. A price set can even be tied to a scheme — a treatment whose price source is a pricing scheme only applies to lines already on that scheme.
If you just want three standard price lists, you want pricing schemes and nothing else.
Step 1: Create the schemes
Doc Item Maintenance > Pricing Schemes > Create
Three fields: the code, which is generated for you; the name, which is required; and a description.
Create Retail, Member and Wholesale. Name them for what they are, because the name is what everybody will see in a dropdown.
The scheme itself holds no prices. It is a column heading.
Step 2: Put the prices in
Doc Item Maintenance > Items > (an item) > Pricing Scheme tab
Each item has a row per scheme. For the flagship smartphone: RM 4,299 retail, RM 4,099 member, RM 3,950 wholesale.
For 5,200 items you do not do this one at a time. Two tools:
- Import Item takes a CSV that includes pricing.
- Export Item exports the current pricing so you can edit it and bring it back — export, edit, re-import is the safe way to make a bulk change.
Copying one scheme from another
Pricing Schemes > (a scheme) > Copy tab
This is the fastest way to create the second and third scheme: duplicate every item price from another scheme, optionally with an amendment. Build Retail properly, then copy it into Member with a reduction, and into Wholesale with a bigger one. Then correct the handful of items where the rule does not hold.
A price for one specific supplier — and why the customer half does not work
Items > (an item) > Entity Pricing tab, or Entity Pricing Import for many at once. A row here ties one item to one counterparty, outside the scheme structure entirely, and it has a purchase half and a sales half.
The purchase half works. Replenishment reads the supplier’s row — purchase price, minimum and maximum order quantity, lead time — when it raises a purchase order for you. Use it sparingly all the same: a dozen supplier prices is maintainable, a thousand is not.
The sales half does not reach a sales document. You can type a sales price for a customer, save it, and see it on the tab afterwards — and no sales order, invoice, quotation or POS line will ever use it. When a line is added, the applet asks the item-scan endpoint for the item’s prices, and that query knows nothing about the customer on the document; it can only see pricing schemes. Nothing warns you, which is what makes this expensive: every invoice to that customer goes out at the ordinary price and looks perfectly normal.
To give one customer a different price, put them in a customer category (Customer Maintenance → Customer Category) and write a price book price set with a Customer Category rule. That rule is one the selling side genuinely evaluates.
Step 3: Say which scheme each applet sells at
This is the step that decides what actually happens, and there is more than one place it is decided.
The branch comes first, not the applet. When a sales applet opens a line it takes the branch’s own Default Pricing Scheme — the field on the branch record, set in Organisation > Branches > edit — and only falls back to the applet’s Settings > Default Selection > Default Pricing Scheme when the branch has none. Both arms of that rule are live, so when one branch sells at a scheme the others do not, look at the branch record before you touch the applet setting.
Then the picker decides what to open with, and it does not always honour either of those. If the item is priced on exactly one scheme, that one is applied and the drop-down is disabled — no default is consulted at all. Otherwise it looks for the customer’s own Pricing Scheme field, and only then for the default above. The customer field is a real override, and it is blank unless somebody filled it in — which is what makes it easy to miss. One scheme saved on one customer record quietly outranks every default you set.
POS has two more layers that the back office does not:
- Branch Settings > Pricing Scheme, with a priority — a second, POS-only branch mechanism, separate from the branch record’s own Default Pricing Scheme above. It is read by the Add Item panel, where the highest-priority scheme the item has a price in wins. A scanned barcode ignores it and prices at the branch record’s Default Pricing Scheme (or the applet default), so a scanned item and a picked one can come in at different prices.
- Role ↔ Pricing Scheme Link — which decides which scheme a role sells at. This is the one that catches people: two cashiers at the same counter, on the same till, can be selling at different prices because they hold different roles.
The role link is a till control, not a company-wide one. POS sends the role’s permitted schemes to the price query and gets back only those. The shared price picker used by Sales Invoice, Sales Order, Sales Quotation and the purchase documents collects the same list and does not send it — the line that would is commented out — so in the back office the drop-down offers every scheme the item is priced on, whatever the user’s role. Nothing creates these role links for you either: they exist only where somebody sat down and built them.
If you are using the role link to stop staff selling at wholesale, it is doing that at the counter and not on a sales order. The POS setting Show All Pricing Schemes also switches the filter off at the till.
And the four tick boxes on that link are not doing anything. Each role-to-scheme row carries Sales Price Read, Sales Price Update, Purchase Price Read and Purchase Price Update. The screen writes all four and the till reads none of them: what it sends to the price query is the list of scheme identifiers, nothing else. No component in any applet repository and nothing in the backend consults the four flags, beyond a search filter on the maintenance listing itself. So a row with Sales Price Update unticked still lets that role’s cashiers change the price. Treat the row as a yes/no — this role may sell at this scheme — and do the rest with ordinary client-side permissions.
So when somebody asks why a price came out differently from what they expected, check in this order: whether the item is priced on only one scheme, then the customer’s own scheme, then the role link if they were at a till, then the branch record’s Default Pricing Scheme, then the applet default, then whether a price book discounted it afterwards.
Step 4: Keep them in step
The commonest failure with pricing schemes is not that they are wrong on day one. It is that Retail gets updated for six months and Member does not, and the gap between them drifts into nonsense.
Pick a rhythm — monthly, or whenever Retail changes in bulk — and use Export Item to compare the schemes side by side in a spreadsheet. It is the only view that shows them all at once.
Step 5: Find out why a price changed
By the end of this step you can answer “it was RM 4,099 last month — why is it RM 3,999 now?” from a record rather than from memory.
Doc Item Maintenance > Item Price Change
Start with the line, not the price list. A document line takes its price at the moment the line is added and keeps it. Changing a price row afterwards travels forward — to the next line anybody adds, and to linked marketplace listings — and never back to lines already on a document. So a draft invoice still showing RM 4,099 after Member dropped to RM 3,999 is not a fault: the line was added before the change. Re-pick the price on that line if the new one should apply.
Then look at the history. Item Price Change is a report, not an editing tool — it changes nothing. Each row is one recorded change to one price row: the item, the scheme, and the old value beside the new for the sales unit, minimum and maximum prices, the purchase unit, minimum and maximum prices, and the delta, reference and rebate prices. For GadgetSphere’s flagship smartphone you might see one row on Member — sales unit price RM 4,099 old, RM 3,999 new — and nothing on Retail, which tells you the gap between the two schemes narrowed on purpose or by mistake, and on which list.
Three things about this report are not on its screen:
- It only knows what was recorded, and recording is switched on per tenant. The history is written by the database the moment a price row is saved with a different value, but only once BigLedger has switched the recorder on for your tenant; no screen switches it on. Before that, nothing was kept, and no report can recover it. An empty report for an item you know was repriced means not recorded, not not changed — ask BigLedger support whether the recorder is on.
- The date range filters on the price row’s latest change, not on each change. Ask for March, and a price changed in March and again in April does not appear at all; ask for April, and both its March and April changes appear. Leave the range open (the screen’s default runs from 2022 onwards) and narrow by item instead.
- The User and Updated Date columns belong to the price row, not to the change. Every history row for one price shows whoever touched that price last, and when. The recorder does keep who saved each change; this report simply does not show it, so for an earlier change ask BigLedger support rather than the person named.
What is recorded is a change to a price, a price’s validity dates, its promotion price and dates, or its tax code and rate. The first price entered on a new row is not a change, and neither is switching a row active or inactive on its own — so a price that appeared or disappeared, rather than moved, leaves no row here.
What success looks like
Three minutes:
- Open an item’s Pricing Scheme tab. All three schemes have a price, and the relationship between them is the one you intended.
- Raise a draft sales invoice line for that item. The unit price is the scheme your applet’s Default Selection names.
- Ask a colleague on a different role to do the same thing on POS. If they get a different price, the Role ↔ Pricing Scheme Link is why — and you now know where to look.
- Open Item Price Change, leave the dates open and search for an item you know was repriced recently. A row with the old and new price means history is being recorded for you; nothing means it is not, and the report cannot help you until BigLedger switches it on.
Discard both drafts.
Common mistakes
| What goes wrong | What you see | The fix |
|---|---|---|
| Expecting the scheme itself to hold prices | An empty scheme that does nothing | Prices live on the item, per scheme |
| No Default Pricing Scheme set on the applet | Lines come in with no price, or the wrong one | Set it in that applet’s Default Selection, then reload |
| Two users getting different prices on the same till | Looks like a bug | The Role ↔ Pricing Scheme Link in POS decides per role |
| One branch pricing differently and nobody knows why | Looks like a bug | POS Branch Settings › Pricing Scheme, with its priority |
| Building the second scheme item by item | Days of work | Use the scheme’s Copy tab, with an amendment |
| Schemes drifting apart over months | Member price higher than retail on some items | Export all schemes periodically and compare |
| Correcting an item’s tax code and expecting the price rows to follow | The invoice still charges the old rate. The price row’s own edit form still shows the old Output Tax Code, and nothing compares it with the item’s | A price row keeps a copy of the item’s tax taken when the row was created and nothing refreshes it. Re-save the price rows, and see the Pricing Scheme tab |
| Treating the minimum price as a rule | Somebody sells below it anyway, through an import or the API | The minimum is checked in the browser only, and only when DISALLOW_SELL_BELOW_MIN_PRICE is on. The maximum price is checked nowhere at all |
| Setting a validity window on a price and expecting it to expire | The expired price is still offered, and still selected | The price query does not filter on those dates; only the POS and Sales Order v2 item search reads them, and only to choose the promotion price |
| Setting a customer’s special price on the item’s Entity Pricing tab | Nothing at all — the price saves, and every invoice still goes out at the ordinary price | Price the customer’s category from a price book price set. Entity Pricing’s purchase half is the half that works, and it is for suppliers |
| Using Item Price Change to change prices | Nothing changes — it is a report | Change prices on the item’s Pricing Scheme tab, or export, edit and re-import |
| Reading an empty Item Price Change report as “nobody changed it” | You rule out a price change that did happen | The report holds only what was recorded after price history was switched on for your tenant — confirm that first (Step 5) |
| Blaming the name in the report’s User column | The wrong person is asked about the change | That column is the last person to touch the price, repeated on every row for it — not the author of each change |
| Using entity pricing for everything | Thousands of one-off prices nobody can audit | Use schemes for price lists and price books for conditional discounts; keep supplier entity prices for genuine exceptions |