Skip to content
An online order is missing from BigLedger

An order is on the shop and not in BigLedger

“The order is in the seller centre, and it is not on the marketplace branch.” The shop says it sold; BigLedger has no sales order for it, so the stock was never held back for it and it will never be invoiced. This page is for whoever runs a marketplace shop day to day, and whoever counts its orders each morning. There is no general alarm for an order that fails to arrive (some jobs e-mail about one cause, below), so absence is usually the only symptom you get, and the check below is yours to run.

The fast path.

  1. Look for it as a draft first. Look for the marketplace order number among the marketplace branch’s sales orders, drafts as well as FINAL ones. An order that is there in draft or with no running number is not missing: skip to It arrived, and stopped half-way.
  2. Check the clock. In the Scheduler, the shop’s order job has an ACTIVE row, and its Last Run Date is within one tick of the clock (its cron period, not the job’s interval). Last Run Date moves when the clock fires, not when the job succeeds, so a recent date is necessary, not sufficient.
  3. Check the connection. On the branch’s connection record, Remarks begins Auto updated by after a good credential refresh and reads Failed to refresh credentials after a bad one.
  4. Check the item. Every item on the order is linked to a listing on that branch: the item’s Marketplace tab in Doc Item Maintenance names the shops it is linked to.
  5. Then bring it in: fix what the checks found, and widen the order job’s interval once, by hand, so that the next run reaches back past the order’s date (Bring the order in).

Meet GadgetSphere

GadgetSphere Online Sdn Bhd (GSO) sells through a Shopee shop on branch GSO-SHOPEE. The order job runs every fifteen minutes and asks Shopee for orders updated in the last hour. On a Monday morning the seller centre shows 212 orders for Sunday and the branch shows 187. Somebody paused the clock at midnight on Saturday to test a change, and switched it back on at 10 a.m. on Sunday.

Why an order goes missing

The order job reads a window, not a bookmark. Each run asks the shop for orders whose time falls in the last interval (the job’s own setting) and fetches only the ones not already on the branch. The time is the order’s creation for Lazada, and for Shopee the time field the job is set to use (creation or last update). It does not remember where the last run stopped.

So any stretch longer than the interval during which no run worked (a paused clock, a lapsed authorisation, an outage) leaves orders that no later run will look at. For GSO-SHOPEE, the 25 orders placed and last updated between midnight and 9 a.m. on Sunday fell outside every window once the clock restarted.

Four causes you can check yourself, in this order:

CauseWhat you seeWhere it is recorded
The job did not run. The clock is INACTIVE, missing, or its code is one the clock cannot startA branch that is quiet while the shop is busy; Last Run Date old or not movingThe Scheduler listing
The gap was longer than the window. Runs failed or stopped for longer than the intervalOrders missing from one stretch of time, and arriving normally on each side of itNothing records it. The count is the only evidence
The authorisation lapsed. The shop’s token expired and the refresh failedEvery order from that shop stops at onceThe connection record’s Remarks and Updated date. BigLedger records a Shopee token as good for four hours and a Lazada one for about thirty days, so a stopped refresh shows on a Shopee shop the same day and on a Lazada shop weeks later
An item is not linked to a listing on the branch. The order job asks the shop for the product and tries to create the listing itself; this is what is left when that failsNo order, on every job we traced; some jobs also e-mailThe e-mail, where the job sends one (below)

What an unlinked item does, job by job. The newer Shopee order job (SHOPEE_ORDERS_V2) creates no order and sends no missing-item e-mail; every later run tries the order again while it is still inside the window, so linking the item quickly brings it in by itself.

The Lazada job creates no order and e-mails the job’s address list, Missing Order Items from Lazada store, naming the items. The older Shopee order job (SHOPEE_ORDERS) e-mails Missing Order Items from Shopee store, and keeps the orders it could not finish on a list it works through before it fetches a new window. We have not traced this case for Shopify or TikTok Shop.

If all four checks pass and the order is still missing, the run itself may have failed (the shop’s answer, or a branch, company or location the job needs). Send support the marketplace order number, the branch, the order job’s code, and the time the order was placed (what to send).

Bring the order in

  1. Fix the cause first. Switch the clock back to ACTIVE, re-authorise the shop, or link the item to its listing in Doc Item Maintenance. A wider window on a job that still cannot run brings in nothing.
  2. Widen the interval once. On the order job’s clock in the Scheduler, raise the interval in its JSON payload so that it covers the gap, back to before the first missing order. For GSO-SHOPEE, from one hour to two days. A note in the job’s code says Shopee allows at most fifteen days; we have not confirmed that limit. If the payload holds a password, key or token, do not save it from the Edit screen (Scheduler): ask support. On the older Shopee job you may not need this step: once the item is linked, it retries the orders it could not finish.
  3. Let one run complete, then put the interval back. A wide window on every run asks the shop for far more than it needs, run after run. The orders the branch already holds are skipped, so the wide run creates only what was missing.

It arrived, and stopped half-way

  • A draft with a line on the connector’s placeholder item (on the connectors that use one). Put the right item on that line and finalise the order by hand. Link the item to its listing too, or the next order for it does the same.
  • Magento or SelluSeller. Orders from those connectors are created unfinalised: finalising them is a person’s job on every order.
  • No running number on a Shopee, Lazada or TikTok Shop order. Those orders are numbered and finalised in the run that creates them, so this is a failed run. Re-running the order job will not repair it, because every order job skips an order already on the branch. Report it to support the same morning with the marketplace order number and the branch (what to send).

What success looks like

Run the count again for the day that was short. Yesterday’s order count in the seller centre equals yesterday’s sales orders on the branch, none of them is in draft or without a running number, and the interval on the order job’s clock is back to its usual value. For GSO-SHOPEE: 212 and 212.

Who looks for these, and when

The person named for each shop, every morning, for the previous day. The check is the one in Best Practices §6: the seller centre’s count against the branch’s count, plus anything on the branch in draft or unnumbered. Name one person per shop, and a deputy for their leave. Make sure the order job’s e-mail list names a person who is at work, not an old shared mailbox. The count is the only alarm for the newer Shopee job, which sends no e-mail at all.

Whoever changes a clock writes down when it was off. A clock paused for a test is the commonest gap we know of, and the person who paused it is the only one who knows the window to widen.

Common mistakes

  • Widening the interval before fixing the cause. The run asks for more orders and still cannot create them. Fix, then widen.
  • Leaving the wide interval in place. Every run then asks the shop for days of orders. Put it back after one good run.
  • Letting a gap grow old. The wider the window, the more the run asks the shop for, and a note in the Shopee job’s code puts Shopee’s limit at fifteen days. Count daily so that a gap is found the next morning.
  • Re-running the job for an unnumbered order. The job skips it, because the order is already on the branch. It needs support.
  • Keying the order by hand. A run that reaches the order does not know your hand-keyed order is the same sale, and creates a second one. Bring it in through the job; key it only on support’s advice, and then keep the widened window off its date.

Related documentation

Last updated on