Use Cases

“Can I run my own storefront?” Yes, and most groups that ask go on to sell on marketplaces too. This page shows the six shapes the e-commerce module takes in a retail group, for whoever runs the online channel, the accounts clerk who receives its money, the credit controller and the finance manager. Each shape traces what one purchase sets off behind the screen, says which job is still a person’s, and ends with how that person knows it went right. After the shapes come what they share: where each figure comes from, what goes wrong, what none of them will do for you, and a monthly check.

The running example is GadgetSphere Sdn Bhd: 22 retail branches under GS, an e-commerce arm and fulfilment centre under GadgetSphere Online Sdn Bhd (GSO), and a wholesale arm under GSD that sells to corporate clients.

Three roads in, and one way out

An online purchase reaches BigLedger by one of three roads, and the road decides who touches it:

• The storefront’s own checkout rewrites the shopper’s cart, in place, into a sales order that is already FINAL. Nobody at GSO opens it first.
• A cart finalised by staff waits until someone at your office sets it FINAL and raises the order from it.
• A marketplace order is created by a scheduled job. No cart exists.

All three end at a sales order, and a sales order carries zero for both stock and amount: it lowers available stock and moves nothing. The way out is the same for every road. The stock leaves, and the sale reaches the profit and loss, when the sales invoice is raised from the order, and that belongs to Sales. The money is a separate track, and each shape below says where it lands.

1. A consumer storefront for the group’s own brand

GSO runs one Website in CP Commerce Admin, attached to the fulfilment-centre branch and to a merchant record for GSO. Its prices come from a pricing scheme with the online prices. Its shipping comes from a Shipping Pricebook whose price sets charge RM 8 under RM 300 and RM 0 above, with a handling fee on a large items category. Card payments go through the gateway’s settlement method linked to the website.

For example, a shopper buys a flagship smartphone at RM 3,999 and a case at RM 89. Behind the screen:

1. The cart exists from the first add-to-cart. It is a document of its own type with zero for stock and amount, so nothing has moved or posted yet.
2. The shopper’s browser works out shipping from the price book and writes the shipping line: RM 0, because the cart is above RM 300. The back office does not work it out again.
3. The gateway calls back, and the cart becomes the order. On a successful payment the server rewrites the same cart, in place, into a sales order on GSO’s branch: FINAL, given a sales-order number, and dated at the moment of the callback. It adds the payment to that order as a settlement line carrying the gateway’s merchant reference, for RM 4,088.
4. Follow-on jobs start from that FINAL. Where the cashbook posting job is among GSO’s follow-on jobs, it writes the settlement line into the cashbook of the settlement item sent with the payment request. No receipt voucher is created for a storefront checkout. The receipt-voucher job you may read about elsewhere serves bills paid through BigLedger’s billing applet, which uses a different payment route.
5. The warehouse works the order in Sales Order (Internal): pick, pack, deliver, and raise the sales invoice that moves the stock and posts the revenue.

What this protects you from, and what it does not. Neither checkout nor the callback checks stock, and FINAL reserves none. If two shoppers buy the last unit within the same minute, both orders exist and the warehouse finds out when it picks.

Who and when. The accounts clerk, each morning, for the previous day. How they know: every paid order on the fulfilment-centre branch carries a settlement line with a merchant reference, the cashbook shows each amount on the order’s date, and the day’s total agrees with the gateway’s own report.

Marked for Vincent’s ruling (Q-1341). Nothing we found links the payment on the order to the invoice raised from it later. How that invoice is shown as settled is for your accountant to decide before the first month-end, and then to check once: the first paid order’s invoice should not appear as owing on the customer’s statement.

2. A gated portal where corporate clients buy on account

GSD gives its corporate clients a second Website. Restrict View/Access by Entity is on, so a person can sign in only if their login is linked to one of the accounts on the website’s Account tab. An entity-pricing model shows each client its contract prices, which the backend reads from the pricing scheme on the client’s own customer record.

The portal has its own credit gate, and it runs at checkout. On a restricted website, when a client’s basket is within their available credit, checkout places the order on account: the cart becomes a FINAL sales order with no gateway and no payment. When the basket is above the available credit, checkout sends the client to the gateway to pay, or refuses with “Your Credit Limit has been exceeded.” when the client has not chosen a way to pay. The available credit is the client’s smallest active credit limit in the cart’s currency, worked out for the company that owns the website’s branch (GSD). A client with no credit limit has none available, so every order they place goes to the gateway or is refused.

Know where this check sits. It runs in the client’s browser, as a screen-level control by design, so an order created through the API is not measured by it, and the server’s conversion checks no credit of its own. Two other controls are easy to mistake for it:

• The Spending Limit rule in CP Commerce Admin stops no order and, today, sends no alert.
• The Sales Order screen’s credit check refuses FINAL once the client’s available credit in that company is used up, when the applet’s credit-limit setting is on. It measures only orders finalised on that screen, so it never sees an order the portal placed itself.

So the credit controller has two ways to run GSD’s portal, and the choice is theirs:

There is no approval routing for either. The generic approval engine covers three purchase-side documents only (Purchasing).

Who and when. The credit controller sets each client’s limit, in the right currency, before the client is given a login. How they know: a test client with a RM 5,000 limit and nothing owing places a RM 4,000 basket, which is placed on account, and then signs in afresh and tries a RM 6,000 basket, which is sent to pay or refused.

3. The same stock on four marketplaces

GSO also sells on Lazada, Shopee, TikTok Shop and Shopify. Each shop is its own marketplace branch in the Organisation applet, with its own connection, settlement method and the online pricing scheme. The items are linked to the shops on their Marketplace tab and published from each branch’s Publish Item queue.

Orders come in by scheduled job, and most arrive finished. Each shop’s order job creates sales orders on its branch, numbers them and, on most connectors, sets them FINAL in the same pass. On several connectors, an order with a line on the connector’s placeholder item is numbered and left in draft for a person to correct.

Stock goes out to Lazada and Shopee only. For each item and shop, the figure sent is the balance at the locations the branch’s stock configuration ticks, less the open orders its sales-order setting selects, then the buffer applied. It is worked out again at once when a marketplace order is finalised, when stock moves and when someone saves the stock configuration. Which open orders count is decided by their marketplace status, so a cancelled Shopee order goes on holding stock back (Core Concepts §3). GSO keeps the stock its TikTok Shop and Shopify shops show in their own seller centres, by hand (Running an Online Channel, Step 2).

Size the buffer from the order job, not from a feeling. GSO sets its order jobs’ schedules to a 15-minute interval, and on a campaign weekend the shops together sell up to four of a flagship smartphone in 15 minutes, so each pushed shop gets a quantity buffer of 4. Read the type before copying a number: a quantity buffer is subtracted, but a percentage is the share that is published, so 5 publishes 5 %, not 95 %.

What else each shop has. The EcomSync index’s marketplace table says it per shop. In short: Lazada and Shopee also send fulfilment status back and bring payouts in as receipt vouchers. TikTok Shop has orders and products but no status back, and its settlement job is not registered. Shopify has orders in only: its products job reads the shop’s listings and sends nothing back. A Shopee payout arrives as one net receipt voucher, in the cashbook named on the payout job’s own schedule, not the branch’s Settlement sub-tab.

The fulfilment clerk works the orders in Sales Order (Internal), or in the Tiktok Sales Order Applet, which is the same document with fewer menus, and pushes Ready To Ship back to Shopee from the bulk-update listing.

Who and when. The online operations lead, each morning, for the previous day. The channel manager resizes the buffer before every campaign. The accounts clerk books what each payout deducted (Reconciling Marketplace Payouts), and every TikTok Shop payout by hand. How they know: each seller centre’s order count for yesterday equals the sales orders on that branch, with none left in draft or unnumbered.

A worked situation: adding a third shop

GadgetSphere Online sells on its own website and in a Shopee shop. It opens a TikTok Shop for gaming accessories. Here is what the module does and does not do for the new shop.

What arrives. The new shop needs its own branch in Organisation, authorised to the shop, and a schedule row for the TikTok order job. Then its orders arrive as sales orders on that branch, numbered and FINAL, with nobody keying them. The Doc Item Scheduler screen offers only Lazada and Shopee jobs, so the TikTok row is made in the Scheduler applet, or BigLedger support says how it is scheduled for your tenant.

What does not leave. BigLedger sends a TikTok Shop no stock figure, so the buffer you sized for Shopee does nothing for it. The channel manager keeps the stock the shop shows in TikTok’s seller centre. Before launch they decide how much of the hub’s stock the new shop may promise, and from then on that figure is theirs to keep true (Running an Online Channel, Step 2).

What money does. Nothing records a TikTok Shop payout. The accounts clerk books each settlement report by hand, as for Shopee’s fees (Reconciling Marketplace Payouts).

How they know it worked. On day one the channel manager counts the orders in TikTok’s seller centre and on the new branch. The two counts should match.

4. Customers who key their own carts

A corporate client’s purchasing clerk prefers to key orders rather than browse. Their login is linked to the client’s customer entity, and they use Shopping Cart Customer Access (Internal): one cart per entity, the client’s own billing and shipping addresses, and attachments for their purchase order PDF. The applet’s own FINAL would turn the cart into a sales order through the storefront’s service, but the backend currently rejects that call from this applet. So your sales administrator finds the client’s cart in the Shopping Cart (Internal) listing, sets it FINAL there, and raises the order from the Sales Order applet’s Search Shopping Cart tab. The tab lists it only because GSD has the Shopping Cart → Sales Order row in its Knock Off Configuration.

This shape has a side effect worth using. Because a person raises every order, every one of these orders passes the Sales Order screen’s credit check (§2), once the applet’s credit-limit setting is on.

Who and when. The sales administrator, at least twice a day, so a client’s cart does not sit unnoticed. How they know: the client’s carts set FINAL today all appear on the Search Shopping Cart tab, and each has become an order by the end of the day.

5. Third-party sellers on the storefront

GadgetSphere lets an accessories wholesaler sell on the GSO storefront under its own name. The wholesaler is a merchant entity in Merchant Admin, with a login link and a marketplace pricing scheme covering its items. The design is that a storefront order containing one of those items is allocated to the wholesaler, automatically and only where its scheme is the only one that covers the item, and the wholesaler sees the resulting seller order in the Seller Applet.

In this version of the platform, that allocation does not start from a sales order. Its first step is not among the jobs a schedule can run, and the next step reads a queue otherwise filled only through the API. The Seller Applet’s Save, Final and Delete buttons on a seller order do nothing in this build either. A seller order, when one exists, is a marketplace record with no journal and no stock movement, and GadgetSphere invoices the shopper itself and settles with the wholesaler through an ordinary purchase invoice and payment voucher.

Who and when. Whoever approves the wholesaler’s purchase invoice, before each payment. How they know: the period’s sales-order lines for the wholesaler’s items equal the lines its purchase invoices cover, and the difference is a known amount still owed. Before promising the wholesaler a seller-order queue, place one test order and see whether a seller order appears.

6. A member pays with points

A GadgetSphere Rewards member redeems 12,000 points for wireless earbuds on the storefront. The earbuds go into the cart as a redemption line carrying a points amount of −12,000. Points can also pay part of a basket, as a settlement line worth a ringgit amount.

When points cover the whole basket, there is no gateway. Checkout turns the cart straight into a FINAL sales order, so there is no payment record and no settlement line from a gateway. Before it does, the server adds up the redemption lines in the POINTS currency and refuses the order if they exceed the member’s balance. That balance is the stored current balance, which a later job updates, so two redemptions made seconds apart can both pass against the same balance. When part of the basket is paid by card, the order is created by the gateway’s callback instead, and the callback runs no points check.

The deduction depends on GSO’s own configuration. The 12,000 points are taken off the member by the points job, and only for the document type and status named in the selling company’s member-point configuration. With no configuration, that is the sales order at FINAL, so the storefront order is deducted as soon as it exists. The configuration belongs to GSO, not to GS. If someone sets GSO’s to the till’s cash bill, as most companies that configure it do, the storefront order is never the named document and the 12,000 points stay on the member. That is a known issue, reported to engineering.

A website can also be set, for a country, to take no gateway payments at all. Checkout then refuses any basket that points and vouchers do not cover in full, which is how a rewards-only catalogue is run.

Who and when. Whoever runs the loyalty programme, once when the storefront opens, and again whenever the member-point configuration of GSO changes. How they know: after one test redemption, the member’s points history shows a −12,000 line against the order, and the balance has fallen by 12,000.

Where the figures in these shapes come from

When one of these shapes goes wrong

What none of these shapes will do for you

• Reserve stock. A storefront checkout and a marketplace order both lower available stock once they are FINAL, and hold nothing. The channel manager protects scarce stock with a quantity buffer and decides, before a campaign, how much each shop may show.
• Settle a storefront payment against its invoice. The payment sits on the order. Finance decides how the invoice raised from it is shown as settled, and checks the first one (Q-1341).
• Approve a corporate order. The portal checks credit in the browser and the Sales Order screen at FINAL; neither routes an order to an approver. The credit controller’s limits are the control, and staff-raised orders are the way to put a person in front of each one.
• Send stock to TikTok Shop or Shopify, or record their payouts. The channel manager keeps their stock in the seller centres; the accounts clerk books each TikTok Shop payout from its settlement report.
• Pay a third-party seller. The accounts payable clerk pays from the seller’s purchase invoice, checked against your own sales-order lines.

What the module leaves to a person, and who does it

How you know a month of online selling went right

At month-end, before the books close, the finance manager runs five checks:

1. Orders. For each marketplace branch, the month’s orders in the seller centre equal the month’s sales orders on the branch, and none is in draft or unnumbered.
2. Storefront money. The month’s paid storefront orders, totalled from their settlement lines, equal the gateway’s report for the month, and the same amount is in the cashbook.
3. Invoices. Every FINAL online order meant for this month has its sales invoice, dated in the month. The invoice’s date decides which month’s consolidated e-invoice takes the sale: the consolidated run picks up only documents dated before the 1st of the current month, Malaysia time.
4. Credit. For each corporate client, the open orders and unpaid invoices together sit within their limit.
5. Points. The month’s storefront redemptions each have a matching negative line in the members' points history.

Where these shapes sit among the other modules

• What must exist first. A branch per shop and one for the website, with the connection for each shop; a listing per item; the Shopping Cart → Sales Order and Sales Order → Sales Invoice knock-off rows (Configuration); for the portal, a credit limit per client in the cart’s currency; and the order, stock and payout jobs on the Scheduler.
• What becomes possible. The sales order is where Sales takes over: delivery, the invoice, and through the invoice the journal, the stock movement and the consumer e-invoice.
• When to use which. A website for your own storefront, a marketplace branch for an external shop. A quantity buffer rather than a stock reservation to protect a margin from the shops. The portal’s own credit gate for speed, staff-raised orders for a person’s review.
• What breaks elsewhere. A wrong credit limit lets a client order on account past what the credit controller meant. A missing Sales Order → Sales Invoice row makes available stock ignore every online order. A member-point configuration set for the till changes what the storefront deducts.
• What it is used together with. Membership for points, Running an Online Channel for the channel manager’s side, and Reconciling Marketplace Payouts for finance’s.

Where to go next

Best Practices turns these shapes into habits, each with who does it and how they know it held.