Simplify Electronic Invoicing with the help of Adobe

A few months ago, during the CEN/ISSS meeting in Brussel, the scenario below was presented as a solution to enable Electronic Invoicing for SME’s.

The scenario is based on provisions that are currently available to companies such as XML message standards and readable document formats (PDF, Word, Open Document). When organizations want to establish Electronic Invoicing with all of their trading partners they are obliged to maintain two different formats: a data file and a readable image. The presented scenario is not going to make it easier for participants because senders and receivers need to take into account the capabilities of their partners.

For realizing general adoption, a message exchange environment is needed that enables all companies to participate whatever their maturity level and capabilities. This technical environment should ensure that all trading partners can reach each other regardless of the message standards being used.

Extending the reach is not only about connectivity but also about being able to process the content of an invoice as an image or as data.

The solution for this issue is a multi-purpose exchange standard, an XML Data Package that contains a readable image of the invoice as well as the document data. The exchange standard requires a technical platform for generating the XML Data Package at the sending side and processing the data at the receiving side. Apart from that a “reader” for viewing the image is required for companies that are not yet able to process the data automatically in their financial applications.

There are potentially two solutions available that can be used as the basis for the multi-purpose exchange standard:
- the Adobe XDP (XML Data Package) format

- the OASIS Open Document format.

Both formats are XML-based containers that are able to support all of the available international data exchange standards. The solution of Adobe has already been implemented for exchanging documents. Adobe wrote a white paper, “Using Intelligent PDF to support compliant eInvoicing solutions” to explain their solution approach.

The Open Document format is also an XML container and supported by several Open Standards minded companies. A working example based on the Open Document format is not yet available.

Although both formats lend themselves perfectly for realizing the multi-purpose exchange approach there still is much work to do before the multi-purpose exchange standard can be processed and transmitted by everyone.

On the weblog of Adobe you can watch a video that explains the power of their intelligent PDF forms. During the video they also indicate that every international message standard can be used as the basis for data storage.

Tags: electronic data interchange, HR-XML, UBL, e-Invoicing, e-Business

Last updated: 27-11-2011

Lees meer!

Vereenvoudig Elektronisch Factureren met de hulp van Adobe

Een aantal maanden geleden werd tijdens de CEN/ISSS bijeenkomst in Brussel het onderstaande scenario voorgesteld als de oplossing om Elektronisch Factureren voor het MKB toegankelijk te maken.

Het scenario gaat uit van de voorzieningen waarover bedrijven vandaag kunnen beschikken zijnde XML berichtstandaarden en leesbare documentformaten (PDF, Word, Open Document). Wanneer organisaties Elektronisch Factureren met al hun handelspartners willen realiseren zijn ze verplicht om twee verschillende formaten te ondersteunen: een gegevensbestand en een leesbare afbeelding. Het wordt hierdoor niet eenvoudiger omdat verzenders en ontvangers rekening moeten houden met elkaars mogelijkheden.

Voor het realiseren van algehele adoptie is een berichtenuitwisselingsomgeving benodigd waaraan alle bedrijven ongeacht volwassenheid en mogelijkheden kunnen deel nemen. Deze technische omgeving moet ervoor zorgen dat alle handelspartners elkaar kunnen bereiken onafhankelijk van gebruikte berichtstandaarden.

Het vergroten van bereik gaat niet alleen over connectiviteit maar eveneens over voorzieningen om de inhoud van een factuur als een afbeelding of als gegevens te verwerken.

De oplossing voor deze problematiek is een multi-purpose exchange standaard, d.w.z. een XML Gegevens Container waarin zowel de leesbare factuur als de gegevens liggen opgesloten. Deze exchange standaard vereist een technisch platform voor het genereren van de XML Gegevens Container aan de verzendende kant en het verwerken van de gegevens aan de ontvangende kant. Daarnaast is een “lezer” benodigd voor bedrijven die niet in staat zijn om de gegevens automatisch te verwerken in hun financiële systemen.

Er zijn twee potentiële oplossingen beschikbaar die als basis kunnen dienen voor deze multi-purpose exchange standaard:
- het Adobe XDP (XML Data Package) formaat

- het OASIS Open Document formaat.

Beide formaten zijn gebaseerd op XML containers die in staat zijn om ale beschikbare internationale berichtstandaarden te ondersteunen. De oplossing van Adobe is reeds op een aantal plaatsen geïmplementeerd voor de uitwisseling van documenten. Adobe heeft de werking van deze oplossing beschreven in een white paper “Using Intelligent PDF to support compliant eInvoicing solutions”.

Het Open Document formaat is eveneens een XML container en wordt ondersteund door bedrijven die hun vertrouwen hebben uitgesproken voor Open Standaarden. Een werkend voorbeeld op basis van Open Document is nog niet voorhanden.

Niettegenstaande het feit dat beide standaarden zich uitstekend lenen voor het realiseren van deze multi-purpose benadering moet er nog veel gebeuren voordat de multi-purpose exchange standaard door iedereen verwerkt en verstuurd kan worden.

Op de weblog van Adobe kunt u een videoopname bekijken waarin de kracht van intelligente PDF formulieren worden toegelicht. Tijdens deze video wordt eveneens verteld dat elke internationale berichtstandaard als basis voor de gegevensopslag gebruikt kan worden.

Tags van Technorati: electronic data interchange,HR-XML,UBL,e-Invoicing,e-Business

Laatste update: 27-11-2011

Lees meer!

The new approach for bringing adoption of e-Invoicing by SMEs to the next level!

The European Commission on 28 January 2009 adopted a proposal to change the VAT Directive 2006/112/EC (from 28 November 2006) with respect to invoicing rules. The main objectives are to reduce burden on business, increase the use of e-Invoicing, support small and medium sized enterprises (SMEs) and help member states tackle fraud.

Regulatory requirements for Electronic Invoicing will change with the advent of the measures aimed at further simplifying, modernizing and harmonizing the VAT invoicing rules. The foundation of the proposal is based on “equal treatment of paper and electronic invoices” in a technologically neutral way by removing the conditions for an Advanced Electronic Signature (AES) and Electronic Data Interchange (EDI).

While in the world of electronic agreements and contracts the need for electronic signatures is apparent the reasoning is that e-Invoicing is part of a larger process where every process step contributes to authenticity and integrity of the trade transaction. Nevertheless many Member States will continue to believe these guarantees can only be provided by electronically signed e-invoices.

Therefore removing the requirement to guarantee the authenticity of origin and integrity of content by means of pre-defined technological solutions, such as EDI and Electronic Signatures, is the most challenging from a political and governmental perspective. It requires a “paradigm shift” in thinking about audit management processes and strategies by Tax Authorities.

Apart from that increasing the use of e-Invoicing requires more than simplification of VAT invoicing rules. Although standardization efforts in Europe are huge the progress of standards bodies is slow with respect to data exchange standards. In response new initiatives emerge from humble beginnings, underpinned by new technologies, with potential to grow into creatures of substance and significance. The a priori standard for e-Invoicing, UN/CEFACT, starts loosing ground due to the growing need for inclusion of all types of companies, the rigidity and slowness of development, and the increased adoption of the Universal Business Language (UBL) as the European data exchange standard.

Although everyone is entitled to their own opinion creating the next wave of e-Invoicing requires re-alignment of views and goals. Hence there are two fundamental questions to answer:
- What is understood by the term “Compliant e-Invoicing”?

- What do SME’s and large companies need to jump on the bandwagon of e-Invoicing?

What is Compliant e-Invoicing ?
One such definition comes from the CEN/ISSS and Fiscalis e-Invoicing Compliance Guidelines as expressed in the section “e-Invoicing Basics Introduction”. Compliant e-Invoicing is about auditability of invoicing processes, verification whether VAT obligations are met and whether the invoice is an accurate reflection of sales and purchases.

Many people believe that e-Invoicing is the first step towards full automation of the end-to-end-trade process. Talking about “Compliant e-Business (Electronic Business)” is more appropriate in view of drafting the rules for the near future.

What do SME’s need to adopt e-Invoicing ? It should be clear that e-Invoicing for SME’s and for large companies requires more than simplification of VAT invoicing rules. There is a need for a multi-purpose exchange standard that enables companies to participate regardless whether they are able to process the invoice data automatically in their financial system.

Such a multi-purpose exchange standard should incorporate a readable image and processable data in one packaged container.

Bringing adoption of the new VAT directives to the next level
The CEN/ISSS e-Invoicing Workgroup Phase II Task Group 2 on Compliance recently presented their e-Invoicing Compliance Guidelines. The CEN/ISSS Task Group 2 and the Fiscalis e-Audit Project Group are paving the way for harmonization of VAT - Compliant e-Invoicing processes.

The principles in “the Guidelines” stimulate the use of a single coherent Business Control Framework (BCF) - Tax Control Framework (TCF) - across Europe. The aim is to attain a sufficient degree of auditability and legal compliance of e-Invoicing from a Tax perspective and to provide a solid foundation for performing tax audits in situations where e-Invoicing solutions are used.

The Guidelines provide practitioners a perfect instrument for self-regulation and self-certification of processes and technologies that are used to ensure invoices are reliable. Primarily enabling organizations to prove that invoices are processed and stored correctly within their individual spheres of governance and liability.

However, if well-understood, “Compliant e-Invoicing” is not about auditing e-Invoicing solutions or Service Providers but about auditability of invoicing processes and fraud prevention by validating whether VAT transactions are accurately administered (paid and deducted). e-Invoicing is part of the total Purchase-To-Pay and Order-To-Cash cycle and orders, deliveries and receipts need to be registered for legally valid transactions.

For most companies the three-way match at the end of their cycle provides means to control the integrity of the content and the authenticity of origin.

The focus of the recommendations should therefore have been more on the auditability and validation of VAT transactions from a Tax Authority’s perspective instead of on auditability of e-Invoicing solutions and Service Providers.

Currently Tax Authorities lack functionality and information to validate whether tax deducted and tax paid are correct and therefore force companies to guarantee authenticity and integrity. Reducing fraud is only possible if Tax Authorities are able to validate sales and purchases, deliveries and receipts, as well as the related invoice and tax transactions between the different involved parties.

Bringing adoption of the new VAT directives to the next level requires a mind shift of Tax Authorities, internal and external Tax Auditors, Businesses and Solution / Service Providers. This “paradigm shift” in thinking about Tax audit management processes and strategies has an impact on all stakeholders.

They all need to consider and establish a new “Compliant e-Business (e-Invoicing) approach” with less focus on the processes and technologies used (technologically neutral) but more on the end-to-end-trade process.

The foundation of the new Compliant e-Business approach is based on two important concepts:
- e-Invoicing is part of a larger process
- a multi-purpose exchange standard

e-Invoicing is part of a larger process
Study of the Purchase-to-Pay (P2P) and Order-to-Cash (O2C) processes with respect to legal and auditability requirements, arising from VAT, manifest that one important step, the exchange of trade related transactions to Tax Authorities, is missing. Based on practical experience with implementing electronic ordering and invoicing architectures a few ideas evolved. These ideas need further widespread elaboration and buy-in from stakeholders to define strategies for development and realization.

Looking at the Purchase-to-Pay (P2P) and Order-to-Cash (O2C) processes e-Invoicing is the last step before payment takes place.

All these steps contribute to proving the authenticity and integrity of the trade transaction to involved business partners. Reporting VAT to Tax Authorities at current is not a part of the end-to-end-trade process in most European countries. As such from a Tax Authority’s viewpoint trade transactions are difficult to follow and validate.

The future of the new VAT directives requires re-defining the position and importance of e-Invoicing in view of the total trade process. New ways of reporting, processing and validating tax-related transactions as part of the total trade process are required. These new ways of working should provide trust to all parties and be easy to implement once standards and procedures are in place.

The new Compliant e-Invoicing approach is based on the act of reporting all financial Tax related transactions from the General Ledgers and Sub-ledgers of Suppliers and Customers in a timely manner to Tax Authorities. The data exchange standards for reporting tax related financial data already exists and are implemented in some European countries. However there is no commonly accepted standard across Europe. SAF-T and XBRL-GL are data standards that qualify for the goal of reporting the related transactions.

The end-to-end-trade process flow will include one of these standards for reporting of transactions to Tax Authorities including corrections made as result of disputes.

Establishing the new Compliant e-Invoicing approach will require all stakeholders to join forces and work together on extending Business and ICT architectures for inclusion of Tax Authorities.

In the Business domain the focus should be on administrative and process-oriented elements. Governments and Businesses will have to ensure that Tax reporting is adequately embedded in policies and laws. Most work has to be done in the ICT domain to ensure technology, information and applications support the new flow of information. All involved parties face significant investments in infrastructures, application systems and exchange standards.

However adoption of e-Invoicing in Europe with a view to the future advent of electronic business will only become successful when Tax Authorities have a clear and complete view on trade transactions. They will gain more control and better understanding of businesses. Moreover the technology drift of e-? will come to an end and businesses will applaud for the transparency in the end-to-end-trade process.

A multi-purpose exchange standard
At current when organizations want to establish e-Invoicing with all their trading partners they will have to send two types of documents: a data message and a readable image. This will introduce additional complexity at both sides because companies will have to deal with the different capabilities of their receiving and sending trading partners.

Global adoption of e-Invoicing requires a business and technical environment that enables all types of companies to participate regardless their capabilities and maturity.

The technical environment must provide reach to all their business partners irrespective of data exchange standards. Providing reach is not about connectivity but about being able to process the invoice content as an image or as data.

The multi-purpose exchange standard is an XML Data Package that contains a readable image and document data. The exchange standard requires a technical platform for generating the XML Data Package at the sending side and processing the data at the receiving side. Apart from that a reader for viewing the image is required for companies that are not able to process the data automatically in their financial applications.

There are potentially two solutions available that can be used as the basis for the multi-purpose exchange standard:
- the Adobe XDP (XML Data Package) format

- the OASIS Open Document format.

Both formats are XML-based containers that are able to support all of the available international data exchange standards. Although Adobe is much further in providing a total working solution, Open Document is based on an Open and Collaborative Community supported by several Open Source minded companies.

Still there is much work to do to ensure these solutions fully support the processing and transmission of the multi-purpose exchange standard.

Building the new Compliant e-Invoicing approach
Establishing the new Compliant e-Business (e-Invoicing) approach requires all stakeholders to support the development of Governmental and Business ICT architectures for reporting, processing and validating the tax related transactions.

These efforts include:
- a data exchange standard for tax related transactions based on SAF-T or XBRL-GL

- a European-wide infrastructure for the communication and storage of tax related transactions including Business Intelligence functionality for analyzing transactions reported by businesses across Europe

- interfaces for generating the data exchange messages from data stored in the General Ledgers and Sub-ledgers from the financial and ERP systems of Suppliers and Customers

Data Exchange Standard based on SAF-T or XBRL-GL
Compliant e-Invoicing will be valid for all types of invoices for sales and purchases of goods or services.

Compliant e-Invoicing in the Staffing Industry where the focus is on delivery of services by hourly workers looks as follows:

Compliant e-Invoicing for non-product and product related (B.O.M.) goods and material looks as follows:

European-wide infrastructure
European Member States have to design and implement an ICT architecture that supports the exchange of trade related tax data between Tax Authorities of different Member States. Conceptually there are a few scenario’s for realizing such a collaborative infrastructure. These range from totally centralized to decentralized service oriented architectures.

1) a central European Tax reporting and Business Intelligence platform including:
- standardized connections for Businesses to provide tax related transaction data based on the European-specific data exchange standard via a web-enabled portal or data exchange services such as EDI

- a central data warehouse for storage of reported tax related transaction data

- Business Intelligence functionality for Authorities and Businesses to analyze, validate and when needed correct stored information

2) a decentralized country-based architecture including:
- country-specific standards and connections for Businesses to provide tax related transaction data

- decentralized local data warehouses for storage of reported tax related transaction data

- a Business Intelligence solution based on a service oriented architecture that enables analysis and validations of transactions across all Country-specific data warehouses

Conclusions
As many of us realize e-Invoicing is just the first step towards full automation of the supply chain. Only when the latter is accomplished all parties involved will realize the return on investment pursued.

Tax Authorities and/or the CEN/ISSS Work Group should launch a new Task Group in phase 3 that is going to formalize a standard for Tax reporting and define / develop European-wide functionality for processing the tax related transaction data by all Member States as such that they are able to validate cross-company transactions.

Tags: electronic data interchange, HR-XML, e-Invoicing, e-Business, UBL

Last updated: 26-11-2011

Lees meer!

Wordt Elektronisch Factureren gegijzeld door technologie bedrijven ?

In recente onderzoeken naar Elektronisch Factureren worden een aantal belemmeringen geïdentificeerd voor de invoering van Elektronisch Factureren waaronder de perceptie van complexiteit, onduidelijke wetgeving en afwezigheid van standaarden. Als grootste belemmering voor de adoptie en het gebruik van Elektronisch Factureren wordt onduidelijke wet- en regelgeving gezien.

Alhoewel de wet- en regelgeving sterk is aangepast de laatste jaren blijft het gevoel bij velen onder ons aanwezig. Vooral grensoverschrijdend factureren lijkt niet van de grond te komen en dit zou voornamelijk te wijten zijn aan deze wet- en regelgeving.

Wordt dit alles nu veroorzaakt door een onduidelijke wet- en regelgeving of door de wijze waarop diverse partijen waaronder de Europese Overheid en de verschillende lidstaten hier invulling aan geven. Een belangrijk knelpunt voor de adoptie van (grensoverschrijdend) elektronisch factureren is de regelgeving rondom het gebruik van de elektronische handtekening.

Waaruit bestaat de regelgeving rondom de Elektronische Handtekening?
Eind 1999 verscheen de Europese Richtlijn 1999/93/EG betreffende een gemeenschappelijk kader voor elektronische handtekeningen. Volgens deze richtlijn zijn elektronische handtekeningen gelijkgesteld aan handtekeningen op een papieren drager vooropgesteld dat aan bepaalde betrouwbaarheidseisen is voldaan. De richtlijn schrijft het rechtsgeldig maken van elektronische handtekeningen in de Europese lidstaten voor.

De Richtlijn onderkent twee soorten elektronische handtekeningen:
- de gewone elektronische handtekening waaronder wordt verstaan een handtekening in de vorm van elektronische gegevens die gekoppeld is / wordt aan andere elektronische gegevens en waarmee de identiteit van een persoon (afzender) vastgesteld kan worden. Denk hierbij aan een e-mailbericht waarin persoonsgegevens staan of een gescande handtekening is gebruikt. Het intoetsen van een pincode of wachtwoord voor het bevestigen van een elektronische transactie is eveneens een gewone elektronische handtekening.

- de geavanceerde elektronische handtekening waaronder wordt verstaan een handtekening die op unieke wijze aan de ondertekenaar is verbonden, het mogelijk maakt de ondertekenaar te identificeren, tot stand is gekomen met middelen die de ondertekenaar onder zijn uitsluitende controle kan houden, en op zodanige wijze aan de gegevens of het elektronische bestand waarop zij betrekking heeft is verbonden dat elke wijziging achteraf van de gegevens kan worden opgespoord.

In Nederland is de Wet Elektronische Handtekeningen (WEH) per 21 mei van kracht gegaan evenals het Besluit elektronische handtekeningen. Verder is een artikel toegevoegd aan het Burgerlijk Wetboek voor de Wet Elektronische Handtekeningen: “Een elektronische handtekening heeft dezelfde rechtsgevolgen als een handgeschreven handtekening, indien de methode die daarbij is gebruikt voor authentificatie voldoende betrouwbaar is, gelet op het doel waarvoor de elektronische gegevens werden gebruikt en op alle overige omstandigheden van het geval.”

De Wet Elektronische Handtekeningen hanteert naast de hierboven beschreven eisen voor de geavanceerde elektronische handtekening de volgende twee kwaliteitseisen bedoeld om de veiligheid te vergroten (zoals ook voorgeschreven door de Europese Richtlijn):
- de handtekening is gebaseerd op een gekwalificeerd certificaat afgegeven door een certificatiedienstverlener die voldoet aan de eisen voor gekwalificeerde certificaten, in Nederland voldoet aan de eisen gesteld in de Telecommunicatiewet

- de handtekening is gegenereerd door een veilig middel voor het aanmaken van elektronische handtekeningen

En let op: Alleen als de elektronische handtekening, naast de eisen van de geavanceerde handtekening ook aan bovenstaande kwaliteitseisen voldoet, dan heeft de elektronische handtekening per definitie dezelfde rechtsgevolgen als een handgeschreven handtekening.

Echter hier brengt de Europese Richtlijn enige nuancering aan:
De Europese Richtlijn zegt wel dat een elektronische handtekening geen rechtsgeldigheid mag worden ontzegd en dat zij niet als bewijsmiddel in gerechtelijke procedures kan worden geweigerd louter op grond van het feit dat:
de handtekening in elektronische vorm is gesteld, of
- niet is gebaseerd op een gekwalificeerd certificaat, of
- niet is gebaseerd op een door een geaccrediteerd certificatiedienstverlener afgegeven certificaat, of
- niet met een veilig middel is aangemaakt.

Als aanvullende regelingen zijn tevens de regeling elektronische handtekeningen en de beleidsregel aanwijzing certificatieorganisaties van kracht geworden. De wet elektronische handtekeningen is in feite een opsomming van wijzigingen in het Burgerlijk Wetboek en de Telecommunicatiewet.

Wat zijn de gevolgen van deze Europese Richtlijn voor Elektronisch Factureren?
Enerzijds heeft deze richtlijn Elektronisch Zakendoen in een versnelling gebracht. Het gaat niet alleen om Elektronisch Factureren maar betreft het volledige scala van business transacties, gaande van contractering tot / met facturering.

Voorheen waren elektronische facturen alleen rechtsgeldig (goedgekeurd door de Belastingdienst) wanneer gebruik gemaakt werd van Electronic Data Interchange, meerbepaald de procedures van verwerking van het bericht garanderen dat voldaan is aan de authenticiteits- en integriteitseisen.

Anderzijds heeft de richtlijn een technologische ontwikkeldrift veroorzaakt bij leveranciers van oplossingen voor elektronische handtekeningen en bij certificatiedienstverleners.

De Belastingdienst beschouwt nu het gebruik van een geavanceerde elektronische handtekening als één van de goedgekeurde methoden voor elektronisch factureren. Daarmee kan eenduidig de authenticiteit van de herkomst en de integriteit van de inhoud van een elektronische factuur gewaarborgd kan worden.

Waarom voldoet de digitale handtekening !
- Authenticiteit van Herkomst waarborgen:
De digitale handtekening zorgt ervoor dat de ontvanger van een bericht vertrouwen kan (mag) hebben in de afzender omdat de ontvanger het bericht alleen kan lezen (verifiëren en decoderen) met de publieke sleutel (public key) van de afzender. De afzender tekent het bericht met een geheime sleutel (private key).

- Integriteit van de Inhoud waarborgen:
Zowel de afzender als de ontvanger van een bericht willen zekerheid dat de inhoud van het bericht niet gewijzigd is tijdens het transport (communicatie). De digitale handtekening krijgt een controlegetal, berekend met cryptografische technieken, van het oorspronkelijk bericht. Bij ontvangst van het bericht kan door het opnieuw uitvoeren van deze berekening gecontroleerd worden of de inhoud gewijzigd is tussen verzending en ontvangst.

Maar welke problemen veroorzaken deze Geavanceerde Elektronische Handtekeningen?
Elke Europese lidstaat heeft invulling gegeven aan de genoemde Europese Richtlijn voor wat betreft het gebruik van de gekwalificeerde elektronische handtekeningen. Als gevolg daarvan worden de elektronische handtekeningen niet grensoverschrijdend geaccepteerd. Dat heeft met regelgeving (geen centrale geaccrediteerde certificatiedienstverleners) en techniek (landelijke technologische benaderingen).

Wat we nu zien is dat het niet mogelijk is om een factuur van de ene lidstaat naar de andere te sturen zodanig dat voldaan is aan gestelde eisen wanneer gebruik wordt gemaakt van geavanceerde elektronische handtekeningen.

Wat gaat op korte termijn veranderen binnen Europa op het gebied van de Elektronische Handtekening?
De vraagstelling is niet alleen wat er gaat veranderen maar waardoor deze veranderingen plaatsvinden?

Een aantal partijen stellen de constructies die door de meeste lidstaten in leven zijn geroepen rondom het gebruik van de Elektronische Handtekening ter discussie. Tussen de regels door valt op te maken dat bedrijven zich hieraan uberhaupt niet hoeven te houden. De Europese Richtlijn had reeds een nuancering opgenomen over de rechtsgeldigheid van de Elektronische Handtekening.

Met betrekking tot de procedures en eisen gesteld aan het waarborgen van de authenticiteit van de herkomst en integriteit van de inhoud van een elektronische factuur zijn recent een aantal uitspraken gedaan die vragen oproepen bij het gebruik van (geavanceerde) digitale handtekeningen zoals gepropageerd door de meeste Europese landen.

1) De koepelorganisatie van Europese belastingadviseurs, de CFE Confederation Fiscale Europeenne, heeft zich duidelijk uitgesproken over de verregaande encryptie eisen in relatie tot de TAX / VAT regels.

In een Opinion Statement Review of the existing legislation regarding invoicing from 26 September 2008 wordt het volgende standpunt ingenomen ten aanzien van elektronische handtekeningen op de factuur.

The Opinion Statement is a reply on the European Commission’s online consultation to ascertain the view of businesses on the existing legislation on VAT invoicing.

Therefore the CFE expresses its major concern about the requirement of sophisticated encryption methods such as for example advanced electronic signatures, for both the electronic invoicing and electronic archiving. There is no evidence that such encryption procedures are necessary.

Complex national encryption requirements imposed on the issuers of invoices are totally useless when the VAT is due from the customer, rather than the supplier, which is the position with many international or intra-community supplies.

2) UEAPME - the European Association of Craft, Small and Medium-Sized Enterprises aisbl, de overkoepelende Europese organisatie van het midden- en kleinbedrijf, waarvan het MKB-Nederland deel uitmaakt en bestaat uit 70 zusterorganisaties uit de overige lidstaten heeft zich uitgesproken over de bevindingen van de Europese Expertgroep voor E-Invoicing (European Electronic Invoicing EEI).

There is no need for onerous security measures when it comes to the authenticity and integrity of e-invoicing, particularly when businesses can prove that proper internal control processes are in place. Therefore, equal treatment of paper invoices and einvoices relates foremost to authenticity and integrity.

Internal business controls, if properly implemented, should be a sufficient reassurance to tax. Although an electronic signature is a method to prove authenticity of origin and integrity of content, the issuance of e-invoices should not trigger the obligation of an electronic signature if authenticity of origin and integrity of content can also be proved by other means

3) De Expert Groep E-Invoicing adviseren om het gebruik van de digitale handtekening te vermijden:

The Expert Group envisages a ‘Model Contract for secure Data Exchange’ as the ‘legal solution’ capable of promoting wider use of e-invoicing by SMEs (in addition to a standard cross-industry ‘basic’ e-invoice and a major role of banks). The ‘Model Contract‘ would not prescribe digital signature but define other ‘simpler’ methods of ensuring an ‘acceptable’ level of authenticity and integrity of the documents exchanged.

Afsluitend :
Eén en ander kan niet beter onder woorden worden gebracht als door de Finse Information Society recent gebeurde: met name waar gaat het nu eigenlijk over : Trust and Confidence

The first difference of the opinion usually springs from the very attitude towards trust and confidence. In Finland, generally speaking, the initial attitude is trust and confidence with the parties being dealt with, unless otherwise proven. In a number of countries, on the other hand, the starting point is that the opposing parties are all crooked – or at least subject to justified suspicion – therefore security and auditing systems must be on fail proof level. This difference in opinions creates really major differences in demands also for electronic invoices.

Belangrijker nog is de videopresentatie van iemand die ECHT weet waarover het gaat, Bo Harald voorzitter van de European Electronic Invoicing Expert Group:

WE ARE HIGHJACKED BY TECHNOLOGY COMPANIES.

Electronic Invoicing - 238 bilion reasons - to begin with...
Bo Harald

Tags: electronic data interchange, Overheid, e-Invoicing

Last update: 26-11-2011

Lees meer!

Is Electronic Invoicing taken hostage by technology companies ?

Recent surveys identified a number of barriers for the introduction of electronic invoicing including the perception of complexity, unclear legislation and absence of standards. The largest obstacle to the adoption and the use of electronic invoicing are ambiguous laws and regulations.

Although the laws and regulations have changed in the past years this feeling remains present among many of us. Especially cross-border invoicing does not seem to come from the ground - mainly - due to these laws and regulations.

Is all of this caused by ambiguous laws and regulations or by the way European authorities and Member States have implemented these regulations. One such bottleneck is the regulatory environment surrounding the use of electronic signatures.

.

What is the regulatory environment surrounding the Electronic signature?

The European Commission on 28 January 2009 adopted a proposal to change the VAT Directive 2006/112/EC (from 28 November 2006) with respect to the invoicing rules. The European Commision published a communication on the technological developments in the field of electronic invoicing (COM/2009/20).

The aim of the proposal is to increase the use of electronic invoicing, reduce burdens on business, support small and medium sized enterprises (SMEs) and help Member States to tackle fraud. This publication includes also measures aimed at further simplifying, modernizing and harmonizing the VAT invoicing rules.

The proposed changes for electronic invoicing are:

- Treat the transmission of paper and electronic invoices equally by removing the conditions for advanced electronic signatures (AES) and electronic data interchange (EDI).

- Notification and acceptance by the receiver of the invoice and Tax Authorities is no longer required instead normal commercial practice will apply.

- Period of storage: Common storage period of 6 years within Europe for VAT invoices.

- Format of storage: Paper invoices may be converted into electronic form for storage purposes. Storage of invoices in original format is no longer required.

- Place of storage: No conditions for the place of storage other than that the invoice must be available without undue delay. The invoice should no longer be online available when held outside the Member State of the supplier or customer.

- Notification of the place of storage: Notification is no longer required.

- Date of supply of an Intra-community transaction = date of chargeability of tax, date when the tax is due to Treasury. The invoice should no longer contain the date of supply but instead the date when the tax is due.

- The invoice has to be issued before the 15th of the month following the date of supply.

The requirements imposed on the authenticity of origin and integrity of content of the invoice are changed by this proposal. The Dutch government adopted the proposal in less than a few weeks after announcement. Just in time for us to tell the Dutch Tax Authorities that we were not going to implement the advanced digital signature for the project Electronic Ordering and Invoicing with the Dutch Tax Authorities which went live in July of 2008.

Going for a technology-neutral solution is the fastest path to adoption of electronic invoicing in Europe. The last year several organizations raised seriously questions on the usage of advanced digital signatures as implemented by most European countries.

1) The Fiscal Committee of the European Tax Advisers - Confédération Fiscale Européenne (CFE) - expressed themselves clearly about the requirement of sophisticated encryption methods for both electronic invoicing and archiving. In their Opinion Statement on VAT formalities from 26 September 2008 - Review of the existing legislation regarding invoicing - they replied on the European Commission's online consultation to ascertain the view of businesses on the existing legislation on VAT invoicing.

“The CFE expresses its major concern about the requirement of sophisticated encryption methods such as for example advanced electronic signatures, for both the electronic invoicing and electronic archiving. There is no evidence that such encryption procedures are necessary.

Complex national encryption requirements imposed on the issuers of invoices are totally useless when the VAT is due from the customer, rather than the supplier, which is the position with many international or intra-community supplies.”

2) The European Association of Craft, Small and Medium-Sized Enterprises aisbl (UEAPME), the European SME umbrella organization, incorporates 83 member organizations from 36 countries consisting of national cross-sectorial SME federations, European branch federations and other associate members, which support the SME family.

The UEAPME replied on the European Electronic Invoicing (EEI) Final Report, the findings of the European Expert Group on E-Invoicing, with the following statement: “There is no need for onerous security measures when it comes to the authenticity and integrity of e-invoicing, particularly when businesses can prove that proper internal control processes are in place. Therefore, equal treatment of paper invoices and einvoices relates foremost to authenticity and integrity. As the experience in practice shows, e-invoicing is used most in those countries which treat paper and e-invoices the same when it comes to integrity and authenticity.”

See document Taskforce reply to EEI Draft Recommendations from 22 September 2008.

Internal business controls, if properly implemented, should be a sufficient reassurance to tax. Although an electronic signature is a method to prove authenticity of origin and integrity of content, the issuance of e-invoices should not trigger the obligation of an electronic signature if authenticity of origin and integrity of content can also be proved by other means.

3) The Expert Group on E-Invoicing advised to eliminate the usage of the advanced digital signature:

“The Expert Group envisages a ‘Model Contract for secure Data Exchange’ as the ‘legal solution’ capable of promoting wider use of e-invoicing by SMEs (in addition to a standard cross-industry ‘basic’ e-invoice and a major role of banks). The ‘Model Contract‘ would not prescribe digital signature but define other ‘simpler’ methods of ensuring an ‘acceptable’ level of authenticity and integrity of the documents exchanged.”

The Communication from the Council to the Commission on the technological developments states: “There is at present no single business-friendly technology to support e-invoicing throughout the EU that satisfies both large and small businesses and has full support of all tax authorities. Moreover, there is no clear prospect of a suitable technology-based solution encompassing the needs of all parties in the next few years. Thus technology should not be relied upon to improve the take up of e-invoicing. “

The Expert Group on E-Invoicing set up by Commission Decision states in an open letter to the Commission: “Any solution to e-invoicing should be technology-neutral as a matter of principle.”

Finally, one cannot formulate it better than done by the Finish Information Society in 2005: “It is all about Trust and Confidence. The first difference of the opinion usually springs from the very attitude towards trust and confidence. In Finland, generally speaking, the initial attitude is trust and confidence with the parties being dealt with, unless otherwise proven. In a number of countries, on the other hand, the starting point is that the opposing parties are all crooked – or at least subject to justified suspicion – therefore security and auditing systems must be on fail proof level. This difference in opinions creates really major differences in demands also for electronic invoices.”

Bo Harald, Chairman EU Commission Expert Group on E-Invoicing, says in his video-statement “there are 238 billions reasons - to begin with ... but we are highjacked by technology companies”. See the e-Business News Channel for the video-statement of Bo Harald.

WE ARE HIGHJACKED BY TECHNOLOGY COMPANIES.

Electronic Invoicing - 238 bilion reasons - to begin with...
Bo Harald

Lesson learned from examinations and investigation of the legal and fiscal regulations and evolution over the past months is that there is no way back from here. The fastest path for adoption of electronic invoicing is a technology-neutral solution where at current there is no place for continuation of the advanced digital signature.

When more countries adopt this proposal towards the 1st of January 2013 the issues of authenticity of origin and integrity of content will have to be embedded in financial systems, procedures and reconciliation of cross-country tax reporting / declarations. Business Control will become the keyword and it is up to us to deal with it.

Tags: electronic data interchange, Government, e-Invoicing

Last update: 26-11-2011

Lees meer!

Is de Inter Enterprise Buziness Hub de toekomst ?

In 2005 heb ik de implementatie van Elektronisch Bestellen en Factureren begeleid tussen twee bedrijven voor een leverancier van diensten. Het doel was om de verkoop- en inkoopprocessen van beide partijen te integreren gebruikmakende van elektronische gegevensuitwisseling op basis van internationale standaarden.

Het verzoek was uitgegaan van de klant omdat deze door elektronische verwerking van facturen aanzienlijke besparingen kon realiseren. De klant had de implementatie en het beheer volledig uitbesteed aan een intermediair, een aanbieder van Electronic Ordering en Invoice Presentment via het Web.

In mijn bloart Definitie Elektronisch Factureren schets ik de voornaamste uitvoeringsvormen van Elektronisch Factureren in Nederland. Het model dat door de klant werd geïmplementeerd was het Buyer Direct Model waarbij de web-gebaseerde oplossing en de integratie met de systemen (klant en leveranciers) door de intermediair werden geleverd.

Het was gedurende deze implementatie dat ik mij bewust werd van het interoperabiliteitsvraagstuk. Nog tijdens het project ben ik gaan nadenken over een andere benadering voor het realiseren van Business-to-Business (Elektronisch Zakendoen) tussen meerdere bedrijven. Conceptueel was het voor mij vrij snel duidelijk dat de bedrijfswereld het beste gebaat was bij een combinatie van Business-to-Business Integratie en Web Presentment waarbij gebruik gemaakt wordt van een gemeenschappelijk informatie model en open standaarden.

Waar gaat het naartoe met Business Integratie ?
Met de sterke opkomst van op diensten gerichte architecturen (Service Oriented Archtectures) leek het mij zinvol om een gedegen onderzoek uit te voeren naar de marktontwikkelingen en de visies van analisten. Heel veel presentaties, onderzoeksverslagen, scripties en thesissen zijn de revue gepasseerd. Interessant was de presentatie “Constructing Software for Service Oriented Architecture” van Jean-Jacques Dubray uit 2004. Ondertussen is een hernieuwde versie met de titel “An Introduction to SOA” beschikbaar op de website www.ebpml.org. In de presentatie wordt een overzicht gegeven van de ontwikkeling van Connectiviteit en Business Integratie over de afgelopen 30 jaar. Forrester en Gartner hebben de voorbije jaren deze grafiek verder aangevuld met hun visie op Business Integratie. Service Oriented Architectures spelen daarin eveneens een belangrijke rol maar beide analisten hebben een eigen kijk op de toekomst zoals ik hierna zal toelichten.

Forrester ziet de Business Service Hub (BSH) een belangrijke plaats innemen in het integratie landschap. Forrester gaat uit van een gelaagde integratiestrategie (layered integration strategy) bestaande uit vier integration layers:
- process (BPM)
- presentation (Portals)
- application (ESB, EAI)
- data (ETL)
De Business Service Hub is een intermediair die on-demand integratiediensten levert waaronder Messaging, Routing, Transformation, Partner Management en Business Acitivity Monitoring (BAM). De Business Service Hub richt zich vooral op bedrijfsoverschrijdende transacties.

Gartner pleit voor de Worldwide Grid en Enterprise Nervous Systems (ENS). De Grid is een wereldwijd computernetwerk samengesteld uit Enterprise Nervous Systems, sub-netwerken. Het is een semantische en procesgerichte infrastructuur waarbinnen interacties tussen bedrijven plaatsvinden. Elk bedrijf beschikt over een eigen Enterprise Nervous System.

Welke conceptuele benadering is ontstaan ?
Gaandeweg is een concept ontstaan met de werknaam “Inter Enterprise Buziness Hub (IEBH)”. De “Inter Enterprise Buziness Hub” is een conceptuele benadering voor het bereiken van Business Integratie. Het kan gezien worden als een partner- en standaarden onafhankelijke universele communicatiepoort met business partners, waaronder klanten, leveranciers, overheid, vervoerders en financiële instellingen. Het voornaamste doel is het koppelen van bedrijfsprocessen en informatiestromen over de grenzen van bedrijven heen door middel van een intermediair platform.

Het concept is vooral een antwoord op de traditionele point-to-point manier van elektronische gegevensuitwisseling. Het streven is om eveneens een antwoord te geven op het interoperabiliteitsvraagstuk.

Essentieel in het concept zijn:
- Verscheidenheid aan connectiemogelijkheden
- Gegevensuitwisseling gebaseerd op Internationale Open Standaarden
- Common Informatie Model (CIM)
- Centrale opslag van alle verwerkte gegevens
- Gegevens toegankelijk voor iedereen via het Web

Het uitgangspunt is dat het concept met verschillende softwaregereedschappen en leveranciers gerealiseerd kan worden.

Het concept kan het beste gerealiseerd worden binnen een Consolidator Model maar andere modellen zijn niet uitgesloten. Alleen zal de functionaliteit dan beperkt blijven tot een 1-op-n relatie. Bedrijven kunnen wel hun bestaande architectuur als basis nemen.

Met welke softwaregereedschappen en leveranciers kan het concept gerealiseerd worden ?
Teneinde het concept gerealiseerd te krijgen heb ik de verschillende softwaregereedschappen op de markt geïnventariseerd en onderzocht. Met enkele aanbieders hebben architectuursessies plaatsgevonden om te komen tot een betere definitie van de eisen gesteld aan de functionaliteit. Dat heeft geleid tot een lijst met vereisten t.a.v. functionaliteit die ondersteund moet worden:
- Business Process Management (BPM) & Orchestration
- Business Activity Monitoring (BAM)
- Trading Partner Management & Enablement (onboarding)
- Connectors voor het verzorgen van de connectiviteit tussen bron en bestemming
- Adapters voor het verzorgen van de connectiviteit met applicaties
- Service Oriented Architecture (SOA)

Een aantal leveranciers en softwaregereedschappen waarmee het concept gerealiseerd kan worden zijn:
Commerciële oplossingen:
- Sun Microsystems Java Composite Application Platform Suite (Java CAPS)
- Axway Synchrony Suite
- SAP
- Oracle

Open Source oplossingen
- JBoss & XAware
- OpenESB & XAware
- Apache ServiceMix & Chainbuilder

Hoe ziet het concept eruit ?
In volgende presentatie wordt het concept van de Inter Enterprise Buziness Hub uitgebreider toegelicht.

Inter Enterprise Buziness Hub Slideshare

View more presentations from Danny Gaethofs

Welke uitdagingen zijn er nog ?
De grootste uitdaging ligt echter nog steeds in het transformatiedomein. De Inter Enterprise Buziness Hub zal geen implementatievereenvoudiging opleveren wanneer de ontwikkeling van transformatiedefinities volledig handmatig moet blijven gebeuren.

Een belangrijke vraag daarom dient nu en in de toekomst beantwoord te worden: Hoe kunnen standaarden getransformeerd worden gebruikmakende van een intelligente benadering.

Ik heb hier de laatste maanden heel veel onderzoek naar gedaan. Er zijn een aantal benaderingen mogelijk:
- de UN/CEFACT Core Components Technical Specification (CCTS)
- Universal Data Element Framework (UDEF)

Over bovenstaande benaderingen heb ik al geschreven in mijn bloarts Hoe lossen we het interoperabiliteitsvraagstuk op ? en Transformatiedefinities voor de Elektronische Factuur.

Een andere benadering waar vanuit Europees perspectief in tal van projecten aan gewerkt wordt is Semantic Based Transformation. Hierover zal ik binnenkort nog verder berichten.

Hoever staat het met commerciële toepassingen van deze concepten ? SAP, één van de grootste sponsors van de UN/CEFACT CCTS werkt aan een modelleer en transformatiegereedschap met de werknaam SAP CCTS Modeler Warp 10. SAP is vrij ver gevorderd in het beantwoorden van de door mij zojuist opgeworpen vraag.

De architectuur van Warp 10 is gebaseerd op SAP NetWeaver en biedt zowel integratie en uitbreiding van de SAP Global Data Types (GDT’s) als de transformatie naar ieder ander logisch data model ongeacht de gegevensbron. Meer hierover in mijn bloart SAP CCTS Modeler Warp 10, modelleer en transformatiegereedschap. Ik zal binnenkort meer in detail ingaan op SAP Warp 10. Meer informatie kunt u vinden op de Collaboration Workspace van SAP onder Business Data Interoperability.

De nabije toekomst zal uitwijzen hoe het integratielandschap in de komende jaren ingevuld gaat worden. Interoperabiliteit staat op de agenda van internationale gemeenschappen en overheden.

Business Integratie blijft een dynamisch domeingebied en wordt heel sterk beïnvloed door de technologische ontwikkelingen.

Tags: electronic data interchange, Enterprise Service Bus, UDEF, Interoperability-Frameworks, UBL

Last update: 3-12-2011

Lees meer!

Wordt UBL, de elektronische communicatiestandaard in Europa ?

In september 2001 is op voorstel van een aantal leden van OASIS (Organization for the Advancement of Structured Information Standards) waaronder Sun Microsystems, Commerce One, SAP en Boeing de OASIS Universal Business Language Technical Committee (UBL TC) opgericht. Het voornaamste doel van de UBL TC, voorgezeten door Jon Bosak (Sun Microsystems), was / is het ontwikkelen van een gratis bibliotheek van gestandaardiseerde elektronische op XML gebaseerde bedrijfsdocumenten.

De ontwikkeling van UBL is gestart gedeeltelijk als reactie op de veelheid en verscheidenheid aan XML standaarden / bibliotheken voor elektronische handel maar eveneens om de toegankelijkheid van elektronische handel te vergroten. UBL moet elektronisch zakendoen voor kleine en middelgrote bedrijven mogelijk maken en de basis leggen voor de wereldwijde overgang van traditioneel zakendoen naar elektronische handel.

De OASIS Universal Business Language (UBL) is gebaseerd op de XML Common Business Language xCBL versie 3.0 van Commerce One. Commerce One nam in 1999 het bedrijf Veo Systems over en kwam zo in het bezit van de Common Business Language (CBL) technologie. Deze technologie is door Commerce One verder uitgebreid en omgedoopt tot xCBL om de relatie met XML te identificeren. De XML Common Business Language (xCBL) is een verzameling van XML bouwstenen en een raamwerk voor de ontwikkeling van herbruikbare XML berichten. xCBL richt zich op documenten en transacties ter ondersteuning van de internationale elektronische handel. Commerce One heeft de versie 3.0 van xCBL ingebracht in de OASIS UBL Technical Committee als startpunt voor de ontwikkeling van UBL.

Op70 version) vrijgegeven aan het publiek voor review waarna in november 2004 de eerste officiële versie van UBL, release 1.0, na drie jaar ontwikkeling werd uitgebracht. Twee jaar later, november 2006, werd UBL 2.0 uitgebracht en als formele standaard geaccepteerd door OASIS.

De Universal Business Language maakt gebruik van XML Schema’s voor het beschrijven van gestandaardiseerde bedrijfsdocumenten. Een XML Schema Definitie Document (XSD) beschrijft de structuur van een XML document. UBL 2.0 ondersteunt 31 bedrijfsdocumenten (document types) en voor elk document is een XSD Schema opgesteld.

Verschil tussen UBL 2.0 en UBL 1.0
Een belangrijk verschil tussen UBL 2.0 en de voorgaande releases is het gebruik van een getrapt (twee-fase) validatiemodel. Tijdens het verwerken van een UBL bericht moet de structuur en het juist gebruik van gestandaardiseerde codes worden gevalideerd. UBL maakt gebruik van internationaal gestandaardiseerde codelijsten, verzameling van toegestane waarden, die worden uitgegeven en onderhouden door standaardisatie instellingen, waaronder ISO (landencodes) en UN/CEFACT (valutacodes, eenheidsmaten, taalcodes). Codelijsten kunnen ook gebruikt worden voor het vastleggen van afgesproken waarden tussen twee of meer handelspartners.

In de voorgaande releases werden de verzameling toegestane waarden of codes rechtstreeks vastgelegd in de XML Schema’s van de bedrijfsdocumenten en kon validatie van structuur en codes gelijktijdig uitgevoerd worden. In UBL 2.0 worden de codelijsten vastgelegd in afzonderlijke configuratiebestanden en kan een getrapt validatieproces gevolgd worden. Hierdoor is het mogelijk om verschillende versies van een codelijst te hanteren per situatie. Zo kan per bedrijf waarmee zaken gedaan wordt een andere versie van een codelijst gehanteerd worden.

UBL 2.0 schema’s ondersteunen het gebruik van een getrapt validatie proces dat schematisch als volgt wordt weergegeven en bestaat uit twee stappen (fasen):

- Stap 1: Controle op structuur, data typing en vocabulary via UBL XSD bestanden en een generieke XSD validator
- Stap 2: Controle op het juist gebruik van waarden uit de codelijsten via UBL XSLT bestanden en een generieke XSLT processor. In deze stap vindt validatie van internationaal gestandaardiseerde codes plaats via de standaard UBL 2 .xsl bestanden en validatie van trading-partner specifieke codes via de customized .xsl bestanden.

Hoe staat het met het gebruik van UBL voor elektronisch zakendoen
Wereldwijd is UBL in gebruik als de elektronische berichtenstandaard voor elektronisch zakendoen tussen bedrijven en overheden. Binnen Europa lopen een aantal landen voorop in de ontwikkeling van een elektronische communicatiestandaard voor elektronisch zakendoen tussen bedrijven en overheden.

Denemarken (National IT and Telecom Agency)
Denemarken heeft de invoering van elektronisch factureren vrij rigoureus aangepakt. Vanaf 1 februari 2005 mogen overheidsinstellingen in Denemarken - dit werd zo vastgelegd in de wetgeving - alleen facturen van leveranciers accepteren in een elektronisch formaat, de OIOXML Electronic Invoice. De OIOXML (Open public Information Online XML) Electronic Invoice is de Deense XML-standaard voor de elektronisch factuur gebaseerd op de eerste versie van UBL release 0.7. Voor meer informatie: OIOXML Electronic Invoicing.

Bedrijven kunnen op een aantal manieren facturen aanleveren:
1) via het aanmaken en verzenden van een elektronische factuur vanuit het facturatie-systeem via de elektronische postbus van een Value Added Network (VAN).

2) via een Read-In Bureau die zorgdraagt voor het scannen en converteren van een papieren factuur naar het elektronische formaat en het verzenden van deze elektronische factuur naar de juiste overheidsinstelling via een Value Added Network.

3) via het handmatig invoeren van de factuur in een Internet Invoice Portal die zorgdraagt voor het aanmaken van de factuur in het elektronische formaat en het verzenden van deze elektronische factuur naar de juiste overheidsinstelling via een Value Added Network

Schematisch ziet dit er op hoofdlijnen als volgt uit:

De Deense overheid stelt volgende eisen aan de informatie in de factuur:
- het gebruik van de EAN locatiecode voor identificatie van de klant is verplicht en de klant moet de EAN code verstrekken tijdens het plaatsen van de order
- een referentie naar de inkooporder of bestelling is verplicht
- een referentie naar de persoon die de order heeft geplaatst is verplicht
- interne identificatiecode van de klant is verplicht als deze verstrekt werd tijdens het plaatsen van de order

Let op: Denemarken maakt vooralsnog geen gebruik van de OIOUBL Invoice. De OIOUBL standaard wordt wel aanbevolen voor het uitwisselen van elektronische catalogi en inkooporders. OIOUBL is gebaseerd op UBL release 2.0 (Voor informatie: Online OIOUBL Documentation)

Noord-Europa
Northern European Subset (NES) is een initiatief dat voortvloeit uit de samenwerking tussen enkele Noord-Europese landen op het gebied van e-commerce en e-procurement. Onder aanvoering van Denemarken hebben vertegenwoordigers van de Noord-Europese landen Denemarken, Zweden, Noorwegen, Ijsland, Finland en van het Verenigd Koninkrijk begin 2007 een werkgroep opgericht voor het ontwikkelen van een Noord-Europese Subset (Northern European Subset (NES)) van op UBL 2.0 gebaseerde documenten.

De NES organisatie heeft de Universal Business Language (UBL) geselecteerd als de Open berichtenstandaard - met op dit moment de meeste potentie - voor het realiseren van grootschalige e-commerce en e-procurement handelstransacties tussen overheden onderling en bedrijven, zowel grensoverschrijdend (cross-border) als nationaal (domestic).

Het NES project richt zich niet op het uitvoeren van implementaties maar heeft als voornaamste doel zorgdragen voor het tot stand komen van een gezamenlijk platform voor e-procurement.

De belangrijke resultaten van het NES project zijn:
- Profielen die bedrijfsprocessen en scenario’s beschrijven uitgaande van UBL voor handelstransacties
- Berichtdefinities gebaseerd op een gemeenschappelijke subset (deelverzameling) van UBL handelsdocumenten
- Handleidingen en codelijsten
- Validatiegereedschappen

De aangesloten landen zijn zelf verantwoordelijk voor de uitvoering en coördinatie van implementaties. De laatste versie van NES is op 11 juli 2007 vrijgegeven en kunt u terugvinden onder de rubriek Documents op de website van NES. Al het materiaal van NES is gepubliceerd onder de Creative Common license.

Zweden
In Zweden loopt het project Single Face To Industry (SFTI). Het is een alles-in-één e-procurement standaard waarmee het bestel- en facturatieproces tussen handelspartners wordt ondersteund. Voor het bestelproces is sinds juni 2010 de CEN/BII Basic Order de aanbevolen standaard voor de publieke sector

Duitsland
In Duitsland is deze maand de German Localization Subcommittee (DELSC) samengesteld. Deze gaat zich buigen over de realisatie van een Duitse UBL Data Dictionary.

Spanje
CODICE is het Spaanse overheidsinitiatief voor het ontwikkelen van een verzameling elektronisch documenten gebaseerd op UBL voor de ondersteuning van het aanbestedingsproces. Vereenvoudigd zijn er drie processtappen die worden ondersteund: aankondigen of bekendmaken, aanbieden en gunnen.

De specificaties van de CODICE standaard zijn terug te vinden op de website contrataciondelestado.es.

ABILITIES
Het Europees project “Application Bus for InteroperabiLITy In enlarged Europe SMEs”, kortweg ABILITIES, is gestart begin 2006 en heeft een looptijd van 2 jaar. Het voornaamste doel van het project is het onderzoeken en ontwikkelen van een architectuur gebaseerd op UBL voor de ondersteuning van e-commerce transacties tussen kleine en middelgrote bedrijven (SMEs) voornamelijk in de minder ontwikkelde landen.

ABILITIES voorziet in drie interfaces:
- een Web portaal
- een GUI voor mobiele toegang
- een interface voor legacy systemen gebaseerd op web services

U.S. Department of Transportation (USDOT) Electronic Freight Management (EFM) initiatief
Het Electronic Freight Management (EFM) initiatief richt zich op de promotie en evaluatie van innovatieve e-business concepten. Het is een Research & Development project dat gesponsord wordt door de U.S. Department of Transportation (USDOT). De Electronic Freight Management (EFM) is geïmplementeerd op basis van de Freight Information Highway (FIH) architectuur. De FIH is een innovatieve non-propriëtaire service-georiënteerde architectuur voor de ondersteuning van de coördinatie tussen bedrijfsprocessen en veilige real-time gegevensuitwisseling.

Het EFM maakt gebruik van gestandaardiseerde berichten gebaseerd op UBL waaronder Advance Ship Notice, Dispatch Advice, Receipt Advice en Transportation Status.

Meer projecten en initiatieven staan op stapel en hierover zal ik later berichten.

Tags van Technorati: electronic data interchange,UBL,EDIFACT,UN/CEFACT,CEN/BII Government,enterprise service bus

Tags: electronic data interchange, Enterprise Service Bus, EDIFACT, Government, UBL, UN/CEFACT, CEN/BII

Last update: 3-12-2011

Lees meer!

Definitie Elektronisch Factureren

In opdracht van het Forum Standaardisatie is een onderzoek uitgevoerd naar de stand van elektronisch factureren in Nederland. (Zie Eindrapport e-Factureren en standaarden voor e-invoicing in Nederland). Voor het verkrijgen van een gemeenschappelijk begrippenkader zijn hieronder een aantal van de voornaamste uitvoeringsvormen van elektronische factureren in Nederland geschetst.

Er worden vier vormen van elektronisch factureren onderscheiden:
1) Electronic Invoice Presentment (EIP) – Seller Direct variant

2) Electronic Invoice Presentment (EIP) – Consolidator variant

3) Electronic Invoice Presentment (EIP) – Buyer Direct variant

4) Electronic Invoicing (E-Invoicing of eInvoicing) variant

Elektronisch Factureren via Electronic Invoice Presentment (EIP) betreft het aanbieden van factuurinformatie in een leesbare vorm via het Internet (een web-gebaseerde oplossing) in een Business-to-Business (B2B) Context, de zakelijke markt. Voor de consumenten markt (Business-to-Consumer context B2C) wordt de term Electronic Bill Presentment (EBP) gehanteerd. De wet- en regelgeving t.a.v. deze laatste verschilt in belangrijke mate van EIP ondermeer omdat een factuur niet verplicht gesteld wordt voor de levering van goederen of diensten aan particulieren.

In de Seller Direct variant stelt de verkoper de factuurinformatie in zijn eigen systeem via een web-gebaseerde toegang beschikbaar aan de koper. De koper dient handmatig de factuurinformatie te verwerken in zijn eigen crediteurenadministratie en controle uit te voeren of de geleverde goederen of diensten overeenkomen met de factuur waarna de factuur betaalbaar gesteld kan worden. Via een aankondiging dient de koper op de hoogte gesteld te worden van de ontvangst van een factuur. Dit heeft te maken met de factureringsverplichting. (Zie mijn bloart Welke vormen van Elektronisch Factureren zijn in Nederland toegestaan ?)

In de Buyer Direct variant stelt de koper zijn eigen systeem via een web-gebaseerde oplossing of toegang ter beschikking aan de verkoper ten behoeve van de overdracht van de factuurinformatie. De verkoper dient dan handmatig de factuurinformatie in te voeren in het systeem van de koper.

In de Consolidator variant stelt de verkoper de factuurgegevens ter beschikking aan een derde partij, de consolidator, waarna deze laatste op zijn beurt de gegevens ter beschikking stelt van de koper voor controle en verwerking

De E-Invoicing variant betreft de meest directe vorm van elektronisch factureren waarbij de informatie uit de factuur rechtstreeks en geautomatiseerd wordt overgedragen aan de gegevensverwerkende systemen waaronder ERP applicaties. Elektronisch factureren kan omschreven worden als het automatisch genereren van facturen uit ERP- en/of facturatiesystemen en/of opslagomgevingen, het automatisch verzenden van facturen in een gestandaardiseerd formaat gebaseerd op een internationale standaard (EDIFACT, UN/CEFACT CII, UBL, ETIX XML INVOICE) naar de klant waar de factuur eveneens automatisch verwerkt wordt in de crediteuren administratie.

Traditioneel worden bij deze vorm van factureren point-to-point verbindingen gerealiseerd tussen klanten en leveranciers en dienen beide partijen afspraken te maken over de Syntax: de structuur of opbouw van een bericht, de Semantiek: de omschrijving en betekenis van gegevenselementen en gehanteerde codes, de Business regels voor het verwerken van de factuur en het transportprotocol, de wijze van verzenden en ontvangen van berichten. Dit alles komt neer op het selecteren van een berichtstandaard voor het uitwisselen van factuurinformatie, het vastleggen van de betekenis van de aanwezige gegevenselementen en het definiëren of afspraken maken over codelijsten en het maken van afspraken het communicatieprotocol.

Deze vorm van elektronisch factureren wordt tegenwoordig eveneens ondersteund in een Consolidator – model waarbij een derde partij met elke partner afzonderlijk afspraken maakt over de gehanteerde syntax en semantiek, anders gezegd de berichtstandaard, het gebruik van gegevenselementen en het communicatieprotocol.

Afbakening van het begrip Elektronisch Factureren
Een belangrijk standpunt (conclusie) dat wordt ingenomen is dat het versturen of ontvangen van facturen in PDF – formaat volgens de definitie van het Forum Standaardisatie geen e-Factureren is. De eerder genoemde varianten zijn dat wel.

Samengevat zijn dat: het koppelen van informatiesystemen zodat factuurpartners facturen geautomatiseerd kunnen verwerken is dat wel. Dat kan via (1) directe, tweezijdige koppeling tussen ontvanger en verzender (e-invoicing), (2) via een eenzijdige oplossing waarin de verzender aan de ontvanger de factuur elektronisch of via Internet beschikbaar stelt (Electronic Invoice Presentment, EIP), en (3) via een derde partij die de factuur voor de verzender aan de ontvanger beschikbaar stelt (een ‘consolidator’).

Een ander belangrijk standpunt is dat het factuurproces niet los kan worden gezien van het totale order- en betalingsproces tussen twee partijen. Het traject van Elektronisch Bestellen en Factureren (EB&F) dat een aantal Overheden heeft ingezet als uitvloeisel van het project Professioneel Inkopen en Aanbesteden (PIA) zal naar (mijn) verwachting meer geaccepteerd worden door bedrijven. Immers dan wordt het volledige inkoop- en verkoopproces elektronisch ondersteund en levert dat beide partijen (leverancier en klant) voordelen en besparingen op.

De Belastingdienst is één van de Overheden die Elektronisch Bestellen en Factureren (EB&F) met leveranciers implementeert zowel met dienstverleners als met leveranciers van producten.

De Belastingdienst heeft begin van de maand juli de eerste implementatie van EB&F op basis van HR-XML, de standaard voor inhuur van personeel, met een leverancier van ICT personeel succesvol afgerond. Met een drankje en hapje is dat vanavond gevierd. De Belastingdienst gaat nu verder met het aansluiten van uitzendbureaus.

HR-XML, electronic data interchange, Overheid

Last update: 26-11-2011

Lees meer!

the XAware Sandbox EDIFACT project requirements

A few weeks ago I wrote about the missing support for EDIFACT and derived standards in Open Source XML-based Transformation Tools such as XAware and Chainbuilder.

The goal was to get the people behind these communities motivated to provide the means and tools for managing Community projects. One of these will of course be the development of EDIFACT functionality.

Meanwhile the XAware Company has established a Sandbox environment for Community Members to start their development projects but moreover to enable knowledge transfer and share prebuilt transformation routines and connectors / adaptors.

The guidelines and procedures for contributing code to the core software are under development. These will include coding guidelines and standards, test and certification guidelines, contributor agreement required for developers wishing to contribute code to the project, acceptance criteria and procedures for the adoption into the core project.

One of the first Community projects will be the development of EDIFACT functionality. A short summary of the UN/EDIFACT message structure can be found in my bloart Short description of the EDIFACT Message Structure.

People from XAware-Europe, Atos Origin, freelancers and private persons are participating on a voluntary basis to establish the first XAware Sandbox project, the EDIFACT functionality. Last week the functional requirements and technical design were discussed in the Netherlands based on a draft proposal from one of the participants.

The goal is to establish a generic approach that will become available for the whole community. The preliminary functional requirements and technical design are described hereafter. You are welcome to join us in the development of the EDIFACT functionality or to comment on the preliminary requirements and design approach.

Background
XAware is Data Integration Middleware provided under the Open Software Foundation approved GNU General Public License Version 2 GPLv2. People all over the world are using XAware technology for various projects and purposes. The main reasons for the popularity are:

1. Benefits of Open Source software.

2. XAware has an open architecture and Application Programming Interface (API)

3. Solutions can be implemented in a short period of time

4. Reusable integration solutions for message standards

The benefits of Open Source software are:
- Lower software licensing costs

- Avoidance of proprietary lock-in

- Compliance with accepted industry standards

- High innovation speed

- Freedom to study how the programs works and adapt it to your needs

- Freedom to run the program

To use XAware as a generic transformation tool in large scale B2B environments the support for EDIFACT and alike standards is imperative.

EDIFACT contains a standard set of message definitions used for particular business functions such as shipment, warehousing and invoicing. This standard has been around for at least two decades and is expected to be replaced by a suitable XML standard in the future. Support for EDIFACT will allow XAware technology to be used for EDIFACT integration and EDIFACT migration projects where EDIFACT is replaced by an XML standard.

Purpose
This document describes the functionality to be provided and/or developed for EDIFACT support in XAware.

User requirements:
1. XAware must support reading, processing and writing of EDIFACT messages

2. Supported EDIFACT messages and specifics are:

a. Message definitions from the UN/EDIFACT Standard Directories

b. Messages with zero or one Functional Group containing the contents of the message

c. XAware will not support customizing EDIFACT message structures such as adding or removing segments

. Subsets of EDIFACT messages

e. Parts of EDIFACT messages

3. EDIFACT support should be built under (commercial) open source conditions, meaning that it is reusable for all customers and users in the community

4. The Project, project documentation and other artifacts should be made available through the XAware community site and forum. This helps the community awareness of the EDIFACT initiative and reuse of the solution.

5. EDIFACT messages must be readable from multiple channels (file, queue, ws, etc)

6. EDIFACT communication configuration must be done at EDIFACT directory level

7. XAware must support multiple versions of the EDIFACT directory provided by UN/ECE

8. XAware must provide a solution that enables reuse of mappings between various standards

9. A methodology for future integration/migration projects using the EDIFACT solution should be defined. This methodology should address the following requirements:

a. EDIFACT message discovery and exploration at business level

b. Mapping specification at business level

c. Mapping based on metadata (XML Schema Definition (XSD))

d. Reusable mapping components

e. Incremental process

f. Define the proper workflow in XAware designer to support this methodology

g. Select (or built in XAware) a powerful mapping facility (IDE) needed to support business consultants in defining the mapping from EDIFACT to other standards at the customer site

Functional requirements
1. XAware must read EDIFACT message definition from multiple files from the directory (edmd.zip, edsd.zip, eded.zip, edcd.zip, message definition)

2. XAware must implement logic to generate the corresponding EDIFACT XML XSD for a specified EDIFACT message definition.

3. XAware must map all messages to the corresponding ‘EDIFACT XML’ as the Common Information Model (CIM) and vice versa.

4. Reusable XAware mappings at segment level, composite data element and primitive data types

5. Separators for segments (‘’’), composite data elements (‘:’) and data elements (‘+’) should be made configurable. Reason is that the default values can be overridden in the message header.

6. The design of the solution should include a plug point for adding business logic (for validation or transformation)

7. The design of the segment processing logic should address

a. Filter(s) for removing and selecting optional sections

b. Handle qualified data elements and data types (composite data elements & primitive data type conversion)

c. Reuse components that map segments, composite data types and primitive data types (e.g date time mappings).

d. Allow for generation of a skeleton BizDocument that implements the processing logic

8. Performance requirements are not clear at this time. Process messages up till certain size under a second.

9. Scalability requirements are not clear at this time.
Rough estimate: Technology should be able to cope with Millions of messages per day?

Technical Design
This section describes the design, considerations and decisions for implementing the EDIFACT functionality. The approach is to split development into two focus areas: the required XAware technology for working with the EDIFACT directories and the XAware scripts and process for building transformation routines.

XAware technology
1. Parser for reading EDIFACT message types and convert this to corresponding XML Schema Definition (XSD).

2. Instruction for processing messages in EDIFACT format similar to multi format instruction

a. Parsing of the messages using EDIFACT directory (or EDIFACT metadata included in BizComponent at design time)

b. Convert the message to corresponding XML structure that conforms to the generated EDIFACT XSD and deliver that in the response

3. User interface wizard to create an EDIFACT BizComponent based on directory version and message id.

4. Where do we want to place EDIFACT directory in the architecture?

XA script
Building blocks for the segment processing logic are:
1. BizComponent that reads the EDIFACT message and returns the corresponding EDIFACT XML

2. (Generated) BizDocument skeleton that maps EDIFACT XML to the source/target system.

a. Data type conversion logic?

b. Transformation logic?

c. Business logic?

3. XML mapper for handling repeatable groups in the EDIFACT XML

Tags van Technorati: electronic data interchange,eclipse,data mapping tool,EDIFACT

Last update: 26-11-2011

Lees meer!