Products, stock, warehouses, purchases, promotions, POS shifts, and day-end — for businesses that sell stock rather than sell hours, and whose real question is which lines actually made money once the day is closed.
A shop’s margin is decided in two places that usually do not talk: the counter and the ledger. The stock list is a spreadsheet last counted in a hurry, the day’s takings are a roll of paper, and the discount that was quietly applied to win a sale is known to the staff member who gave it and to nobody else. Then month-end arrives and nobody can answer which lines actually made money, which were sold below cost by accident, or what is genuinely on the shelf. The inventory problem is rarely a stock problem. It is that the sale, the stock it consumed, and the cash it produced were never required to be the same event, so nothing can be reconciled afterwards.
Works with: Customer → Opportunity → Quote → Project → Work → Invoice → Payment
A sale is rung up on the POS against a product, with the business’s tax treatment applied and a receipt produced from the same entry. Payment is captured as a method — cash, card, or another configured option — so the payment mix of a day is a consequence of the transactions rather than a separate exercise at closing time.
When the sale completes, the stock position moves against the warehouse it was drawn from. This is the step that separates a stock-aware counter from a till: the on-hand figure is produced by selling, not by somebody remembering to update a sheet. Warehouses and their balances are modelled separately, so a shop with more than one storage point can hold them apart.
Purchasing is raised as a purchase order against the products and warehouse that need replenishing, informed by what actually moved rather than by what was ordered last time. Receiving what arrives brings the balance in line with reality. The point is not a sophisticated forecasting model — it is that the reorder decision follows the movement the counter recorded.
Promotions and discounts are configured and applied inside the transaction, and approval thresholds can gate who may reduce a price. Where a discount needs a manager, the counter keeps serving the customer and the approval becomes an explicit step rather than a verbal agreement. Whatever was given away then shows up in the day’s numbers by name.
The POS shift is closed with a review of what was sold, in what payment mix, with which adjustments and approvals. Day-end produces an operational summary the owner can read without asking the shift supervisor to retell it. Cash counted against the shift is a comparison with a recorded result, not an informal reconciliation done at the back of the shop.
Stock levels stop being a claim and start being the result of every sale that has happened.
A discount given at the counter is visible to the owner afterwards, instead of being known only to the person who gave it.
Reordering follows what the shop actually consumed, so purchasing stops depending on last season’s instinct.
The day’s payment mix is known before the cash is counted, which turns day-end into a comparison rather than a reconstruction.
Multi-branch and multi-warehouse stock can be reviewed together and still be kept apart where the operation is genuinely separate.
Real captures, not marketing mockups. Configuration and availability are confirmed during setup rather than promised on a page.
These are illustrative workflows, not customer results. We do not publish outcome claims without approved customer material.
Two branches count on the same evening and produce different numbers for products both branches claim to hold. Because every sale and every receipt moved a real balance, the drift is traceable: it is not a mystery, it is a specific set of unrecorded movements that happened outside the counter. That is an uncomfortable conversation to have, and it is the one that is impossible to have honestly from a spreadsheet alone.
Staff give a discount to close a sale, which is a reasonable thing to do at a counter. With approval thresholds in place, the transaction still completes, but the exception is recorded and visible to the owner. Over a month the owner can see not just what was discounted but by whom, which is the only version of this conversation that leads anywhere.
A shift closes slightly out. Previously this became an argument about who was counting and when. With the shift recorded and reconciled as a step, the difference is a number in a review the owner can inspect, alongside the payment mix that produced it. The conversation can then be about the process instead of about the drawer.
Every part of NoxOrigin has awkward edges. Naming them now is cheaper than discovering them in month two.
It is the trading side of billing. Invoices, tax treatment, and receivables behave as they do in the finance area; what Commerce adds is the catalog, stock, warehouses, purchasing, POS, and day-end that a stock-selling business needs in order to bill accurately at all.
Transactions are recorded with offline queues and sync recovery rather than being held hostage to a live connection, and the behaviour is validated during rollout for your actual counters, devices, and connectivity. Connectivity assumptions are part of setup, not an assumption we make for you.
Yes. Discount approval is an explicit permission, so you can let counter staff sell quickly and require an approval above a threshold instead. The public POS employee permission matrix shows how these splits are usually drawn in practice.
Branches, stores, and teams exist for that, and a workspace holds each one. Balances can be held per warehouse while the consolidated view is read from the same information, so a group-level number and a shop-level number are not two different truths.
No. Commerce produces the sale, the stock movement, the tax treatment, and the day-end summary that a ledger needs. Statutory accounting and filing stay with the tools built for them.