EcomSync Related Applets
Keep your online shops and BigLedger in step: items and prices out, orders in as sales orders, and each shop’s settlements back as receipt vouchers. There is no single EcomSync screen. The set-up is spread over three applets and every exchange with a shop is a background job, so a job that exists but is not scheduled for your tenant never runs.
Overview
EcomSync is BigLedger’s name for keeping marketplace shops (Lazada, Shopee, TikTok Shop, Shopify and others) in step with the ERP: publishing items and prices to the shop, pulling the shop’s orders in as sales orders, pushing fulfilment status back, and turning the marketplace’s payouts into receipt vouchers.
It is not one applet. In the current source code there is no separate EcomSync user interface; the screens are spread across three standard applets — Organisation (the marketplace branch), Doc Item Maintenance (the listings) and Sales Order (Internal) (the orders) — and the synchronisation itself runs as background jobs on the server. This page is the index: it tells you which applet holds each step, links to the reference page for that applet, and lists the jobs that run behind the scenes.
Where it fits
| Applet | What it holds for EcomSync | Reference page |
|---|---|---|
| Organisation | The marketplace branch: a branch whose Marketplace Type is Lazada, Shopee, TikTok, Shopify, Magento, Selluseller, Anchanto OMS or CP Commerce, with the shop’s authorisation, the marketplace settlement method, the branch-level stock rule (mode, buffer or percentage, sales-order handling), the default pricing scheme and the Publish Item queue. | Organisation Applet — Branch → Marketplace tab |
| Doc Item Maintenance | The listings: each item’s Marketplace tab links it to one or more shops, the Stock Availability tab shows the resulting marketplace balance, Settings → Ecomsync Management pulls Lazada / Shopee category trees, brands and logistics for a branch, and the Scheduler menu creates the Lazada / Shopee sync jobs. | Doc Item Maintenance — Marketplace tab, Scheduler, Ecomsync Management |
| Sales Order (Internal) | The orders: marketplace orders arrive as sales orders; the Ecomsync menu has the Lazada / Shopee dashboards, the scheduler, and review replies; the Ecomsync tab on an order shows its marketplace status; the Bulk Update listing pushes pack / ready-to-ship status back to the marketplace. | Sales Order (Internal) — Ecomsync menu and tab |
| Receipt Voucher (Internal) | Where marketplace payouts land: the Shopee payout job (and the older Lazada receipt job) create receipt vouchers against the marketplace branch, for the net amount and matched to no invoice. A Lazada receipt stays a draft and posts nothing until someone acts, a known defect BigLedger is tracking. TikTok’s settlement matcher is not registered. Who finds the Lazada drafts, and what to book around every payout, is on Reconciling Marketplace Payouts. | Receipt Voucher (Internal) |
| Stock Availability | The item’s stock by location. It does not show a shop’s figure: that is the Balance on the item’s Stock Availability tab in Doc Item Maintenance. | Stock Availability Applet |
| Pricebook | The pricing scheme chosen as the branch’s default marketplace price source; the branch’s Pricing Scheme sub-tab shows which item prices are No Pricing, Syncing or Synced. | Pricebook Applet |
| CP Commerce Admin | BigLedger’s own web store. CP Commerce is one of the marketplace types, so a CP Commerce branch and items are set up the same way — but the store itself is configured in this applet. | CP Commerce Admin Applet |
A marketplace-specific build of the Sales Order applet also exists — the Tiktok Sales Order Applet, which keeps only the Sales Order, Line Items, SO Detailed Report and Ecomsync menus over the same documents.
You may also see two older applets named Ecom Sync and Ecom Sync Organisation in the applet list. They are the original standalone EcomSync applets: an item editor and a company / branch editor whose screens now live inside Doc Item Maintenance and Organisation. There is nothing separate to set up in them, and this page is their reference.
Marketplaces supported
The Marketplace Type list on a branch offers None, Lazada, Shopee, CP Commerce, Magento, Selluseller, Anchanto OMS, Shopify and Tiktok (plus one customer-specific option). Not every type has a full synchronisation cycle — each step below is a separate background job:
| Marketplace | Orders in | Products / inventory out | Fulfilment status back | Payout → receipt voucher | Reviews |
|---|---|---|---|---|---|
| Lazada | Yes (order ids, then order items) | Yes | Yes, plus cancellation update | Yes | Reply from BigLedger |
| Shopee | Yes | Yes | Yes (fulfilment, logistics), plus cancellation update | Yes | Reply from BigLedger |
| TikTok Shop | Yes | Products | — | A settlement matcher exists in the code but is not registered, so it cannot be scheduled — record TikTok payouts by hand (Reconciling Marketplace Payouts) | — |
| Shopify | Yes | Nothing goes out. The products job reads the shop’s products the other way: it links each one to the BigLedger item whose code matches its SKU and e-mails a list of the SKUs BigLedger does not have. Inventory is not sent either | — | — | — |
| Magento | — | Yes — products, product updates, inventory, and an immediate inventory push | — | — | — |
| Anchanto OMS | — | Inventory yes — the stock-availability job pushes to the OMS, and a copy-products job copies listings to it | — | — | — |
| Selluseller | Product and order retrieval only; no background job runs for it |
“Yes” means the job exists; whether it is scheduled for your tenant is a separate question (see Background jobs).
Setup order
The original version of this page was a list of eleven how-to titles. They are the right steps, in this order; each now points at the applet that owns it.
Step 1 — Organisation: company, marketplace branch, stock rule
- Create the company (if the marketplace trades under a separate legal entity) — Organisation Applet, Company.
- Create the marketplace branch — a normal branch record whose Marketplace → Details sub-tab sets the Marketplace Type and completes the shop authorisation (token fields appear for the types that need them) and the default entity. This is what older documentation calls the virtual branch. Behind the screen it is a separate marketplace-branch record linked to the ordinary branch; it must carry a code and point at an existing branch, or the save is refused.
- Set the branch’s stock and sales-order rule — Marketplace → Stock Configuration: stock mode, buffer by quantity or by percentage, whether the branch overrides item-level stock configuration, and how sales orders are treated.
- Pick the marketplace settlement method — Marketplace → Settlement (separate from the branch’s outer Settlement tab, which is for ordinary branch settlement methods).
- Choose the default pricing scheme — Marketplace → Pricing Scheme, then Sync; the No Pricing / Syncing / Synced views show progress.
Step 2 — Doc Item Maintenance: items and their listings
- Create the items — single (Basic), Bundle (fixed child items and quantities) or Grouped (variants with ratio and display option) — Doc Item Maintenance, Items. Set the Manage Media main image and the Dimension Details (height, length, width, weight) before linking: the listing carries its own copy of both, taken at the moment you link, so a later change on the item does not reach the shop by itself — re-link the item to push it, or wait for the item-update job if your tenant has one scheduled (check Ecomsync → Jobs; nothing on this page can tell you whether it is).
- Pull the marketplace’s reference data once per branch — Settings → Ecomsync Management: choose the branch, then Lazada Get Category Tree, Lazada Get Brands, Shopee Get Category Tree, Shopee Get Logistics. Category and brand pickers on the listing stay empty until this has run.
- Link the item to its shop(s) — the item’s Marketplace tab: Main selects the stores (multi-select over the marketplace branches), Other Resellers records reseller URLs, and Checking follows this item’s prices on the way to the shops — No Pricing, Syncing (price changes still queued for a shop) and Synced (each price the pricing-scheme push sent, by branch and date). A change of name, image, dimensions or stock never appears under Checking. Bundle and single items are linked the same way; a Grouped item’s listing can point at a parent listing. Each link is a marketplace item record holding the shop’s own identifiers — the marketplace item id, seller SKU, SKU id, shop SKU and the item’s status on the shop — next to the ERP item.
- Item-level stock and sales-order overrides (optional) — the listing carries the same stock rule as the branch (mode, buffer by quantity or percentage, sales-order handling) plus an override branch stock configuration switch and a pre-order flag; the item’s Stock Availability tab shows each shop’s resulting Balance and its buffer.
- Publish — either from the branch’s Marketplace → Publish Item sub-tab (select item category / category-group labels and run the branch item insert queue), or by importing the Doc Item with Ecomsync Item Link CSV template from Import Item.
- Schedule the sync jobs — Scheduler: one record per job code with a time interval or cron expression and the branch list. Codes offered on this screen:
LAZADA_PRODUCTS,LAZADA_SALES_ORDER_IDS,LAZADA_QC_STATUS,LAZADA_FULFILLMENT,LAZADA_SALES_ORDER_CANCELLATION_UPDATE,INVENTORY_SYNCING_TO_LAZADA,SHOPEE_PRODUCTS,SHOPEE_ORDERS,SHOPEE_BRANDS,SHOPEE_CATEGORIES,SHOPEE_SALES_ORDER_CANCELLATION_UPDATE,INVENTORY_SYNCING_TO_SHOPEE.
Step 3 — Sales Order (Internal): orders and status
Watch orders arrive — Ecomsync → Dashboard has a Lazada Dashboard and a Shopee Dashboard tab. The order-ingestion jobs create the sales order on the marketplace branch active, numbered and FINAL in a single pass — the order is written, given its running number and finalised in one go. No marketplace order is created as a draft and none waits for a person; an order with no running number is a failed run, not a queue.
Know what the dashboard’s figures count before you quote one. Dashboard Main is worked out in your browser from that marketplace’s sales orders already in BigLedger, dated by when each order was created in BigLedger — the run that brought it in, not the moment the buyer ordered — and counted from midnight 30 days back, or 7 if you choose 7 Days. Its Total Sales is not the sales orders’ own totals: it adds up a marketplace order price stored with each order, and the order jobs in the current backend do not store that price, so the orders they bring in add nothing to it. Take marketplace revenue from the sales orders themselves, filtered to the marketplace branch.
Update the marketplace order status — the Internal Sales Order Bulk Update Listing: tick the orders, choose the mode and click Update. The current build offers one mode, Create Package and Print Invoice and Shipping Label: Lazada: the Arrange Shipment: Lazada and Ready To Ship: Shopee modes are switched off in the source, so a Shopee order’s status cannot be pushed from this screen. The result is recorded per order as a fulfilment record: what was requested, whether it succeeded, and the marketplace’s reply.
Reply to reviews — Ecomsync → Reply To Review and Replied Review (Lazada and Shopee).
If you remember a separate marketplace order listing — status buckets from New Orders through Ready to Pack to Delivered, an Actions panel for shipping labels and invoices, and a five-tab order panel — it is not on any menu in the current build. The screen is still in the applet’s source code, but no menu item, route or dashboard tab opens it. Lazada order status is pushed from the Bulk Update listing (step 13), and each order’s Ecomsync tab shows its marketplace status.
Background jobs
Everything that actually talks to a marketplace is a scheduled background job, not a button. The jobs, by family:
| Job family | What the jobs do |
|---|---|
| Item publish and update | Push new or changed items, images and prices from the ERP item to the listing; a failed push is kept in an error queue rather than lost |
| Stock | Recompute marketplace availability from stock balance, open sales orders and buffer, and send it to a Lazada or Shopee shop or to Anchanto OMS. Nothing is sent to a TikTok Shop or Shopify shop |
| Lazada | Orders in (order ids first, then their lines), cancellations, receipt vouchers, reviews and review replies |
| Shopee | Orders, products, fulfilment and logistics status, cancellations, payout → receipt voucher, reviews and review replies |
| TikTok Shop | Orders, products (a settlement → receipt voucher job exists in the code and is not registered) |
| Shopify | Orders in; products read from the shop and matched to items by SKU, with an e-mail listing the SKUs BigLedger lacks |
| Housekeeping | Refresh shop tokens, re-check orders, copy listings between branches or to an OMS, rewrite market-specific item codes |
Errors from the order jobs go to a separate error queue, and a failed item push goes to the item-update error queue; no applet displays either queue. The item’s Marketplace → Checking view reads only the price queue and the price-push history, not the per-item sync events the product jobs record, so it answers “has my price gone out?” and nothing else.
Only the Lazada and Shopee jobs can be created from the Doc Item Scheduler screen. The TikTok, Shopify and housekeeping jobs are not offered there; create those in the Scheduler applet, which accepts any registered code (then confirm the clock can start it, as its page describes), or ask BigLedger support how they are scheduled for your tenant.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Category, brand or logistics pickers on a listing are empty | Ecomsync Management has not been run for that marketplace branch | Doc Item Maintenance → Settings → Ecomsync Management: select the branch, run the Get Category Tree / Get Brands / Get Logistics actions |
| Ecomsync Management shows “Please select the branch” | The four pull actions need a marketplace branch chosen first | Pick the branch in the Branch field, then run the action |
| Bulk update refuses: “Please Select a Mode or Select at least One Data from Listing” | No mode chosen or no rows ticked | Choose a mode and tick the orders |
| Bulk update toast “Error mode being selected for shopee” | Shopee orders were ticked: the only mode offered is the Lazada one, and every Shopee order is refused with this toast | Untick the Shopee orders: the current build has no Shopee mode on this screen |
| A marketplace order has no running number | Not expected: ingestion numbers and finalises the order in the run that creates it | Treat it as a failed run: check the branch’s connection record. Re-running the order job will not repair it, because every order job skips an order already on the branch. Report the order to support with its marketplace order number and branch, and keep it on your exception list until the Sales Order listing shows it numbered and FINAL |
| An order is on the shop and nowhere in BigLedger | Three causes, in the order to check them. (a) The job did not run in time: the pull is a lookback window, not a cursor, so a gap longer than the job’s Interval is permanent unless somebody widens it (Shopee’s own limit is fifteen days). (b) The order’s SKU is not linked to a listing: the whole order is skipped — not partially created, not queued — and an e-mail titled “Missing Order Items from Shopee store” goes to the address list on the job. (c) The shop’s authorisation has lapsed. | Re-run the pull with a wider interval after fixing the cause. For (c), the branch’s connection record is the only place the platform records it: its Remarks reads Auto updated by ECOMSYNC_REFRESH_CREDENTIALS_PROCESSOR after a good run and Failed to refresh credentials after a bad one, and its Updated date is the nearest thing to a heartbeat |
| Available quantity on a Lazada or Shopee shop is lower than the stock balance | Partly by design and partly not. The buffer is subtracted (or, for a percentage buffer, the figure is multiplied by it — 5 publishes 5 %, not 95 %), and channel orders are deducted by their marketplace status, not by whether they are still to ship: on Shopee READY_TO_SHIP, SHIPPED and CANCELLED are counted, so cancelled Shopee orders go on suppressing stock indefinitely, while almost no Lazada status is. With the branch’s SO Config Type ACTIVE and no branch ticked, every branch’s orders for the item are counted, not only this shop’s (Core Concepts §3) | Check Stock Configuration on the branch (the buffer, and the Sales Order sub-tab) and the item’s Stock Availability tab first. If the gap is larger than the buffer explains, work out what the open orders are taking (the stock balance less the buffer less the shop’s Balance on that tab) and compare it with the orders each seller centre shows as still open; ask support before you lower the buffer on that difference. A counted order takes the open quantity of every line on it, so the exact figure depends on your orders and how the branch is set up (Running an Online Channel, Step 2) |
| Item changed in the ERP but the shop still shows the old value | The item-update job has not run, or its run is in the item-update error queue | A price: the item’s Marketplace → Checking — under Syncing it is still queued, under Synced it was sent, with the date. Anything else (name, image, dimensions, stock) does not appear there: compare the listing in the seller centre with the item, re-link the item to push its copy again (step 6) or re-run the products job for that marketplace, and if the change still does not arrive, send support the item code and branch so they can read the item-update error queue for it, which no applet displays |
| Nothing syncs for a TikTok or Shopify branch although the branch is authorised | Their processors are not created from the Doc Item Scheduler screen | That screen is not the only route: the Scheduler applet accepts any code from its Select Processor picker. That picker is BigLedger’s platform-wide list, not your tenant’s, so finding the TikTok or Shopify code in it does not prove the clock can run it. To find out, create the clock there with Status INACTIVE and press Run Now: an error means the code is not one the clock can start; a success means it started, so look for the sync’s output on the branch. If Run Now errors, that is ours to change (what to send). |
Related documentation
- Sales That Arrive From Another System — the daily check that notices a feed has stopped, for marketplace orders and every other synced sale
- E-Commerce module and its related applets
- Item maintenance user guide
- Applet reference pages: Organisation Applet · Doc Item Maintenance · Sales Order (Internal) · Receipt Voucher (Internal) · Stock Availability Applet · Pricebook Applet · CP Commerce Admin Applet