Setting up
Validation
A document can be checked before it leaves, against the rules the receiving end will apply to it. What a failure costs is your decision, per agreement.
The public formats come with published rules: not just whether the XML is well formed, but whether the business content makes sense. An invoice whose lines do not add up to its total is valid XML and an invalid invoice. Those rules exist as rulesets, and the module can run them before a document goes anywhere.
The value is not in catching your own bugs. It is in catching a document that would be silently rejected three days later by a system you cannot see into, at a point where you can still do something about it.
Where rulesets come from
| Source | What it is |
|---|---|
| Official | Published by whoever owns the format. Imported as they are, and replaced when a new version is published |
| Customer | Yours. A rule a specific partner insists on that the published set does not cover |
A ruleset is bound to a document type and carries a version and an expected profile, so a document is checked against the rules for what it actually is rather than against everything on file. The number of assertions is recorded on import, which is the quickest way to see whether a ruleset loaded fully.
The three modes
| Mode | What happens on a failure |
|---|---|
| Off | No check. The document is produced and sent |
| Warn | The failure is recorded on the message and the queue row. The document is still sent, and the posting completes |
| Block | The posting is refused. Nothing is posted and nothing is sent |
The outcomes
| Outcome | What it means |
|---|---|
| Valid | Every rule passed |
| Advisory | Something failed that the rules mark as a warning. Worth reading, not worth stopping for |
| Blocking | Something failed that the rules mark as an error |
| Not applicable | No ruleset covers this document type, so there was nothing to check |
| Unavailable | The check could not run. Not the same as passing, and never treated as passing |
The distinction between not applicable and unavailable is deliberate. The first means there are no rules; the second means there are and we could not reach them. A document that could not be checked is sent in warn mode and refused in block mode, because block means block.
Where to start
Warn, everywhere, for the first month. Read what it finds. Most of it will be one or two rules that fire on every document because of a habit in your master data, and fixing those is worth more than the validation itself.
Then move to block on the documents where a rejection is expensive, which in practice means invoices. Leaving despatch advices on warn is a reasonable permanent position: a rejected despatch advice is a phone call, and a refused packing slip posting is a lorry that does not leave.