Start from the exact failing order or invoice rather than a generic dashboard. Trace customer and credit context, price-list and scheme qualification, tax and line calculation, approval state, then allocation and fulfilment. Correct the earliest authoritative input that disagrees with intent rather than editing a downstream total or creating an unexplained compensating document. This page stays text-only because no single read-only screen represents all of these failure modes accurately.
This page collects the handful of situations sales users actually hit in xMatix — an order that won't allocate, a price that looks wrong, a scheme that didn't apply, a credit-limit block, a quantity change that is refused — with what each one means and the fix, grounded in how the engine actually decides.
An order won't allocate
Allocation only considers stock at the order's own branch for the order's selling company, and only from the source the item's tracking dictates: a lot-tracked item allocates from item lots, any other inventory-tracked item from stock on hand — never the other way around.
- No pending allocation quantities found — the lines have nothing left to allocate: already fully allocated, cancelled, or the quantities were never released to fulfilment. Check the lines' pending counters.
- Item Lot not found for allocation — a lot-tracked line cannot find another eligible lot for its remaining requested quantity. Verify branch, selling company, SKU, lot type, preferred lot, hold state and expiry constraint.
- Available stock not found for allocation — a non-lot inventory line cannot find enough eligible stock at the order's branch and selling company. Stock at another branch does not count.
- The standard order Allocate action must finish every selected line's requested quantity. It stages allocation rows in memory and adds them only after all selected lines pass, so a later shortage fails the action instead of committing a partial allocation. Replenish or correct the source and run it again.
See Allocating stock to orders.
A price looks wrong
A line's price comes from the price list rule in effect on the pricing date — the line's price as on date, else the document's, else the document date. When it looks wrong, check in this order:
- Which price list the line and order actually carry — line beats order beats the default price list.
- Eligibility and dates — the optional SKU, lot type and service type must be blank or match. A matching service type outranks an unscoped one; then the latest effective-from wins. SKU or lot specificity does not automatically beat a newer eligible generic rule.
- A typed price — a non-zero price entered while adding a new line is kept initially. Reprice re-evaluates existing eligible lines, but bundle-priced and explicitly manual-rate lines are excluded.
- The discount — contract discount resolves separately from discount group rules; a missing discount usually means no rule covers the item, not a pricing bug.
Full resolution rules in Pricing, discounts and taxes.
A scheme didn't apply
Work down the same list the engine works down:
- The scheme is approved and today is within its validity dates.
- Its scheme type covers this document — a per-invoice scheme never fires on an order.
- Its application mode — Apply On Selection schemes must be applied by hand via Apply Scheme; only Auto Apply schemes fire on save.
- The conditions are met — run Get Qualified Scheme Slabs to see what qualifies, and Get Scheme Recommendations to see how far short the document is ("5 more value required!").
- The account is in scope — account/group/branch/selling-company scoping, including Exclude Scheme account groups.
- The budget configuration and headroom are valid. An order may apply a scheme with no budget rows, but an invoice requires both a scheme-wide tier and an applicable partner/account-group tier unless Ignore Budget is on. Every applicable configured budget must also have live ledger headroom.
- The lines aren't flagged to skip schemes.
If a scheme applied but looks stale after edits, run Reset Scheme and re-apply. Details in Trade schemes.
The order or invoice is blocked by credit limit
The message Credit limit exceeded… means a positive limit exists and the customer's open receivables plus the proposed amount used by that check exceed it. Interactive order creation usually supplies zero because lines do not exist yet, so it mainly blocks a customer already over the limit; API/import callers can supply an order amount. An invoice with a positive finance amount is sized against remaining headroom. Missing or non-positive limits mean unlimited credit, and invoice creation fails open if the finance credit service cannot be queried. Collect or apply credit notes, correct stale open transactions, or obtain approval for a higher limit; editing the stored utilized/available fields does not change the gate. See Credit limits.
A quantity change or cancellation is refused
Two guards protect processed orders. A line's quantity cannot be reduced below its transacted quantity (fulfilled + cancelled + returned) — the error names the transacted amount; reduce only what is untransacted, or cancel the pending remainder instead. And a cancellation cannot exceed the quantities still pending invoicing and fulfilment — over-cancelling is rejected rather than pushing counters negative.
Bulk processing skipped or shorted an order
The Order Processing result names each shortfall: no item (a line without an item), no stock available, or partially fulfilled with the achieved quantity. An order where no line could draw anything fails — or is skipped and reported when Exclude Stock Out is enabled. On Order Lines, clicking that option while selected rows already fail on-screen validation first unselects exactly those rows. Partly available lines are invoiced for what was found; the remainder stays pending for a later run.