E-Commerce Module
E-commerce in BigLedger is two different ways for an order to arrive, feeding the same sales documents. A customer on your own Customer Portal storefront fills a shopping cart, pays through a payment gateway, and the server converts the cart into a sales order. A customer on Lazada, Shopee, TikTok Shop or Shopify buys from your shop there, and a background job pulls the order in as a sales order on a marketplace branch — already numbered and already FINAL: each channel’s ingestion service creates the header, calls the tenant running-number service and sets the posting status to FINAL in the same pass, so no one has to open it (Ecomsync, step 12). From that point on, the order is an ordinary Sales Order (Internal) and belongs to the Sales module: invoicing, delivery, returns and stock all happen there.
Applets in this module
Membership is an editorial judgement — the product has no module↔applet relationship in its data. E-Commerce owns 12 applets. Eight have a reference page; four do not yet, and the end of this list says why.
The storefront — your own web and mobile shop
The Customer Portal (CP Commerce) is BigLedger’s own storefront: a website and mobile app that a tenant configures rather than builds. Everything a shopper sees is configured in one applet and stored in a handful of others.
| Applet | What it is for |
|---|---|
| CP Commerce Admin | The console behind every storefront: the Website record (pricing model, menus, layouts, sign-in providers, shipping, legal agreements, linked accounts), plus ratings, newsletter topics, push notifications, dynamic forms, B2B spending limits, blocked customers and the facilities / activities booking engine. Configuration only — it posts nothing |
| Shopping Cart (Internal) | The back-office listing of INTERNAL_SHOPPING_CART documents — carts raised by staff, by customer logins, or by storefront checkouts. Staff correct a cart and set it FINAL so a sales order can be raised against it. Amount and quantity signums 0: a cart is a pre-order, not an accounting document |
| Shopping Cart Customer Access (Internal) | The same cart document, opened by a customer login rather than staff: one open cart per customer entity, scoped by the login’s link on the customer record. Its FINAL converts the cart in place into a sales order through the storefront service — a call the backend currently rejects from this applet |
| Shipping Pricebook | Conditional delivery charges — who qualifies, which lines count, what is charged. Master data with exactly one consumer: the storefront evaluates it in the shopper’s browser at checkout and writes the fee as a service-item line on the cart. Filed under master data; owned here (spec §5, A7) |
| Content Management System | The older content editor for the same CMS tables the storefront reads — themes, pages, widgets, menus and categories |
| Media Library Applet | Tenant file drives and categories: the images and documents that storefront pages, posts and facilities link to |
The marketplaces — Lazada, Shopee, TikTok Shop, Shopify
There is no EcomSync applet you open for the work. The screens are spread across three standard applets and the synchronisation runs as server-side jobs; the index page ties them together. Two applets called Ecom Sync do survive — 2020 builds that are still served and whose screens now live inside Doc Item Maintenance and Organisation. They are not where the marketplaces are run from and one of them calls a token endpoint the backend no longer has.
| Applet | What it holds for the marketplaces |
|---|---|
| EcomSync Related Applets | The index: which applet holds each setup step, which marketplaces have a full sync cycle, the background jobs, the troubleshooting table. Start here |
| Organisation — Branch → Marketplace tab | The marketplace branch: marketplace type, shop authorisation, the stock rule (mode, buffer, how open sales orders are treated), settlement method, default pricing scheme, the publish queue. Owned by Core |
| Doc Item Maintenance — Marketplace tab, Scheduler, Ecomsync Management | The listings: which shops an item is linked to, the shop’s own identifiers, the category and brand pulls, the Lazada / Shopee job schedules. Owned by Core |
| Sales Order (Internal) — Ecomsync menu and tab | The orders: marketplace orders arrive as numbered, FINAL sales orders on the marketplace branch; the Lazada / Shopee dashboards, review replies, and the bulk status update back to the marketplace. Owned by Sales |
| Tiktok Sales Order Applet | A marketplace-oriented build of Sales Order (Internal) that keeps only the Sales Order, Line Items, SO Detailed Report and Ecomsync menus. Same INTERNAL_SALES_ORDER document; its code, bundle path and routes still say Shopee |
Sellers and merchants — other businesses trading through you
| Applet | What it is for |
|---|---|
| Seller Applet | The seller-side workspace of the marketplace tables: a login linked to a merchant entity maintains that seller’s marketplace products and store stock balances, sees the seller orders allocated to it out of your sales orders, and the purchase invoices and payment vouchers you settle with. A seller order is a marketplace-table record, not a finance document |
| Merchant Admin | Where the merchant entity itself is created, with its gateway credentials, contracts, rate cards and monthly transaction report. Owned by Core; listed here because every seller is a merchant entity |
Registry applets with no reference page yet
Four applets belong to this module and have no page yet, for two different reasons.
| Applet | Why there is no page |
|---|---|
Payment Channel (paymentchannelApplet) and Merchant Access (MerchantAccessApplet) | Real, live applets — Payment Channel maintains the payment channels, payment providers and gateway contracts the storefront’s Settlement Method choices are read from; Merchant Access is the merchant’s own window on the rate cards and monthly reports that Merchant Admin maintains. Neither is documented yet |
Ecom Sync (ecomSyncApplet) and Ecom Sync Organisation (ecomSyncOrganisationApplet) | The original standalone EcomSync applets (2020), still served. Their screens are the item editor and the company / branch editor that today live inside Doc Item Maintenance and Organisation; the organisation build no longer works against the current backend |
Two names you may meet elsewhere are not installable applets and are not counted: Seller Admin cannot be installed from the Applet Store, and E-Commerce Catalog was a placeholder for what is in fact the item master behind CP Commerce Admin. Their former pages were unpublished.
What becomes a sales order, and what posts
flowchart LR
subgraph STORE["Your storefront (CP Commerce)"]
W["Website<br/>CP Commerce Admin"] --> CART["Shopping cart<br/>INTERNAL_SHOPPING_CART · qty 0 · amt 0"]
SP["Shipping Pricebook"] -.fee line.-> CART
CART -->|"gateway payment"| SO1["Sales order<br/>INTERNAL_SALES_ORDER · qty 0 · amt 0"]
CART -->|"staff FINAL, then knock-off<br/>in Sales Order (Internal)"| SO1
end
subgraph MKT["Marketplaces"]
LZ["Lazada · Shopee · TikTok Shop · Shopify"] -->|"order-ingestion jobs"| SO2["Sales order on the<br/>marketplace branch<br/>numbered · FINAL"]
LZ -->|"payout / settlement jobs"| RV["Receipt voucher<br/>INTERNAL_RECEIPT_VOUCHER · amt −1"]
end
SO1 --> POS["Sales module:<br/>invoice (posts, stock out) · delivery · return"]
SO2 --> POS
RV --> FA["Financial Accounting: bank and debtor"]
Three facts on this diagram explain most of what goes wrong:
- A shopping cart and a sales order both carry amount signum 0 and quantity signum 0
(
ServerDocTypes.INTERNAL_SHOPPING_CART(0,0),INTERNAL_SALES_ORDER(0,0)). Neither writes a journal; neither moves stock. A sales order counts against available stock and it can hold a reservation through the Stock Reservation applet, but nothing in this module reserves stock as a side effect of a checkout. The first document that posts and moves stock is the Sales Invoice (quantity −1, amount +1), which belongs to Sales. - Two paths turn a storefront cart into a sales order. A paid checkout is converted on the server without anyone opening the cart applet; a cart that staff set FINAL is instead offered to the Sales Order applet’s Search Shopping Cart knock-off tab — and only if the company’s Knock Off Configuration has a Shopping Cart → Sales Order row.
- Money from a gateway lands as a receipt voucher, by a job. A gateway callback queues a receipt-voucher job, which creates the receipt voucher and contras it against the document that was paid; the Shopee payout job (and an older Lazada receipt job) creates a receipt voucher for the net payout against the marketplace branch; TikTok’s settlement matcher is not registered. There is no gateway-fee accounting in the module: the merchant rate cards in Merchant Admin price the fee for the monthly merchant report, and nothing posts it.
Module pages
- Core Concepts — the cart, the two order paths, what a marketplace sees as available stock, how a gateway payment is recorded, websites versus marketplace branches, sellers versus merchants, and what the module has no engine for.
- Configuration — the setup order that makes the first storefront order and the first marketplace order land where you expect.
- Use Cases — the shapes the module is used in, on the running example.
- For developers: E-Commerce API notes — the one API, the document types this module produces, the endpoint families and the integrations that exist.
- Best Practices — advice that follows from the mechanics.
- Reports — the reports that exist, and the ones people ask for that do not.
- Related Applets — what this module needs from Core, Sales, Inventory, Financial Accounting, Membership and CRM, and what it supplies.
The job that is still the job with BigLedger switched off. Most of running an online channel happens in the platform’s seller centre and in decisions nobody writes down. Two guides take it on and say, for each part BigLedger does not do, who does it instead, when, and how they know it is right: Running an Online Channel (what a listing promises, sizing the buffer, the ship-by date, returns, disputes and chargebacks, the platform’s scorecard, the buyer’s data, whether a channel pays) and Reconciling Marketplace Payouts (every cut the platform takes, what BigLedger records of a payout, and the month-end proof).
For the finance side of the same orders — how to tell a marketplace or storefront sale from one somebody keyed, and the morning check that notices when a feed has stopped delivering — see Sales That Arrive From Another System.