Keeping pricing schemes in step, and finding out why a price changed

Steps 4 and 5 of setting up pricing schemes: keep the schemes consistent as prices change, and answer “why is this price different now?” from a record. It follows Step 3. The running example is GadgetSphere’s flagship smartphone at RM 4,299 Retail, RM 4,099 Member and RM 3,950 Wholesale, sold across 22 branches; How a line gets its price explains why a price change travels forward only. Once a document is FINAL, VOID or DISCARDED, the scheme picker is locked: a finalised invoice at the old price is corrected with a credit note, not by re-picking.

1. Step 4: keep them in step.
2. Step 5: find out why a price changed.

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.

BigLedger keeps no rule that ties one scheme to another — after a Copy, Member is a separate list, and a later change to Retail does not reach it. Keeping them in step is the price-list owner’s job. Pick a rhythm — monthly, or whenever Retail changes in bulk — export all three schemes with Export Item › Doc Item Pricing and compare them side by side in a spreadsheet; it is the only view that shows them all at once. You have got it right when every item’s Member price sits below its Retail price and above its Wholesale price, by the margin you meant.

Changing a price while 22 branches are selling

A price change is one save in head office and a different moment in every branch. This is what each part of GadgetSphere sees when the flagship smartphone’s Member price drops from RM 4,099 to RM 3,999 at eleven in the morning:

Changing a branch’s Default Pricing Scheme, rather than a price, also queues a marketplace update for every item priced in the new scheme — for a 5,200-item list, that is 5,200 updates.

What breaks is consistency between branches for a few hours, not any document. The software does the forwarding; the timing is yours. Make the change before branches open or after they close where you can. When you cannot, tell branch managers in the same message which drafts to re-pick, and ask any branch running a till offline to sync it. Then check it worked: add the phone to a new back-office line for a customer on Member, and look for RM 3,999.

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 for this part

Exported side by side, every item’s Member price sits below its Retail price and above its Wholesale price, by the margin you meant. After a reprice, a new back-office line for a Member customer shows the new price (RM 3,999 for the phone), and Item Price Change, with the dates left open, shows a row for an item you know was repriced, old price beside new, if price history is recorded for your tenant.

Common mistakes in this part

The rest of the task’s mistakes are on the front page and with Step 3.

Related documentation

• Setting up pricing schemes — the whole task.
• Doc Item Maintenance applet — the Pricing Scheme tab, the Copy tab and Item Price Change.
• Commission Scheme applet — commission paid on a scheme’s price.