Pick the level, and know what it costs — 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 you if you have decided some GadgetSphere sales are not yours to report and now have to choose where to say so. The same flag sits at three levels and the three are wildly different in blast radius. About eleven minutes, and the aim is that you pick the narrowest level that does the job, and leave a note saying why.

Step 1 — Skip one document when one document is the exception

After this step you will know the safest of the three and its one limitation. On any of the three pools you can skip a single row, which deletes the pool row and marks that document skipped. Use it for the genuine one-off: an order that turned out to be somebody else’s to report, a sale abandoned after finalising, a document raised in error that you will not void. It is precise and it catches nothing you did not choose. Its limitation is obvious — it is one row at a time, and somebody has to notice each one before the consolidation sweeps it.

Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do

Step 2 — Skip a customer when the relationship is the exception

After this step you will use the customer flag for what it is for. On a customer’s E-Invoice tab, beside their identity, tax number and address, there is a skip flag. Setting it excludes every future document raised for that customer, which is right when the relationship itself is the reason — a partner who invoices the end buyer directly, an intercompany account inside the GadgetSphere group whose documents are reported elsewhere. Be careful with it for a retail customer record that your tills fall back on, because that single record can carry a great deal of a branch’s daily takings.

Reference: Customer Maintenance — Edit customer

Step 3 — Skip a branch only when the whole shop is the exception

After this step you will treat the branch flag with the respect it needs. One tick on one branch takes every document that branch will ever raise out of e-invoice reporting, silently, while the branch carries on trading exactly as before. There is no banner, no warning and no daily reminder. That is correct and useful for a channel where the platform reports the sale, and it is a serious accident anywhere else, because the first symptom is a month-end report that quietly shows a whole shop as unreported. Never set it on a branch that also takes ordinary retail sales.

Reference: Organization — Branch Details, Pick Pack, Extension and Marketplace

Step 4 — Recognise the design the branch flag was built for

After this step you will see why this is a feature and not an oversight. A branch record carries marketplace fields as well as its address, which tells you what kind of branch the designers had in mind: a selling channel whose orders arrive from an outside platform rather than over a counter. For a channel like that, every order is reported by the platform, so the correct setting is one flag on one record — not a flag on eighty thousand order documents, and not a flag on every buyer. Modelling the channel as its own branch is what makes the one tick safe.

Reference: Organization — Branch — Details, Address and Marketplace

Step 5 — Audit all three before you trust any of them

After this step you will have a way to see the flag you did not set. Because the three combine, the only reliable check is the outcome rather than the settings: run your monthly report and read the skipped documents total before you read anything else. If that number is larger than the sales you consciously decided not to report, something upstream is skipping for you. Then work backwards — which branch, which customer — rather than reading three screens hoping to spot a tick. The total is the instrument; the tick boxes are just where it comes from.

Reference: E-Invoice Submission Mechanics — The discrepancy report: what “missing” means

Step 6 — Write the reason down, because the tick outlives it

After this step you will have saved your successor a bad afternoon. These flags are typically set once, during a migration or when a new channel opens, by somebody who had a perfectly good reason and is no longer in the room. A year later the flag is still there and the reason is not, and nobody dares clear it because nobody knows what it was for. Put the reason in the record’s own description, and in whatever your finance team treats as its configuration log, on the same day you set it.

Reference: Organization — What breaks elsewhere when something here is wrong

How the steps fit together

    flowchart TD
  s1["Step 1 — Skip one document when one document is the exception"]
  s2["Step 2 — Skip a customer when the relationship is the exception"]
  s3["Step 3 — Skip a branch only when the whole shop is the exception"]
  s4["Step 4 — Recognise the design the branch flag was built for"]
  s5["Step 5 — Audit all three before you trust any of them"]
  s6["Step 6 — Write the reason down, because the tick outlives it"]
  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: What happens behind the scene when you skip · Back to the series · Play this as a presentation