One tax rate, four copies, and the one that charged — 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 changed a tax rate and found the next invoice still charging the old one. In about fourteen minutes you will be able to point at the exact record that gave any line its rate, and you will know why there is more than one candidate.

Step 1 — Accept that a rate is stored, not looked up

After this step you will stop expecting a live lookup. A tax rate in BigLedger is copied, not referenced. It is entered once in Tax Configuration, and from there it is copied onto items, onto pricing-scheme links and onto document lines, each copy taken at a different moment. That is deliberate and it is what you want for a tax document: an invoice raised in March at six per cent must still say six per cent after the rate changes in April. The cost of that safety is that the same number now exists in four places and only one of them is the one you edited.

Reference: Tax Configuration — Lifecycle and effects

Step 2 — Learn that the tax code holds two rates, not one

After this step you will know a distinction that decides which screen shows what. Every tax code row carries two rate columns. One is read by document lines. The other is read by every master-data screen that caches a rate — the item’s Tax tab, and the customer and supplier tax tabs. Both maintenance screens write the two together, and across every tenant on the platform they hold the same value on every row, so today this costs nobody anything. It is worth knowing because two different applets maintain the same table, and because the rate you see on an item and the rate an invoice charges are answers from different columns.

Reference: Tax Configuration — Lifecycle and effects

Step 3 — Follow the three routes onto a line

After this step you will know which copy your documents are using. If somebody picks a code in the line editor’s tax drop-down, the line gets the tax code’s current rate, rounded to two decimal places. If the line is built from a pricing resolution, it gets whatever the pricing-scheme link holds — and that link took a copy of the item’s tax code, type and rate when the link was created, and no later item edit refreshes it. If the document arrives through the import endpoint, the line gets the item header’s stored rate directly. Same item, same tax code, three different stored numbers, all of them potentially old.

Reference: Tax Configuration — Lifecycle and effects

Step 4 — See why the refresh usually does not fire

After this step you will understand a rule that reads like a safety net and mostly is not one. There is a refresh: when a document is saved with a line carrying a tax code but no tax type, the platform looks the code up and overwrites the line’s rate with the code’s current one. It sounds like every line would be corrected. It is not, because a line assembled from an item already carries both the code and the type, so the condition is false and nothing is refreshed. The refresh catches lines that arrive half-filled from an integration. It does not catch the ordinary case.

Reference: Tax Configuration — Lifecycle and effects

Step 5 — Know what rounding does to the number

After this step you will not try to configure a fractional rate. Tax Configuration divides the percentage by a hundred and rounds the result to two decimal places, so eight and a half per cent collapses to a whole percent before it is ever saved. A second screen writes the same table without rounding, so a fractional rate can reach the row — but the sales-invoice line editor rounds again when it stamps the rate on a line, so it still does not reach a document. Measured across every tenant on the platform, nobody holds a rate finer than a whole percent. Treat whole percentages as the only rates this platform supports.

Reference: Tax Configuration — Troubleshooting

Step 6 — Change a rate without leaving a trail of old ones

After this step you will know what a rate change actually requires. Editing the code is one step of several. Documents already saved keep their stamped rate, which is correct. Items keep their cached rate until somebody reopens and saves them. Pricing-scheme links keep theirs until the link is rebuilt. So a rate change wants a plan: change the code, then decide whether the items and pricing links that copied it need refreshing, and check what the next few invoices actually charged rather than assuming. And remember what this feeds — the tax amount on the line is what decides the tax type the regulator is told.

Reference: Tax Configuration — Lifecycle and effects

How the steps fit together

    flowchart TD
  s1["Step 1 — Accept that a rate is stored, not looked up"]
  s2["Step 2 — Learn that the tax code holds two rates, not one"]
  s3["Step 3 — Follow the three routes onto a line"]
  s4["Step 4 — See why the refresh usually does not fire"]
  s5["Step 5 — Know what rounding does to the number"]
  s6["Step 6 — Change a rate without leaving a trail of old ones"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

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: Tax Applicable is the switch, and most items have it off · Back to the series · Play this as a presentation