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 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 to find the stale ones on your own items, 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 when a copy drifts, and check your own

After this step you will know when the copy goes stale and how to find out whether yours has. A price row made by the item-code generator agrees with its item on the day it is made. It drifts only when the item’s tax code is changed afterwards, because saving the item does not touch the price rows. So an item edited after its price rows were created is not necessarily wrong: an edit to its description or price leaves the tax copy still true. The ones to worry about are the items whose tax code you have ever corrected. For each of those, open the item’s Pricing Scheme tab, open each price row, and compare its Tax Code and Tax Rate with the item’s own Tax tab. A row that disagrees is either a stale copy or one that was born empty, and either way its tax block needs correcting.

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. Lines typed by hand, imported, or created before the field was used do not carry it, so expect some of your lines to have it and some not. 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, some will have a standard price that no longer equals what that row says today. 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 a line that names a price row which 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: How do I give members, retail and wholesale different prices for the same item? 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 30, 2026

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