Common problems

Almost every recurring incident is one of six things. Work down this list before you open a support case, because five of the six are fixable by you in under ten minutes.

Symptom to cause

"The run did not fire"

In order, because the order matters:

1. Is it active? A pause set by the buyer three weeks ago accounts for more of these than every other cause combined. Nothing is broken.
2. Is the next-run date what you think? Monthly on day 31 does not fire in February, April, June, September or November. A 14-day interval drifts across the week and eventually lands on a Sunday.
3. Did it produce an order that is on hold? A run whose value crosses the buyer's approval limit creates the order and holds it for release. The order exists. See Stuck approvals.
4. Did the conversion refuse? One discontinued article can stop a whole run if your policy is to refuse rather than skip.
5. Is the owning contact still able to order? A contact who left, lost their permission, or belongs to a blocked customer cannot produce an order. This is the cause that survives longest undetected, because everything about the arrangement still looks fine. An organization with a delivery block produces the order but nothing ships.

"The price is wrong"

It is almost never a bug in the run. It is one of four things, and three of them are your pricing configuration.

1. The price mode. Current at each run is the default: every run resolves pricing exactly as a checkout would. If the customer expected the price they saw at setup, the arrangement is on the wrong mode and this is a conversation, not a fix.
2. A contract price expired between runs. The run does not fail. It falls back to the next applicable price list and books at that price. This is the single most common "wrong price" on a standing order. A price list carries valid_from and valid_until; put those dates, for every account with an arrangement, on a review calendar. See Contract prices and Time-limited prices.
3. A scale-price bracket changed underneath them. A customer who moved from quarterly 200-unit orders to monthly 70-unit runs may have dropped out of a quantity_min bracket and now pays more per unit for the same annual volume. Correct with an annual-volume condition, not by editing the run.
4. The list held a stale captured price and somebody read it as the order price. A position on an order list stores the price at the moment it was added; it is not what the order books on.

To find out which, resolve the price for that customer, that article and that quantity and read the explanation. See Check a price.

"There was no stock on run day"

A scheduled run competes for stock with every walk-up order placed that morning, and it usually loses, because it fires at 02:00 against yesterday's picture and the warehouse works from 06:00.

Remember what the availability number means:

available = on_hand − reserved

available is computed, never stored. A run that finds nothing available when on_hand looks healthy is looking at reservations, not at an empty shelf.

Reserve stock for scheduled runs when the goods matter. A reservation counts against reserved and is honoured against other orders. Three things to get right:

• Reserve early enough. A hold placed at the moment of the run is not a reservation, it is a race. Place it when the run enters its notification window, not on the morning.
• Give the hold an expiry. Every reservation carries expires_at, and the inventory app's sweeper releases expired ones every 15 minutes; a market-level reservation_ttl_minutes setting supplies a default when the caller passes none. A reservation with no expiry that outlives its run holds stock indefinitely, and the symptom is a phantom stock-out on a completely different order. Check Order Management › Stock › Reservations for holds older than your lifetime. See When stock numbers drift.
• Decide what a partial reservation should do. Ship what is there and backorder the rest, or hold the whole run. For consumables the first is usually right; for a maintenance kit where a missing part makes the rest useless, the second is.

If your ERP is the authority on stock, none of the above is your reservation logic. It is a live read, and a run-day shortage is an ERP conversation. See Deciding your system of record and Stock, locations and availability.

"The customer got a delivery they did not want"

Take it seriously, because it is the failure that ends the programme.

• Take the return, immediately and without argument.
• Find out which of the four it was: an auto-converted suggestion that should not have been, an open-ended standing order that outlived its agreement, a quantity nobody updated, or a run during Betriebsferien.
• Fix the class, not the instance. One unwanted delivery means the same arrangement will do it again next cycle.
• If it was an auto-conversion, switch that account back to suggestion-only until you can show a quarter of correct predictions.

When to open a support case

You have checked the state, the next-run date, the on-hold orders, the pricing resolution and the reservations, and the run still did not produce an order that you can find. Bring the arrangement, the expected run date, the account, and the timestamp and response of any API call involved if the run was triggered externally. See Common API problems.

Next

• Manage standing orders — the weekly checks that prevent most of this.
• Recurring revenue health — the monthly read.