Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Sales
The order that is ready to ship, right until the warehouse asks where
A sales order needs a delivery address to become a shipment. The address can be blank, incomplete, or quietly defaulted to the customer's main site when the goods were meant to go somewhere else. In each case the order can still be confirmed, still reserve stock, still read as ready. The problem waits at the last step. The warehouse goes to pick and ship, and the destination is wrong or missing, so the shipment stalls, or worse, it goes out to the wrong place. What looked like an order on time becomes a late delivery and a return, and nobody saw it coming because the order looked complete.
Key takeaways
- A delivery address is what turns a sales order into a shipment. An order confirmed with a missing, incomplete, or wrongly defaulted address is ready in every respect except the one that gets the goods to the customer.
- This is not the same as a sales order with no price. A missing price stops the money; a missing address stops the goods. Both can pass confirmation looking fine.
- It is different from an order that was changed after confirmation. Here the address was never right to begin with, not altered later.
- Left alone, it surfaces at the worst moment as stock picked but not shipped or as a late customer delivery that gets blamed on the warehouse rather than the order data.
- The order's delivery address fields and its status both live in IFS Cloud, so a read-only monitor can list confirmed orders whose delivery address is blank or incomplete, before they reach the pick, and write nothing back.
1.How an order confirms without a usable delivery address
The delivery address on a sales order can be filled from the customer record, so an order can be confirmed with an address that is present but wrong for this shipment. A default is convenient and correct when the goods go to the customer’s main site. It stops being correct when the goods were meant for a different site, a drop-ship location, a project address, or an end customer, and nobody changed the default. The order carries an address that exists, so a blank-field check has nothing to flag, but it is not the address the goods should go to.
The other case is a genuinely blank or incomplete address: a new customer set up in a hurry, a one-off ship-to that was never completed, an order imported from another system with the address fields empty. Whether such an order can reach a confirmed state depends on how it was created and on your configuration, so it is worth checking in your own data.
Either way, the order looks finished. The gap is invisible until the warehouse tries to turn the order into a physical shipment and the destination does not hold up.
2.Delivery addresses that put a confirmed order at risk
A confirmed sales order due to ship soon with a blank or incomplete delivery address is the case that matters, and the earlier it is caught the cheaper it is to fix. The distinctions below sort the real risks from the noise.
| What you see | What it points to |
|---|---|
| Confirmed order, delivery address blank or incomplete, ship date near | The highest risk. The pick is imminent and there is nowhere valid to send the goods yet. |
| Address defaulted to the customer's main site on a drop-ship or project order | A silent wrong destination. The order looks complete but the goods are headed to the wrong place. |
| A new customer or one-off ship-to with partial address fields | A setup that was never finished, which will fail carrier validation or delivery at the last step. |
| A repeating gap on orders from one channel or import | A process or interface that is not carrying the address through, so each new order arrives the same way. |
A defaulted address is the dangerous case, because nothing looks wrong. It is a complete, valid address, just not the right one, so no blank-field check catches it. An order entry clerk working one order at a time cannot see which confirmed orders are heading to a default that should have been overridden. A monitor cannot know the intended ship-to on its own, but it can list confirmed drop-ship and project orders that still carry the customer's default address, so a person checks the orders most likely to be wrong.
3.Finding confirmed orders that cannot actually be delivered
The delivery address fields on a sales order, the order status, and the planned ship date are all available through standard OData projections, so they can be read without touching a record. Detection reads them and looks for two things:
- Confirmed, yet the delivery address is blank or incomplete - orders that have reached a shippable status while a required address field is empty, so the ones that will fail at the pick surface before the pick, as a short list.
- Urgency against the ship date - how soon the order is due to ship, so an order shipping this week ranks above one weeks out that still has time to be corrected.
Because it is a read-only monitoring pattern, it runs beside order management and writes nothing back to IFS. It adds no object inside the client system, so an R1 or R2 release leaves nothing of ours in your IFS to retest. Before each release I check that the standard projections it reads still match, as part of the subscription. Correcting the address stays with the order desk. The monitor just makes sure the desk fixes it before the warehouse hits an order it cannot ship.
4.Rolling it out without noise
- Start with orders due to ship soon - the near-term confirmed orders are where a missing address turns into a stalled shipment first, so watch those before the rest.
- Dry-run first - log which orders would have been flagged across a full period before a single alert reaches the order desk.
- Watch drop-ship and project orders - these order types need the default address overridden, so they are worth a list of their own.
- Read only, no footprint - standard OData reads, nothing written back, no new object inside IFS Cloud.
Related reading
5.Frequently asked questions
How can a sales order confirm without a valid delivery address?
The delivery address can be defaulted from the customer record, so an order can carry an address that exists even when it is wrong for this shipment. A defaulted address is a real address, so a blank-field check does not catch it, and whether an incomplete address stops confirmation depends on how the order was created. That is why an order can look ready and still have no usable ship-to. Check in your own data which confirmed orders carry a blank, partial or defaulted ship-to.
How is this different from a sales order with no price?
A sales order with no price stops the invoice: the goods can move but the money cannot. A sales order with no delivery address stops the goods: the money is fine but nothing can ship. Both can pass confirmation looking complete and both fail at a later step, so both are detected the same way, by reading the confirmed orders and checking the field that the next step depends on.
Why is a defaulted delivery address a risk if it is a valid address?
A defaulted address is valid and complete, which is exactly why it is dangerous. It passes a blank-field check because nothing is empty. The risk is that it is the wrong destination: a drop-ship, project, or end-customer order where the default should have been overridden and was not. The goods then ship confidently to the wrong place. A blank-field check will not catch it; listing drop-ship and project orders that still carry the default address narrows the review to the orders most likely to be wrong.
Does this monitoring write anything to IFS Cloud?
No. The delivery address fields, the order status, and the ship date are read through standard OData projections and checked outside IFS. Nothing is written back, so there is no upgrade footprint and no new object inside the client system. Correcting the address stays an order-desk action taken by a person.
6.About the author
Dariusz Myśliwiec brings 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Catch the order with nowhere to ship before the warehouse does
Tell me where a wrong or missing ship-to hurts you most. On a 30-minute fit call we check whether a rule that reads confirmed orders and their delivery address fits your data. The SCM Automation Pack runs three rules today (unconfirmed purchase orders, late deliveries, stock below minimum), so this would be an additional rule built to order, read-only, with a dry-run period before anything reaches the order desk.
