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.
Almost 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. The exception is the message log, where a person can enter a message by hand in either direction, and can resend one that was already transmitted. Everything else follows from those 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, checks that the envelope is addressed to you, and refuses it if it is not. It writes the file down with the sending party stamped on it. Which of your companies the document belongs to, and which partner sent it, is settled in Dynamics when inbound processing reads the file. The legal entity comes from the receiver id in the document itself.
- 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. An order becomes a sales order. An order change is applied to that sales order line by line. An order confirmation confirms your purchase order. A despatch advice registers the goods it announces, as an advance shipping notice or an item arrival journal. An invoice is saved as a pending vendor invoice. Either automatically, if the agreement says so and the verdict allows it, or when a person presses Process.
The staged rows stay after the order is created, with the comparison that was made and the wire file they came from. Six months later, when a customer asks why a line was priced the way it was, the answer is still there.
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, Rejected |
| 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 itself and answers what happened to this one. The message log answers what happened across all of them, with the wire file behind every row. The operations workspace answers what needs a person right now, which is the short list: documents that failed, receipts that are overdue, inbound documents waiting on a decision.
None of the three is a report you have to run. They are screens in Dynamics, and the first of them is on the order a colleague was already looking at.
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.