CEF telecom call on e-invoicing - generalization of e-invoicing

Owned by Dirk Willekens (Unlicensed)
May 16, 2018
5 min read

CEF telecom call on e-invoicing - Application proposal: stimulate interoperability between all correspondents by systematizing the underlying code, maximizing the benefits of the existing Interoperability framework

 

Abstract of the proposal:

This proposal can be submitted by Service Providers (SPs) wishing to contribute to the generalization of e-invoicing, and other document processing automatization tracks, especially in the procurement area.

 

Such SP are invited to first adhere to the PEPPOL Interoperability framework, if it isn’t yet the case, for it is the foundation of the proposed improvements. Indeed, a model that makes any to any exchanges feasible, is indispensable to the generalization of e-invoicing, though it is not sufficient. To date, PEPPOL is the only such model available.

 

Further, the implementation of the proposal would modernize the SP’s solutions, to fully exploit the potential of PEPPOL, and stimulate its rollout. It would enable any sender to send any document to any receiver, and vice versa. It is founded on a formats manager component, that links all formats used by the SP’s clients together, defining a generic mapping between each format. The format manager complements the standardized transport infrastructure, the BIS as common denominator for cross sectors interoperability, and the SMP/SML discovery and capabilities lookup mechanisms, to offer a comprehensive solution for sending/receiving all kinds of documents to/from any other correspondent.

 

Definitions:

  • Participant: term used in the PEPPOL IFW to qualify the sender or receiver of the document
  • Correspondent = synonym for participant, emphasizing the exchange of information
  • Format : specific encoding of a document type, subject to a specification at sematic and syntactic level, supporting the exchange of the document between a reasonably large amount of senders and receivers. Specifications that apply only to bilateral exchanges are not considered to be part of format specifications: they are supposed to be expressed in the content of the documents. They are commonly referred to as usage specifications.
  • “last mile”: https://en.wikipedia.org/wiki/Last_mile

 

Assumptions:

  • an interoperability framework (IFW) is used. This IFW addresses (1°) efficient and seamless message transport for each participant: he only needs to bother of his own “last mile”; (2°) one “lingua franca”-format for each document Type (hereafter called BIS); (3°) receivers capabilities discovery mechanism (hereafter called SML/SMP).
  • In general, a Participant has his “own” format (for each supported document type). Can be whatever format, ranging from very confidential to very common.
  • mapping between formats is, in essence, a generic process. It is reusable for all senders and receivers facing the same need for format conversion. (*)

 

(*) in practice, for some reason or another, some participants can partially deviate from the generic mapping. Consequently, the ability to add participant-specific mapping rules above generic mapping rules might surface. This complexity is not further taken into account in the present discussion, to avoid making it excessively long/complex. It can be addressed at a later stage

 

Track 0: the formats manager

 

Abstract: both improvements described in track 1 (sender side) and 2 (receiver side), depend on a systematic and generic approach to formats management and conversion. The formats manager implements this condition.

 

Content:

  • build a formats manager:
    • Identify formats to manage: typically, all formats that the SP’s clients use, as well as the formats that their correspondents use.
    • Map each format onto any other managed format:
      • Initial: typical point to point mapping between formats, based on the available specifications. Remark 1: 90% of the usage scenarios should be covered by this step; the remaining 10% to be addressed through the improvement mechanism ; Remark 2: this includes mapping from each “own” format to PDF, for the case the Receiver is not yet reachable through the IFW(see track 1, “sequence”); Remark 3: not all formats need to be converted to any other format. Example: the EHF format is, by design, limited to the Norwegian Market. Only a Norwegian sender can face the need to convert his format to EHF.
      • Evolution: handled by mapping improvement mechanism
  • build a mapping improvement mechanism:
    • definition of a Mapping failure: a document, received in a source format, contains a data element that cannot be mapped onto the target format, based on the existing mapping available in the formats manager
    • Handling of a mapping failure:
      • create a problem log entry, including source document, target format, mapping failure details;
      • all subsequent identical failures are nicely added to the same problem description.
      • SP analyses the log;
      • SP modifies the mapping as appropriate.

 

Track 1: outbound documents processing (sending side)

 

Abstract: run ONE single logic for sending ANY DOCUMENTS from ANY serviced SENDER to ANY RECEIVER

 

Actors:

  • The participants:
    • the sender,
    • the receiver;
  • the SP,
  • the SML/SMP

 

Preconditions:

  • see track 0 : SP has implemented a formats transformation process that covers all possible transformations that the sender is eligible to need. This mechanism includes mapping to BIS and to PDF. This transformation process mainly consists in generic mapping (central service), that can be completed by own specific mapping, if needed by sender.
  • sender has communicated (a) his own format (e.g HO2C), and (b) a list of additional formats he supports (eg: e-FFF, EHF)
  • for each document to be sent, Sender has stored the receiver’s email address in the document

 

Sequence:

  • Sender sends his document using his own format – for all his outbound documents
  • SP receives the document
  • SP looks up SML/SMP to retrieve the receiver’s capabilities (RC)
  • If RC is empty (meaning, the receiver is not yet reachable through the IFW), then SP converts document to PDF and sends to the receiver’s email address provided in the document (*)
  • Else, if RC include sender’s own format, then SP send in pass-through
  • Else, if RC include sender’s additional supported format, then SP transform (using predefined mapping) and send it.
  • Else, SP transform into BIS

 

(*) alternatively, if the sender does not want his invoice to be mapped into pdf and sent by email, the SP will return an undeliverable to the sender – which involves that the sender must be able to process such notifications (which is not a straightforward issue)

 

Application:

  • Add a sending component that executes the above described sequence, based on the input from (a) the sender (ie, the documents flow) and (b) the formats manager

 

Track 2: inbound documents processing (receiving side)

 

Abstract: SP to run ONE single logic for receiving ANY DOCUMENT from ANY SENDER to ANY serviced RECEIVER

 

Preconditions

  • SP has registered Receiver in the SMP/SML, with following RC, for each document Type that Receiver can receive: (1°) BIS (mandatory) ; (2°) optionally: own format , any additional supported format;
  • Previous condition relies on the ability for receivers to register a sufficiently diverse set of formats on the SML/SMP. In other words, all these formats must be identified on the transport infrastructure. Notice that this condition requires that an organization takes ownership of the format, and in this role, registers the format against the Transport Infrastructure, which involves a set of administrative and technical duties.

 

Sequence:

  • SP receives a document on behalf of receiver, in one of the formats supported by the receiver
  • Depending on the contract between SP and Receiver, SP either (a) passes the document, “as is”, to Receiver, or (b) converts the document to the receiver’s “own” format

 

Implementation considerations

This proposal supports incremental implementation. This approach would help (a) coping with external constraints such as the limited amount of formats currently available on PEPPOL Transport infrastructure, and (b) minimizing the impact of possible design / implementation flaws. Consider starting with one document type (invoice) and a limited amount of formats/ format mappings. Then roll out the logic progressively.