The tenant default that nothing reads any more — 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 has been told to go into Application Settings and set a tenant-wide e-invoice default so that new items at GadgetSphere stop going out unclassified. Do not spend the afternoon on it. In thirteen minutes you will know why it would do nothing, what does work instead, and how to tell the two kinds of setting apart in future.

Step 1 — Find the setting that looks like the answer

After this step you will recognise the trap. The item applet’s Application Settings screen offers three e-invoice defaults: a classification, a taxable type and a unit. They are exactly what the problem calls for. You pick a classification from the same list the item tab uses, you save, and the screen confirms it. Six tenants on the whole platform have done this for the classification and seven for the unit. Every one of them has a value stored that no item has ever seen, because nothing in the product reads these three keys. The screen writes; nobody listens.

Reference: Doc Item Maintenance — Applet settings

Step 2 — Learn that it was deliberate

After this step you will not file this as a bug. The code that read those settings exists and is complete: a three-level fallback taking the value from the form, then the item, then the tenant default, along with a flag marking which fields had come from a default so the screen could say so. It was commented out in November twenty twenty-five, in a commit that says it is removing the e-invoice default integration from the item create and edit forms, raised as a customer request to stop the tab pre-filling a default. Somebody asked for this. What was never done is the other half: the settings were left on the screen, so the product still invites you to configure something it no longer uses.

Reference: Doc Item Maintenance — Applet settings

Step 3 — Ask why a customer would want that

After this step you will understand the argument, which is better than it sounds. A tenant-wide default classification is a guess applied to everything. Set it to Others and every new item is silently Others. Set it to computers and smartphones and your cleaning supplies are too. Either way the item now carries a code, which is worse than carrying none, because the blank was at least visible as a gap. A default that fills a compliance field for you converts an obvious omission into an invisible misstatement, and it does so on every item created from then on. Removing it is a defensible answer to a real problem.

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

Step 4 — Meet what replaced it

After this step you will know where the codes on your new items come from. The screen kept a default of its own, narrower and harder. Open the E-Invoice tab on an item with no classification and it fills in Others, and marks the form as changed so the value is saved with everything else. That is the same guess the removed setting made, with the choice taken away from you. It fires on the tab, not at creation, so an item created and never opened on that tab keeps a genuine blank — and both end up as Others at submission anyway. The difference is only in what your own item list will show you afterwards.

Reference: Doc Item Maintenance — E-Invoice tab

Step 5 — Use the mechanism that does work

After this step you will have a real answer to give. There is one thing that outranks the hard-coded Others, and it is the Item Template. A template carries field defaults, it is chosen on the create screen’s first tab, and if it names a classification the tab will not overwrite it. That is the supported way to make every new accessory Others on purpose, every new handset computers and smartphones, and every new gift card the voucher code. Categories can carry e-invoice defaults too. Both work per group of items rather than per tenant, which is the granularity this decision actually needs.

Reference: Doc Item Maintenance — Create item

Step 6 — Take away the habit, not just the fact

After this step you will spend fewer afternoons like this one. A settings screen is a promise made by one applet, and nothing checks that another part of the product ever kept it. Two questions catch most of it. What changes on a screen when this key is set — if you cannot name the visible difference, do not assume there is one. And what does the system do when the key is absent, which is the behaviour almost every tenant is actually running, since most keys are saved nowhere. Our applet reference answers both per key, and it is worth reading before configuring rather than after.

Reference: Doc Item Maintenance — Applet settings

How the steps fit together

    flowchart TD
  s1["Step 1 — Find the setting that looks like the answer"]
  s2["Step 2 — Learn that it was deliberate"]
  s3["Step 3 — Ask why a customer would want that"]
  s4["Step 4 — Meet what replaced it"]
  s5["Step 5 — Use the mechanism that does work"]
  s6["Step 6 — Take away the habit, not just the fact"]
  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: Three lists, and the one that was never filled · Back to the series · Play this as a presentation