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

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

Is het MKB klaar voor elektronisch zakendoen?

Het vraagstuk “Waarom komt elektronisch zakendoen / factureren niet van de grond ?” houdt mij al geruime tijd bezig.

Op 28 januari 2009 heeft de Europese Commissie het voorstel - COM(2009) 21 - tot wijziging van de BTW Richtlijn geadopteerd onder voorbehoud dat alle lidstaten de bepalingen aannemen uiterlijk op 31 december 2012. Als één van de eersten heeft Nederland de administratieve verplichtingen en factureringsverplichtingen op het gebied van de omzetbelasting geactualiseerd.

Met name de regels voor elektronisch factureren zijn sterk vereenvoudigd met het Beleidsbesluit van 12 februari 2009, nr. CPP2009/263M, Stcrt. nr. 32

Het uitgangspunt van de vereenvoudigde regels is “equal treatment of paper and electronic invoices” of “gelijke behandeling van papieren en elektronische facturen”. Dit resulteert in twee belangrijke wijzigingen:
- de vormgeving en implementatie van oplossingen voor elektronisch factureren wordt aan marktpartijen overgelaten waardoor de wijze van opmaak en versturen van de elektronische factuur vorm- en middelvrij kan plaatsvinden

- de ondernemer is niet verplicht om de aanvaarding van de elektronische factuur door zijn afnemer vast te leggen in zijn administratie

De vereenvoudiging van deze regels vindt plaats omdat een brede acceptatie en toepassing van elektronisch factureren belangrijk is voor het bedrijfsleven. De versoepelde regels gelden alleen voor belaste prestaties die in Nederland plaatsvinden.

Met het vereenvoudigen van de regels rondom elektronisch factureren verwachtte iedereen dat bedrijven massaal aan de slag zouden gaan. Niets is minder waar, de interesse in elektronisch factureren is weliswaar toegenomen maar grootschalige implementaties blijven achterwege.

Nu de technische en fiscaal / juridische drempels zijn aangepakt heeft bij het bedrijfsleven onduidelijkheid en onzekerheid toegeslagen.

Het blijft gissen maar een aantal redenen waarom e-Zakendoen niet van de grond komt zijn:

- de belangen van marktpartijen en de Overheid
Alle aandacht van de Overheid gaat uit naar Elektronisch Factureren richting de Overheid, natuurlijk omdat aan de ontvangende kant de meeste besparingen te realiseren zijn. De Overheid zou zich moeten richten op Elektronisch Bestellen en Factureren zodat alle deelnemers kunnen genieten van de voordelen.

- de Standaarden - UBL en UN/CEFACT - en Open Source gereedschappen
De standaarden - OASIS UBL en UN/CEFACT - zijn gratis beschikbaar en in de Open Source wereld zijn voldoende gereedschappen aanwezig om een B2B platform te realiseren.

Zie: Transformatie van een UBL Invoice naar een OAGI Invoice met ChainBuilder ESB IDE

De Overheid heeft gekozen voor UBL , de OASIS Universal Business Language. Daar is de Overheid besluitvaardig te werk gegaan en zal het niet aan liggen wordt geroepen. Echter het is noodzakelijk dat Nederland tot duidelijke afspraken komt over de gegevens die wel of niet moeten worden meegegeven in een bericht en de bijbehorende processen. Dan kan men daarop de structuur (semantiek en syntax) van het bericht afstemmen en een subset definiëren die door iedereen gebruikt moet / kan worden.

Dat niet volstaan kan worden met slechts het selecteren van een berichtstandaard toont de pilot Elektronisch Bestellen en Factureren voor Inhuur van personeel van de Belastingdienst aan. De Belastingdienst koos voor de berichtstandaard HR-XML SIDES, de SETU (Stichting Elektronische Transacties Uitzendbranche) standaard. Samen met de Belastingdienst hebben de deelnemers aan de pilot hard moeten werken om tot afstemming van de processen en afronding van de berichtspecificaties te komen. Dit heeft uiteindelijk op 20 mei 2009 geresulteerd in opname van de standaard op de lijst met open standaarden van de Overheid.

De Overheid had er goed aan gedaan om tijdens het Congres e-Factureren voor het MKB de beschrijving van de Nederlandse UBL - Factuur te presenteren. Het opstellen van deze beschrijving is op zich niet meer zo moeilijk als men weet dat om ons heen genoeg voorbeelden en specificaties beschikbaar zijn (NESUBL, UBL die door de Belastingdienst wordt gebruikt, ...).

Zie ook mijn bloart: Transformatiedefinities voor de elektronische factuur

- de overvloed aan aanbieders en de verscheidenheid aan benaderingen:
De voornaamste reden waarom e-Zakendoen niet van de grond komt in Nederland zou te wijten kunnen zijn aan het grote aantal aanbieders van en de verscheidenheid aan oplossingen die worden aangeboden.

Daarnaast is de beïnvloeding van de markt door de verschillende marktpartijen de laatste jaren sterk toegenomen.

De Overheid stimuleert dit verschijnsel door voor beantwoording van complexe vragen over e-Factureren (technisch, functioneel of juridisch/fiscaal) het bedrijfsleven door te verwijzen naar Billing Service Providers. De vraag rijst meteen hoe het dan met objectiviteit van deze providers is gesteld en of bedrijven de juiste antwoorden krijgen in het licht van hun situatie.

- onduidelijkheid over het fiscaal toezicht (Horizontal Monitoring) van de belastingdienst
De Belastingdienst richt zich de komende jaren op Horizontaal Toezicht en laat het aan de bedrijven over om aantoonbaar te maken dat zij het proces van e-Factureren onder controle hebben. Het is voor bedrijven moeilijk om precies in te schatten wat dan van hen verwacht wordt en waar ze moeten aan voldoen.

Het is verstandig te streven naar een situatie waarbij de Belastingdienst de controle op transacties in eigen hand neemt zonder bedrijven hiermee lastig te vallen. Naast Horizontaal Toezicht dus controle op de achtergrond van Taxable transacties, zelfs over de landsgrenzen heen. Op Europees niveau zien we soortgelijke initiatieven om Tax fraude tegen te gaan.

Wel moeten dan een aantal randvoorwaarden worden ingevuld. Zo moet(en) de Belastingdienst(en) toegang krijgen tot de transacties die hebben plaatsgevonden bij bedrijven.

Met de ontwikkelingen op het gebied van XAF , SBR en SAF-T is in elk geval de basis gelegd waarmee deze informatie ter beschikking gesteld kan worden. De Belastingdienst zal duidelijke keuzes moeten maken voor de toekomst.

- volwassenheid bedrijven en flexibiliteit oplossingen
Het feit dat niet alle bedrijven volwassen genoeg zijn om nu in e-factureren te stappen is een belangrijke factor om rekening mee te houden. Deze bedrijven moeten over de streep gehaald moeten worden. Dit kan door het aanbieden van alternatieve voorzieningen zoals dat ook in Denemarken gebeurt: scan-straten, ... maar eveneens intelligente document-formaten zoals Adobe XDP en ODF kunnen daarbij helpen.

Dit zijn voorzieningen die het voor deze bedrijven mogelijk maken om in beperkte mate te participeren.

Samenvattend zijn een aantal initiatieven nodig die het voor de Belastingdienst mogelijk maken om transacties beter te controleren en fraude te identificeren ALSOOK het voor alle bedrijven mogelijk maken deel te nemen aan elektronisch factureren. Zie: The new approach for bringing adoption of e-Invoicing by SMEs to the next level ! voor een aantal mogelijke benaderingen.

- een openbare informatiesnelweg met digitale handtekeningen van de Overheid
Het voorstel om via de Kamer van Koophandel digitale handtekeningen te verstrekken is in een aantal landen op een vergelijkbare wijze gerealiseerd:
- in Mexico kunnen bedrijven naar de overheidsbalie stappen en aangeven dat ze elektronisch willen gaan factureren. Binnen een aantal minuten hebben ze een certificaat en kunnen ze starten op het overheidsnetwerk.

- in Denemarken kunnen alle partijen gebruik maken van de Deense SOA Infrastructuur, een platform dat nu in Europa als basis is genomen voor de ontwikkeling van de PEPPOL infrastructuur (Pan European Public Procurement OnLine).

Hoe staat het met de belangen van bedrijven?
Wat mij betreft zouden bedrijven zich moeten verenigen in een platform dat zorg gaat dragen voor hun belangen. Er is behoefte aan een platform en discussieforum waarin alle bedrijven vrijwillig en gratis kunnen deelnemen, dat het beste voor heeft met e-Zakendoen in Nederland en waar bedrijven terecht kunnen voor beantwoording van hun vragen.

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

Last update: 25-11-2015

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

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

Transformatiedefinities voor de elektronische factuur

Het opstellen van transformatieregels voor de transformatie van berichten tussen verschillende standaarden mag niet worden onderschat. Het vereist grondige kennis van berichtstandaarden en van de betekenis van gegevens binnen een bedrijfsdomein. De Core Components Technical Specification (CCTS) en de Universal Data Element Framework (UDEF) streven naar een semantisch referentiekader voor de realisatie van informatieinteroperabiliteit. Wanneer beide concepten algemeen geaccepteerd en doorgevoerd worden dan zal transformatie veel eenvoudiger worden.

De Core Components Technical Specification kent aan elke Business Information Entity een unieke identificatie en Dictionary Entry Name (DEN) toe, net als de Universal Data Element Framework. Voorbeeld: De Invoice Issuer, de persoon of organisatie die de factuur uitgeeft, heeft als CCTS Unique ID de waarde UN01001476 en als DEN Invoice Issuer_ Party. Primary_ Identification. Identifier gekregen. De Universal Data Element Framework UDEF ID die daarmee overeenkomt is y.3_2.35.8 en de UDEF Name is Supplier.Enterprise_Purchaser.Assigned.Identifier.

Voor het verkrijgen van een beter beeld van de complexiteit van het transformeren van berichten en ter voorbereiding van het gebruik van transformatiegereedschappen ga ik de transformatieregels van de factuur uitwerken.

Het factuurproces richt zich op de uitwisseling van de factuur tussen leverancier en klanten voor geleverde goederen of diensten. Ter vereenvoudiging van het proces worden andere deelnemers buiten beschouwing gelaten. Zowel de klant als de leverancier kan in het proces meerdere rollen vervullen. Zo kan de klant acteren als klant (customer), besteller (buyer), ontvanger (consignee), invoicee en payer (betaler). De leverancier als leverancier (supplier), verkoper (seller), afzender (consignor), invoice issuer en payee.

Er zijn twee soorten factuurprocessen:
- de traditionele of door de leverancier geïnitieerde factuur waarbij de factuur door de leverancier wordt gegenereerd naar de klant

- de self-billing invoicing waarbij de factuur door de klant wordt gegenereerd naar de leverancier

Ik ga de mappingdefinitie uitwerken voor de traditionele factuur voor volgende internationale berichtstandaarden.

- Universal Business Language (UBL) Release 2.0
- Open Applications Group (OAGIS) Release 9.1
- UN/CEFACT Cross Industry Invoice (CII) Release 1.0
- EDIFACT Release 0.7B
- SAP IDOC Invoice02

Voor de berichtdefinitie ga ik uit van de UN/CEFACT Cross Industry Invoice (CII) specificatie die is opgesteld door de UN/CEFACT in samenwerking met verschillende industriesectoren.

Verder heb ik de UDEF ID en Name evenals de CCTS Unique ID en Name toegekend aan de elementen.
- UDEF ID
- UDEF Name
- CCTS ID

Invoice Number
Description = The unique number assigned by the issuer to identify an invoice.

CII = Billing_ Document. Issuer Assigned_ Identification. Identifier

UBL NAME = ID
UBL DEN = Invoice. Identifier
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentID.ID

EDIFACT =
- BGM.C106.1004

IDOC =
- E2EDK02.E1EDK02.QUALF [Qualifier: 009 Invoice Number]
- E2EDK02.E1EDK02.BELNR

UDEF ID = bd.2_17.35.8 (proposed)
UDEF Name = Invoice.Document_Creditor.Assigned.Identifier (proposed)

CCTS ID = UN01001356

Copy Indicator
Description = The indicator that identifies whether or not the invoice is a copy of the original invoice.

CII = Billing_ Document. Copy. Indicator

UBL NAME = CopyIndicator
UBL DEN = Invoice. Copy_ Indicator. Indicator
Svefaktura = not included

OAGIS = ?

EDIFACT =
- BGM.1225 [Code: 9 Original]

IDOC = not available

UDEF ID = bd.2_49.7 (proposed)
UDEF NAME = Invoice.Document_Copy.Indicator (proposed)

CCTS ID = UN01001359

Invoice Global Unique Identifier
Description = The Global Unique Identifier (GUID) of the invoice.

CII = ?

UBL NAME = UUID
UBL DEN = Invoice. UUID. Identifier
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = ?

Invoice Issue Date
Description = The date when the invoice was issued.

CII = Billing_ Document. Issue. Date Time

UBL NAME = IssueDate
UBL DEN = Invoice. Issue Date. Date
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentDateTime

EDIFACT =
- DTM.C507.2005 [Qualifier: 3 Invoice Document Issue Date Time]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 016 Invoice Date]
- E2EDK03.E1EDK03.DATUM

UDEF ID = bd.2_9.6
UDEF Name = Invoice.Document_Issued.Date

CCTS ID = UN01001357

Invoice Type Code
Description = The code specifying the invoice type (e.g. invoice, debit note, credit note).

CII = Billing_ Document. Type. Code

UBL NAME = InvoiceTypeCode
UBL DEN = Invoice. Invoice Type Code. Code
Svefaktura = likewise

OAGIS = ?

EDIFACT =
- BGM.C002.1001 [Code: 380 Commercial Invoice]

IDOC =
- E2EDK01005.E1EDK01.BSART [Value: INVO = debit, CRME = credit]

UDEF ID = bd.2_33.4
UDEF NAME = Invoice.Document_Type.Code

CCTS ID = UN01001358

Note
Description = Free-form text applying to the Invoice not contained in another structure.

CII = ?

UBL NAME = Note
UBL DEN = Invoice. Note. Text
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

Tax Point Date
Description = The date of the Invoice, used to indicate the point at which tax becomes applicable.

CII = ?

UBL NAME = TaxPointDate
UBL DEN = Invoice. Tax Point Date. Date
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

[Remarks = Validate whether this remains valid with the new proposed VAT directives !]

Invoice Language
Description = The code specifying the language of the free text of the invoice.

CII = Billing_ Document. Language. Identifier

UBL NAME = not included
UBL DEN = not included
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = UN01001360

Invoicing Currency
Description = The code identifier of the monetary unit used for amounts.

CII = Billing_ Document. Billing_ Currency. Code

UBL NAME = InvoiceCurrency
UBL DEN = Invoice. Document_ Currency Code. Code
Svefaktura = Invoice. Invoice Currency. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 4 Invoicing Currency]

IDOC =
- E2EDK01005.E1EDK01.CURCY

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001361

Price Currency
Description = The code identifier of the monetary unit used for the price.
CII = Billing_ Document. Price_ Currency. Code

UBL = Invoice. Pricing_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 10 Pricing Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001362

Payment Currency
Description = The code identifier of the monetary unit used for the payment of the invoice.
CII = Billing_ Document. Payment_ Currency. Code

UBL = Invoice. Payment_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 3 Target Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 11 Payment Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001363

Alternative Payment Currency
Description = The code identifier of the monetary unit used as an alternate currency for the payment of the invoice.
CII = Billing_ Document. Alternative Payment_ Currency. Code

UBL = Invoice. Payment Alternative_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT = not available

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001364

Number of Invoice Lines
Description = The number of invoice lines.
CII = Billing_ Document. Line Count. Numeric

UBL = Invoice. Line Count. Numeric

OAGIS = not available

EDIFACT =
- GRP51.CNT.C270.6069 [Qualifier: 2 Number of lines]
- GRP51.CNT.C270.6066

IDOC =
- E2EDS01.E1EDS01.SUMID [Qualifier: 001 Number of items]
- E2EDS01.E1EDS01.SUMME

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001365

Total Invoice Additional Charge Amount
Description = The sum of all charges at the invoice header level before tax or fee.
CII =

UBL =

OAGIS =

EDIFACT =

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID =

Total Invoice Line Amount
Description = The sum of all invoice lines amounts, including all allowances and charges related to the invoice line before tax or fee.
CII = Billing_ Monetary Summation. Line Total. Amount

UBL = Invoice. Legal_ Monetary Monetary Total. Line Extension Amount. Amount

OAGIS = Invoice. InvoiceHeader. ExtendedAmount

EDIFACT =
- GRP52.MOA.C516.5025 [Qualifier: 340 Original Total Net Invoice Value]
- GRP52.MOA.C516.5004

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001367

Invoicing Period Start Date
Description = The date, time, date time or other date time value for the start of this billing period.
CII = Billing_ Period. Start. Date Time

UBL =
* Invoice. Invoice_ Period. Start Date. Date
* Invoice. Invoice_ Period. Start Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 194 Start Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 019 Start of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* bd.2_18.6
* bd.2_1.15

UDEF NAME =
* Invoice.Document_Start.Date
* Invoice.Document_Start.Time

CCTS ID = UN01001386

Invoicing Period End Date
Description = The date, time, date time or other date time value for the end of this billing period.

CII = Billing_ Period. End. Date Time

UBL =
* Invoice. Invoice_ Period. End Date. Date
* Invoice. Invoice_ Period. End Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 206 End Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 020 End of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* to be determined
* bd.2_2.15

UDEF NAME =
* to be determined
* Invoice.Document_End.Time

CCTS ID = UN01001387

Invoice Issuer Identification Code
Description = The invoice issuer is the person or organization making the invoice, claiming payment for the goods or services rendered.

CII = Invoice Issuer_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Customer Assigned_ Account Identifier. Identifier

OAGIS = Invoice. InvoiceHeader.SupplierParty.PartyIDs.ID
<em>[Remark: OAGIS InvoicerParty is a better match but not provided]</em>

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID = y.3_2.35.8
UDEF NAME = Supplier.Enterprise_Purchaser.Assigned.Identifier

CCTS ID = UN01001476

Invoice Issuer Name
Description = The name, expressed as text, for this invoice issuer party.

CII = Invoice Issuer_ Party. Name. Text

UBL = Invoice. Accounting_ Supplier Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID = UN01001479

Invoice Issuer VAT ID
Description = vat-nbr / registrationnbr selling company

CII = Invoice Issuer_ Party. Tax_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Party Tax Scheme. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference Qualifier: VA VAT Registration Number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDK01005.E1EDK01.EIGENUINR

UDEF ID =
UDEF NAME =

CCTS ID = UN01001478

Chamber of Commerce Number
Description = Identifies a company as registered with the company registration scheme.

CII =

UBL = Invoice. Accounting_ Supplier Party. Party Legal Entity. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference CodeQualifier AHO Chamber of Commerce registration number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME4

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Identification Code
Description = The primary identifier of this invoicee party.

CII = Invoicee_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Customer Party. Customer Assigned_ Account Identifier. Identifier

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Name
Description = An association to Party Name.

CII = Invoicee_ Party. Name. Text

UBL = Invoice. Accounting_ Customer Party. Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID =

Tags: CCTS, EDIFACT, electronic data interchange, HR-XML, UBL, UDEF

[Last update: 26-11-2011]

Transformation definitions for the electronic invoice

Defining transformation rules for the transformation of messages between different international standards should not be underestimated. It is a difficult task that requires extensive knowledge of these message standards and the data within the Business domain.

The Core Components Technical Specification (CCTS) and the Universal Data Element Framework (UDEF) define a semantic reference framework, principles and standards, for achieving information interoperability. Whenever both concepts are commonly accepted and implemented then transformation will become a lot easier.

The Core Components Technical Specification assigns each Business Information Entity a unique identifier and Dictionary Entry Name (DEN), similar to the Universal Data Element Framework. Example: The Invoice Issuer, the person or organization making and issuing the invoice, gets the CCTS Unique ID UN01001476 and DEN Invoice Issuer_ Party. Primary_ Identification.Identifier. The Universal Data Element Framework UDEF ID that corresponds is y.3_2.35.8 and the UDEF Name is Supplier.Enterprise_Purchaser.Assigned.Identifier.

For a better understanding of the complexity involved in the transformation of messages and in preparation of the usage of transformation tools I am going to work out the transformation rules for the invoice.

The invoicing process is used to exchange an invoice between a supplier and customer for the supply of goods or services. To simplify the process only the supplier and customer parties are taken into account. Each of the parties can have more than one role. The customer can act as the customer or ordering company, buyer, consignee, invoicee and payer. The supplier covers the roles of supplier or sales company, seller, consignor, invoice issuer and payee.

There are two variants of invoicing:
- the traditional or supplier initiated invoice, where the supplier generates and issues the invoice to the customer

- the self-billing invoicing, where the customer generates and issues the invoice to the supplier

I am going to work out the transformation rules for the traditional invoice from and to the following international standards.

- Universal Business Language (UBL) Release 2.0
- Open Applications Group (OAGIS) Release 9.1
- UN/CEFACT Cross Industry Invoice (CII) Release 1.0
- EDIFACT Release 0.7B
- SAP IDOC Invoice02

I will use the UN/CEFACT Cross Industry Invoice (CII) specification, defined by the UN/CEFACT organization together with participants from different industry sectors, as the starting point.

Besides that I have assigned the UDEF ID and Name, likewise for the CCTS Unique ID and Name.

- UDEF ID
- UDEF Name
- CCTS ID

Invoice Number
Description = The unique number assigned by the issuer to identify an invoice.

CII = Billing_ Document. Issuer Assigned_ Identification. Identifier

UBL NAME = ID
UBL DEN = Invoice. Identifier
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentID.ID

EDIFACT =
- BGM.C106.1004

IDOC =
- E2EDK02.E1EDK02.QUALF [Qualifier: 009 Invoice Number]
- E2EDK02.E1EDK02.BELNR

UDEF ID = bd.2_17.35.8 (proposed)
UDEF Name = Invoice.Document_Creditor.Assigned.Identifier (proposed)

CCTS ID = UN01001356

Copy Indicator
Description = The indicator that identifies whether or not the invoice is a copy of the original invoice.

CII = Billing_ Document. Copy. Indicator

UBL NAME = CopyIndicator
UBL DEN = Invoice. Copy_ Indicator. Indicator
Svefaktura = not included

OAGIS = ?

EDIFACT =
- BGM.1225 [Code: 9 Original]

IDOC = not available

UDEF ID = bd.2_49.7 (proposed)
UDEF NAME = Invoice.Document_Copy.Indicator (proposed)

CCTS ID = UN01001359

Invoice Global Unique Identifier
Description = The Global Unique Identifier (GUID) of the invoice.

CII = ?

UBL NAME = UUID
UBL DEN = Invoice. UUID. Identifier
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = ?

Invoice Issue Date
Description = The date when the invoice was issued.

CII = Billing_ Document. Issue. Date Time

UBL NAME = IssueDate
UBL DEN = Invoice. Issue Date. Date
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentDateTime

EDIFACT =
- DTM.C507.2005 [Qualifier: 3 Invoice Document Issue Date Time]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 016 Invoice Date]
- E2EDK03.E1EDK03.DATUM

UDEF ID = bd.2_9.6
UDEF Name = Invoice.Document_Issued.Date

CCTS ID = UN01001357

Invoice Type Code
Description = The code specifying the invoice type (e.g. invoice, debit note, credit note).

CII = Billing_ Document. Type. Code

UBL NAME = InvoiceTypeCode
UBL DEN = Invoice. Invoice Type Code. Code
Svefaktura = likewise

OAGIS = ?

EDIFACT =
- BGM.C002.1001 [Code: 380 Commercial Invoice]

IDOC =
- E2EDK01005.E1EDK01.BSART [Value: INVO = debit, CRME = credit]

UDEF ID = bd.2_33.4
UDEF NAME = Invoice.Document_Type.Code

CCTS ID = UN01001358

Note
Description = Free-form text applying to the Invoice not contained in another structure.

CII = ?

UBL NAME = Note
UBL DEN = Invoice. Note. Text
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

Tax Point Date
Description = The date of the Invoice, used to indicate the point at which tax becomes applicable.

CII = ?

UBL NAME = TaxPointDate
UBL DEN = Invoice. Tax Point Date. Date
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

[Remarks = Validate whether this remains valid with the new proposed VAT directives !]

Invoice Language
Description = The code specifying the language of the free text of the invoice.

CII = Billing_ Document. Language. Identifier

UBL NAME = not included
UBL DEN = not included
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = UN01001360

Invoicing Currency
Description = The code identifier of the monetary unit used for amounts.

CII = Billing_ Document. Billing_ Currency. Code

UBL NAME = InvoiceCurrency
UBL DEN = Invoice. Document_ Currency Code. Code
Svefaktura = Invoice. Invoice Currency. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 4 Invoicing Currency]

IDOC =
- E2EDK01005.E1EDK01.CURCY

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001361

Price Currency
Description = The code identifier of the monetary unit used for the price.
CII = Billing_ Document. Price_ Currency. Code

UBL = Invoice. Pricing_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 10 Pricing Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001362

Payment Currency
Description = The code identifier of the monetary unit used for the payment of the invoice.
CII = Billing_ Document. Payment_ Currency. Code

UBL = Invoice. Payment_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 3 Target Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 11 Payment Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001363

Alternative Payment Currency
Description = The code identifier of the monetary unit used as an alternate currency for the payment of the invoice.
CII = Billing_ Document. Alternative Payment_ Currency. Code

UBL = Invoice. Payment Alternative_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT = not available

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001364

Number of Invoice Lines
Description = The number of invoice lines.
CII = Billing_ Document. Line Count. Numeric

UBL = Invoice. Line Count. Numeric

OAGIS = not available

EDIFACT =
- GRP51.CNT.C270.6069 [Qualifier: 2 Number of lines]
- GRP51.CNT.C270.6066

IDOC =
- E2EDS01.E1EDS01.SUMID [Qualifier: 001 Number of items]
- E2EDS01.E1EDS01.SUMME

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001365

Total Invoice Additional Charge Amount
Description = The sum of all charges at the invoice header level before tax or fee.
CII =

UBL =

OAGIS =

EDIFACT =

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID =

Total Invoice Line Amount
Description = The sum of all invoice lines amounts, including all allowances and charges related to the invoice line before tax or fee.
CII = Billing_ Monetary Summation. Line Total. Amount

UBL = Invoice. Legal_ Monetary Monetary Total. Line Extension Amount. Amount

OAGIS = Invoice. InvoiceHeader. ExtendedAmount

EDIFACT =
- GRP52.MOA.C516.5025 [Qualifier: 340 Original Total Net Invoice Value]
- GRP52.MOA.C516.5004

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001367

Invoicing Period Start Date
Description = The date, time, date time or other date time value for the start of this billing period.
CII = Billing_ Period. Start. Date Time

UBL =
* Invoice. Invoice_ Period. Start Date. Date
* Invoice. Invoice_ Period. Start Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 194 Start Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 019 Start of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* bd.2_18.6
* bd.2_1.15

UDEF NAME =
* Invoice.Document_Start.Date
* Invoice.Document_Start.Time

CCTS ID = UN01001386

Invoicing Period End Date
Description = The date, time, date time or other date time value for the end of this billing period.

CII = Billing_ Period. End. Date Time

UBL =
* Invoice. Invoice_ Period. End Date. Date
* Invoice. Invoice_ Period. End Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 206 End Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 020 End of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* to be determined
* bd.2_2.15

UDEF NAME =
* to be determined
* Invoice.Document_End.Time

CCTS ID = UN01001387

Invoice Issuer Identification Code
Description = The invoice issuer is the person or organization making the invoice, claiming payment for the goods or services rendered.

CII = Invoice Issuer_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Customer Assigned_ Account Identifier. Identifier

OAGIS = Invoice. InvoiceHeader.SupplierParty.PartyIDs.ID
<em>[Remark: OAGIS InvoicerParty is a better match but not provided]</em>

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID = y.3_2.35.8
UDEF NAME = Supplier.Enterprise_Purchaser.Assigned.Identifier

CCTS ID = UN01001476

Invoice Issuer Name
Description = The name, expressed as text, for this invoice issuer party.

CII = Invoice Issuer_ Party. Name. Text

UBL = Invoice. Accounting_ Supplier Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID = UN01001479

Invoice Issuer VAT ID
Description = vat-nbr / registrationnbr selling company

CII = Invoice Issuer_ Party. Tax_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Party Tax Scheme. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference Qualifier: VA VAT Registration Number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDK01005.E1EDK01.EIGENUINR

UDEF ID =
UDEF NAME =

CCTS ID = UN01001478

Chamber of Commerce Number
Description = Identifies a company as registered with the company registration scheme.

CII =

UBL = Invoice. Accounting_ Supplier Party. Party Legal Entity. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference CodeQualifier AHO Chamber of Commerce registration number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME4

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Identification Code
Description = The primary identifier of this invoicee party.

CII = Invoicee_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Customer Party. Customer Assigned_ Account Identifier. Identifier

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Name
Description = An association to Party Name.

CII = Invoicee_ Party. Name. Text

UBL = Invoice. Accounting_ Customer Party. Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID =

Tags: CCTS, EDIFACT, electronic data interchange, HR-XML, UBL, UDEF

[Last update: 26-11-2011]

Installatie van de ChainBuilder Enterprise Service Bus

ChainBuilder is een Open Source Enterprise Service Bus ontwikkeld door het bedrijf Bostech Corporation. De ChainBuilder ESB bestaat uit een runtime- en ontwikkelomgeving met een grafisch configuratie en ontwerp gereedschap voor Eclipse. De software is vrij beschikbaar onder de Open Source General Public License (GPL) maar eveneens te verkrijgen met een Commerciële licentie.

De ChainBuilder ESB is een Java Business Integration (JBI) compliant oplossing voor gebruik in Service Oriented Architecture (SOA) omgevingen. De oplossing is ontwikkeld voor het realiseren van betrouwbare en snelle Java Business Integratie implementaties en biedt naast XML-functionaliteit de mogelijkheid voor het werken met legacy (non-xml) gegevensformaten.

De ChainBuilider ESB oplossing bestaat uit een verzameling van gereedschappen en componenten gebaseerd op de Java Business Integration (JBI) specificatie. De ChainBuilder ESB kan samenwerken met alle bestaande JBI compatibele containers en componenten. De eerste versie van de ChainBuilder ESB wordt geleverd met Apache ServiceMix 3.0.

De Java Business Integration Specification (JSR 208) is ontwikkeld onder toezicht van de Java Community Process (JCP). De JBI specificatie beschrijft een service-georiënteerde integratiebus en componentenarchitectuur voor SOA. De JBI specificatie definieert een standaard container met een pluggable architectuur waarop andere componenten (service engines en bindings) aangesloten kunnen worden. Hierdoor is het mogelijk om een uitbreidbare verzameling van onderling verbonden en samenwerkende software componenten samen te stellen. Deze software componenten kunnen op zichzelf weer containers zijn zoals een EJB container.

De JBI specificatie legt vast hoe componenten binnen de JBI container moeten samenwerken en volgt daarin een service-georiënteerde benadering.

Enkele op JBI gebaseerde ESB oplossingen zijn ondermeer:
- Open Enterprise Service Bus (OpenESB)

- Apache ServiceMix

- JBossESB

- Oracle Fusion Middleware

EN de Bostech ChainBuilder ESB. Bostech Corporation is eveneens Community Partner van de Open Source OpenESB oplossing maar biedt daarnaast een compleet Enterprise Integration Platform met EDI / B2B en EAI functies.

De twee belangrijkste features van de ChainBuilder ESB zijn:
- een verzameling grafische gebruikersinterfaces voor het het creëren en onderhouden van JBI artefacts. De voornaamste interfaces zijn de Flow Editor, Message Format Editor en Message Map Editor

- een verzameling JBI componenten en bibliotheken met waardevolle functies voor het realiseren van implementaties waaronder ondersteuning van legacy berichtformaten (X12, CSV), een mapping component, foutafhandeling en de mogelijkheid om scripts te koppelen aan elke component/element.

De ChainBuilder ESB file binding component maakt het werken met non-XML berichten (X12, CSV, fixed en variabele formaten) mogelijk en voorziet in archiveringsfuncties voor het opslaan van berichten wanneer deze zijn verwerkt.

Downloaden van de ChainBuilder IDE + Server
Ga naar de website www.chainforge.net en klik op de link Downloads > Download Now.

Klik nu onderaan onder de kolom Windows Release op de link voor het downloaden van het installatieprogramma voor de IDE + Server.

Installatie van ChainBuilder
Het installatieprogramma komt als een zip-bestand en is ongeveer 305 MB groot. Download het bestand naar een folder op uw harde schijf en pak het daarna uit.

Dubbelklik dan op het installatieprogramma om de installatie van ChainBuilder te starten. Na installatie kunt u de Eclipse ChainBuilder IDE opstarten via Start > Al uw programma’s > ChainBuilder ESB > ChainBuilder ESB IDE.

Wanneer de ChainBuilder ESB IDE is opgestart ga naar het menu Window > Preferences en open de node Java > Compiler. In het compiler scherm stel de waarde van het veld Compiler compliance level in op 6.0 (voor Java 1.6).

Tijdens installatie van Chainbuilder worden volgende omgevingsvariabelen aangemaakt:

Systeem Variabelen:
ANT_HOME = C:\ProgramFiles\cbesb-1.2\apache-ant
CBESB_CLASSPATH = C:\ProgramFiles\cbesb-1.2\config\errordb
CBESB_HOME = C:\ProgramFiles\cbesb-1.2
SERVICEMIX_HOME = C:\ProgramFiles\cbesb-1.2\apache-servicemix

Aan de Path-variabele worden de volgende paden toegevoegd:
C:\ProgramFiles\cbesb-1.2\bin;
C:\ProgramFiles\cbesb-1.2\apache-servicemix\bin;
C:\ProgramFiles\cbesb-1.2\apache-ant\bin;

Gebruikersvariabelen
ANT_HOME = C:\ProgramFiles\cbesb-1.2\apache-ant

Een ChainBuilder ESB project kan meerdere JBI Service Assembly projecten herbergen. Deze Assembly projecten kunnen refereren naar de definitiebestanden in het ESB project waaronder:
- Message Formats
- X12 Formats
- Schema en Transformation definitie bestanden

De structuur van een ESB project bestaat uit de volgende folders:
- bin
- build
- lib
- dist
- src

De structuur van een Service Assembly project bestaat uit de volgende folders:
- bin
- build
- lib
- dist
- src

In de folder src\formats worden de MDL (Message Definition Language) bestanden en XSD schema’s worden opgeslagen.

Om een beeld te krijgen van hoe deze projecten eruit zien kunt u achtereenvolgens een ESB project en een JBI SA project aanmaken via de onderstaande stappen.

Aanmaken van een ESB Project
- Klik met uw rechtermuisknop in de Package Explorer en selecteer de menuoptie New > Other.

- Open de node ChainBuilder ESB-IDE en ChainBuilder ESB Project

- Selecteer de optie New ChainBuilder ESB Project en klik op de knop Next

- Geef uw project de naam ESB en klik op de knop Next om verder te gaan

- Klik op de knop Finish

Aanmaken van een JBI Service Assembly Project
- Klik met uw rechtermuisknop in de Package Explorer en selecteer de menuoptie New > Other.

- Open de node ChainBuilder ESB-IDE en ChainBuilder ESB Project

- Selecteer de optie New JBI Service Assembly Project en klik op de knop Next

- Geef uw project de naam SA en klik op de knop Next

- Klik op de knop Next en vink in het dialoogscherm Setup Reference Relationship with Other project uw ESB Project aan

- Klik op de knop Finish

Na creatie van het ESB en SA project ziet uw scherm er als volgt uit:

Voor meer informatie over het gebruik van de ChainBuilder ESB blijf deze weblog volgen. Ik vertel u binnenkort hoe u de ChainBuilder ESB kunt gebruiken voor transformatie van een HR-XML Invoice-bericht naar een UBL Invoice-bericht.

Tags: electronic data interchange, HR-XML, Enterprise Service Bus, open source

Last update: 26-11-2011

Implementatie van de HR-XML standaard in Nederland

Het HR-XML Consortium is een onafhankelijke, leveranciersneutrale organisatie zonder winstoogmerk met als doel het stimuleren en ontwikkelen van elektronische gegevensuitwisseling in het domein van Human Resource Management.

Het Consortium heeft de open communicatiestandaard HR-XML ontwikkeld voor gegevensuitwisseling rondom selectie van personeel, beloning, opleiding en management van personeel. Deze standaard is gebaseerd op de eXtensible Markup Language (XML), de universele taal voor het structureren van data en documenten en licentievrij ter beschikking gesteld door het World Wide Web Consortium (W3C). XML is eigenlijk een formaat waarbij de inhoud van het bestand ook gelijk wordt beschreven, zodat de interpretatie van de aangeboden gegevens veel gemakkelijker verloopt.

Voor leveranciers van oplossingen en diensten, die gebruik maken van de HR-XML open standaarden, heeft het HR-XML Consortium een certificatieprogramma ontwikkeld. Na succesvolle afronding van de certificering mogen deze bedrijven gedurende een periode van twee jaar het HR-XML logo hanteren en worden ze opgenomen in de lijst van gecertificeerde bedrijven en oplossingen. Hierbij moet ik wel opmerken dat het aantal gecertificeerde bedrijven en oplossingen op de website HRcertify.org momenteel minimaal is. Veel bedrijven zien kennelijk toch op tegen de hoge kosten verbonden aan de certificering.

Het HR-XML Consortium stelt eveneens een web-gebaseerde testomgeving, de HR-XML testbed, ter beschikking. Organisaties kunnen via deze web-omgeving volledig zelfstandig instanties van hun HR-XML berichten valideren tegen de beschikbare HR-XML specificaties.

Er worden twee methoden aangeboden voor het valideren van een HR-XML bericht:
- een web-formulier voor het invoeren van de inhoud van een HR-XML bericht
- een op SOAP-gebaseerde web-service die aangeroepen kan worden

Samenwerking met de Open Applications Group

De Open Applications Group en het HR-XML Consortium hebben op 13 Maart 2007 aangekondigd te gaan samenwerken. De Open Applications Group Integration Specification (OAGIS) dekt een uitgebreide verzameling van bedrijfsfuncties af waaronder inkoop, supply-chain (keten) management, productie en verkoop. Het voornaamste doel van het samenwerkingsproject is het in lijn brengen van de architecturen van beide standaarden.

Daarnaast zal gestreefd worden naar:
- het beschikbaar maken van de Open Applications Group’s Business Object Document (BODs) voor de ontwikkeling van HR-XML berichten

- het integreren van de OAGIS implementatie van de UN/CEFACT Core Components, een verzameling semantische bouwstenen die generieke data types van bedrijfsgegevens vertegenwoordigen

- het hergebruiken van belangrijke elementen uit elkaars bibliotheken

Het HR-XML Consortium heeft vooruitlopend op de formele samenwerking de OAGIS benadering geadopteerd en verwerkt in de HR-XML 3.0 draft.

HR-XML SIDES voor de Nederlandse Uitzendorganisaties

In Nederland zijn de uitzendorganisaties verenigd in de Algemene Bond Uitzendondernemingen (ABU). Door invoering van een volledig transparant elektronisch berichtenverkeer wordt het arbeidsintensieve verwerkingsproces van transacties tussen inleners en uitleners enorm beperkt. Jaarlijks worden 25 tot 40 miljoen urenbriefjes opgesteld, door het inhurende bedrijf goedgekeurd, door intercedenten van de uitleners op maandag verwerkt en in week-facturen omgezet. Lagere kosten en verhoging van de concurrentiekracht van de B.V. Nederland is het voornaamste streven van de invoering van HR-XML SIDES. De Staffing Industry Data Exchange Standard (SIDES) richt zich specifiek op het inhuren van personeel met name het proces van offreren, selectie van de uitzendkracht, tijdsregistratie en facturering.

In april 2004 werd de projectgroep PleinU (Platform elektronische inhuur uitzendkrachten) opgericht met als doel het stimuleren van de invoering van elektronisch berichtenverkeer tussen inleners en uitzendorganisaties op basis van internationale open XML standaarden. PleinU was een ‘plaats van samenkomst’ waar verschillende partijen samenkwamen om te werken aan verbeteringen van de standaard.

Inmiddels is (juli 2007) PleinU opgegaan in de Stichting Elektronische Transacties in de Uitzendbranche (SETU). Na de projectmatige start binnen PleinU krijgt de ontwikkeling van HR-XML SIDES een door de uitzendbranche gedragen en permanent karakter. De SETU staat in principe open voor participatie vanuit diverse belangengroeperingen en gaat bijdragen aan de verdere ontwikkeling en het beheer van standaarden, support en informatievoorziening.

HR-XML Projecten in Nederland

[www.ecp.nl/download/3_Presentatie_Akzo_Nobel_-_PleinU_31-5_final.pdf] Managing the flexible workforce – Akzo Nobel

[www.ecp.nl/download/050413_presentatie_[2]_EssentVediorAdecco.pdf] Elektronische inhuur uitzendkrachten – Essent / Vedior / Adecco

[www.ecp.nl/download/050413_presentatie_[4]_Flexchange.ppt] Elektronische inhuur uitzendkrachten – MinVrom / Nétive

[www.ecp.nl/download/presentatie-MarcelFluitman.pps] Elektronische inhuur uitzendkrachten – Belastingdienst

Het project Elektronisch Bestellen en Factureren van de Belastingdienst

Een belangrijk project dat de komende maanden gaat lopen is de implementatie van HR-XML door de Nederlandse Belastingdienst. De Nederlandse Belastingdienst gaat de internationale standaard HR-XML implementeren voor de communicatie met de leveranciers van tijdelijk personeel, waaronder uitzendkrachten, ICT consultants en specialisten. Het project heeft de naam Elektronisch Bestellen en Factureren (EB&F) gekregen en is een onderdeel van het inkoop- en verkoopproces tussen leveranciers van personeel en de Belastingdienst.

De acties van verkopende en inkopende partij voor het inkopen en verkopen van diensten vinden in een logisch verband plaats.

Globaal worden in de tijd gezien de volgende processtappen doorlopen:
• Aanvragen (koper): het selecteren van de mogelijke leveranciers volgens raamcontracten, het opstellen en aanvragen van een offerte
• Aanbieden (verkoper): het aanleveren van een catalogus of het offreren van goederen of diensten.
• Selecteren (koper): het selecteren van goederen of diensten uit het aanbod.
• Bestellen (koper): het bestellen van één of meer goederen of diensten.
• Overeenkomst (verkoper): het verwerken en bevestigen van de bestelling
• Leveren - urenregistratie (verkoper, koper): het verzenden van goederen of het leveren van diensten door de verkoper, respectievelijk het ontvangen van goederen of afnemen van diensten (en het bevestigen ervan aan de verkoper) door de koper.
• Factureren (verkoper, koper): het opstellen, afdrukken en versturen van de factuur door de verkoper, respectievelijk het ontvangen en afhandelen van de factuur door de koper.
• Betalen (koper)

De Belastingdienst zal allereerst het proces van Bestellen en Factureren invoeren en in een latere fase het proces van Selecteren en Offreren.

Het Elektronisch Bestellen en Factureren bestaat uit de fasen Bestellen, Leveren en Factureren. Deze fasen vallen onder de operationele inkoop- en verkoopactiviteiten.

Het Selecteren en Offreren bestaat uit de fasen Aanvragen en Aanbieden. Deze fasen vallen onder de tactische inkoop- en verkoopactiviteiten.

Meer Informatie over HR-XML / SIDES / PleinU

[www.ecp.nl/download/Presentatie_Dennis_Krukkert.pdf] SETU in e-Nederland, standaardisatie binnen een branche

[www.ecp.nl/download/2_Introductie_PleinU_sessie_op_31_mei_2006.pdf] Lancering van de Nederlandse versie van SIDES

[www.ecp.nl/download/050413_presentatie_[3]_Capgemini.ppt] Implementatie van HR-XML in een organisatie - Capgemini

[www.ecp.nl/download/050413_presentatie_[1b]_Paul_Blom.ppt] Elektronische inhuur uitzendkrachten - Paul Blom

[www.ecp.nl/download/Presentatie-ErwinFolmer.pdf]Elektronische inhuur uitzendkrachten - Erwin Folmer

[www.ecp.nl/download/presentatie-FredvanBlommestein.pps] Elektronische inhuur van uitzendkrachten - Fred van Blommestein

Tags: HR-XML, electronic data interchange

Last update: 26-11-2011