xMatix Commerce is how a business sells on xMatix — to other businesses (dealers, distributors, stockists and key accounts) and, through the direct-to-consumer channels, to end customers. It covers the merchandised catalogue a buyer browses, cart-style order capture, the price lists and discounts each account trades on, the trade schemes that reward volume, the credit limits that keep exposure in check, and the pipeline that turns an order into stock movement, an invoice and cash.
Where Commerce actually lives
Commerce is deliberately not a separate engine with its own orders. A dealer order is a sales order: it is priced by the same price lists, discounted by the same discount groups, promoted by the same scheme engine, gated by the same credit limits, and processed by the same allocation, fulfilment, delivery and invoicing chain documented under xMatix Sales. What Commerce adds is the B2B layer on top of that machinery:
| Layer | What it is | Built on |
|---|---|---|
| Merchandised catalogue | Store catalogues that present items with marketing content, images and offers | The item master + store catalogue entries |
| Cart-style capture | The Product Catalogue surface: browse, set quantities per unit, save lines onto the document | Standard order and purchase-order documents |
| Dealer ordering | A dealer's requirement, raised as a purchase order, handed off into the supplier's sales order | The Sales and Procurement pipelines |
| Commercial terms | Per-account price lists, discount groups, trade schemes, credit limits | The Sales pricing and scheme engines |
| Storefronts | External-facing catalogue and account surfaces on their own hostname | xMatix Portals |
Because each layer is the standard platform, everything else in this documentation applies unchanged — record security, customization, reporting and the mobile app all work on commerce data exactly as they do anywhere else.
The Commerce app
The Commerce app (open it from the App Launcher; it appears when your administrator has granted it) gathers the module's screens in one navigation bar.
- 1
The navigation is the map of the module: Stores and Carts for the catalogue and basket, Checkout Sessions and Orders for conversion, Payment Transactions, Coupon Campaigns and Partner Microsites, plus Reports and Dashboards.
- 2
Commerce Channels — one record per selling surface (a portal storefront, a headless API consumer, a partner microsite).
- 3
Payment Gateway Accounts hold key-vault references for the account the money lands in — never the secrets themselves.
- 4
Webhook Subscriptions tell a headless consumer about orders and payments.
- 5
Partner Settlements accrue what is owed to a partner for a period of microsite sales; Partner Targets set what a customer or partner account is expected to buy in a period.
| Entry | What it holds |
|---|---|
| Stores | The stores a channel sells from — name, currency, optional partner scope — with their categories and catalogue publications |
| Carts | Shoppers' baskets, signed-in or anonymous, with status, totals and applied coupon (read-only: written by the pricing services) |
| Checkout Sessions | Each attempt to turn a cart into an order and where it stopped (read-only) |
| Orders | The ordinary sales orders that converted carts and dealer orders become |
| Payment Transactions | One row per payment attempt with its gateway event trail (read-only) |
| Coupon Campaigns | Offers, their codes, caps and budget |
| Partner Microsites | A partner's storefront on its own address and the service areas it delivers to |
| Reports, Dashboards | Commerce reporting |
| Settings | Tiles for Commerce Channels, Payment Gateway Accounts, Webhook Subscriptions, Partner Settlements and Partner Targets |
Which screens are editable and which are written only by the services that own them is covered in Screens and records. Dealer ordering itself happens on the sales order — see Dealer ordering.
Section map
| Page | What it covers |
|---|---|
| Catalogue and pricing | Store catalogues and merchandising, and how price lists and discount groups give each account its own terms |
| Dealer ordering | Cart-style capture, the purchase-order handoff, and the standard pipeline the order then runs |
| Schemes and credit | Trade scheme evaluation on B2B documents and the credit gates on ordering |
| Portal storefronts | Delivering catalogue and account experiences to external buyers with Portals |
| Direct to consumer | Selling to end customers — published catalogues, guest carts, checkout and payment, coupons, partner microsites |
| Screens and records | Every screen in the Commerce app — what each one holds, and which are read-only by design |
| Commerce FAQ | The questions B2B commerce evaluators ask, answered from how the platform works |
Common questions
Do commerce orders live somewhere separate from sales orders?
No. There is one order pipeline. An order captured from a catalogue cart, handed off from a dealer's purchase order, typed in by a back-office user or taken on a field visit is the same document with the same lifecycle — the sales order lifecycle describes it once for all of them.
Does Commerce only cover B2B?
No. The pages below describe the B2B layer, which is the older and larger half. Direct to consumer covers selling to end customers: published catalogues served to anonymous shoppers, guest carts, card and UPI checkout, coupons and partner microsites. Both produce the same order document and run the same pipeline.
Do I need Portals to use Commerce?
No. Dealer ordering, catalogues, pricing, schemes and credit control all run inside the platform's own web and mobile apps. Portals come in when you want buyers to browse or sign in on an external site of your own — that part is covered in Portal storefronts.
Where do invoicing and payment fit?
Downstream, unchanged: once a dealer order is allocated and fulfilled, it is invoiced and collected exactly like any sales order — see invoicing and payments. Receivables from those invoices are what the credit limit gate measures.