Several years ago, Abogabir the adoption of a single electronic invoice format. In a post on this blog, we discussed the need to use a single format for interoperability and promote the adoption of B2B worldwide.
A few years later, and seeing the picture that in Europe about the B2B and specifically in the field of electronic bill, we need to rectify and become more realistic. There are multiple forms of electronic invoices in Europe. We ebInterface eg in Austria, Svekfactura in Sweden, Italy or Facturae SDI in Spain. In countries that use the same basic format as in the Nordic countries with UBL, the different versions and customizations can lead to mutually exclusive initiatives.
The struggle to have a single global standard, shared by everyone is a losing battle .... and probably useless.
Today, seeing the reality of companies and their needs we should ask again if you need to have a single standard.
In the paper world there are also global standards. The UN Layout Keys standardized format the document format when presented on a sheet of paper. Any company in Spain used a Layout Keys? I do not know if there will be a company that prints its bills following the standard format, but what is certain is that there are many forms of paper bills that are constantly on business. Formats are not equal, have different colors, colorful logos, graphics have some consumer bills, others have long lists of data to justify their high cost. In some invoices is a challenge to find the CIF of the issuer, hidden in small print on the left vertical of the document. In others, try to recalculate the tax total is more fun to play sudoku.
In short, all those bills on paper, different in many ways, they share a number of elements that make identify as invoices, and we can perform a number of processes, such as receptors, are we supposed to do: Check they are correct, that correspond to a service / product purchased, that the calculations are well made. It's good pay (if the findings are correct, of course), and if payment on the invoice, then pay as directed by the issuer is an entire detail.We must also count them: this means copying in our management system a number of invoice data (hence the sometimes cumbersome to find the CIF in any of the bills received!).
Post invoices received handy to know where our company. Do we lose or win money? Invoices will cost or investment and are usually classified in any game to fit our budget. With this extraction of invoice data and check into our management system, we will come to know as our company. It also helps us to know what taxes we pay to the Treasury at the end of the period. Also important.
Finally, we take the invoices received, we make two holes and saved to a file on whose back it says "Bill" (with the volume number or year of exercise, depending on the volume of incoming invoices.) This file is stored in a warehouse in case some day we come to ask for that particular expenditure or investment, to see how well we do things.
The data we need to perform these tasks, we can extract more or less easily from paper invoices why people have a great capacity to understand the meaning of the contents of a paper. Until we are able to process an invoice in Greek ... Because not only is our understanding, another important factor is that ultimately, this is really picking up little information. With a handful of invoice data can perform all transactions.
Just as in the paper world have an intuitive way to deal with heterogeneous bills before an international stage like this, with multiple formats, or usage of electronic invoices, all fighting to gain a place in the heart of the business, we should try that our systems could process the data of any bill, regardless of format.
The syntax of electronic invoices is not important.
What matters is the content of electronic invoices, which is known as the semantic model. What matters is that the management system of an electronic invoice receiver is able to identify the invoice number received, the total amount of taxes that I can pass on, the company is billing me. All these elements must be on one invoice. And it is you need to know our system to perform certain automatic processes with them.
If our process of receiving electronic bills, we have implemented a complex mechanism and approval work-flow that emulates the process we are doing on paper, need to know a number of invoice data. For example, if the total is greater than a certain threshold, say EUR 10000, the bill requires the approval of department head. This means that the amount of the invoice must be an element known for our work-flow system, and therefore this information should be structured in the model.
If we perform an automated project assignment, need to know the order number or contract. Other data necessary to get our system to make a direct assignment of the invoice to a particular project.
Why would they want the bill is structured to inform us of the payment? If you do not have a system that facilitates payment based on structured data reported in an electronic bill makes no sense to have such structured information.But if we can generate electronic transfers, then I welcome that the electronic payment information in the invoice.
The same goes for delivery information. Why do we need information delivered in a bill if we can not use automated in our management systems to ensure that the invoice corresponds with products / services delivered in certain conditions?
In short, we need the electronic invoice data that we may provide certain processes. Processes that our management systems are capable of doing. The rest is data that we store as they have come, in a file (now digital) for Mr. inspector or auditor can look at and verify an audit or inspection later that the document is an invoice, and that invoice is correct and corresponds with a product / service performed.
If we can identify this bunch of data that allows us to manage most of the processes that need to be done with electronic invoices, we'll be near the interoperability.
The first workshop of CEN BII started this line of work, which is continuing in the second phase is currently running.The search for neutral approach to syntax, forced by political pressure and lobbying are well positioned, CEN BII forced to perform the search path to CORE, the semantic search model that should allow information systems to understand electronic invoices regardless of syntax in which they were written.
In the first version of CEN BII, we defined a semantic model for the invoice document. This model is mapped to the end with the model defined by UN / CEFACT Cross Industry Invoice known.
We already have a common semantic model.
CEN BII gives us a common information model that all electronic bill should contain. But not only that. It is not just a theoretical semantic model, interpreted by people. At the end of CEN BII and PEPPOL pilot project development has gone a step further and defined the technical mechanisms that allow management systems to understand the electronic invoices, regardless of syntax. The CEN BII does not define a syntax, there is an XSD schema from an invoice BII, defines a set of rules and a series of devices based on a technology called Schematron to validate these rules.
The methodology to determine whether an electronic bill is consistent with the semantic model proposed by the CEN BII, regardless of format is based on technology and "old" called XPath.
CEN BII neutrally define the elements that must contain an electronic invoice. Natural language is used to create these definitions. For example:
A bill must contain an invoice identifier.
This is a rule of CEN BII. Regardless of the syntax of the electronic invoice, it must have an invoice ID, the problem is that the ID number or invoice will be located in different places and is called in different ways depending on the syntax used for their generation.
BII This rule can be translated into an XPath expression, one for each different type of syntax. For example, to find the ID of the bill:
- in UBL Invoice would be talking / cbc: ID,
- in CII would say CrossIndustryInvoice / CIIHExchangedDocument / ID
- in ISO20022 FinInvc / InvcHdr / Id and
- in 3.2 Facturae concat (Facturae / Invoices / Invoice / InvoiceHeader / InvoiceNumber, Facturae / Invoices / Invoice / InvoiceHeader / InvoiceSeriesCode).
In all cases apply the XPath expression (language) would get the invoice number of the electronic invoice. Although our management system is not able to understand all the syntax of electronic bill, you should be able to read an XML document using an XPath expression and choose the required data item.
With this and the mapping of the different syntax to the neutral model, semantic, defined by CEN BII, will be sufficient for management systems to support the processes necessary to manage invoices:
- The identification of the issuer
- The identification of the contents of the bill
- Contrasting verification against known data (orders, invoices, ...)
- His posting to see if we win or lose money to make ends meet
- Your prompt payment to the supplier
The line is drawn by the CEN BII. We have a second WS BII hopefully be able to map the semantic model to other syntax. And management systems no longer have to understand a particular syntax. You only have to be able to understand and implement XML XPath syntax defined for the electronic invoice receipt to get your required metadata.
And what are "necessary metadata? Only those that our application can / know process. What is done with other data reported in the bill will depend on the policy established in the receiver. Just as when we receive an invoice in Greek, and do not understand some of the points reported verbatim in it, we are able to process the relevant part of its content, in formats we can establish that our system does not understand, but which are compatible BII , we can automatically pre-processed, leaving the documents stored as received for a manual inspection.
This model would allow management systems were not affected by the emergence of new syntax, or by the appearance of versions of a syntactic model, so as to obtain a highly flexible system.
Source : http://blog.invinet.org/?p=666
