Skip to content
Guide
Daily Tasks
Pricing Schemes: How a Line Gets Its Price

How a line gets its price from a pricing scheme, and why an old invoice keeps its old price

Part of setting up pricing schemes: the order in which a document line gets its price, and what it keeps. Read it before you change a price that branches are already selling at. It follows Steps 1 and 2, where the schemes and their prices are set up, and Step 3 comes next.

What happens when a line is priced

Behind the scene, a line gets its price in a fixed order, and it is worth knowing because each step is a place a “wrong” price can come from.

  1. The applet works out a default scheme. It takes the Default Pricing Scheme on the branch record of the document’s branch, and only when that is blank the applet’s own Default Selection › Default Pricing Scheme. The applet’s settings, and at a till the role links in Step 3, are read when the applet starts.
  2. It asks for every price the item has. One request per line, to the item’s price rows, returns every ACTIVE row on every scheme. The request carries no customer and no date, so a price typed against a customer on the item’s Entity Pricing tab, or a validity date on a price row, plays no part. At a till the request is narrowed to the schemes the cashier’s role may sell at (Step 3).
  3. One scheme is picked. In the back office: if the item is priced on exactly one scheme, that one; otherwise the customer’s own Pricing Scheme, if the item has a price on it; otherwise the default from step 1. At a till: a scanned barcode is priced at the default from step 1, and the Add Item panel takes the highest-priority scheme in the POS branch list that has a price above zero.
  4. A price book adjusts it. The price book starts from whatever unit price step 3 put on the line (Pricebook applet).
  5. The line keeps a copy. Picking a price writes onto the line the unit price with and without tax, the minimum price, the replacement and reference prices, a tax code — which comes from the first of the customer’s own branch (outlet) record, the customer’s Tax tab, the price row, the item or the company default that has one (the Pricing Scheme tab) — and a pointer to the price row it came from.
  6. Saving the document refreshes part of that copy — not the price. Every time the document is saved, the server reads the price row the line points at, as that row is now, and rewrites the line’s replacement price and replacement cost, its reference, delta, rebate and promotion prices, and its minimum and maximum prices. If the line carries no points of its own, the row’s reward-point setting fills the line’s item points. The unit price, the discount, the tax and the line amounts are left exactly as they were.
  7. After Finalise, everything works from the line. The posting processors that Finalise starts — journal, stock, cashbook, e-invoice — take the line’s own amounts, so the e-invoice line’s unit price and subtotal come from the line, not from the price list. This split is what lets you change a price list without disturbing a single issued document. Two things read the price list again later: a commission scheme whose price source is Pricing Scheme reads the item’s price in that scheme at the moment the commission is written, and Item Price Change (Step 5) reads the recorded history.
    flowchart TD
  DEF["Default scheme<br/>branch record, else the applet's<br/>Default Selection"] --> ROWS["Every ACTIVE price row<br/>the item has · at a till,<br/>the role's schemes only"]
  ROWS --> PICK["One scheme picked<br/>back office: the only one priced,<br/>else the customer's, else the default"]
  PICK -.->|"a matching price set"| PB["A price book adjusts it"]
  PICK --> LINE
  PB --> LINE["The line keeps a copy<br/>prices, tax code,<br/>pointer to the price row"]
  LINE -->|"every save"| REF["Reference figures re-read<br/>from the row as it is now<br/>unit price left alone"]
  LINE -->|"Finalise"| POST["The posting processors Finalise starts<br/>journal, stock, cashbook, e-invoice<br/>take the line's own amounts"]

Why an old invoice keeps its old price

Step 5 above is a snapshot — the same design BigLedger uses for the customer’s details on a document. A document is the record of what was agreed with the customer at the time of the sale; if a price-list change reached back into last month’s invoices, a reprint would no longer match the paper the customer holds. So a price change travels forward only.

Two consequences you will meet:

  • Opening an existing line to edit it does not re-price it. The picker shows the scheme the line came from and leaves the price alone. To take the new price, pick the scheme again on that line.
  • 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.

What does move on a re-save is the set of reference figures in step 6. A draft saved before a price change and saved again after it carries the old selling price beside the new minimum and replacement figures.

Next: Step 3: Say which scheme each applet sells at.

Related documentation

Last updated on
Setting Up Pricing SchemesPricing Schemes: Which Scheme Each Applet Sells At