CP Commerce
“Can I run my own storefront?” Yes. A website and mobile app your customers browse, register, order and book on is configured in one applet, CP Commerce Admin, and the orders it takes arrive as ordinary sales documents. That applet’s page is the reference for every screen in it. This folder holds two features of it that needed a page of their own: push notifications to the mobile app, and the shopper claiming their own e-invoice. This page says which page answers your question, what has to be in place before a storefront answers at all, what runs behind it with nobody pressing a button, and how you check it is working.
Which page answers your question
| You want to… | Read | Why there |
|---|---|---|
| Set up a storefront: its pricing, menus, sign-in buttons, shipping, legal agreements, which customers may see it | CP Commerce Admin | Everything is a tab on the Website record, and the applet page walks all twenty-one |
| Lay out the pages and choose what each one shows | Layout Instance and the widget reference | A page is a tree of rows, columns and widgets; the widget table there says what each widget does and which parameters it takes |
| Let a store manager change the shop without opening the console | The Webstore dashboard and Website Builder | The dashboard is part of the storefront, not of this applet. Its Product Management tile opens the item master your merchandising team uses |
| Send a message to everyone who installed your app | Push Notification Configuration | Three things outside the screen have to line up first, and the success message does not prove a send |
| Let a shopper ask for their own LHDN e-invoice from the website | Storefront E-Invoice Request | It is a widget, with no menu, and it takes the sale out of your monthly consolidated e-invoice with no approval step |
| Cap what a B2B buyer orders | Spending Limits, then the Customer record | The rule here was built to raise an alarm after an order, blocks nothing, and today raises none. A hard stop is a credit limit and the spending-limit lines on the customer |
| Take bookings for rooms, classes or events | Activities and Facilities | The booking engine is a menu of the same applet |
| Change what a product costs or how it is described | Doc Item Maintenance, Pricebook | The storefront owns no product data. The website only chooses which pricing scheme or price book it reads |
| Find an order a customer placed, or the payment for it | Shopping Cart, then E-Commerce core concepts §2 and §4 | Checkout produces a sales order; the receipt voucher is written afterwards by a job |
| Sell on Lazada, Shopee, TikTok Shop or Shopify | EcomSync Related Applets | Not this applet. A marketplace order arrives with no cart and no website behind it |
What a storefront is made of
Three records have to agree before a shopper sees anything, and BigLedger keeps one of them for you.
- The Host Name record for your domain. BigLedger keeps it. When the storefront starts, it looks up the address it was opened on and reads three values from that record: a public key that authenticates everything a guest does, your tenant, and which Website to show. So the domain decides the website, not the other way round. A Host Name record missing one of them stops the storefront before its session starts. The error, “Configurations of: … for Hostname: … - has not been configured” when the key or the website is missing, goes only to the browser’s developer console. The shopper sees no message at all.
- The Website record, which is yours, in CP Commerce Admin. It needs a branch and a membership class before it saves. Its Pricing setting decides whose prices the shop shows. Its Status decides whether the shop is served.
- A branch in Organisation, which the website is attached to. A branch whose Marketplace Type is CP Commerce takes the same stock rule and publishing as a marketplace shop (core concepts §5).
Everything else is optional, and each feature brings its own requirement. Push notifications need a Firebase credential on the website, which BigLedger support places there. The e-invoice widget needs your company already set up for e-invoicing.
Two situations it was built for
The walk-in who paid cash and wants an e-invoice a week later. A retailer does not make a walk-in open an account to buy a charger, so the sale goes to a cash customer and is reported in the monthly consolidated e-invoice. Then the buyer asks for an e-invoice in their own name. The storefront’s e-invoice widget is their self-service door. They find the receipt by its number and PIN, or by amount and date, give their identification number and TIN, and the sale leaves the consolidation as an individual e-invoice in their name. Nobody opens an account and nobody in your office keys anything. The cost is that nobody approves it either, which is why someone has to read Portal Request.
The corporate buyer with a negotiated price. A B2B portal where each account sees its own prices uses entity pricing. The website reads the pricing scheme on the signed-in customer’s own record, and only when Restrict View/Access by Entity is ticked. One storefront path does not understand entity pricing, so walk a category listing and a product page as a signed-in customer before you open the portal (Pricing).
What happens behind the screen
Nothing in CP Commerce Admin posts. Every screen writes configuration, and the storefront reads it the next time a shopper asks for a page. That has one consequence worth planning around: a save is live. A website, menu, layout or post has no draft copy and no undo, so build a new storefront on a second website record and switch it Active when it is ready.
The money and stock happen elsewhere, after the shopper acts:
- A paid checkout goes to the payment gateway. When the gateway calls back, the server turns the cart into a sales order itself. A sales order moves no stock and posts no journal; the sales invoice does that (core concepts §1).
- The payment is recorded on the document, and a background job writes the receipt voucher. A payment with no receipt voucher is a job to look at, not a storefront fault (§4).
- A finalised sales document recalculates the buyer’s spending-limit usage on the customer record and moves their membership points, at once.
- A shopper’s e-invoice request is queued and run immediately. It puts the buyer on the document, and a receipt that was waiting for the monthly consolidation becomes an individual e-invoice instead.
What runs only if somebody switched on a clock
Three CP Commerce jobs run on a timetable from the Scheduler, and none of them is among the clocks a new tenant is given. Assume your tenant has none of them until its Scheduler listing shows the row. The listing names each clock by its code. The admin page gives the codes for the reset and the calibration, and the push notification page gives the code for the notification scheduler.
| Job | Without its clock |
|---|---|
| The notification scheduler | A scheduled push notification saves, shows its future date, and is never sent |
| The spend-alert reset | A spending-limit ban stays until someone clears it by hand. The admin page explains why scheduling it does not help today |
| The agreement calibration | An expired privacy or terms document stays the default. Read the job’s keep all consents property before you schedule it, or it deletes consent history |
Two more behaviours are configured on screen and started by nothing at all: the spending-limit alert e-mails and any follow-up to a submitted form. Both save, and neither does anything after the save.
Where the figures come from
| Figure | What it is |
|---|---|
| A product’s price on the storefront | Looked up when the page loads, from the pricing scheme the website names (By website) or the branch’s price book (By branch). An item with no price there shows without one. Change the price in the scheme, not in CP Commerce |
| A customer’s spending-limit usage | A stored figure on the customer record, recalculated on every finalised sales document. It belongs to the customer’s own spending-limit lines, a separate mechanism from the CP Commerce rule |
| “The notification has been published successfully” | Fixed text. It is shown whatever Firebase answered, so it proves the button was pressed, not that a phone received anything |
| The In Queue count on the shopper’s e-invoice list | A count of pool rows by status, with failed requests added into it, so In Queue includes requests that have already failed |
| “Customers viewed this item” on a product page | Off until someone adds a parameter to the widget. The admin page says what it counts |
When something goes wrong
| What you see | Why | Where the fix is |
|---|---|---|
| The website is saved and customers see nothing | Status is not Active, no Default Layout Routing, or the Host Name record lacks a value | Admin troubleshooting; for the Host Name record, ask BigLedger and name your domain |
| “Something went wrong. Please contact the admin to set up source pricing scheme.” | The website’s Pricing is set to entity pricing, which one storefront path does not understand | Pricing |
| A product shows with no price, or the wrong one | The item has no price in the scheme or price book the website reads, or the second pricing scheme wins | Admin troubleshooting |
| Published successfully, and no phone received it | Firebase refused the send, and the screen shows the same message either way | Push notification troubleshooting: ask support for Firebase’s reply |
| A scheduled notification never went out | The notification clock is not on your tenant | Add it in the Scheduler, or use Publish Now until you have |
| Every e-invoice search on the website fails | The Host Name record has no public key, so no guest call is authenticated | The public key is the whole guest path |
| A sale is in neither the consolidated e-invoice nor an individual one | A shopper’s request failed after the sale had already left the consolidation | The FAILED row under Portal Request in My E-Invoice Admin (what happened) |
| A spending-limit rule never fires, or a ban never lifts | The alert e-mails are started by nothing, and the reset is a clock you have to add | Spending Limits; clear a ban on the customer record |
| A customer paid and there is no receipt voucher | The receipt voucher comes from a job the gateway callback queued | Core concepts §4 |
What this part of the product does not do
- It does not create, price or post an order. Checkout does, through a sales order, and the sales invoice is what moves stock and the ledger.
- It keeps no draft and no undo of a website, menu, layout or post. A saved change replaces the last one, and the Audit Trail logs only changes made through this applet.
- It tells nobody when something fails. Not a refused push, not a failed e-invoice request, not a clock that is missing. Each one has to be looked for, which is what the next section is for.
- Hiding a dashboard tile is not a permission. The screen behind the tile still opens for anyone who knows its address. Take the permission away instead.
- The spending-limit rule blocks no checkout. It was built to raise an alarm after the order, and today it raises none.
How you know your storefront is working
The product will not tell you when a storefront stops working, so the person who owns the shop checks it before customers find the problem. After any change to the website, and once a week otherwise:
- Open the shop in a private browser window, signed out, and walk one category, one product page and the cart. That is a guest’s view, and it exercises the Host Name record’s public key. Then sign in as a test customer and do the same: that exercises the pricing your B2B customers see.
- Place one order on a test customer and find it in the Sales Order listing, with its receipt voucher if you paid through the gateway.
- If you send push notifications, keep one phone subscribed to every topic and look at it after each send. If you schedule them, the Scheduler listing must show an ACTIVE row for the notification scheduler whose Last Run Date moves. The push notification page gives its code.
- If the e-invoice widget is live, someone in accounts reads Portal Request in My E-Invoice
Admin each morning. A
FAILEDrow is a sale that will reach LHDN in nobody’s e-invoice unless that person acts on it.
Write down who does each check. The product does not assign it.
Where CP Commerce sits
- Must exist first: a branch and merchant in Organisation, a membership class in Membership Admin, items priced in a pricing scheme or price book, settlement methods in Cashbook, and the Host Name record for your domain, which BigLedger creates.
- Becomes possible: orders and bookings taken on your own site, customers and members created at registration, membership points on portal orders, B2B ordering limited to the accounts you link, a push channel to your app’s users, and e-invoices your shoppers claim themselves.
- Its siblings: a marketplace shop (EcomSync) when the customers are already on Lazada or Shopee, and orders arrive with no cart and no website. Content Management System edits the same menus and posts with no website selector. A change made there is just as live, and this applet’s Audit Trail does not record it. MY E-Invoice Portal is the same e-invoice request made from a buyer’s own BigLedger account rather than a website.
- Breaks elsewhere if wrong: changing the branch of a website that prices by branch repoints the whole catalogue to that branch’s price book. A storefront e-invoice request changes what your month-end consolidated e-invoice contains. A spending-limit rule written as a monthly budget never fires.
- Used together with: Shopping Cart for orders, Media Library for every image the site shows, Voucher Management for promotions, and Running an Online Channel for the part of the job that is not software: stock to show, cancellations, returns and disputes.