How a message becomes a record.
Five steps, each of which can refuse the message and say why. This page is the detail behind the drawing on the front page: what is verified, what is checked, what blocks a posting, and what you see when it does.
If any of this is new, the plain language version is a better place to start.
The path of one order.
The same five stations run for every document type, in both directions.
-
1
Receive
The partner connects over AS2, AS4, or SFTP. Signed and encrypted, strictly, with no fallback to plain if a certificate is missing. The payload is archived before anything touches it, so the original is always recoverable.
-
2
Acknowledge the envelope
An MDN for AS2 or an ebMS receipt for AS4 goes back, and the receipt the partner sends us is verified rather than assumed. A transmission is not transmitted until its receipt checks out.
-
3
Translate
EDIFACT D96A in, Dynamics 365 entities out, qualifier by qualifier. A partner's own variant is remapped in one place rather than in code.
-
4
Check, then post
Preconditions run before anything is written: is the partner known, do the identifiers parse, does every item resolve. A message that fails is refused with a named code instead of posting something half right. Try breaking one.
-
5
Answer the document
A CONTRL answers the envelope and an APERAK answers the document, positive or negative with reason codes. Both are sent, and the ones you receive are reconciled onto the exact message they answer.
Outbound runs the same way in reverse: you post a confirmation, a despatch advice or an invoice in Dynamics 365, and it leaves as the agreed document without anyone exporting anything.
When it does not go through.
This is the part worth reading. Most of the work in an EDI integration is not the happy path, it is knowing what happened when a message did not land, and being able to answer a partner about it.
| Code | What happened | What you do |
|---|---|---|
| PARTNER-IDENTITY | The sender identifier in the envelope does not match a partner you have set up. | Add the identifier to the partner, or correct it with the partner. Nothing posts meanwhile. |
| IDENTIFIER-SYNTAX | An identifier is the wrong shape, for example a GLN that is not thirteen digits. | A partner side data problem. The message waits rather than posting against a guess. |
| VALIDATION | A field in the document is unusable, and the line names the EDIFACT element at fault: BGM 1004, DTM 2380, LIN 7140, QTY 6060. | Answer the partner with an APERAK carrying the reason, which the module can send for you. |
| Item not resolved | The order is sound but one of the partner's item codes has no counterpart in your item master. | Map the code once. The message is held as needing action rather than refused outright. |
| Certificate expired | A transport certificate has run out. The posting is blocked with a named code before a bad send can exist. | Renew it. Failing closed is deliberate: a silent unsigned send is worse than a stopped one. |
Failed sends retry with backoff and then land in your own error store. Resending is an action on the outbound queue, so a person decides. And all of it is safe to rerun: duplicates deduplicate, posters detect what has already posted, and status only advances. Nothing posts twice.
Four questions, one word.
The pill on the order is not a single flag. It collapses four independent axes, so one word can be trusted.
| Axis | The question it answers |
|---|---|
| Lifecycle | How far has this message got: received, translated, posted, answered. |
| Envelope ack | Did the interchange arrive intact, and did we get a receipt saying so. |
| Document ack | Did the partner accept the document itself, or refuse it, and for what reason. |
| Health | Is anything wrong that a person needs to act on, now. |
They collapse into one of Settled, Waiting, Action, Overdue or Failed. Overdue is worth singling out: it comes from the deadline stamped on the agreement itself, so a message that should have been answered by now says so on the order, rather than waiting for someone to remember to run a query. See the tracker.
Transport and trust.
Strict, with no quiet downgrade
AS2 and AS4 are signed and encrypted. If the material for that is missing, the transmission stops. There is no configuration that lets it through unsigned, because the option to be careless is the one that eventually gets used.
Receipts in both directions
MDN for AS2, ebMS for AS4, verified when they come back to us and sent when a partner needs one from us. A receipt nobody checks is decoration.
Networks fail closed
NemHandel eDelivery and Peppol AS4 do their own discovery and their own certificate trust: SML and SMP lookup, NemHandelsRegisteret, SBDH envelopes, OCES3 signing per legal entity. If trust cannot be established the send does not happen, which is the behaviour you want from a network you cannot see the other end of.
The audit trail is yours
The full trail is written to a log you own and drained into Dynamics 365 on schedule, so what happened on the wire stays answerable from the record itself.
Adding your own documents and formats.
Not a promise about a roadmap. It is how the module is built, and there is a worked example in the box.
From your own model
You extend the published surface from a separate model of your own: extend the document type enumeration, register a handler with an attribute, and bring your own mapping configurations. Zero changes to our model, so an upgrade of ours does not undo work of yours.
A whole new format, not just a document
The same surface takes a format we have never seen. A complete worked example ships with the module: a fictitious format, implemented the way a customer would implement one, compiling as a model that is not a friend of ours.
Your partner's variant is data, not code
When a partner insists on their own reading of a segment, that is a mapping change in one place. Nobody recompiles anything to onboard a partner.