Shopping Cart Customer Access (Internal)

The customer’s own window onto shopping carts: a login sees only the carts of the customer records it is linked to, is allowed one open cart per customer record, and cannot raise a cart for anyone else. Finalising here is meant to turn the cart itself into a finalised sales order, but at the backend commit read for this page that call is refused for this applet and the failure toast is switched off, so FINAL appears to do nothing; staff can finalise the cart from the back-office Shopping Cart applet instead.

Overview

Shopping Cart Customer Access (Internal) is the customer-side window onto INTERNAL_SHOPPING_CART documents (short code SHPCRT). It is the same document and largely the same screens as the back-office Shopping Cart (Internal) applet, with one structural difference: it works through the customer-facing rules, which show a login only the carts of the customer records that login is linked to, allow one open cart per customer record, and refuse a cart raised for anyone else.

A customer (or a staff member acting through a customer login) opens it to build a cart — branch, items, bill-to and ship-to addresses — and then presses FINAL. In this applet FINAL does not merely post the cart: it calls the CP Commerce convert to sales order endpoint, which rewrites the cart in place into a FINAL INTERNAL_SALES_ORDER with a fresh running number. At the backend commit read for this page that call is rejected for this applet — see Lifecycle and effects.

This page documents only what differs from the twin. Field-by-field tables for the Line Items dialog and the shared behaviour of the cart form are on the Shopping Cart (Internal) page.

Where it fits

Direction	Document / applet	How it connects
Access	Customer Maintenance → Login tab	The login must be linked, `ACTIVE`, to the customer. A cart whose customer is not one of the login’s is refused as not authorised.
Sibling	Shopping Cart (Internal)	Same `INTERNAL_SHOPPING_CART` rows; staff see and edit every cart there through the generic `gen-doc` endpoint, without the per-login scoping.
Sibling	CP Commerce Admin storefronts	Storefront checkout creates carts of the same type and converts them through the same `cp-commerce/internal-shopping-carts/convert-to-sales-order` service this applet’s FINAL uses.
Master data	Organisation, Doc Item Maintenance	Branch and location (required on every cart; the branch’s `MAIN_LOCATION` extension fills Location); items offered by the line-item search.
Downstream	Sales Order (Internal)	The converted cart is the sales order — the same document, turned into an `INTERNAL_SALES_ORDER` and finalised.

Screens and menus

One sidebar item, Shopping Cart; the usual two-column stack (listing left, selected screen right).

Internal Shopping Cart Listing — ag-grid, client-side pagination, first 50 carts, most recently updated first, loaded through GET …/ecom/internal-shopping-carts/query. Columns are fixed in code: Doc Short Code (with checkbox), Doc No, Branch, Posting Status (blank shown as DRAFT), Status (blank shown as ACTIVE), Customer Name, Creation Date, Amount Txn, Updated Date. Branch and customer names are resolved row by row (two extra reads per cart, plus a third for the sales agent recorded on the cart). Two buttons above the grid: FINAL (converts every ticked cart that is not already FINAL — see Lifecycle) and DISCARD (discards every ticked cart that is ACTIVE and not yet FINAL). Advanced search: keyword (matched against the cart’s search word, branch names and customer names, results unioned) or Customer Name, Creation Date from/to and Branch.
Create Internal Shopping Cart — RESET and CREATE (disabled while Main Details is invalid or no customer is selected). Three tabs: Main Details, Account (Entity Details / Bill To / Ship To) and Line Items. There is no Payment tab in this applet: the payment component exists in the code but is not placed on either the Create or the View screen.
View Internal Shopping Cart — RESET (disabled once FINAL or when the cart is not ACTIVE), FINAL and DISCARD (both shown only while the cart is ACTIVE and its posting status is empty or DRAFT), SAVE; tabs Main, Account, Line Items, Export, Attachments; and a DELETE button at the bottom that needs a second click within three seconds (CLICK AGAIN TO CONFIRM). The View screen reads SHOW_DOCUMENT_DELETE_BUTTON from the applet settings into a flag, but the template never tests that flag — DELETE is always rendered.
Select Customer — lists only the customer records linked to the current login (entity-login-subject-links?subject_guid=<login> followed by customers?hdr_guids=…). If exactly one customer comes back it is selected automatically. The add (+) button on this screen routes to the 404 page; a customer cannot be created here.
Select Billing Address / Select Shipping Address, Select Line Item (item search with an advanced-search drawer by keyword, item code and label list), Add / Edit Line Item — as on the twin.
Export tab — choose one of the applet’s printable formats and download the cart as PDF (GET …/ecom/internal-shopping-carts/print-jasper-pdf/{guid} with CP_COMMERCE_INTERNAL_SALES_ORDERS_JASPER_PRINT_SERVICE). Unlike the twin, printing works here.
Attachments tab — list, add (multi-file upload through the generic-document attachment service) and view attachments.
Settings (gear): System Configuration › Application Settings, Default Selection, Printable Format Settings. The routes feature-visibility, webhook, permission-set-listing, user-permission-listing, team-permission-listing and role-permission-listing exist (and settings with no sub-path redirects to feature-visibility) but have no menu link.
Personalization: Default Selection only.

No screenshots are published for this applet: the captures that accompanied the earlier version of this page were taken on a tenant loaded with production-shaped data and show a real person’s name, a real customer’s branch names and a signed-in user’s avatar.

Configuration

Before you can use it

A customer record with a portal login in Customer Maintenance — the Login tab invites the login and links it to the customer, and everything in this applet is limited to the customers a login is linked to. A login with no link sees an empty listing, an empty Select Customer screen, and cannot create a cart.
Company, branch and location in the Organisation applet: Branch and Location are required; choosing a branch fills Company and Currency, and the branch’s MAIN_LOCATION fills Location.
Items in Doc Item Maintenance. Note that the item search in this applet does not limit itself to goods items the way the back-office twin does; whatever the login can read is offered.
For FINAL to produce a sales order: the CP Commerce conversion service checks cart-line integrity tokens when a website has line_integrity_config enabled, and member-point redemption when a line is paid in points — the same rules as a storefront checkout.

Applet settings

Settings live in three places: the shared settings screen (Settings › Application Settings), this applet’s own Default Selection screen (saved with the same applet-wide settings), and Personalization › Default Selection (per login). Anyone who can open the applet’s Settings menu can change applet-wide settings.

The table lists only the settings that are shown, saved and actually used by a cart screen.

Setting	Where	What it controls	Default	Effect when changed
`HIDE_UNIT_PRICE_STD_PRICING_SCHEME`	Application Settings › Line Items	Pricing-scheme / UOM selector in Add and Edit Line Item	Off (nothing is pre-hidden for this applet code — `shouldHideSetting` special-cases only the stock-transfer and delivery-order codes)	Field disappears unless the login holds the matching `SHOW_*` client-side permission
`HIDE_UNIT_PRICE_STD_EXCL_TAX`, `HIDE_UNIT_PRICE_STD_INCL_TAX`	same	Standard unit price excl. / incl. tax	Off	Both boxes only display the price the chosen pricing scheme gives; nobody can type into them. Hiding them takes the list price out of the customer’s sight without changing what the line costs
`HIDE_UNIT_DISCOUNT`, `HIDE_UNIT_DISCOUNT_UOM_EXCL_TAX`, `HIDE_DISCOUNT_AMOUNT_EXCL_TAX`	same	The three discount inputs: per unit, per unit of the chosen UOM, and for the whole line	Off	Unit Price Net, Unit Price Txn, Unit Price Txn by UOM, Amount Net and Txn Amount can also be typed, and a change in any of them is worked back into the line’s discount. So if a customer login should choose only items and quantities, hide all eight inputs, not just these three. None of the three discount inputs refuses a minus sign, and a negative discount raises the price
`HIDE_QTY_BASE`, `HIDE_QTY_UOM`, `HIDE_UOM_TO_BASE_RATIO`	same	Quantity, quantity by UOM, UOM-to-base ratio	Off	Quantity starts at 1 and must be at least 1, so hiding both quantity inputs leaves every line at one unit. UOM to Base Ratio only displays the ratio of the unit chosen in the pricing-scheme selector
`HIDE_UNIT_PRICE_STD_UOM_EXCL_TAX`, `HIDE_UNIT_PRICE_STD_UOM_INCL_TAX`, `HIDE_UNIT_PRICE_NET_UOM_EXCL_TAX`, `HIDE_UNIT_PRICE_TXN_UOM_INCL_TAX`, `HIDE_UNIT_PRICE_NET_EXCL_TAX`, `HIDE_UNIT_PRICE_TXN`	same	Six unit prices. Three can be typed: Unit Price Txn by UOM (incl. tax), Unit Price Net (excl. tax) and Unit Price Txn (incl. tax). The other three only display a value	Off	Each typed price recalculates the discount, the amounts and the tax on the line. Hiding a display-only price takes information away without taking any control away. Where line integrity is switched on (see Settings in other applets below), any edit that changes the unit price of a line already saved — a typed price or a new discount — is refused at SAVE with a message that the price may not be modified after the item was added; remove the line and add it again
`HIDE_AMOUNT_STD_EXCL_TAX`, `HIDE_AMOUNT_NET_EXCL_TAX`, `HIDE_AMOUNT_TXN`	same	Line amounts. STD Amount (unit price × quantity) only displays a value; Amount Net and Txn Amount can be typed	Off	A typed Txn Amount is worked back from the standard unit price with its cents dropped, so the discount and STD Amount it produces are out by those cents. For a price that ends in cents, type Amount Net or the discount instead, and check Discount Amount before you press ADD
`HIDE_TAX_CONFIG_SELECTION`, `HIDE_WHT_CONFIG_SELECTION`	same	SST selector + rate + amount; WHT selector + rate + amount	Off	same
`DEFAULT_BRANCH`, `DEFAULT_LOCATION`, `DEFAULT_COMPANY`	Default Selection	Pre-fills Branch, Location and Company on a new cart, and Currency from the default branch’s currency (falling back to `MYR`)	Unset — a new cart starts with an empty Branch and Location	Read from the master settings by the Main Details form. This is the opposite of the twin, where the same keys are saved and never read

The price on the cart is the price on the order. The conversion behind FINAL (see Why FINAL currently fails) turns this same document into the sales order and keeps its lines, prices included, as they are. So checking prices stays a person’s job: whoever releases a customer’s order (usually the order desk) compares each line with the price list before it is picked or invoiced. The lines worth a second look are the ones where Discount Amount is not zero, or where Unit Price Net differs from Unit Price STD (both excl. tax, side by side in the line dialog).

Keys rendered and saved but not read by this applet:

Personal DEFAULT_BRANCH / DEFAULT_LOCATION (Personalization › Default Selection) — saved per login, but the Main Details form subscribes to the master settings only, so a personal default never reaches a cart.
Everything else the shared Application Settings screen renders for this applet code — SHOW_DOCUMENT_DELETE_BUTTON (read into a flag the View template never uses), VERTICAL_ORIENTATION and the EXPAND_* keys (the Create and View screens here are fixed tab groups), and the ~200 generic document toggles. None is declared in this applet’s settings model or consumed by its screens.
Printable Format Settings — uploads Jasper formats under this applet’s own extension code (INTERNAL_SHOPPING_CART_APPLET_EXT_CODE_PRINTABLE_FORMAT_GUID_INTERNAL_SHOPPING_CART) and filters the listing to txn_type = INTERNAL_SHOPPING_CART. These are consumed by the Export tab, so this screen is live — again unlike the twin, whose Printables screen carries copied Sales Quotation constants.

Document behaviour settings

No exposed control found: the applet reads no FINAL_STATUS_GUID, workflow, void-reason, auto-print or e-Invoice key. FINAL, DISCARD and DELETE are fixed in code — see Lifecycle.

Settings in other applets that control this applet

Setting	Where it is set	Effect here
Customer → Login (linked, `ACTIVE`)	Customer Maintenance	Decides which customer records a login sees and may raise a cart for; without it every write is refused as not authorised
Line integrity checking (`line_integrity_config` on the website, with `enable` — that spelling, not `enabled` — and `day_limit`, default 3)	Website record of the CP Commerce Admin applet (no admin screen; set by BigLedger)	When enabled for any website, lines created here are sealed when added and checked again at conversion
Knock Off Configuration row `INTERNAL_SHOPPING_CART` → `INTERNAL_SALES_ORDER`	Organisation › Company	Not consulted by this applet’s FINAL, which converts the document in place rather than leaving it for the Sales Order applet to knock off

Feature visibility / permissions

Server side. What a login can list, read, create and change here is decided by the customers it is linked to, not by the TNT_API_DOC_INTERNAL_SHOPPING_CARTS_* permissions. The one exception is FINAL: the conversion this applet uses needs TNT_API_DOC_INTERNAL_SHOPPING_CARTS_UPDATE_TGT_GUID, which a customer login does not normally hold (see Why FINAL currently fails).
Client side. The Add and Edit Line Item dialogs show each price, quantity, discount and tax field when it is not hidden or the user holds its SHOW_* permission — the twenty SHOW_* counterparts of the settings above. Whether those permissions are defined for this applet has not been confirmed; check the Client Side Permission screen before planning on them.

Fields

Only the differences from the twin are listed; Line Items, Add Line Item and Edit Line Item are identical.

Main Details

The tab opens with Doc Short Code (always SHPCRT, read-only) and, on an existing cart only, Doc No (Tenant), Doc No (Company) and Doc No (Branch). The three number boxes accept typing, but nothing typed is kept: SAVE sends back the numbers the cart was loaded with. They are the cart’s numbers only. When FINAL converts the cart, the conversion clears them and the sales order is given new ones.

The free-text boxes are Reference and Remarks. When FINAL converts the cart, the same document becomes the sales order, so both stay on it and are what the sales team reads there. Reference is the natural place for the customer’s own purchase-order number. On an existing cart, clearing either box and pressing SAVE keeps the old text, because the form passes on only a box that has something in it. To blank one, type a replacement such as a single dash.

Field	What it holds	Required	What to know
Branch	The selling branch; choosing it fills Company and Currency	Yes	Pre-filled from master `DEFAULT_BRANCH`; locked once FINAL. On CREATE and SAVE the company is re-read from the branch record
Location	The stock location	Yes	Pre-filled from the branch’s main location, else master `DEFAULT_LOCATION`; locked once FINAL
Currency	The cart’s currency	Yes	From the branch; `MYR` if the default branch has none
Transaction Date	The cart’s date	No	Set to today on a new cart and cannot be changed on this screen. “Today” is worked out in UTC, so a cart started before 8 a.m. Malaysian time carries yesterday’s date. On SAVE the date already stored is kept. FINAL re-dates the converted order to the moment of conversion, so this date matters only while the document is still a cart

There is no Sales Agent, Sales Lead, Permit No, Tracking ID, CRM Contact, Credit Terms / Credit Limit or Member Card control on this form — the twin’s Main Details carries those; this one does not.

A SAVE here clears what staff added in the back office. Sales Agent, Sales Lead, Permit No and Tracking ID are kept in the same part of the cart as the customer details, and this form writes all four as empty on every SAVE, because it has no box for them. If staff set a sales agent on the cart in Shopping Cart (Internal), the customer’s next SAVE here removes it. The back office then shows Sales Agent empty, and the twin will not SAVE the cart until an agent is chosen again. This is read in the code, not seen run. Before you rely on an agent set in the back office, test it once: set an agent on a test cart in the back office, save that cart here, then reopen it in the back office. Where the agent matters for commission, the order desk records it on the sales order, after the customer has finished editing.

Account

Sub-tab	Field	Required	Notes
Entity Details	Entity ID (opens Select Customer)	Yes	Only customers linked to the login are offered; auto-selected when there is exactly one. CREATE stays disabled until it is set
Entity Details	Name, Type, ID Number, GL Code, Email, Phone, Status	—	Read-only, from the customer record
Bill To / Ship To	Name, Email, Phone, Address (picker), Address Line 1–5, City, State, Postcode, Country	No	Address picker limited to the selected customer’s addresses

Lifecycle and effects

What it saves. Listing, read, create, save, delete, discard and print all work on the customer’s own carts only. FINAL is a conversion to a Sales Order (below). Attachments are ordinary document attachments.

Statuses. Empty posting status (DRAFT) → FINAL (through conversion) or DISCARDED; or the cart is deleted. DISCARD is refused by the server for a FINAL or VOID cart or one that is not ACTIVE / DRAFT (“Generic Document cannot be discarded!”); the screen only offers the button while the cart is ACTIVE and not yet FINAL. There is no VOID.

Create and save. Creating checks the login’s link to the customer, requires a customer, refuses a second open cart for the same customer, forces the cart to carry no amounts that post, seals the lines where a website has line integrity switched on, and saves it. Saving repeats the link check and re-seals changed lines, but where line integrity is on it refuses any change to the unit price of a line that was already saved (see the unit-price row under Applet settings). The one-cart rule counts every cart of that customer that has not been deleted, whatever its posting status, so a DISCARDED cart, or one finalised by staff in the back office, still blocks a new one.

What posting does (the cart itself).

Document type: INTERNAL_SHOPPING_CART, short code SHPCRT.
No money and no stock — no journal, no stock movement; the reasoning is on the twin’s Lifecycle and is unchanged here.
What VOID reverses: nothing; there is no VOID.

What FINAL does. Both the View button and the listing’s bulk FINAL convert the cart to a sales order. The conversion re-checks the line seals, validates any member-point redemption, then turns the same document into the sales order: it becomes an INTERNAL_SALES_ORDER, running numbers are given out afresh, it is finalised and dated now, and every non-settlement line becomes a sales-order line. It is checked as a sales order, the main posting job runs (so the document now posts as a Sales Order — see Sales Order (Internal)), along with the membership item-update and CP Commerce sales-order file jobs, and any voucher lines are marked redeemed. The cart disappears from this listing because it is no longer a cart.

Why FINAL currently fails from this applet. The conversion refuses the request with HTTP 400 “Please update the app or hard reload your browser to proceed.” because this applet does not say which platform it is calling from — and the screen’s failure toast is switched off, so the user sees nothing. Even when that is fixed, the conversion this applet uses needs TNT_API_DOC_INTERNAL_SHOPPING_CARTS_UPDATE_TGT_GUID, which a customer login does not normally hold.

Delete. Deleting reads the cart through the login’s own customers first (refused as not found if it is not one of them) and then deletes it; nothing on the screen stops a FINAL cart being deleted, but the server read still applies.

Convert to receipt voucher. As in the twin, not available: the Convert tab is not shown on the View screen.

Related applets

Shopping Cart (Internal) — the back-office twin: same rows, unscoped, with the full field tables and the knock-off route to a Sales Order.
Customer Maintenance — the Login tab creates the entity → login link this applet is scoped by.
CP Commerce Admin — the storefront that creates carts of the same type and whose conversion FINAL uses; the website’s line-integrity setting decides whether lines are sealed.
Sales Order (Internal) — what a converted cart becomes.
Organisation and Doc Item Maintenance — branch / location and the items offered.

Troubleshooting

Symptom	Cause	Fix
Listing is empty and Select Customer offers nobody	The login is not linked, `ACTIVE`, to any customer	Invite the login from the customer’s Login tab in Customer Maintenance
CREATE is refused as not authorised	The cart’s customer is not one of the login’s linked customers, or the login has no links at all	Pick a customer from Select Customer; do not reuse a draft built under another login
CREATE is refused because the customer already has a cart	One cart per customer, and every cart that has not been deleted counts: a DISCARDED cart, and a cart staff finalised in the back office, still block a new one	Open and edit the existing cart, or open it and DELETE it (click twice), then retry. DISCARD alone does not free the place. If the old cart was finalised by staff, ask them before deleting it
CREATE is refused because no customer is set	No customer selected — normally impossible because CREATE is disabled until Entity ID is set	Select the customer on the Account tab
FINAL appears to do nothing; the cart stays in the listing	The conversion answers 400 “Please update the app or hard reload your browser to proceed.” because the applet does not say which platform it is calling from, and the failure toast is switched off	Cannot be fixed by configuration. Staff can FINAL the cart from Shopping Cart (Internal) and knock it off into a Sales Order there. A cart finalised that way stays a cart and keeps counting as the customer’s one cart, so the customer’s next CREATE is refused until it is deleted. Agree who deletes finalised carts and when. Deleting a cart that has already been knocked off has not been tested here, so try it once on a test cart and check that its sales order is unchanged before you make it routine
FINAL fails with a not-authorised response	The conversion needs the `TNT_API_DOC_INTERNAL_SHOPPING_CARTS_UPDATE_TGT_GUID` permission	Same workaround as above
DISCARD fails with “Generic Document cannot be discarded!”	The cart is already `FINAL` / `VOID` or not `ACTIVE`	Nothing to do; a FINAL cart is a Sales Order
Conversion fails because a line’s integrity seal does not match, or is missing	Line integrity is enabled for a website and a line’s seal no longer matches (edited elsewhere, or created before the feature was enabled). As read at the backend commit, the seal also includes the second at which it was made, and the check at conversion recomputes it with the current time, so a sealed line may fail even when nothing changed. This is read in the code, not seen run	Remove and re-add the line here. If a line that nobody touched still fails, re-adding will not help: ask BigLedger to switch line integrity off for that website
Conversion fails because the member does not have enough points to redeem the item	A line is paid in membership points the member does not hold	Reduce the quantity or remove the line
Sales Agent, Sales Lead, Permit No or Tracking ID set in the back office is gone	The customer saved the cart here: this form has none of those boxes and writes them empty on SAVE	Re-enter them in the back office once the customer has finished, or record them on the sales order
A new cart carries yesterday’s date	It was started before 8 a.m. Malaysian time, and the date is worked out in UTC; it cannot be changed on this screen	Nothing to fix on the cart. FINAL re-dates the converted order to the moment of conversion
Default branch / location never appear on a new cart	They are set only in Personalization › Default Selection; the form reads the master Default Selection	Set them under Settings › Default Selection
DELETE is visible on a FINAL cart	The template never tests the `SHOW_DOCUMENT_DELETE_BUTTON` flag or the posting status	Expected at this commit; the server-side read still refuses carts outside the login’s scope
The + button on Select Customer opens a “not found” page	The add handler routes to 404 by design (customer creation is not offered here)	Create the customer in Customer Maintenance