Getting a catalogue ready, and proving it — 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 the one to do rather than read. GadgetSphere has five thousand items and the e-invoice tab was an afterthought on most of them. In about fourteen minutes you will have an order of work that fixes the future first, the volume second, and proves itself against the only evidence that counts.
Step 1 — Stop creating the problem before you fix it
After this step your backlog will stop growing while you work on it. Every item created between now and the end of this project is another item to fix, unless the creation path itself supplies a classification. So the first thing to change is not the catalogue, it is the templates: one per class of thing you sell, each naming the classification that class should carry. A template default is also the only thing that stops the E-Invoice tab quietly writing Others the moment somebody opens it. Doing this first takes an hour and removes an entire category of work from the rest of the project.
Reference: Doc Item Maintenance — Create item
Step 2 — Fix by category, not by item
After this step you will not try to classify five thousand things by hand. The forty-five codes are coarse on purpose: for a consumer-electronics group, most of the catalogue falls into a handful of them, with phones and computing under one code, gift cards under another, and everything that fits nothing else under Others — chosen this time rather than defaulted. So the unit of work is the category, not the item. Export the catalogue, sort by category, decide the code once per category, and fill the column down. The decisions take an afternoon; the typing is a spreadsheet operation.
Reference: Item Master Extensions
Step 3 — Send the file back knowing what it is
After this step you will upload without a bad surprise. Three things about the item import are worth holding in mind and are covered in full elsewhere in this library. Every row is matched on item code, so a file of existing codes is an edit of those items rather than a batch of new ones. A failed upload has usually already written most of its valid rows. And the e-invoice unit column will resolve only if your tenant happens to have rows in the unit table — in most tenants it is dropped in silence, so treat that column as unreliable and set the unit through templates instead.
Reference: Doc Item Maintenance — Import is an upsert, not a create
Step 4 — Collect the documents the fix reaches for free
After this step you will get more out of the same work. Anything finalised but not yet submitted will pick up the classification you just loaded, because that field alone is re-read from the item when the record for the tax authority is built. So the moment the import finishes, the queue of unsubmitted documents is already better than it was, with no action from you. It is worth doing the import before a submission run rather than after one, and worth knowing that the same is not true of the unit or the tax type, which every existing line keeps as it copied them.
Reference: Item Master Extensions
Step 5 — Verify against what was sent, never against the item list
After this step you will stop proving the wrong thing. The item list cannot confirm this work. A blank classification is substituted at submission, and the tab pre-fills Others by itself, so an item list with no blanks in it is consistent with a catalogue nobody has ever classified. The evidence is on the other side: the submitted records. Open the To IRB listing, take a day of it, and read the classification actually on those lines. If a day’s phone sales still show Others, something between the item and the line is not what you think it is, and you have found it in a day rather than in a tax audit.
Reference: My E-Invoice Admin Applet — Screens and menus
Step 6 — Leave behind a check somebody will actually run
After this step the work will not decay. Two habits keep a catalogue classified. Once a month, when you pull the submitted records for any other reason, glance at the spread of classifications: a healthy consumer-electronics month is mostly one or two codes with a tail, and a month that is almost entirely Others means new items have been arriving without a template. And whenever somebody adds a product line, add its template in the same week. Neither is a report anybody has to build, and between them they are the difference between doing this once and doing it every year.
Reference: E-Invoice Submission Mechanics — The discrepancy report: what “missing” means
How the steps fit together
flowchart TD
s1["Step 1 — Stop creating the problem before you fix it"]
s2["Step 2 — Fix by category, not by item"]
s3["Step 3 — Send the file back knowing what it is"]
s4["Step 4 — Collect the documents the fix reaches for free"]
s5["Step 5 — Verify against what was sent, never against the item list"]
s6["Step 6 — Leave behind a check somebody will actually run"]
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.
Answer key
- Otherwise every item created during the project is another one to fix, and the tab writes Others by itself — Doc Item Maintenance — Create item
- Edited those 4,000 items, because a row is matched on code and a match updates — Doc Item Maintenance — Import is an upsert, not a create
- Almost nothing, because the tab pre-fills Others and blanks are substituted anyway — Doc Item Maintenance — E-Invoice tab
- The submitted records in the To IRB listing, reading the classification actually sent — My E-Invoice Admin Applet — Screens and menus