Support & Troubleshooting

Find answers to common questions here, and know where to go when the documentation does not cover your problem.

Start here

Troubleshooting

Troubleshooting lives with the thing that breaks, not in a separate section. Each applet reference page carries a Troubleshooting section naming the errors that applet actually produces and what to do about them — start from the applet you were using when the problem appeared.

Meet GadgetSphere: one rejected invoice, five places the answer could be

GadgetSphere Distribution finalised a RM 38,500 sales invoice to a corporate customer yesterday, and the customer wants the e-invoice in its own name. This morning the record in My E-Invoice Admin → Internal Submission → To IRB E-Invoice reads Invalid. The instinct is to write to somebody. Choosing who — or whether — is a person’s job, and the moment to do it is before the message is written, by working down this list and stopping at the first rung that answers. Each rung below it costs a round trip, and most problems end on the first two.

1. The screen, then the applet’s own page. The record’s Validation Error Table already names the field, LHDN’s code and the message — here CF358, an invalid buyer tax number — so the question is not what went wrong but how to put it right, and that is on the applet page’s Troubleshooting section and on the rejections guide: correct the buyer on the record’s own Account tab and press Save and Resubmit. What that button sends is the buyer on the record, not the customer record. The record copied the customer when it was built, and a customer corrected afterwards changes nothing on it, so fix the record first and then the customer, or the same rejection is waiting on that customer’s next sale. Fifteen minutes, nobody written to.

2. The FAQ, when the question is what should I do rather than what broke. Suppose the buyer turns out to have no tax number at all, or the name on the e-invoice is meant to differ from the account you billed. Both are on the e-invoice FAQ page: a buyer without a tax number (what to send) and a buyer who is not the billed customer (is that wrong). The FAQ is the right rung for a question another business has already asked, which is most of them.

3. Your own administrator. My E-Invoice Admin is not in your applet list, or Save and Resubmit comes back refused as not authorised. Neither is a fault and neither is ours: the applet comes from the Applet Store, and the right to resubmit is a permission granted at Settings → Permission Set / Role Permission — both inside your tenant, by someone holding owner or admin rank. Teams and permissions says who that is and what a grant looks like.

4. Your BigLedger contact. The document is in none of the pools, not in the Posting Queue, and has no record under To IRB E-Invoice at all. That is the one case in this story that is ours: the gate that admits a document to e-invoicing runs once, at finalisation, and putting a document it dropped back into the Posting Queue is done from our side. Send the document number, the company and when it was finalised — the date is what identifies the batch — through your contact, because the message names your tenant.

5. The public tracker. What is left is a question about the product with nothing of yours in it, or a page you believe is wrong. Ask on BigLedger-Support/public with the document number and the customer left out; the answer is written once, in the open, for the next distributor with the same question.

Getting help from a person

Open an issue at BigLedger-Support/public — BigLedger’s public inquiry tracker. Anyone can post there, you can see what other people have already asked, and the answer stays visible for the next person with the same problem. Say which applet you were in, what you expected to happen and what happened instead. Because anyone can read it, keep your tenant code and your own records out of the post: a question about the product belongs there, a question about your own tenant does not.

Your BigLedger contact — the person or partner who onboarded your company — is the fastest route for anything specific to your tenant: permissions, e-invoice authorisation, applet registration, or data questions. They can see your configuration; the documentation cannot. If nobody in your organisation knows who that is, ask for the contact on the tracker — that question carries no detail of your own, and the answer gives you a private route for the one that does.

Our service commitment

This commitment covers questions raised on the public tracker, BigLedger-Support/public.

Every new issue gets a first response within three Malaysian business days — Monday to Friday, excluding Malaysian public holidays. The first response is an acknowledgement or a first answer: it tells you the question has been read and, where the answer is short, gives it. It is not a promise of when the matter will be resolved, because that depends on what the question turns out to be.

After that, the issue is triaged, labelled and answered in the open, and the answer stays visible for the next person who asks the same thing. If we need more from you to answer, we ask on the issue.

It does not cover anything specific to your own tenant — permissions, authorisations, your data, or documents that need repairing. Those go to your BigLedger contact, as the section above says, because they can see your configuration and work on it privately.

If your company has a support agreement with BigLedger, that agreement sets the terms of your own support, and where the two differ, your agreement applies. The three-day target is what we aim for on the public tracker. It is a target, not a contractual guarantee.

When the only answer is support — and exactly what to send

Pages across this wiki end a fix at ask support, ask your BigLedger contact or ask your administrator. That is an honest ending only if the page says why you cannot do it yourself and what to put in the message, so here it is once, and every page that points here means it.

First, check it is not yours to do after all

Suppose your request is “a background job is not running on my tenant”: an e-invoice sweep that never fires, a replenishment run that never happens, a notification that never goes out. Check this before you write. The schedule itself is a row in your own tenant’s cron table, and the Scheduler applet writes it. If Scheduler is in your applet list and you hold the schedule-create permission, you can add the clock yourself: *Scheduler →

• → click Scheduler Code → pick the processor from the Select Processor picker → set the cron expression → Status ACTIVE*. That picker is also the only screen in the product that shows you which job processors your tenant actually has, which is worth knowing before you ask anyone anything. (Not for now: a known defect.)

Read the Scheduler listing before you press +. If a row for that processor is already there, the question is why it has not fired — its Last Run Date is where that starts — not whether to add one. Nothing in the product stops you creating a second row for the same processor, and if you do, both of them fire.

If Scheduler is not in your menu, or + is refused, that is not a request to us. Applet access comes from the Applet Store and the permission from Settings → Permission Set / Role Permission — both inside your own tenant, and both your own administrator’s to grant. Ask them before you ask us — that distinction is the last section of this page.

Do not stop there, and do not guess the rest from this page. The cron expression is parsed with the UNIX five-field definition, a new schedule’s first firing is computed forward from the moment you created it, a job that needs properties takes them on the row’s Json tab, and Run — on the schedule’s Edit screen — fires it once so you find out today instead of tomorrow. All of that, and how to tell a schedule that never fired from one that fired and failed, is on the Scheduler applet page, including how to try it safely first. Which processor you need is on the page for the thing that is not happening — the Peppol guide names the Peppol sweep, the e-invoice applet page names the e-invoice ones.

What you cannot do from there is make a processor appear in that picker in the first place. So the honest split is:

What to send

The rows that end with us need different things, because different things have to be built at the other end. Sending the wrong bundle costs you a round trip.

Which “us”? Your BigLedger contact for anything naming your own tenant — that is every request on this page. The public tracker is for a question about the product itself, and because anyone can read it, keep your tenant and your data out of the post.

A processor that is not in your picker, or a schedule only we can create. Until a known defect is fixed, that is every schedule: the Scheduler screen shows only ERR for everyone (what still works). A schedule row holds three things: a processor code and a cron expression, which it will not save without, and the properties the job may need when it runs. Name all three, then your tenant:

• the processor code, exactly as you have seen it written — not “the Peppol sweep”. If you do not have a code, say which screen is not doing its job and let the reply supply it;
• the cadence — how often, and whether a time of day matters (a consolidation sweep a few days before the 7th is a different request from “hourly”);
• the properties the job needs, where you know them: which company and branch, because several jobs read a company from their properties and abort the whole run if it is missing;
• and separately, your tenant code and what you expect to see once it runs, so the reply can tell you whether it did. The tenant code is not your company code and not your branch code — three different codes, and sending the wrong one costs a round trip. If you are not certain which is which, say so and name your company instead; the reply can look the tenant up.

An applet that is not in the Applet Store. Name the applet, the login or team that needs it, and what you are trying to do with it — a few applets have a registry row that is deliberately retired and a different applet is the answer, and that reply is faster than an install.

A credential, token or seeded row. Say which one, which company, and — for anything with a test and a live side, such as the LHDN intermediary configuration — which environment. Configuration put on the wrong environment looks exactly like configuration that was never done.

Repairing documents that have already been written. This is the one where detail decides whether it can be done at all:

• the document numbers, or an export of them — a list beats a description every time;
• what you expected to happen and what happened instead, in that order;
• when it was finalised, and whether anything downstream has already picked it up — reported to LHDN, matched on a bank reconciliation, included in a submitted return. A document that has been reported is not corrected, it is superseded, and that changes the answer;
• what you have already tried. Re-finalising, undoing to draft and voiding all leave their own traces, and unpicking them comes first.

What not to send

Do not paste a password, an access key or an API token. Nobody here needs one, and a key that reaches a ticket has to be revoked. Do not send a spreadsheet of live customer records when the document numbers would do.

If the answer is “ask your administrator”, we do not mean us

Some pages send you to your own administrator instead — the person in your organisation who holds owner or admin rights. That is a different route and a faster one: permissions, applet settings that hide a tab or a button, and per-user defaults are all changed inside your tenant, by someone who already has the rights to do it. If a page tells you to ask your administrator and does not tell you which screen they should open, that is a fault on the page — tell us and we will fix it.

What success looks like

Thirty seconds, whichever rung you stopped on.

• You fixed it yourself. To IRB E-Invoice, filtered to the document, reads Valid — not Submitted, which means LHDN has not answered yet, not that anything is wrong. For any other applet, the check is the one its Troubleshooting section names for the symptom you had.
• You asked your administrator. The applet is in your list, or the button that refused you no longer does. Try the same action again rather than asking whether it was done.
• You wrote to your contact or to the tracker. Read the message back before sending: it names a document number, a company and a date, and holds no password, token or customer list. On the tracker, the issue has a number, and a first response arrives within three Malaysian business days; if the fourth passes with nothing, comment on the same issue rather than opening another. A reply that asks you for something you already had to hand means the bundle was short — the lists under What to send are the checklist for next time.

What to read next

If you stopped on rung 1 or rung 4, read the e-invoice applet page’s weekly check — the seven screens that show the pipeline is moving — which is how the silent case in rung 4 is caught before month-end instead of after it. For every other applet, the next page is the one for the applet you were in, at its Troubleshooting section: Applets.