Sales That Arrive From Another System — and How to Notice When They Stop

Most of your sales invoices may never have been typed by anybody in your accounts team. They come in from your online store, from EMP, from a marketplace shop, from a till that was offline, or from a spreadsheet somebody imported. This guide is for the person who looks after the books those documents land in. By the end of it you will know how each document shows where it came from, what it does to your books and what it does not, and you will have a five-minute morning check that tells you when a feed has stopped. For most feeds, nothing in BigLedger warns you when one stops: it simply delivers nothing, and that looks exactly like a quiet day.

Meet GadgetSphere

GadgetSphere Sdn Bhd (GS) keys very few sales invoices by hand. Its sales arrive four ways:

• The online store run by GadgetSphere Online (GSO) sends every paid order to BigLedger as a sales invoice through the integration API — about 380 a day.
• The distribution company (GSD) still raises its invoices in EMP, and they sync into BigLedger so that they can be e-invoiced from there.
• Two marketplace shops arrive as sales orders on their own marketplace branch.
• The two Kota Kinabalu branches (GS-KK-01, GS-KK-02) run their tills in Offline Mode, because the mall connection drops in the afternoons.

On a Monday in March the online store’s sync stopped at 14:10. Nothing on any BigLedger screen changed. The first person to notice was a customer, who scanned the QR code on her receipt on Thursday and was told the tax authority had no record of it. By then, 1,140 invoices worth RM 612,300 were sitting in the store and not in the books. This guide is about finding that out on Tuesday morning.

Three things to know first

A synced document is BigLedger’s copy, not the original. The original lives in the system that sent it. If the two disagree, decide which one is the master for that kind of document before anything goes wrong, and write it down. Usually the other system is the master and BigLedger keeps the copy.

Where a document came from is not one field you can filter on. An integration records its own name on every document it sends, but no listing shows that name. What you can see is who created the document and when, and the document type the BigLedger screen stamps on anything keyed through it. Step 1 shows how to read those.

Finalising is the same step, whichever way the document arrived. In BigLedger, saving a document does not post it. Finalising (FINAL) runs one set of checks and then starts the posting: stock, the journal, the receivable, the e-invoice. A keyed invoice and a synced one go through the same finalise step. What differs is who presses it, and whether anybody does — see Step 2.

Before you start

• You can open the Sales Invoice listing in Sales Invoice (Internal) for every company that receives synced sales.
• You know every system that sends sales into BigLedger. If you do not, Step 1 is how you find out. Ask your administrator, or whoever set up each integration, for three things: the name of the login each integration uses, the branches it sends to, and where in the other system you can see a day’s total.
• For each feed you have a daily count, or a daily total, from the sending system. This is the one thing BigLedger cannot give you, because BigLedger only knows what arrived. It is the number that makes the check work.

Step 1: Find out how each of your sales documents arrived

The outcome: for each way sales reach you, you know how to recognise its documents on the listing.

Sales Invoice (Internal) › Sales Invoice

Open the listing and bring three columns into view: Created By, Created Date and Client Doc Type. (If Client Doc Type is missing, an administrator has hidden it in the listing settings. Ask for it back, or ask for the permission that shows it.) Then sort by Created By.

If a document fits none of these — a login you do not recognise, and no screen type code — it came in some other way. The listing cannot tell you which. Ask your administrator which system owns that login before you rely on anything it sends.

The most common mistake at this step: assuming that any invoice with a type code was typed in by you. A BigLedger screen always stamps exactly INTERNAL_SALES_INVOICE. A different code, or a blank, means another system created the document, whoever Created By says it was.

Step 2: Know what each way posts, and what it does not

The outcome: you know which documents are finished when they arrive and which are waiting for somebody.

The checks and the posting behind FINAL are the same for a keyed invoice, an invoice sent through the integration API, an invoice from BigLedger’s standard integration intake and an imported invoice. They all go through the same finalise step. So a synced invoice for a customer with no e-invoice identity fails, or posts, exactly as a keyed one would. The differences are about who presses FINAL:

• An integration can leave a document as a draft. A draft posts nothing and carries no running number, and nothing reminds anybody it is there. If you finalise it by hand, check first that the other system will not send it again.
• Marketplace orders are FINAL the moment they arrive. No marketplace order waits for a person. A marketplace order with no running number is a run that failed, not an order waiting in a queue.
• An imported file finalises only the rows it marks as final. A blank status column gives you a pile of drafts.
• Whether FINAL writes a journal depends on how your company is set up, not on where the document came from. Some businesses use BigLedger for e-invoicing and operations and keep their general ledger somewhere else. For them, no invoice posts a journal, however it arrived. If you are not sure which kind of business you are, run the Missing Journal check in Step 6 on a keyed invoice first.

Step 3: Decide who watches each feed, and when

The outcome: every feed has a named person, a time of day and a test they can pass or fail.

BigLedger keeps no list of the feeds you expect, so it cannot notice when one goes quiet. Someone in your business has to hold that list. Write it down once:

Keep the person who reconciles a feed separate from the person who fixes it. If the person who runs the integration also signs off its daily count, a feed that is quietly dropping one branch’s sales can go unnoticed for weeks.

Step 4: Empty every offline till’s queue before the branch closes

The outcome: every sale rung up today is in BigLedger tonight, not sitting on a till.

POS General › (the till) › Transaction Queue

With Offline Mode on, the till keeps working when the connection drops. It holds each finished bill in a Transaction Queue on that till: in that browser, on that machine. The queue is sent to BigLedger only when:

• somebody opens the Transaction Queue tab and at least 15 minutes have passed since the last send, or
• somebody presses SYNC ALL.

Reconnecting does not send the queue by itself, and nothing sends it on a timer. A till that was offline at 15:00 and back online by 15:20 still has the afternoon’s bills on it at closing time. Nobody opened the tab, so nothing was sent.

At close, the supervisor opens the tab on every offline till, presses SYNC ALL, and waits until the queue is empty.

If you skip this: the bills exist only on that till. The branch’s takings and the stock look wrong in BigLedger until somebody opens the tab. If the browser data on the till is cleared, or the till is swapped, before the queue is empty, those bills are gone from BigLedger’s reach and have to be re-created from the paper receipts.

Step 5: Run the morning arrival check

The outcome: by 10:00 you know that yesterday’s sales from every feed arrived, or you know exactly which feed and how many are missing.

Sales Invoice (Internal) › Sales Invoice › Advanced Search

For each feed on your list:

1. Search with Transaction Date set to yesterday, and the feed’s branches.
2. Sort by Created By and count the rows that belong to the feed’s login. Add up the amount.
3. Compare the count and total with the sending system’s own figure for yesterday. On the Tuesday after the stop in Meet GadgetSphere, the store’s report for Monday said 386 orders and RM 207,450. BigLedger held 212 orders and RM 113,980.
4. Look at the newest Created Date for that login. On a working feed it is from this morning. On that Tuesday it read Monday 14:10. That is the moment the feed stopped, and you can tell support that time to the minute.

What a stopped feed looks like, so you recognise it: nothing is red, no error appears and no status changes. The documents that did arrive are perfect. There are just fewer of them than yesterday, and the newest Created Date stops moving. A short count on its own could be a slow day. A short count, together with a newest Created Date that is hours old, is a stopped feed.

When the count is short:

• Do not key the missing sales by hand. When the feed restarts, the sending system sends them all again. Unless the integration checks for documents BigLedger already holds, you get every one twice, and duplicate invoices on the tax authority’s system are much harder to undo than a late day.
• Tell the person who runs the integration, or support if BigLedger runs it for you (what to send). Give them: the feed, the branches, the date, the count and total you expected, the count and total that arrived, and the newest Created Date.
• Check again the next morning. Confirm the missing day arrived in full, with the original transaction dates, and that nothing arrived twice.

If your invoices come from EMP, your business may also have an EMP Missing Documents screen. A scheduled run compares EMP with BigLedger and lists the documents EMP holds that BigLedger does not. Where it is set up, it also e-mails that list every day. Read it with three cautions:

• It is set up for your business by BigLedger, not by you, and it is not on everywhere. Ask support whether it runs for yours. If it does, the e-mail arriving every day is your heartbeat. An e-mail that stops coming is itself the symptom, and the screen goes on showing the last list it made.
• Refresh removes documents that have arrived since the last run. It does not look for new missing ones.
• Re-Push asks EMP to send the selected documents again. It does not create them in BigLedger. If they still do not arrive, the cause is on the EMP side, and the list’s Syncing Status column shows EMP’s own reason, such as a customer or item it could not match.

Step 6: Check that what arrived went all the way through

The outcome: every synced document is finished: final, posted and on its way to the tax authority.

Once a week, and at month-end before you close:

• Drafts nobody finalised. On the Sales Invoice listing, filter Posting Status to Draft and look for the integration logins in Created By. A draft from an integration is a sale that is not in your books yet. Find out from whoever runs the integration why it stopped short, then finalise it or discard it. Do not leave it for the month-end.
• Invoices with no journal. Ledger And Journal › Error Checking › Missing Journal, for the sales-invoice type and the week. It lists every FINAL document with no journal behind it. For a single document, use Financial Report › Error Checking › Trace Document. Both are described in the cash-sale check. This catches a missing mapping, and it also catches a document that was created already FINAL (Step 2).
• The e-invoice. A synced invoice is e-invoiced from BigLedger like any other one, so check it the same way: Understanding e-invoice statuses. A sale that never arrived is never e-invoiced at all. That is why the morning check in Step 5 is also a tax check.

What BigLedger will not do, and who does it instead

• It will not tell you that a feed has stopped. Nothing compares what you expected with what arrived for an integration. The accounts person for each feed does that every working morning (Step 5), and knows it is fine when yesterday’s count matches the sending system’s.
• It will not send an offline till’s queued bills by itself. The branch supervisor does, at close, with SYNC ALL, and knows it is done when the Transaction Queue is empty (Step 4).
• It will not finalise a draft an integration left behind, or remind anybody it is there. The accounts person sweeps drafts by integration login every week (Step 6), and knows it is done when none is older than a day.
• It will not compare your other system with BigLedger, unless the EMP missing-document report is set up for you, and then only for EMP. Everywhere else, the sending system’s day-end figure is the comparison, and the accounts person makes it. Where the report is set up, the same person notices the day its e-mail does not come.
• It will not stop you keying a sale that the feed will deliver later. That rule is yours to keep: nobody re-keys a synced sale. The person who runs the integration re-sends it, and the accounts person confirms it arrived once (Step 5).

What success looks like

Run this at 10:00 on any working morning. It takes about thirty seconds per feed:

1. For every feed on your Step 3 list, yesterday’s count and total in BigLedger equal the sending system’s, and the newest Created Date for its login is from this morning.
2. Every offline till’s Transaction Queue was empty at close. The supervisor confirmed it, and did not just assume it.
3. There are no drafts from an integration older than a day.

If all three hold, nothing is stuck between another system and your books.

Common mistakes

Reading “no errors” as “no problem”. A stopped feed raises no error. The only sign is a count that is too low, so the count has to be taken.

Re-keying the missing day. It feels responsible, and it doubles your sales the moment the feed recovers. Fix the feed and let it re-send.

Trusting a list that has stopped updating. The EMP Missing Documents screen shows its last run. If that run was days ago, a short list means the report stopped, not that the feed is healthy. Check that the e-mail came today.

Clearing the browser on an offline till. The Transaction Queue lives in that browser. Empty it with SYNC ALL before anyone clears the cache, reinstalls or swaps the machine.

Letting the integration’s owner sign off its own count. The person who fixes a feed is the person least likely to notice that it drops one branch. Give the daily count to somebody else.

Related documentation

• Sales Invoice (Internal): the listing columns, File Import and the finalise step, field by field
• EcomSync Related Applets: marketplace orders, their background jobs, and their own troubleshooting
• POS General: Offline Mode and the Transaction Queue
• Integration: Getting Started: for whoever builds the integration, including how it should mark its documents and avoid sending one twice
• Cash Sales Workflow: the Missing Journal and Trace Document checks
• Understanding e-invoice statuses