Skip to content
The customer the whole group shares, and whose e-invoice it is — transcript

The customer the whole group shares, and whose e-invoice it is — transcript

Presentation 3 of 4 in E-invoice across a group of companies and its branches · about 11 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 presentation is for whoever maintains customers for a group and has just been asked “if all three companies sell to the same customer, whose e-invoice is it?” In about eleven minutes you will be able to answer that, say which of the customer’s e-invoice facts follow them into every company, and settle where a document’s submission type comes from.

Step 1 — Recognise that the customer is one record and the suppliers are three

After this step the question will have a shape. GadgetSphere’s retail company sells a corporate customer a batch of laptops, the online company sells the same customer accessories, and the distribution company wholesales to them. In BigLedger that is one customer record, because the customer list is one list for the whole tenant, by design: a shopper who buys at one branch and returns the item at another has to be the same record, found by both counters, and the same rule carries the corporate customer across the three companies. The tax number, identity type and e-invoice address were typed once, by whoever created the record, and every company’s sales screen reads them from the same place.

Reference: Organization — What the organisation tree does not divide

Step 2 — Answer whose e-invoice it is

After this step you can answer in one sentence. The e-invoice belongs to the company on the document. When the retail company’s invoice is finalised, the supplier block is built from the retail company’s record — its tax number, its address, its industry code — and the buyer block is the customer as the document holds them, snapshotted onto the document when it was raised and read from there in the order buyer details, then entity details, then the record itself. So three companies invoicing one customer produce three e-invoices with three different supplier blocks and the same buyer. Nothing about the shared record makes the invoice the group’s; the group is not a taxpayer, and neither is the tenant.

Reference: My E-Invoice Admin Applet — 2 posting queue to irb or a pool cron e_invoice_generic_document_to_irb_processor

Step 3 — Know that the skip flag travels with the customer, not the company

After this step you will set one checkbox with three companies in mind. The customer record carries a Skip e-Invoice flag, and at the moment a document is finalised the platform asks three questions in a row: is the document itself marked skip, is its branch marked skip, is its customer marked skip. Any yes silences the document. The customer question is asked by the customer’s identifier alone, with no company in it. So when the online company skips a marketplace platform’s entity because the platform reports those sales itself, the retail company’s sales to that same entity are skipped as well, silently, from the same tick of the same flag. There is no per-company skip on a customer, and there is no setting that gives you one.

Reference: My E-Invoice Admin Applet — Which level each e-invoice fact lives on — tenant, company, branch

Step 4 — Know the other two facts that travel the same way

After this step you will not be surprised by a number format or a self-billed invoice. A customer record can carry its own e-invoice running-number pattern; when any company in the group issues an e-invoice to that customer, the customer’s pattern is looked up first and wins over the issuing company’s own pattern. And a supplier record carries a self-billed flag; every company’s purchase invoice screen picks it up from the same record, so marking a supplier self-billed for the distribution company marks them for the retail company’s purchases too. These are not defects. Master data is group-wide because the trade is group-wide. The discipline it asks of you is to set a customer’s flags as the group, never as one company.

Reference: Organization — What the organisation tree does not divide

Step 5 — Find out where the submission type actually comes from

After this step you will stop looking for a default that does not exist. The submission type — Individual, Consolidated, Single General or blank — is a value on the document, not on the customer, not on the company, and not on a document-type setup screen, because there is no such screen. The sales invoice applet starts a new invoice at Individual. The point of sale starts a new cash bill with nothing, and only a cashier’s choice on the E-Invoice panel fills it; across the customer base, most finalised receipts carry no type at all. Blank is routed through the mandatory-field check, so a walk-in who gave full details gets an individual e-invoice without anyone choosing it, and an incomplete one goes to the Batch Pool with the missing fields written on the row. An explicit Consolidated skips that check entirely.

Reference: E-Invoice Pools & Submission Routing — Submission types

Step 6 — Check it on one customer in thirty seconds

After this step you will have seen the whole lesson on your own screen. Open the shared customer once and note the tax number and the skip flag. Then open one document to that customer from each company and go to the E-Invoice tab. The buyer details are identical on all three, because they came from the one record; the supplier details differ, because they came from three companies. The Submission Type reads Individual on a sales invoice that nobody touched, and is empty on a counter receipt unless the cashier chose. If the skip flag on the record is ticked, none of the three documents has an e-invoice at all — which is the fact to remember before anyone ticks it for one company’s convenience.

Reference: My E-Invoice Admin Applet — Which level each e-invoice fact lives on — tenant, company, branch

How the steps fit together

    flowchart TD
  s1["Step 1 — Recognise that the customer is one record and the suppliers are three"]
  s2["Step 2 — Answer whose e-invoice it is"]
  s3["Step 3 — Know that the skip flag travels with the customer, not the company"]
  s4["Step 4 — Know the other two facts that travel the same way"]
  s5["Step 5 — Find out where the submission type actually comes from"]
  s6["Step 6 — Check it on one customer in thirty seconds"]
  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. The online company ticks Skip e-Invoice on a marketplace platform's entity. What happens to the retail company's sales to the same entity?


2. Three companies invoice the same customer in one month. What differs between the three e-invoices?


3. Where does a new point-of-sale cash bill's submission type come from?


4. A walk-in gives full details on a RM 300 receipt whose submission type is blank. What happens?


5. A customer record carries its own e-invoice running-number pattern. Which pattern is used when the distribution company invoices them?


Answer key
  1. They are skipped too — the flag is on the one shared record and is read by the customer's identifier aloneMy E-Invoice Admin Applet — Which level each e-invoice fact lives on — tenant, company, branch
  2. The supplier block — the buyer block comes from the same record on all threeMy E-Invoice Admin Applet — Which level each e-invoice fact lives on — tenant, company, branch
  3. Nowhere — it starts blank, and only the cashier's choice on the E-Invoice panel sets itE-Invoice Pools & Submission Routing — Submission types
  4. It passes the mandatory-field check and becomes an individual e-invoice without anyone choosing itE-Invoice Pools & Submission Routing — Submission types
  5. The customer's pattern — it is looked up first and wins over the issuing company'sOrganization — What the organisation tree does not divide
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: What a branch does and does not do to an e-invoice · Back to the series · Play this as a presentation

Last updated on