Where the number came from, and what the line forgets — 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 for whoever at GadgetSphere has to answer “why is this line RM 1,710 when the list says RM 1,899” about a document somebody raised three months ago. In about thirteen minutes you will know which field on the line each engine writes, why the same promotion prints as a discount on one document and as a price on another, and what the document does and does not remember.

Step 1 — Know which field the book writes on an invoice

After this step you will read a sales invoice line correctly. The invoice engine deliberately leaves the standard price alone. It computes the adjustment, writes the whole of it into Unit Discount, and puts the result in Unit Price Net. So the line keeps a visible before and after: list price, discount, net. Alongside it the applet records each treatment that was applied, with the price set’s name, which is what appears as the description. That is the shape an accountant expects, it survives into the printed document, and it is the reason an invoice is the easiest of the three screens to audit after the fact.

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

Step 2 — Know why a till line can look like it was never discounted

After this step you will stop trusting the discount column at a counter. The till writes the computed figure into the line’s transaction and net amounts and then derives the discount as the difference from the standard amount. With most operators that gives the same before-and-after an invoice gives. With the Absolute operator it does not: the till also overwrites the standard price with the absolute value, so the standard and the net become the same number and the discount comes out as zero. The bill then shows a price, not a saving. Nothing was lost and nothing is wrong with the money — but a report that counts promotional discount at the counter will not see it.

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

Step 3 — Accept that the line does not remember the book

After this step you will know why “which promotion priced this” is a hard question. There are two columns on every document line for exactly this — a price book header reference and a price set reference. The backend checks them as foreign keys when they are filled, and a listing query will filter on them. Nothing writes them. Measured across every tenant database, the price book reference is empty on every document line in every tenant that has any, tens of millions of rows without a single exception. The only trace a price set leaves is its name, copied into the line’s description as text.

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

Step 4 — Make the name carry the weight it has been given

After this step you will have a policy that costs nothing and saves a great deal. Since the name is the audit trail, name price sets so that a string on a line is enough to identify them a year later: a period, a scope and a mechanism, not “Promo 3”. Never rename a price set that has already priced documents, because renaming changes nothing on the old lines and now two different strings mean the same rule. And never reuse a name after a campaign ends. This is the same discipline you would apply to a journal reference, for the same reason — it is the only handle the history has.

Reference: Pricebook — Price Set — Details

Step 5 — Use the guard the sales invoice gives you

After this step you will know which screen protects a promoted price and which does not. On a sales invoice the price field is read-only unless an applet setting allows editing, and when it is allowed, typing over a price that a treatment produced raises a Manual Price Override dialog that names the treatment and warns that continuing removes it. Confirm, and the treatment is cleared rather than silently layered over. At the counter there is no such dialog and no marker on a typed price, so a later change to the customer on the bill can re-resolve the line from the scheme and take the typed price away with it.

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

Step 6 — Answer the question in this order

After this step you will have the routine. Given a line and the question “where did this number come from”, work outwards. Start with the line’s description, which names the price set if a price book priced it. Then find that price set and read its treatment: the operator, the value and the price source tell you what it did to the number it was given. Then establish what it was given — the price list the document opened on, which is the previous series in this programme. Only then consider that a human typed it, which on a till leaves no evidence at all. Four steps, and the first one is a string you must have made meaningful in advance.

Reference: Pricebook — Troubleshooting

How the steps fit together

    flowchart LR
  P["price the line opened with"] --> T["treatment"]
  T --> I["Sales Invoice<br/>Unit Price Std kept<br/>Unit Discount written<br/>Unit Price Net = result"]
  T --> C["POS, Absolute operator<br/>unit_price_std overwritten<br/>discount computes to zero"]
  I --> N["price set NAME<br/>in the line description"]
  C --> N
  N --> Q["the only audit trail:<br/>pricebook_hdr_guid is<br/>never written"]
  

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: What a price book will not do · Back to the series · Play this as a presentation