Skip to content
Which of the three a late fix still reaches — transcript

Which of the three a late fix still reaches — transcript

Presentation 2 of 5 in Get your items ready for e-invoice · about 14 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 for whoever has just classified four hundred items at GadgetSphere and wants to know whether the three weeks of invoices already sitting in the queue will benefit. Part of the answer is yes, and the part that is no is the part nobody expects. Fourteen minutes.

Step 1 — Follow one line from the till to the regulator

After this step you will know why this question has an answer at all. When somebody adds an item to a sales invoice, the applet copies the item’s classification onto that document line there and then, and takes the unit and the tax type from the line’s own detail form. So the document now holds its own copy of all three. Much later, when the document becomes an e-invoice, a second routine builds the record for the regulator out of that line. Two copies, made at two moments, weeks apart. Everything interesting about correcting an item late lives in the gap between them.

Screen: a sales invoice line’s item details, showing the e-invoice unit and tax type fields beside the price

Reference: Doc Item Maintenance — E-Invoice tab

Step 2 — Learn the one field that heals

After this step you will know what a late fix buys you. The classification is treated differently from its two neighbours. When the builder finds the document line carrying no classification, it does not give up and it does not reach for a default yet: it goes back to the item master, reads that item as it stands right now, and takes the classification from it. That read happens at submission time, not at sale time. So every document raised before you classified the item, still sitting unsubmitted in a queue or a pool, will pick up the code you set this morning. You do not have to touch those documents at all.

Reference: Item Master Extensions

Step 3 — Learn the two that do not

After this step you will stop expecting too much of the fix. The e-invoice unit and the taxable type have no such second chance. The builder takes them from the document line and nowhere else. If the line was created while the item’s unit field was empty, the line’s unit is empty, and no amount of correcting the item afterwards will change it — the line simply falls to piece at submission. The same is true of the tax type. So one of the three fields you just corrected reaches back in time and two do not, and nothing on any screen distinguishes them. For those two, the only route is cancel and resubmit.

Reference: E-Invoice Submission Mechanics — The record that goes to LHDN is not your invoice

Step 4 — Know when the item never had a say

After this step you will stop diagnosing the wrong field. Two things overrule the item completely. If the document is going out as part of a consolidated e-invoice, every line is stamped with the consolidation classification and a quantity of one, whatever the item said — so a beautifully classified catalogue makes no difference at all to a month of consolidated cash bills. And the taxable type is derived from the line’s own tax amount: no tax on the line gives not applicable, tax on the line gives sales tax, regardless of what the item’s tab says. The item’s taxable type only survives when the line carries tax and the item says something other than not applicable.

Reference: Consolidated e-invoices

Step 5 — Contrast it with the account code, which works the other way

After this step you will stop generalising from one master-data field to another. The account an item posts to behaves in the opposite direction. The selling applets copy the item’s account onto the line when the line is added, and the posting routine uses the line’s copy first — so correcting an item’s account changes nothing already raised, and a purchase invoice line pulled from a goods receipt ignores the item entirely and keeps the account the older document carried. Same record, same screen, two fields, two opposite answers to the question “does fixing this now help?” The only safe habit is to know which field you are asking about.

Reference: Doc Item Maintenance — Main tab

Step 6 — Turn it into a rule you can follow

After this step you will have something short enough to remember. Fix the classification whenever you notice it, because the fix reaches every document that has not yet been submitted, and it costs nothing. Fix the unit and the taxable type for the future only: assume every existing document keeps whatever it copied, and if a particular document matters enough, cancel and resubmit it rather than hoping. And before you spend a day on any of this, check whether the sales you care about go out consolidated, because if they do, the classification on those lines was never going to be yours.

Reference: Cancelling and Correcting a Validated E-Invoice

How the steps fit together

    flowchart TD
  s1["Step 1 — Follow one line from the till to the regulator"]
  s2["Step 2 — Learn the one field that heals"]
  s3["Step 3 — Learn the two that do not"]
  s4["Step 4 — Know when the item never had a say"]
  s5["Step 5 — Contrast it with the account code, which works the other way"]
  s6["Step 6 — Turn it into a rule you can follow"]
  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.

1. You classify an item today. A sales invoice for it was finalised last week and is still waiting in a pool. What classification is submitted?


2. You set the e-invoice unit on the same item today. What happens to that same waiting invoice?


3. A month of cash bills goes out as a consolidated e-invoice. How much does classifying those items change?


4. An item's taxable type says Not Applicable and the invoice line carries tax. What is submitted?


Answer key
  1. The one you set today, because the item is re-read when the record is builtItem Master Extensions
  2. Nothing — the unit comes from the line only, so that line still falls to H87 pieceE-Invoice Submission Mechanics — The record that goes to LHDN is not your invoice
  3. Nothing — consolidation stamps its own classification on every lineConsolidated e-invoices
  4. Sales Tax, because the tax amount on the line decidesMy E-Invoice Admin Applet — Before you can use it
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 tenant default that nothing reads any more · Back to the series · Play this as a presentation

Last updated on