When the book and the scheme disagree — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is the centre of the series, for whoever at GadgetSphere has a price book and more than one pricing scheme. In about thirteen minutes you will know what happens when a price set names a scheme — and the answer is three different things on three different screens, which is why this behaviour has been so hard to pin down.

Step 1 — See what the question actually is

After this step you will have the question framed correctly. GadgetSphere runs a Retail list, a Member list and a Wholesale list, and every item carries a price on each. A document opens a line on one of those lists. Now a price set matches, and its treatment says Price Source: Pricing Scheme, naming Member. Two layers now have an opinion about this line’s price. The interesting part is not who is right — it is that the platform answers this question differently depending on whether you are standing at a counter, editing a sales invoice, or keying a sales order, and nothing on any of those screens tells you which answer you are getting.

Reference: Doc Item Maintenance — The price on a document line

Step 2 — At the till, the book wins and rewrites the standard price

After this step you will know what a counter actually does. When the till applies the treatment, it looks the named scheme up among the item’s pricing-scheme links, takes that scheme’s sales unit price excluding tax, and writes it onto the line as the standard price before applying the operator. So the “before” figure printed on the bill is not the price the line opened with — it is the book’s choice of list. Then the operator runs on top of it. If the item has no link to the named scheme at all, the till silently falls back to the amount already on the line, with no message and no marker. The book wins here, completely, and it covers its tracks.

Reference: Pricebook — Where the number came from, and what the line remembers

Step 3 — On a sales invoice, the same setting does nothing

After this step you will stop expecting parity between a till and an invoice. The sales invoice applies treatments through a different engine, which understands exactly three price sources: the moving-average cost, the standard amount and the net amount. A pricing scheme is not one of them. The engine does not warn, does not refuse and does not fall back to a default source — it simply keeps working on the price the line already had. So the identical price set that re-lists a line at the Member price at a counter merely discounts the branch’s own price on an invoice. Two documents for the same customer and the same item can carry two different prices, both correct as configured.

Reference: Pricebook — Which engine prices your line

Step 4 — On a sales order, it is a filter, not a price

After this step you will have the third meaning. The sales order path passes the line’s own pricing scheme into the engine, and the engine uses the treatment’s named scheme as a gate: any price set whose treatment names a different scheme is skipped, and the search moves to the next price set. Nothing is re-priced from the scheme. So on that screen the field answers “does this promotion apply to lines on the Member list”, which is a genuinely useful question and a completely different one from “take the price from the Member list”. One field, one stored value, and three readings.

Reference: Pricebook — Which engine prices your line

Step 5 — Decide which of the two jobs you wanted

After this step you will be able to configure this deliberately instead of hopefully. Ask which sentence you mean. If it is “this promotion is only for customers we sell at Member prices”, that is qualification, and it belongs on the Doc Hdr tab as a Member Class or Customer Category rule, which every engine reads the same way. If it is “charge this line from the Member list”, that is pricing, and the honest way to get it everywhere is to have the document open on the Member list in the first place, which is a decision the customer record and the branch default already make. Naming a scheme on a treatment gives you whichever of the two the screen happens to implement.

Reference: Pricebook — Where the number came from, and what the line remembers

Step 6 — Check it before you trust it

After this step you will have a test you can run in five minutes. Take one item that has a price on two schemes with a clear difference between them, and put it through three documents: a cash bill at a counter, a sales invoice, and a sales order. Compare the unit price, the discount and the net on all three. If the till shows the other scheme’s price as its starting figure and the invoice does not, you have reproduced everything in this lesson on your own data. Then repeat the till test with a quantity of two, because the counter’s arithmetic on this price source mixes a unit figure with a line total, and that is worth seeing before a customer does.

Reference: Pricebook — Where the number came from, and what the line remembers

How the steps fit together

    flowchart TD
  T["treatment.pricing_scheme<br/>one stored value"] --> A["POS General<br/><b>a PRICE</b><br/>overwrites unit_price_std"]
  T --> B["Sales Order<br/><b>a FILTER</b><br/>skip price sets naming<br/>another scheme"]
  T --> C["Sales Invoice<br/><b>NOTHING</b><br/>price source not implemented,<br/>falls back to the line"]
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: Where the number came from, and what the line forgets · Back to the series · Play this as a presentation