Fix a whole book of customers at once — 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 when the problem is not one customer but four hundred. GadgetSphere carries roughly eighty-five thousand customer entities and about twelve hundred suppliers, and a list that size is never corrected by opening records. About sixteen minutes, covering the one bulk tool e-invoicing has — which does something quite different from what its name suggests — the lookup BigLedger already runs for you, and the parts that still come down to somebody typing.

Step 1 — Decide the shape of the job before you open anything

After this step you will know which of your problems has a bulk route and which does not. Export or list your customers and sort the work into three piles. Customers whose tax number is missing or wrong, which is the pile with a real bulk tool behind it. Customers whose identity type is wrong, typically a foreign buyer keyed as a Malaysian individual. And customers with no usable e-invoice address, which is a third job again. Size the piles first, because the bulk tool covers more of the second pile than you would expect and none of the third.

Reference: Customer Maintenance — Screens and menus

Step 2 — Send the whole book a request, instead of chasing them one at a time

After this step four hundred missing tax numbers becomes one file. In the My E-Invoice Admin applet, open Tools, then Bulk Tin Validation. Download the template from the screen, and look carefully at what is in it: a name, an e-mail address, a phone number and a customer code. There is no column for a tax number. You are not uploading corrections. You are naming the customers whose identity BigLedger should check with the Inland Revenue Board and, where that check fails, write to. Choose the delimiter that matches your file, comma or pipe, attach the single file and submit it.

Reference: My E-Invoice Admin Applet — Fields

Step 3 — Know what happens to each row after you press Submit

After this step a quiet screen will stop worrying you. For every customer the file matches, BigLedger reads three fields together: identity type, identity number and tax number. If all three are present and the board says they agree, nothing happens at all — no row, no e-mail, and no screen anywhere telling you that customer passed. If the board says no, or if any of the three is blank, a request row is created carrying a random six-character access key. A second job then takes that row and e-mails the customer a link. So silence after an upload usually means most of your list was already correct.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 4 — Know what your customer’s reply writes, and who approves it

After this step you will stop planning a separate job for identity types. Your customer opens the link and keys their tax number, identity type and identity number. The board is asked to validate all three together before anything is saved, and an invalid set is refused outright. A valid one writes five fields onto your customer record: tax number, identity type and identity number on the E-Invoice tab, and the identity number and type on the Main tab as well. Nobody in your office approves it and nobody is asked to. That is the point of the design, and it is why the identity types you were dreading as a separate import are already covered.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 5 — Know when a request expires, and who never receives one

After this step you will plan around a campaign you cannot watch. The e-mail goes to the address on the customer’s own record, so a customer with no e-mail address is never contacted and nothing tells you that. Reminders go out at most every two days, up to ten of them, and the row is deleted after the tenth — or after thirty days, answered or not. Nothing sweeps up afterwards and nothing reports on it. So run the upload, give it a month, then list your customers again and see who is still missing a number. Those are the ones you telephone.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 6 — Fix addresses and contacts the other way

After this step you will not expect one tool to solve everything. The request campaign corrects identity and tax numbers when a customer answers. It touches nothing else, and contact numbers and e-invoice addresses sit behind a great many pooled documents. For those, the Customer applet’s own File Import takes a customer template, and File Export downloads the customer database for offline editing and re-import. Before you round-trip eighty-five thousand records that way, check that the file you get back actually carries the e-invoice columns you intend to edit — the applet page calls it the customer database without saying which columns it holds. Prove it on a handful of records first.

Reference: Customer Maintenance — Import, export, merge

Step 7 — Let the lookup do the large corporate ones for you

After this step you will stop keying tax numbers you never needed to key. When BigLedger turns a queued document into an e-invoice it checks three things together: the amount is ten thousand ringgit or more, the buyer’s identity type is a business registration number, and the tax number is blank. When all three hold it searches the board by that registration number and writes the tax number it finds back onto the customer, onto the document and onto the e-invoice. So a corporate buyer with a registration number and a large order may correct itself. Below ten thousand nothing is searched, which is why a small corporate sale with a blank number simply parks.

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

Step 8 — Use the lookup by hand, and know which of the two buttons does it

After this step you will get more out of a pool row than most people do. Open an Individual Pool row and the buyer block offers two actions beside the tax number, and they are not the same thing. Get TIN searches the board by identity type and identity number and fills the field for you. Verify TIN checks a number you already hold against that identity pair, and can never hand you one. Neither carries the ten thousand ringgit condition the automatic search has. So press Get TIN on a small corporate sale too, and run Verify when you onboard a business customer, because nothing else in BigLedger ever checks that number.

Reference: My E-Invoice Admin Applet — Fields

Step 9 — Merge the duplicates instead of deleting them

After this step your list will shrink without losing history. A customer who has transacted cannot be deleted, and a large list usually carries the same buyer two or three times, entered slightly differently at different branches. The Customer applet has Entity Merging for exactly this: pick the record that survives, pick the duplicates to fold into it, and watch the job on the Entity Merge Processing screen. It is also the answer when a save is refused because another record already holds that customer reference. Merging keeps the transactions attached to one record, so the e-invoice fields you fix are the ones the next sale reads.

Reference: Customer Maintenance — Import, export, merge

Step 10 — Know how you would find out any of this ran

After this step you will have a realistic picture of what tells you anything. Not much does. The bulk run writes no report: the evidence is a customer record whose fields have filled in, and a document that has left a pool. The lookup writes a tax number with no notification, and no page documents a completion report for either. There is no ageing alert on any pool or queue in the whole of e-invoicing. The one thing that comes to you is a per-company e-mail listing failed individual-pool transactions as a spreadsheet, and whether that job is scheduled on your tenant is a question for support rather than a setting you can see.

Reference: Pools and queues — How it behaves in BigLedger

How the steps fit together

    flowchart TD
  s1["Step 1 — Decide the shape of the job before you open anything"]
  s2["Step 2 — Send the whole book a request, instead of chasing them one at a time"]
  s3["Step 3 — Know what happens to each row after you press Submit"]
  s4["Step 4 — Know what your customer's reply writes, and who approves it"]
  s5["Step 5 — Know when a request expires, and who never receives one"]
  s6["Step 6 — Fix addresses and contacts the other way"]
  s7["Step 7 — Let the lookup do the large corporate ones for you"]
  s8["Step 8 — Use the lookup by hand, and know which of the two buttons does it"]
  s9["Step 9 — Merge the duplicates instead of deleting them"]
  s10["Step 10 — Know how you would find out any of this ran"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  s6 --> s7
  s7 --> s8
  s8 --> s9
  s9 --> s10
  

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: Let your customers key their own details · Back to the series · Play this as a presentation