Sales and inventory: pricing, reservations and delivery

When sales says an order is confirmed and the warehouse says nothing has left, both may be right. Confirmation can reserve stock; delivery records a different event. A reliable workflow keeps those facts separate and shows the next person what to do.

We will follow pricing, a reserved order and its delivery decision using the local WholesaleOS demo. The screenshots are actual interfaces with synthetic records. They are not a sequence of a customer transaction or a claim that every displayed action was submitted.

First, establish which price the customer receives

Retail and wholesale customers may buy the same product under different commercial terms. A price list gives the team an explicit pricing source instead of relying on a salesperson remembering an agreed amount. Customer groups and customer-specific pricing need to be agreed when configuring the catalogue.

WholesaleOS — Demo screen: Pricing before the order — The demo contains active retail and wholesale price lists. The retail list is marked as the default. This screen shows list configuration, not a calculated order total.

Before testing an order, choose a customer, a product variant, its selling unit, the applicable price list and currency. Ask the team to explain the price it expects. Then compare that expectation with the order. A mismatch here will later look like a billing problem, even if stock quantities are correct.

Next, read the order without treating reservation as delivery

The example below contains ten units ordered and zero delivered. Its status is reserved and its delivery remains pending. That gives the warehouse a clear outstanding task without claiming that the goods have already left.

WholesaleOS — Demo screen: Ten ordered, none delivered — Actual reserved demo order. Read the ordered and delivered columns together with the pending delivery. The Deliver action is available; it was not submitted for this capture.

For this specific record, the business question is simple: who will pick and hand over the ten units, and who records that hand-over? A salesperson should not answer by changing a stock balance manually. That would bypass the relationship between the order and the inventory movement.

What happens when only part of an order leaves?

Consider a separate acceptance scenario: a customer orders 100 units, and the warehouse ships 40 today. The remaining 60 should remain visibly outstanding, with the reservation treated according to the delivery rules. The project includes a delivery test for a 40-then-60 sequence; these quantities do not belong to the ten-unit screenshot.

In your demonstration, ask for the first delivery record, remaining quantity and second delivery record. Do not accept a single final “delivered” badge as proof of the intermediate states. Also test a shortage before confirmation and the treatment of backordered quantities.

Counter sales need a register workflow

Point-of-sale transactions have a different starting point: the cashier needs an open register session before selling. Include the opening session, payment method, receipt and closing procedure in your scope. Do not assume that a sales-order screen and a POS screen have identical permissions or operational steps.

Cancellation and return are different decisions

Cancellation before goods leave can release a reservation. Once some goods have been delivered, cancelling the entire order is not an appropriate substitute for recording what came back. The implemented order rules restrict cancellation after partial delivery. Use the returns workflow for the separate receipt, condition and credit decision.

The delivery also needs to connect to customer balances and collection. Stock leaving a warehouse does not prove the customer has paid.

A useful acceptance exercise

Select the intended customer pricing and check a known item.
Confirm an order and compare on-hand, reserved and available stock.
Record a partial delivery in a test environment and inspect the remainder.
Attempt a disallowed cancellation and check the explanation.
Finish the delivery, then inspect the customer's financial record.

Use your own units, credit terms and approval roles. If the team cannot explain a changed number from the preceding record, resolve that gap before migrating balances or training more staff.

Continue with the workflow you need

How this walkthrough was prepared

We reviewed the WholesaleOS implementation and opened its local demo on November 4, 2026. Screens show actual interfaces with synthetic fixtures, cropped to the relevant area without changing their content. Interface states alone do not establish customer outcomes or successful external delivery.

More perspectives