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 — in TEMP status, with no running number until somebody opens and saves it; the job creates the record, a person makes it a document (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 — and it is written down in planning/specs/module-applet-membership.md. E-Commerce owns 12 registry applets. Eight have a reference page; four do not, 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.

The marketplaces — Lazada, Shopee, TikTok Shop, Shopify

There is no EcomSync applet you open. The screens are spread across three standard applets and the synchronisation runs as server-side jobs; the index page ties them together.

Sellers and merchants — other businesses trading through you

Registry applets with no reference page yet

Four ACTIVE registry rows belong to this module and have no page, for two different reasons. Their names are given so nobody mistakes them for phantoms; none of them may be described on a module page beyond what is stated here.

Two names you may meet elsewhere are not registry applets and are not counted: Seller Admin is a maintained repository that has no registry row (F-0186 — it 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 (F-0118). Their former pages were unpublished under ADR-0008.

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<br/>(bl_fi_generic_doc_pgw_txn)"| 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 · TEMP"]
    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 decide most support questions:

• 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 (CpCommerceShoppingCartService.convertShoppingCartToSalesOrder) 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 GEN_DOC_PGW_RECEIPT_VOUCHER_PROCESSOR, which creates the receipt voucher and contras it against the document that was paid; the marketplace payout jobs (Shopee payout, TikTok settlement, Lazada receipt) create receipt vouchers against the marketplace branch. 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

1. 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.
2. Configuration — the setup order that makes the first storefront order and the first marketplace order land where you expect.
3. Use Cases — the shapes the module is used in, on the running example.
4. API Reference — the one API, the document types this module produces, the endpoint families and the integrations that exist.
5. Best Practices — advice that follows from the mechanics.
6. Reports — the reports that exist, and the ones people ask for that do not.
7. Related Applets — what this module needs from Core, Sales, Inventory, Financial Accounting, Membership and CRM, and what it supplies.