Inbound order
An order arrives, is read into staging, is checked against what creating it would need, and becomes a sales order. The check is the part worth understanding.
This is the flow with the most value in it and the most that can go wrong, because it is the only one where a partner's data becomes your records. Everything else in the module reports what you already did.
Staging first, always
An arriving order is never turned straight into a sales order. It is read into staging: a header and its lines, in your database, in a form you can open. Only then is anything created.
The staged header keeps what the partner said, as they said it: their order number, their reference, their delivery address and its GLN, the currency, the dates, the totals. Their item numbers stay on the lines next to yours. When a dispute arrives eight months later, this is the record that settles it.
The check before it is created
An inbound order is the first document of an exchange, so there is nothing to hold it against. The customer’s order is whatever they sent. What runs before creation is therefore a validity check rather than a comparison, and it checks exactly the things that creating the sales order is about to fail on.
- The sending partner maps to a customer, because without one there is no order to create.
- Every item can be resolved to something you sell.
- Every quantity is one that can be ordered, in a unit that exists.
- The currency is one Dynamics knows, where the partner states one at all.
- There is a usable order date.
- The delivery identifier is one you recognise, and a site can be resolved.
Running these first is what turns a stack trace into a sentence the partner can act on. A failure is not an error in a log; it is a finding with a reason, and when the order is rejected that reason is what the partner is told, in whatever their format calls it.
The inbound documents on the purchase side do have something to compare against, because by then you sent the order. A confirmation, a despatch advice and a supplier invoice are each held against it, and there the verdict really is about differences: a price that moved, a quantity that is short, a line nobody ordered.
The three verdicts
| Verdict | What it means | What happens |
|---|---|---|
| Green | Every row passed and nothing is missing | May be created automatically, if the agreement allows |
| Yellow | Something differs in a way that may be acceptable | Waits for a person |
| Red | Something failed. Creating the order would fail too, or create the wrong thing | Held for a person, or rejected, as the agreement says |
Not most of them. One failed rule is a red row with a finding, and the gate stays shut. A document with no rows at all does not roll up to green either: nothing to compare is not evidence that the document is good.
Becoming a sales order
With automatic processing on and a green verdict, the sales order is created without anyone looking. Otherwise it waits in the inbound workspace until someone presses Process.
Processing is retryable. If it fails, the staged document and the message both go to failed with the error on them, you fix the cause, and you press Process again on the same rows. It is not a queue that has to be drained by hand.
Orders created from EDI have order promising switched off deliberately. The partner has told you when they want the goods, and the module records that rather than replacing it with a date your own availability calculation preferred. If you want promising applied, that is a decision to make on the order after it exists, not silently during creation.
When the buyer changes the order
A customer who has sent you an order may send a second document about it: a change, a cancellation, or the whole order again. The module treats the three differently, because the wire says three different things.
| What arrives | What happens to the sales order |
|---|---|
| An order change, as an EDIFACT ORDCHG or an X12 860 | Line by line. A line it adds is created, a line it deletes is cancelled, a line it changes takes the quantity, price and requested date the document states. A line it does not name is left exactly as it stood |
| A cancellation | The order is cancelled |
| The order again | The order is rewritten to what the document says |
A changed line is found by the buyer’s own line number, which was stamped on the sales line when the order was created. That is what lets a change arrive weeks later and still land on the right line.
Two cases are deliberately never applied without a person. A line that is reserved against stock is held yellow, because releasing a reservation is a warehouse decision and not a document’s. And a confirmed order is refused outright: you have promised something, Dynamics cannot unpromise it, and the honest answer to the buyer is a rejection they can act on rather than a silent amendment. A line the warehouse has already picked, delivered or invoiced is refused for the same reason.
An added line is created rather than refused. The buyer owns the order, and adding a line is a thing a buyer may do to one; a line refused quietly here would leave them believing it was ordered.
An order number you have seen before
An order arriving under a reference that is already on one of that customer’s orders is held for a person rather than created. It could be a cancellation, a replacement, a change the module cannot apply, or the same order sent twice, and the four want four different answers. The module does not guess between them.
Held is not failed, and the difference matters on the workspace: the row keeps the status it arrived with, sits under Needs a decision rather than on the failed tile, and still owes the partner whatever acknowledgement it owed a minute ago. The reason is written on it in the words you would use to answer the buyer.
What comes back out
Two things, if you have agreed to them. A receipt, saying the document arrived and was accepted or refused, which is covered in acknowledgements. And an order confirmation once the order is confirmed, which is the next flow.
When an order does not appear
In order of how often it turns out to be the answer:
- The sender identifier is not on any partner link, so the order has no customer to belong to.
- It was addressed to a company where that partner has no link.
- There is no inbound agreement for that document type with that partner.
- It is staged and red, waiting for a person, and nobody has looked at the workspace today.
- The inbound agreement is set to store without importing, so the order was recorded, archived for another system and never read into staging.
The first four are visible in the inbound workspace. The fifth is on the message log, where the message reads Handed over and is finished at Stored, and where Import here pulls a single message in anyway. None of them requires reading a log file.