Three lists, and the one that was never filled — 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 is about to set e-invoice values on several thousand GadgetSphere items and wants to know what they are choosing from. The three fields on that tab are backed by three completely different kinds of list, and one of them is empty in almost every tenant. Fourteen minutes, and it will save you a failed bulk fix.

Step 1 — Look at the classification list you are choosing from

After this step you will know how much choice you have. The classification list holds forty-five codes, from breastfeeding equipment at zero-zero-one to self-billed non-monetary payments at zero-four-five. They were inserted into every tenant by a database changeset in twenty twenty-four and never touched again. Every one of the ninety tenants holds exactly forty-five rows; not one holds forty-six. So this is not a list your tenant has drifted away from, and it is not a list anybody is keeping current either. It is a photograph of what the tax authority published on one day, copied everywhere, and left.

Reference: Doc Item Maintenance — Classifications

Step 2 — Understand what “never refreshed” costs you

After this step you will know what to do when the code you need is not there. There is no synchronisation with the tax authority. If a code is published after that seed, nobody’s tenant will have it, and nothing will tell you it is missing — you will simply not find it in the drop-down and will pick something close. The screen does have a Create form, taking a code, a name and a type, with the Malaysian e-invoice type as the only choice. So the answer is to add the row by hand. The consequence worth planning for is that you must add it in every tenant and every company you run, and nothing will remind you.

Reference: Doc Item Maintenance — Classifications

Step 3 — Compare it with the tax-type list, which behaves

After this step you will have a control to measure the others against. The taxable type list is six rows, and all ninety tenants hold all six. It is small, stable, published rarely and seeded properly, so it is the one of the three where what you see on your screen is certainly what a colleague sees on theirs. Keep it in mind while reading the next step, because it is the reason you can be confident the measurement is real rather than an artefact: when a query finds six rows everywhere and forty-five rows everywhere, a third list that is present in seven tenants and absent in eighty-three is telling you something true.

Reference: Doc Item Maintenance — E-Invoice tab

Step 4 — Find the list that was never filled

After this step you will know the strangest fact in this series. The unit of measure has two lists, not one. The drop-down on the E-Invoice tab is a list of roughly two thousand unit codes compiled into the applet itself — it ships with the screen, so it is always there and always identical. There is also a database table for the same thing, created by the changelog and never given any rows. Seven of the ninety tenants have data in it. Eighty-three have an empty table. Nothing on any screen depends on that table, so nobody has ever noticed, and for typing a unit into an item it genuinely does not matter.

Reference: Doc Item Maintenance — E-Invoice tab

Step 5 — Find out where it does matter

After this step you will not lose a column in a bulk fix. The item file import resolves a unit differently from the screen. It does not use the compiled list; it looks the code up in that database table. In a tenant where the table is empty the lookup finds nothing, the failure is caught and discarded, and the unit column is quietly left off the item. No error row, no warning, no mention in the upload’s result. You will believe you have set the unit on four thousand items and the field will still be blank on all of them — and every line will go out in pieces, which is the value you were trying to correct.

Reference: Doc Item Maintenance — Troubleshooting

Step 6 — Plan the bulk fix around what each list can do

After this step you will know how to spend the effort. The classification is the field worth bulk-loading: the list is present everywhere, the import resolves it, and a correction reaches documents that have not yet been submitted. The taxable type is also resolvable and rarely worth setting, because the line’s tax amount decides it anyway. The unit is the one to do on the screen, or through a template on new items, unless you have first confirmed that your tenant has rows in that table. And before any of it, check whether a code you need is even in the forty-five.

Reference: Doc Item Maintenance — Import Item

How the steps fit together

    flowchart TD
  s1["Step 1 — Look at the classification list you are choosing from"]
  s2["Step 2 — Understand what 'never refreshed' costs you"]
  s3["Step 3 — Compare it with the tax-type list, which behaves"]
  s4["Step 4 — Find the list that was never filled"]
  s5["Step 5 — Find out where it does matter"]
  s6["Step 6 — Plan the bulk fix around what each list can do"]
  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: Getting a catalogue ready, and proving it · Back to the series · Play this as a presentation