Watching it run
Staging and compare
Every inbound document lands here first. It is the room where a partner's data waits while it is checked against yours.
Staging is not a technical detail. It is the reason an inbound order can be trusted: nothing a partner sends becomes a record until it has been read into your database, compared with what you have, and either approved by a rule or approved by a person.
What is kept
A header and its lines, holding what the partner said as they said it. Their order number, their reference, their item numbers, the delivery address and its identifier, the currency, the dates, the totals, and the identifiers from the envelope.
It stays after the order is created. That is the point: months later the staged rows still say what arrived, next to the order that came from it.
The verdict
| Verdict | Meaning |
|---|---|
| Green | Everything matched |
| Yellow | Something differs and might be acceptable |
| Red | Something is wrong enough that creating the record would be a mistake |
The verdict is written on each line and rolled up on the header, with counts in the summary. Green only when there is at least one row and every one of them passed; a document with nothing to compare rolls up to neither green nor red, and no gate opens on it.
Two kinds of check
What is asked depends on whether there is anything to ask it against.
- An inbound order has no baseline. It is the first document of the exchange, so the rules are validity rules: can this be created at all. A customer that resolves, items that exist, quantities in units that exist, a currency Dynamics knows.
- Everything after it does have one. A confirmation, a despatch advice and an invoice arrive against an order you sent, so the rules are difference rules: what did they change, and what is missing that you expected.
That is why a yellow means different things in the two cases. On a confirmation it is a changed price or date. On an order it is something the rules tolerate but want a person to see.
Either way the finding is written down, in words, on the row. The first weeks of a partner produce a lot of them, and nearly all are fixed once in master data rather than per document. That is the work that makes automatic processing safe to switch on.
Reading a red
Red means do not create it. An item you do not sell them, a customer that cannot be resolved, a quantity that is not a number. Fix the cause and process again, or reject the document and tell the partner.
Processing status
| Status | What it means |
|---|---|
| Not processed | Staged and waiting |
| Processed | It became a record. The record is named on the row |
| Failed | Processing was attempted and did not work. The error is on the row, and it is retryable |
| Rejected | A person decided not to create it. The reason is kept |
Store without importing
An inbound agreement can be set to keep a document without reading it. The file is stored and the message is logged, and nothing is staged. Use it for a document type you want on record but do not want in your ledger, or for a partner you are still testing with.
Rejecting
Rejecting is a decision, and it is recorded as one with the reason. Where the agreement sends document receipts, the rejection is what the partner is told, which is better than silence: they learn the order was refused instead of assuming it is being picked.