Documents and formats
Twenty nine document types across three wire formats, and which way each one travels. If a partner has named a format to you, it is on this page or it is not in the module.
Document types
A document type is the wire format and the business document in one: EDIFACT INVOIC, X12 810, UBL Invoice. It is the thing a partner names when they tell you what they send, and it is the thing an agreement is made on.
| Business document | EDIFACT | X12 | UBL | OIOUBL | Direction |
|---|---|---|---|---|---|
| Order | ORDERS | 850 | Order | None | In from a customer, out to a supplier |
| Order change | ORDCHG | 860 | None | None | In from a customer, out to a supplier |
| Order confirmation | ORDRSP | 855 | OrderResponse | None | Out to a customer, in from a supplier |
| Despatch advice | DESADV | 856 | DespatchAdvice | None | Out to a customer, in from a supplier |
| Invoice | INVOIC | 810 | Invoice | Invoice | Out to a customer, in from a supplier |
| Credit note | INVOIC | 810 | CreditNote | CreditNote | Out to a customer, in from a supplier |
| Project invoice | None | None | ProjectInvoice | ProjectInvoice | Out to a customer |
| Project credit note | None | None | ProjectCreditNote | ProjectCreditNote | Out to a customer |
| Reminder | None | None | Reminder | None | No business process |
| Envelope acknowledgement | CONTRL | 997 | MessageLevelResponse | None | Both ways |
| Document acknowledgement | APERAK | 824 | ApplicationResponse | ApplicationResponse | Both ways |
Direction is a property of the business document rather than a separate choice. The same wire document is an order arriving and an order leaving: an EDIFACT ORDERS read inbound becomes a sales order, and the same type sent outbound is your own order to a supplier. That is why every row in the order half reads both ways.
The two acknowledgements have no direction of their own. A receipt travels opposite the message it answers, so you send them for what arrives and expect them for what you sent.
UBL carries two dialects
UBL is one syntax and two sets of document types. The Peppol BIS set is the default one; OIOUBL 2.1 is the Danish set, and it is types of its own rather than a flag on the others. An OIOUBL invoice and a Peppol invoice share a root element and are judged by different rules, so the dialect has to be something the document type says rather than something a reader guesses.
On an arriving document nobody has to say which it is. The module reads the CustomizationID off the file and settles the dialect before the message row exists, so an OIOUBL invoice meets the OIOUBL agreement and a Peppol one meets the Peppol agreement. What that means in practice is that a partner who sends both needs both agreements: set up one of the two and the other arrives to nothing and is refused, with nothing on the document itself to say what was missing.
Where UBL splits a document, EDIFACT and X12 do not. An invoice and a credit note are two document types on UBL, with two root elements. On EDIFACT and X12 they are one type, told apart by a code inside the message. So EDIFACT INVOIC covers both postings and UBL Invoice covers one of them.
OIOUBL has no envelope acknowledgement. The envelope layer on UBL is the Peppol Message Level Response, and it answers the five Peppol business documents: Order, OrderResponse, DespatchAdvice, Invoice and CreditNote. An OIOUBL document, and any answer to any document, is acknowledged at the document layer alone. Nothing acknowledges an acknowledgement, or two access points would answer each other for ever.
The project invoice and the project credit note exist on UBL alone, and each dialect has its own pair. On the wire a pair is an Invoice and a CreditNote of its own dialect: a Peppol project invoice goes out as a UBL Invoice, a Danish one as an OIOUBL Invoice. What makes them types of their own is where they come from, which is the project module rather than the sales one.
UBL Reminder is recognised as a UBL document and named as one. No business process in the module produces a reminder.
Business processes
The business process, and not the document type, is what routes a message. It is also how the flow tracker groups the documents an order touched.
| Process | Direction | Which document |
|---|---|---|
| Sales order creation | In | An order arriving from a customer |
| Sales order confirmation | Out | Your answer to it |
| Sales order packing slip | Out | The despatch advice you send |
| Sales order receipt advice | In | What the customer received from your despatch, told back to you |
| Sales order invoice | Out | The invoice you send |
| Purchase order inquiry | Out | The order you send a supplier |
| Purchase order confirmation | In | Their answer |
| Purchase order packing slip | In | Their despatch advice |
| Purchase order receipt advice | Out | What you received on your purchase order, told to the supplier |
| Purchase order invoice | In | Their invoice |
| Project invoicing | Out | An invoice raised in the project module |
| Envelope acknowledgement | Either | A receipt for one interchange |
| Document acknowledgement | Either | A receipt for one business document |
Eleven of the thirteen carry an agreement of their own. The two acknowledgements do not: they are agreed on the document they answer, per layer, which is why a partner can owe you an envelope receipt and no document receipt.
No document type in the table above carries a receipt advice. Both receipt advice processes are there for a document type added against the module’s published extension surface, in a model of your own, and the module routes it exactly as it routes a shipped one.
Transports
| Transport | How it travels | Networks |
|---|---|---|
| AS2 | HTTP, point to point | None |
| AS3 | Files on a server, over FTP or FTPS | None |
| AS4 | HTTP, point to point or across a network | NemHandel, Peppol |
| Plain file | Files on a server, over SFTP, FTP or FTPS | None |
On NemHandel and on Peppol the receiver is looked up in the network’s own registry, so you address a participant rather than a server. Without a network the two sides address each other directly. AS4 also carries a profile, which is one of Standard, eDelivery, eDelivery v2 or ENTSOG.
AS3 is defined on FTP, so an AS3 message travels over FTP or FTPS and never over SFTP. A plain file may take any of the three. The server is ours or the partner’s, and one connection can answer that differently in each direction.
Identifier types
| Type | What it is |
|---|---|
| GLN | Global location number. An EAN location number is the same number under an older name |
| CVR | Danish company register number |
| SE number | Danish tax number |
| P number | Danish production unit number |
| VAT | European VAT number |
| DUNS | Dun and Bradstreet number |
| Agreed code (ZZ) | A number two parties agreed between themselves, with no registry behind it |
The type travels with the value. A party is identified by the pair, and the type is also what decides whether a network will accept the number as an address at all.
States, in one place
| What | Values |
|---|---|
| Tracker state | Settled, waiting, action, overdue, failed, superseded |
| Lifecycle stage | Created, transmitted, stored, processed, rejected |
| Health | Ok, degraded, failed |
| Acknowledgement layer state | Not expected, pending, positive, negative |
| Correlation confidence | Confident, uncorrelated |
| Compare verdict | Green, yellow, red |
| Staging status | Not processed, processed, failed, rejected |
| Outbound queue status | Queued, sent, failed |
| Validation mode | Off, warn only, block posting |
| Validation outcome | Valid, advisory findings, blocking findings, not applicable, validator unavailable |
| Confirmation line status | Accepted, changed, rejected |
| Order change action | Added, deleted, changed, unchanged |
| Receipt route | Advance shipping notice, item arrival journal |
Not applicable means no validator covers the document’s format. Unavailable means one does and it could not give a verdict, because the rule set has not been uploaded, the EdiFabric licence did not arrive, or the engine failed. Neither one ever blocks a posting, whatever Validation is set to. Only a blocking finding blocks, and only where the agreement’s Validation is Block posting. An unavailable outcome is warned about and written on the queue row, so you can see that the document went out unchecked.
Order types
A message is anchored to one of four things: a sales order, a purchase order, a project, or a free text invoice. That anchor is what puts it on a flow tracker. A message without one is still perfectly valid; it is simply only visible in the message log.
A receipt is matched to the message it answers, and its verdict is promoted onto that message rather than read off a row of its own. A receipt that matched nothing is kept with its correlation confidence at Uncorrelated, and the reason the match was not made is kept with it, so an answer that arrived is never mistaken for one that did not.