A price row remembers the item as it was — transcript

Presentation 4 of 5 in Where a price and its tax came from · about 12 minutes · for the whole-system operator — you run the books.

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 about the single most-asked shape in BigLedger support: a number that is right on one screen and wrong on the document, with nothing in between to explain it. In about twelve minutes you will know exactly which copy is stale, how many of them are stale across the whole platform, and what you can and cannot conclude from the link a posted line keeps.

Step 1 — Learn that a price row carries its own tax

After this step you will know a price record holds more than a price. Besides the amounts, each one carries a full tax block: an output code, type and rate, an input triple, and both withholding triples — twelve columns in all. They are not a reference to the item’s tax. They are a copy of it, taken at one moment, and nothing on the screen says so. When the row is created by the item-code generator, those twelve columns are copied straight off the item header. Every other way of creating a price row copies none of them, and the validator fills each missing rate with zero. So two rows on the same item can disagree from birth.

Screen: the item’s Pricing Scheme tab, a price row’s edit dialog with its own Tax Code and Tax Rate boxes

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 2 — See how far the copies have already drifted

After this step you will know the size of the problem, not just its shape. Across all ninety tenant databases, a price row’s output tax rate differs from its item’s on about fifteen thousand rows in fifteen tenants, against ten million rows where the two agree in fifty-four tenants and one point one million where one of the two is null in forty-five. So realised drift is small. The exposure is not: the item has been edited more recently than its price row on about seven point three million rows in sixty-three tenants, against four million the other way in sixty-five. Most of those items simply never changed their tax code. The ones that did are the fifteen thousand.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 3 — Recognise the pattern, because it is not unique here

After this step you will spot this shape elsewhere without being told. The item’s own Tax tab caches the tax code’s filing rate the same way. The customer’s Tax tab freezes a whole tax row into a stored extension. And now the price row holds twelve columns copied from the item. Three master records, three frozen copies of something that lives somewhere else, none of them refreshed and none of them showing the reader that they are a copy. When a rate is wrong and the tax code is right, the question is never whether the platform is confused. It is which of the three copies was taken before the change.

Reference: Doc Item Maintenance — Tax tab

Step 4 — Follow a posted line back to its price

After this step you will know what a finished line can tell you. Every line that was priced through the picker records the identifier of the price row it came from. Across the platform, about four point eight million document lines in thirty-five tenants carry that identifier, and thirty-one million lines in seventy-four tenants do not — lines typed by hand, imported, or created before the field was used. Where it is there, it is the only thread from a posted invoice back to a price list, and it is what makes a real answer to “where did this number come from” possible instead of an opinion.

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

Step 5 — Know what that thread does not prove

After this step you will read the comparison honestly. Of the lines that do name a price row, about one point eight million in thirty-one tenants have a standard price that no longer equals what that row says today, against three million in thirty-five that still match. That is not all drift: a price list that has legitimately been repriced since the invoice will produce exactly the same difference, and so it should. What the comparison gives you is a candidate list, not a verdict. The stronger signal is the smaller one: about one thousand eight hundred lines in seven tenants name a price row that is no longer active at all.

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

Step 6 — Do the three things that keep the copies honest

After this step you will have the habits. First, when you correct an item’s tax code, re-save its price rows — the correction does not reach them and no screen will tell you. Second, when you create price rows by any route other than the item-code generator, expect their tax block to be empty and fill it or accept that the cascade will fall through to the item. Third, at the till, attach the member before adjusting any price: nothing marks a typed price as typed, and changing the entity on a bill re-resolves every line from the scheme. All three are ordering problems, and all three are free to avoid.

Reference: Setting Up Pricing Schemes — Common mistakes

How the steps fit together

    flowchart LR
  TC["Tax code<br/>2 rate columns"] -->|"copied once"| IT["Item header<br/>Tax tab"]
  IT -->|"copied once,<br/>only on one creation path"| PR["Price row<br/>12 tax columns"]
  IT -.->|"other paths copy nothing:<br/>rates default to 0"| PR
  PR --> LN["Document line"]
  IT --> LN
  LN -->|"keeps the price row id"| PR
  style PR fill:#fff3cd,stroke:#856404

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.

1. You correct an item's output tax code from six percent to zero. What happens to its price rows? They are refreshed when the item is saved
They are refreshed the next time a document reads them
Nothing — the tax block on a price row is a copy taken when the row was created, and nothing refreshes it

2. Two price rows on the same item carry different tax rates, and one is zero. What is the likely cause? They were created by different routes — one copied the item's twelve tax columns, the other copied none and was defaulted to zero
One of them was edited by a user
The tax code itself has two rates

3. A posted invoice line's standard price no longer equals the price row it names. What may you conclude? The line was tampered with
Only that they differ — a legitimate reprice since the invoice produces the same result, so this is a candidate list, not a verdict
The price row was deleted

4. At the till, a cashier types a price and then attaches a member. What should you expect? The typed price is kept, because a manual price wins
The line can be re-resolved from the scheme, because nothing marks a price as typed
The member cannot be attached once a price is typed

Answer key

Nothing — the tax block on a price row is a copy taken when the row was created, and nothing refreshes it — Doc Item Maintenance — Pricing Scheme tab
They were created by different routes — one copied the item's twelve tax columns, the other copied none and was defaulted to zero — Doc Item Maintenance — Pricing Scheme tab
Only that they differ — a legitimate reprice since the invoice produces the same result, so this is a candidate list, not a verdict — Doc Item Maintenance — The price on a document line
The line can be re-resolved from the scheme, because nothing marks a price as typed — POS General — Branch Settings — what each tab actually reaches

This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Next: The guard rails on a price, and which of them are real · Back to the series · Play this as a presentation

Last updated on September 18, 2026

A price row remembers the item as it was The guard rails on a price, and which of them are real