Getting started
How a document travels
From a posting in Dynamics to a partner's system and back. Six steps out, four steps in, and a record at every one of them.
Nothing in the module is triggered by a clock or by a person pressing send. Documents leave because you did ordinary work: you confirmed an order, posted a packing slip, posted an invoice. Documents arrive because a partner sent one. Everything else follows from those two facts.
Outbound, in six steps
- You post. A confirmation, a packing slip, an invoice. The module is watching that posting, and it asks one question: is there an outbound agreement with this partner for this document type?
- The document is built. An Electronic Reporting configuration reads the record you just posted and produces the wire file: an EDIFACT interchange, an X12 envelope, a UBL document. Nothing is copied to a staging area first; the source is the journal you posted.
- It is validated. If the agreement asks for it, the file is checked against a ruleset before it goes anywhere. What happens on a failure is your choice, and is covered in the posting gate.
- It is queued. A row appears in the outbound queue, and a message row appears in the log with the state Created.
- It is handed over. The service takes the file and speaks whatever transport the partner requires. The message row moves to Transmitted and the time is stamped on it.
- Receipts come back. Depending on what you agreed, one or two: one that says the envelope arrived intact, one that says the business document was accepted. Each lands on the same message row.
Inbound, in four steps
- A document arrives. The service receives it, works out which of your companies and which partner it belongs to from the identifiers in the envelope, and hands it over.
- It is read. An Electronic Reporting configuration parses the wire file into staging rows: a header and its lines, in your database, readable in a form.
- It is compared. Before anything is created, the staged document is held against what you actually have: the customer, the items, the prices, the quantities. The comparison produces a verdict of green, yellow or red, and the reasons behind it are kept.
- It becomes a record. A sales order, a confirmation against a purchase order, a receipt. Either automatically, if the agreement says so and the verdict allows it, or when a person presses Process.
What a message row remembers
One row per transmission, in each direction. It is the thing you look at when you want to know what happened, and it carries more than a status.
| What it holds | Why it is there |
|---|---|
| The partner and both identifiers | Who sent it and who it was addressed to, as it was on the wire |
| Document type and format | What it was, in whose dialect |
| The document number | The order, packing slip or invoice it belongs to |
| Lifecycle stage | Created, Transmitted, Stored, Processed |
| Two acknowledgement states | One for the envelope, one for the document |
| A deadline | When a receipt stops being late and starts being a problem |
| Health, and the last error | Whether it is fine, degraded, or failed, and why |
Where you watch it
Three places, for three questions. The flow tracker sits on the order and answers what happened to this one. The message log answers what happened across all of them. The operations workspace answers what needs a person right now.
Where the service ends and you begin
The handover is the boundary. Outbound, the module produces the document and the service delivers it; once it is handed over, delivery, retries and certificates are ours. Inbound, the service receives and identifies, and once it is handed over, the reading, the comparison and the posting are yours.
This matters when something goes wrong, because it tells you which half to look in. A document that never reached Transmitted did not leave Dynamics, and the reason is on the message row. A document that was transmitted and never acknowledged left you and did not arrive, and that is a conversation with the partner, or with us.