The flows
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 other three inbound documents do have something to compare against, because by then you have sent the order. A confirmation, a despatch advice and an invoice are each held against it, and there the verdict really is about differences. That is on staging and compare.
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 | Waits for a person |
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.
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.
All four are visible in the inbound workspace. None of them requires reading a log file.