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

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

SAP neemt de UN/CEFACT Core Components als basis voor WARP 10

De SAP medewerkers Mark Crawford en Gunther Stuhec hebben de voorbije twee jaar hard gewerkt aan de ontwikkeling van een nieuw modelleer- en transformatiegereedschap gebaseerd op de UN/CEFACT Core Components Specification (CCTS).

Beide heren zijn actief betrokken bij de UN/CEFACT en de CCTS: Gunther is de voorzitter van de UN/CEFACT Techniques and Methodologies Group (TMG) en voorzitter van het project team verantwoordelijk voor de ontwikkeling van de CCTS standaard. Mark is de voorzitter van de UN/CEFACT Applied Technologies Group (ATG), de projectverantwoordelijke voor de UN/CEFACT Naming and Design Rules Specification en het Core Components Harmonization Project.

In het verlengde van hun waardevolle bijdrage aan de UN/CEFACT hebben zij de Core Components Specification als basis genomen voor het ontwerpen van een modelleer en transformatiegereedschap met de werknaam SAP CCTS Modeler Warp 10. 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 transformatie naar ieder ander logisch data model ongeacht de gegevensbron.

De SAP CCTS Modeler Warp 10 is ontworpen met als doel het verminderen van de ontwikkel- en integratieinspanningen van data modellering en mapping. Het gereedschap richt zich voornamelijk op het vereenvoudigen van de inspanningen voor het bouwen van transformatiedefinities. Daarbij wordt ondersteuning geboden voor het automatisch genereren van transformatiemappings tussen verschillende standaarden op basis van industrie, internationale standaard, berichttype en doel van het bericht.

De SAP CCTS Modelere Warp 10 is een web-gebaseerd gereedschap met repository waarin data structuren, modellen en mapping definities zijn opgeslagen.

Vrij recent (9 juli 2008) is door Gunther Stuhec de Community Advisory Group (CAH) 12 Business Data Interoperability opgericht met als doel het nieuwe prototype van CCTS Modeler Warp 10 een beetje dichter bij het grotere publiek te brengen. De vraag is of het publiek wel interesse heeft in een propriëtair online gereedschap. Het aantal deelnemers en activiteiten aan deze community is vrij beperkt wat meestal geen positief teken is.

Voor het realiseren van integratie tussen bedrijfsprocessen en -systemen is het van groot belang dat een oplossing wordt gevonden voor het interoperabiliteitsvraagstuk. De kern van het vraagstuk is het ontbreken van informatieinteroperabiliteit tussen bedrijfsondersteunende systemen. Al jaren is het één van de beperkende factoren in de realisatie van inter-enterprise collaboratieve bedrijfsprocessen en gegevensuitwisseling. Zoals ik in mijn bloart Hoe lossen we het interoperabiliteitsvraagstuk op ? beschrijf zijn er reeds verschillende benaderingen ontwikkeld maar geen is momenteel voldoende volwassen om als uitgangspunt te dienen.

Ik geloof dat het bedrijfsleven behoefte heeft aan een Open Gemeenschappelijke Intelligente Oplossing die de brug slaat tussen al deze initiatieven en geaccepteerd wordt door de deelnemers in het integratie-speelveld. Daarbij valt te denken aan standaardisatieinstellingen, overheden tot leveranciers van oplossingen zoals SAP maar eveneens Open Source Communities zoals Eclipse.

Tags van Technorati: electronic data interchange,UDEF,CCTS,Government,Interoperability Frameworks

Last update: 26-11-2011

De ABILITIES Interoperability Bus

Het project “Application Bus for InteroperabiLITy In enlarged Europe SMEs” (ABILITIES) is/was een onderdeel van het Sixth Framework programma van de Europese Commissie. Het project was gestart in januari 2005 en kende een looptijd van 2 jaar. Het project had als voornaamste doel het onderzoeken, ontwerpen en ontwikkelen van oplossingen voor het verbeteren van de interoperabiliteit in het bestel-tot-facturatie proces (order-to-invoice procurement cycle).

Ik zal hierna het ABILITIES project verder toelichten maar voor meer informatie kunt u terecht op de website ViewZone.org onder ABILITIES.

Het ABILITIES project richtte zich op de Interoperabiliteit tussen kleine en middelgrote bedrijven in de minder ontwikkelde landen en de minder technologie gedreven industriesectoren. Bedrijven en partners uit Duitsland, Hongarije, Slovenië, Rusland, Lithouwen, Roemenië, Turkije en Italië waren betrokken.

Analyse van de problematiek van Enterprise Interoperabiliteit leidde tot de identificatie van twee focusgebieden - interoperabiliteitslagen (interoperability levels):
- de ontwikkeling van een innovatieve architectuur voor de realisatie van Interoperabiliteit met ondermeer intelligente adaptieve bedrijfsdocumenten en integratie van state-of-the-art languages en standaarden voor Business Process Management en Service Orchestration

- de definitie van Intelligente en Adaptive UBL bedrijfsdocumenten voor de kleine en middelgrote bedrijven in het uitgebreide Europa

Het voorstel was om een gemengde architectuur te ontwikkelen die voor uitwisseling van documenten de voordelen combineert van message-based Service Oriented Architectures en van intelligente systemen.

Functionaliteit van ABILITIES
De ABILITIES architectuur voorziet in een aantal functies waarmee de onafhankelijkheid en autonomie van elke deelnemer wordt gegarandeerd.

Ondermeer volgende functies zijn voorzien:
- Configuration Module (Module voor de configuratie van samenwerking)
Voor de communicatie tussen bedrijven zijn de gegevens van de inkooporder en het definiëren van specificaties van goederen en diensten belangrijk. Wanneer standaard samenwerkingsverbanden of -configuraties niet meer volstaan of ontoereikend zijn dan kan met deze functie gedefinieerd worden in welke gevallen een sessie gestart moet worden tussen twee bedrijven voor het afhandelen van openstaande kwesties.

- Negotiation Rules Engine
Elk bedrijf kan haar algemene regels vastleggen en de speciale regels die gelden voor sommige partnerbedrijven.

- Process Designer
De applicatie ondersteunt het ontwerpen en beheren van bedrijfsprocessen via een Process Designer Module.
Via deze module kunnen procesmodellen gedefinieerd, onderhouden en grafisch weergegeven worden.

- Collaboration Configuration Manager
Via de Configuration Manager kunnen partijen verschillende vormen van samenwerking inregelen en inplannen.

Het hart van de ABILITIES architectuur
Het hart van de ABILITIES architectuur is de ABILITIES Interoperability Bus (AIB), gerealiseerd op basis van een Open Source Enterprise Service Bus (ESB). Alle componenten die de interoperabiliteit tussen samenwerkende bedrijven ondersteunen worden gekoppeld aan deze ESB zoals aangegeven in onderstaande figuur.

Een ESB heeft als voornaamste taken Messaging, Transformation en Routing. Daarvoor beschikt een ESB over drie centrale eigenschappen:
1) een Message Oriented Middleware (MOM),
2) connectiviteit gebaseerd op Web Services
3) XML- en SOAP-Messaging and Routing

Voor de Enterprise Service Bus is in het ABILITIES project uitgegaan van Apache ServiceMix. Apache ServiceMix is een Enterprise Service Bus (ESB) die de functionaliteit van Service Oriented en Event Driven Architectures combineert.

Belangrijk gegeven is dat het ABILITIES project uitgaat van de OASIS UBL specificaties voor het uitwisselen van bedrijfsdocumenten tussen afzender en ontvanger. Daarmee bevestigd UBL nogmaals vrij algemeen geaccepteerd te zijn als berichtenstandaard binnen Europa.

Volgens de informatie die ik verder kon vinden heeft het ABILITIES project niet geleid tot een oplossing die daadwerkelijk in gebruik genomen is. De opgedane kennis en ervaring wordt wel weer in andere projecten ingezet en/of toegepast ondermeer door het Software Research & Development Center van de Middle East Technical University (METU) in Turkije.

Het architectuurconcept van ABILITIES zou naar mijn mening in de Open Source wereld opgepakt en verder uitgewerkt kunnen worden. Een combinatie met ChainBuilder van BosTech zou tot iets moois kunnen leiden.

Hint: Op de website van CORDIS (Community Research & Development Information Service) kunt u meer informatie vinden over projecten die uitgevoerd worden binnen het Sixth Framework programma van de Europese Commissie.

Tags van Technorati: enterprise service bus,Government,interoperability frameworks,UBL

Last update: 3-12-2011

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

Tux Paint, Open Source tekenprogramma voor kinderen

Aangezien mijn kinderen in de leeftijd zijn dat zij gebruik beginnen maken van computers en van het internet ben ik regelmatig voor hen op zoek naar educatieve programma's. Tevens wil ik hen enthousiast maken voor Open Source Software. Daarom kijk ik vooral naar software die beschikbaar is onder een Open Source licentie en waarvan ook de broncode gedownload kan worden.

Tux Paint is een gratis tekenprogramma voor kinderen tussen 3 en 12 jaar dat hieraan voldoet. Tux Paint wordt ontwikkeld door vrijwilligers wereldwijd en is gratis beschikbaar onder de GNU General Public License. Lead Developer en Designer is Bill Kendrick, eigenaar van het bedrijf New Breed Software. Tux Paint draait onder verschillende besturingssystemen waaronder Windows (incl. Tablet PC), Mac OS X, Linux, FreeBSD en NetBSD. Het programma draait zelfs onder Citrix® en Windows Terminal Services en op handheld computers.

Tux Paint is in gebruik bij verschillende scholen in de wereld van België tot in de Verenigde Staten.

Tux Paint combineert een handige gebruikersinterface met geluiden en uitdagende humoristische mascotte die de kinderen richting geven tijdens het gebruik van het

Downloaden en installeren U kunt Tux Paint downloaden van de website tuxpaint.org maar u kunt ook de Tux Paint CD bestellen bij CafePress

Selecteer de versie voor uw besturingssysteem.

Tux Paint komt in twee delen: het Tux Paint programma en de verzameling van stempels.

Download beide installatieprogramma's.

Na het downloaden start achtereenvolgens de programma's tuxpaint-0.9.20b-win32-installer.exe en tuxpaint-stamps-2008.06.30-win43-installer.exe.

Volg de installatieinstructies.

Opstarten Tux Paint
Ga naar Start > Alle programma's > Tux Paint en selecteer de optie Tux Paint (Windowed).

Wanneer u Tux Paint opstart krijgt u direct de beschikking over een lege canvas en een verscheidenheid aan tekengereedschappen. Aan de linkerkant van het canvas staan de hulpmiddelen en aan de rechterkant staan bij het hulpmiddel horende knoppen.

De hulpmiddelen kunt u activeren door de knop van het betreffende hulpmiddel dat u wenst te gebruiken aan te raken met uw muis. Tussen de hulpmiddelen vindt u ook de knoppen Terugwijzigen, Opnieuw doen, Nieuw, Opslaan, Openen en Stoppen.

Wanneer u een hulpmiddel selecteert ziet u aan de rechterkant de verzameling knoppen eveneens veranderen. Kiest u het hulpmiddel stempel dan ziet u daar een overzicht verschijnen van stempels. Het overzicht bestaat uit een grote verzameling van dieren. Het grappige is dat wanneer u één van deze dieren aanklikt u het geluid van het dier en de naam van het dier te horen krijgt.

Wist u al welk geluid een pinguïn maakt ? Nee zorg ervoor dat het volume van uw luidsprekers openstaat en het niveau van Tux Paint voldoende luid staat. Het niveau kunt u instellen met de volumebalk onder de stempels.

Zoek nu de pinguïn op in de lijst met stempels en klik op de stempel. Voor bijna elk dier is het geluid aanwezig. Een handige manier om kinderen vertrouwd te maken met dieren en met hun geluiden. Volwassenen raken natuurlijk snel uitgekeken op Tux Paint maar ik beveel het toch aan voor kinderen rond de leeftijd van 4 tot 6 jaar.

Tux Typing en Tux Math
Naast Tux Paint zijn er nog Tux Typing en Tux Math Command.

Spelenderwijs proberen deze programma's kinderen kennis van rekenen en van typen bij te brengen.

Als u deze programma's wilt uitproberen ga dan naar de betreffende website, klik op de knop download en download de versie van het installatieprogramma voor uw computer en besturingssysteem.

Dubbelklik daarna op het installatieprogramma en volg de instructies.

Ik heb deze programma's één voor één uitgeprobeerd en ze zijn prachtig. Vooral de intromuziek van Tux Typing moet u horen.

Spelen met Tux Typing en Tux Math
Via het menuscherm van Tux Typing kunt een aantal opties instellen waaronder de taalcode en kunt u eveneens de lijst met woorden waarmee gewerkt wordt onderhouden.

Tux Typing en Tux Math presenteren de gebruiker een scherm waar letters of rekenformules naar beneden dwarrelen. Door de letters in te tikken of het juiste antwoord te geven op de rekenformules kunnen punten verdiend worden. De gebruiker met de hoogste score - vanzelfsprekend - wint natuurlijk.

Tux Typing is vergeleken met Tux Math rijker aan variaties maar u moet het zelf maar eens proberen.

Ik wens u veel plezier met Tux en laat even weten wat uw kinderen van Tux vinden.

Tags van Technorati: open source,desktop tools

Last update: 3-12-2011

Open Source Screen Capture gereedschappen

Al sinds begin 2005 gebruik ik het gratis Screen Capture gereedschap MWSnap van Mirek Wojtowicz. Alhoewel de laatste versie van MWSnap dateert van Juli 2002 is de aangeboden functionaliteit meer dan voldoende.

Ik gebruik MWSnap als hulpmiddel voor het maken van screenshots van afbeeldingen die ik dan weer verwerk ik handleidingen en mijn weblog artikelen.

MWSnap biedt gebruikers een aantal functies:
1) een aantal standaard capture - opname mogelijkheden
- een vaste rechthoek
- een vrij te selecteren rechthoek
- een dialoogvenster
- het volledige bureaublad
- initiëren met sneltoetsen

2) een aantal edit functions - bewerkingsfuncties
- transformeren (spiegelen, omkeren, links roteren, rechts roteren)
- inlijsten:
- toevoegen van cursors

3) extra functionaliteit
- System Tray Launcher
- Automatisch opslaan
- Geluiden bij opname
- Undo / Redo
- Herhalen laatste schermopname

Ik heb de laatste jaren gezocht naar Open Source Screen Capture gereedschappen die eveneens deze functies bieden. De voorbije week heb ik een aantal Screen Capture gereedschappen gevonden. Het mooie is dat deze gereedschappen in verschillende talen (Java, C#) ontwikkeld zijn waardoor een gebruiker een keuze kan maken.

- JShot is ontwikkeld in Java door Attila Magyar (Zeroflag) uit Hongarije.

- ZScreen is ontwikeld in C# door BrandonZ

- Greenshot

Een lijst van Screen Capture gereedschappen kunt u terugvinden op mijn website onder de menuoptie Links, categorie Desktop Tools.

Tags van Technorati: screen capture

Last update: 26-11-2011

ZScreen, het gratis en platformonafhankelijke screen capture en upload gereedschap

ZScreen is een Screen Capture gereedschap ontwikkeld in C# door BrandonZ en gratis beschikbaar onder de GNU General Public License (GPL) Versie 2 licentie.

Met ZScreen kunt u screenshots maken van het volledige scherm, een actief scherm of een selectie van het scherm. Het is zelfs mogelijk om een screenshot te maken van een context menu, wat met sommige Screen Capture gereedschappen niet kan. Wanneer u ZScreen opstart wordt deze automatisch geladen in de system tray en kunt u met de rechtermuisknop het ZScreen context menu oproepen. Via het context menu krijgt u toegang tot een aantal menufuncties waaronder het bekijken van de verschillende instellingen.

Het is niet mogelijk om via het context menu afbeeldingen vast te leggen. ZScreen maakt gebruik van sneltoetsen die u zelf kunt instellen op het moment dat u ZScreen installeert of later door het instellingenscherm te openen vanuit het context menu.

Downloaden en installeren van ZScreen
U kunt het installatieprogramma van ZScreen downloaden van de website code.google.com/p/zscreen. Ga naar de website en selecteer de optie downloads. Selecteer dan de laatste versie van het Setup programma.

Sla het bestand (ZScreenSetup-abcd.exe) op in een folder van uw keuze en ga daarna naar deze folder.

Dubbelklik op het bestand en volg de installatieprocedure.

Na het opstarten van ZScreen wordt het scherm met instellingen geopend waar u alle benodigde instellingen kunt bekijken en aanpassen.

ZScreen Instellingen
Het scherm met instellingen bestaat uit een aantal tabbladen waarmee u het gebruik en functioneren van ZScreen naar uw hand kunt zetten.

Wanneer u onder het tabblad Basis op het ikoon van ZScreen klikt wordt de documentatie geopend. Hier kunt u meer informatie terugvinden over de verschillende instellingen en het gebruik van ZScreen.

Onder het tabblad Basis kunt u de taal van de gebruikersinterface definiëren en de bestemming van de screenshot vastleggen:
- Klembord (Clipboard)
- Bestand (File)
- FTP
- ImageShack

Via het tabblad Bestand Instellingen kunt u aangeven in welke folder afbeeldingen (tijdelijk) opgeslagen moeten worden. Standaard worden alle afbeeldingen in deze folder opgeslagen ongeacht of u deze bewerkt met een tekenprogramma of naar een FTP server upload. In het laatste geval kunt u hier wel aangeven of de afbeelding na het uploaden uit deze folder verwijderd moet worden.

Standaard wordt ZScreen geïnstalleerd met voorgedefinieerde Automatic Naming Conventions en Picture Quality. U kunt de naamgeving en kwaliteit die ZScreen moet gebruiken voor het vastleggen van afbeeldingen aanpassen. Zelf heb ik het bestandsformaat aangepast van PNG naar JPG omdat dit het formaat is dat ik het meest gebruik. Voor de naamgeving kunt u twee conventies instellen: (1) voor het maken van een screenshot van het Actieve Scherm en (2) voor het maken van een Verkleind /Volledig Venster.

Het is eveneens mogelijk om ZScreen zo in te stellen dat u tijdens het maken van een screenshot de naam van het bestand kunt aanpassen. Een instelling die wel handig is omdat de naamgeving van ZScreen vrij cryptisch is, voorbeeld SS-18.08.2008-11.31.10AM.

Voor het weergeven en aanpassen van de afbeelding kan ZScreen gebruik maken van een tekenprogramma. Standaard is het gebruik van een tekenprogramma niet geactiveerd. U kunt zelf instellen welk tekenprogramma u wilt gebruiken of u kunt gewoon MS Paint selecteren. Dit dient u wel te doen alvorens u een afbeelding vastlegd. Ga daarvoor naar het tabblad Image Software Instellingen en selecteer MS Paint of voeg uw tekenprogramma toe.

Maken van screenshots
ZScreen geeft u de mogelijkheid om een deel van het scherm te selecteren, vast te leggen en te publiceren. Publiceren wil zeggen dat u uw screenshot kunt uploaden naar een FTP server, een Image Hosting server (ImageShack) of opslaan als een bestand.

ZScreen maakt gebruik van sneltoetsen voor het vastleggen van screenshots. Deze sneltoetsen kunt u zelf instellen onder het tabblad Sneltoetsen. Ik heb de sneltoetsen als volgt ingesteld zodat deze overeenkomen met de instellingen van MWSnap:
- Actieve scherm: Shift+Control+W, voor het maken van een screenshot van het openstaande actieve venster

- Verkleind screenshot: Shift+Control+A, voor het maken van een screenshot van een geselecteerd deel van een venster

- Volledige scherm: Shift+Control+D, voor het maken van een screenshot van het volledige venster

Conclusies
ZScreen waarschuwt u niet waneer u een screenshot hebt gemaakt. Alleen wanneer u een tekenprogramma hebt gekoppeld aan ZScreen of de optie Prompt for File Name hebt aangezet kunt u zien dat een screenshot wordt vastgelegd. Het onbreken van geluiden is één van de enige beperkingen van ZScreen.

Verder biedt ZScreen alle functies die nodig zijn waaronder sneltoetsen en het tonen van de screenshot. Met een ander tekenprogramma dan MS Paint is het mogelijk om cursors en andere tekens toe te voegen aan de gemaakte screenshot.

De ondersteuning voor sneltoetsen en de mogelijkheid om eveneens screenshots te kunnen maken van context menu's zijn wel de voornaamste redenen waarom ZScreen mij aanspreekt.

Hierna zal ik aangeven welke functionaliteit aanwezig is:
een aantal standaard capture - opname mogelijkheden
- een vaste rechthoek: niet aanwezig
- een vrij te selecteren rechthoek: aanwezig
- een dialoogvenster: aanwezig
- onderdelen van het venster: niet aanwezig
- het volledige openstaande scherm: aanwezig
- het volledige bureaublad: niet aanwezig

- initiëren van screenshot met sneltoetsen: aanwezig

een aantal edit functions - bewerkingsfuncties
- instellen van tekenprogramma: aanwezig

- transformeren (spiegelen, omkeren, links roteren, rechts roteren): afhankelijk van tekenprogramma
- inlijsten: afhankelijk van tekenprogramma
- toevoegen van cursors: afhankelijk van tekenprogramma

extra functionaliteit
- System Tray Launcher: aanwezig
- Automatisch opslaan: aanwezig
- Geluiden bij opname: niet aanwezig
- Undo / Redo: afhankelijk van tekenprogramma
- Herhalen laatste schermopname: niet aanwezig

Tags van Technorati: screen capture

Last update: 18-08-2008

JShot, het gratis en platformonafhankelijke screen capture en upload gereedschap

JShot Screen Capture is ontwikkeld in Java door Attila Magyar (Zeroflag) uit Hongarije.

JShot geeft u de mogelijkheid om een deel van het scherm te selecteren, vast te leggen en te publiceren. Publiceren wil zeggen dat u uw screenshot kunt uploaden naar een FTP server, een Image Hosting server (ImageShack) of kunt verzenden naar uw Instant Messaging partner (Skype, MSN). JShot kent echter geen sneltoetsen waardoor het niet mogelijk is om een screenshot te maken van een context menu.

JShot beschikt eveneens over teken- en bewerkingsfunctionaliteit waaronder het aanbrengen van cursors of andere vormen (lijnen, tekst) op uw afbeelding. JShot maakt daarvoor gebruik van het tekenprogramma dat standaard aanwezig is of dat u instelt via het configuratiescherm.

Helaas is er nog geen documentatie of helpfunctie beschikbaar en zult u wat moeten experimenteren om met JShot te leren werken. Echter in een mum van tijd hebt u wel begrepen hoe één en ander werkt. Ik zal hierna een aantal basis functies toelichten.

Downloaden en installeren van JShot
U kunt JShot downloaden van de website JShot.info via het hoofdmenu. Klik op de link Download en in het download scherm selecteer de versie voor uw besturingssysteem (Windows, Linux of ander platform).

Sla het bestand jshotinstall.exe (of jshotinstall.jar voor Linux) op in een folder van uw keuze.

Ga naar de folder waar u het bestand hebt opgeslagen en dubbelklik op het bestand.

Volg de installatieprocedure. Tijdens de installatie moet u de licentie overeenkomst (geen open source licentie) accepteren en aangeven in welke folder u JShot wilt installeren. U kunt tijdens de installatie van JShot eveneens de plugin's voor ImageShack en Skype selecteren.

JShot beschikt momenteel nog niet over een plugin-manager, deze is in ontwikkeling, maar optionele plugin's kunnen wel handmatig worden toegevoegd in een eigen folder onder de directory plugins. Een plugin bestaat uit een .jar-bestand, plugin.xml met daarin de beschrijving en een optionele lib-folder.

Wanneer u JShot voor de eerste maal opstart wordt de configuratie wizard geopend waarin u geadviseerd wordt om uw configuratieinstellingen te controleren en een uploader profiel aan te maken.

In het scherm met configuratieinstellingen kunt ondermeer instellen in welk formaat uw afbeeldingen opgeslagen moet worden en welke look-en-feel u wilt hanteren.

JShot maakt het mogelijk om afbeeldingen te uploaden naar een FTP server, ImageShack, Skype, Twitter, Picasa, Dropbox of Minus. Daarvoor maakt JShot gebruik van een uploader plugins die afzonderlijk geïnstalleerd moeten worden. U kunt zelf een uploader plugin ontwikkelen als deze nog niet beschikbaar is voor uw omgeving.

Maken van screenshots
JShot kunt u op twee manier openen: als applicatie en in de system tray.

Als u de applicatie hebt geopend kan u een screenshot maken van een volledig venster via de toetsen CTRL + E of de Menu Optie Picture > Recapture. Wanneer u JShot hebt geopend in de system tray kunt u de gewenste screenshot maken via het context menu. Klik voor het openen van het context menu met uw rechtermuisknop op het JShot ikoontje in de system tray en selecteer de screenshot die u wilt maken.

JShot biedt u een aantal mogelijke screenshots aan via het context menu:
- het volledige scherm (whole screen)
- actieve schermdelen (widget)
- het openstaande scherm (active window)
- de desktop - bureaublad (desktop)
- de taskbar (taskbar)

- de vijfde mogelijkheid - Wanneer u dubbelklikt op het JShot ikoontje in de system tray kunt u een rechthoekig venster selecteren voor het maken van een screenshot. Er verschijnt op het scherm de melding Drag your mouse to select a portion of the screen.

Conclusies
Na wat experimenteren kan ik voorlopig de volgende conclusies trekken. JShot biedt heel wat voorzieningen voor het aanpassen van uw screenshots. Dit komt met name omdat JShot gebruik maakt van een tekenprogramma dat u zelf kunt instellen. Standaard is MS Paint ingesteld als tekenprogramma maar dit kunt aanpassen aan uw eigen voorkeur. >/p>

JShot sneltoetsen maar u zult deze zelf moeten definiëren onder het context menu > options > hotkeys.

JShot kan op twee manieren geopend kan worden:
- in de system tray
- als afzonderlijke applicatie

Helaas kan in de laatste modus alleen maar een screenshot van een volledig venster gemaakt worden.

Welke functionaliteit is aanwezig:
een aantal standaard capture - opname mogelijkheden
- een vaste rechthoek: niet aanwezig
- een vrij te selecteren rechthoek: aanwezig
- een dialoogvenster: aanwezig
- onderdelen van het venster: niet aanwezig
- het volledige openstaande scherm: aanwezig
- het volledige bureaublad: aanwezig

- initiëren van screenshot met sneltoetsen: niet aanwezig

een aantal edit functions - bewerkingsfuncties
- instellen van tekenprogramma: aanwezig

- transformeren (spiegelen, omkeren, links roteren, rechts roteren): afhankelijk van tekenprogramma
- inlijsten: afhankelijk van tekenprogramma
- toevoegen van cursors: afhankelijk van tekenprogramma

extra functionaliteit
- System Tray Launcher: aanwezig
- Automatisch opslaan: niet aanwezig
- Geluiden bij opname: aanwezig
- Undo / Redo: afhankelijk van tekenprogramma
- Herhalen laatste schermopname: aanwezig

Tags van Technorati: screen capture

Last update: 26-11-2011

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

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

Welke vormen van Elektronisch Factureren zijn toegestaan in Nederland

In december 2001 werd de Europese richtlijn 2001/115/EG goedgekeurd. Deze richtlijn gaat over de vereenvoudiging, modernisering en harmonisering van de ter zake van de facturering geldende voorwaarden op het gebied van de belasting over de toegevoegde waarde. In de richtlijn wordt een geharmoniseerde lijst vastgesteld van verplichte vermeldingen die een factuur moet bevatten en worden een aantal gemeenschappelijke voorwaarden voor elektronische facturering, elektronische opslag van de facturen, eigenhandige facturering en uitbesteding van de factureringswerkzaamheden vastgelegd.

Op 1 januari 2004 werd de Europese richtlijn omgezet naar Nederlands recht, zie aankondiging op de website van het Ministerie van Financiën, maar helaas heeft dat niet geleid tot een sterke toename van Elektronisch Factureren. De Nederlandse Overheid gaat nu Elektronisch Factureren de komende jaren stimuleren met als streven om in 2010 tien procent van de facturen elektronisch te ontvangen en te verwerken. Uit de bevindingen van de Factuurmonitor 2008 blijkt dat het merendeel van de bedrijven en organisaties in Nederland eveneens de komende drie jaar willen overstappen op geautomatiseerde factuurverwerking. De Factuurmonitor is een onderzoek naar het gebruik van elektronisch factureren en geautomatiseerde factuurverwerking in Nederland en in Europa.

Het onderzoek geeft aan dat onduidelijke wet- en regelgeving de grootste belemmering vormt voor het in gebruik nemen van Elektronische Facturatie. Daarom is het goed om te eens te kijken naar hoe de Europese richtlijn in Nederland is vormgegeven en/of ingevuld. Het gaat dan met name over de wettelijke eisen en voorwaarden waaraan voldaan moet zijn.

De Europese richtlijn stelt dat elektronisch factureren toegestaan is mits:
1) De afnemer / koper heeft bevestigd een factuur in elektronisch formaat te willen accepteren.
2) De authenticiteit van de herkomst en de integriteit van de inhoud worden gewaarborgd door middel van:
- Een beveiligde elektronische handtekening ofwel een geavanceerde elektronische handtekening. Lidstaten kunnen eisen dat de handtekening is voorzien van een goedgekeurd certificaat, de handtekening wordt dan een gekwalificeerde elektronische handtekening.

- EDI (Electronic Data Interchange)

- Een andere manier onder de voorwaarde dat de lidstaat dit goedkeurt

Opmerking: De Belastingdienst heeft op 17 november 2005 de eis laten vervallen om bij een EDI-factuur een afstemmingsoverzicht op papier aan te maken en deze vervolgens naar de ontvanger te versturen. Ondanks het feit dat deze eis is vervallen, adviseert de EDI Toetsing Commissie (ETC) het afstemmingsoverzicht te handhaven. Het afstemmingsoverzicht vormt voor de ontvanger namelijk een belangrijk hulpmiddel om te controleren of alle EDI-facturen ook daadwerkelijk zijn binnengekomen en of de factuurtotalen op het afstemmingsoverzicht overeenstemmen met de totalen van de EDI-facturen. Door middel van het afstemmingsoverzicht is de controleerbaarheid van de EDI-facturen goed uit te voeren.

In Nederland worden de volgende eisen gesteld aan Elektronisch Factureren:
1) De ontvanger of afnemer van de factuur moet vooraf akkoord gaan met elektronische facturatie.

2) De elektronisch factuur moet ten minste alle gegevens bevatten die wettelijk vereist zijn bij papieren facturen. Ga voor een overzicht van verplichte gegevens naar de website van de Belastingdienst, www.belastingdienst.nl. Kies Zakelijk en vervolgens “Omzet, btw en winst”. Selecteer daarna “Btw berekenen over uw omzet” en “Tijdstip van aangifte”. Onder “Onderdelen factuur” vindt u het overzicht van gegevens die op de factuur moeten staan.

3) De authenticiteit (echtheid) van de herkomst en de integriteit van de inhoud moet gewaarborgd zijn. De afnemer moet er zeker van zijn dat de factuur werkelijk van de leverancier afkomstig is. De leverancier en de afnemer moeten er zeker van zijn dat de factuur niet veranderd is.

4) De Belastingdienst moet de factuur kunnen controleren.

Verder gelden dat de regels voor de verschuldigdheid en aftrek van btw op een zelfde wijze moeten worden toegepast en het moment van uitreiken van de factuur wordt bepaald door de factuurdatum.

Vergeleken met papieren facturen zijn elektronische facturen makkelijker te veranderen zonder dat de afzender en/of ontvanger hier iets van merkt. De authenticiteit van de herkomst en de integriteit van de inhoud van de elektronische factuur moet in alle gevallen worden gegarandeerd. Bij een papieren factuur kunt u dat bereiken door gebruik te maken van facturen met een logo of een watermerk in het factuurpapier maar bij een elektronische factuur is zo’n watermerk - op dit moment - niet voorzien.

De Nederlandse Belastingdienst heeft analoog aan de Europese richtlijn 2001/115/EG een aantal voorwaarden gedefinieerd waaraan elektronisch verzonden facturen moeten voldoen. Deze voorwaarden zijn vertaald naar methoden voor elektronisch factureren die door de Belastingdienst zijn goedgekeurd. Als gebruik gemaakt wordt van één van deze methoden dan is voldaan aan de eis van authenticiteit en integriteit van de elektronisch factuur.

De Belastingdienst heeft de volgende methoden voor elektronisch factureren goedgekeurd:
1) Verzenden van facturen door gebruik te maken van een geavanceerde elektronische handtekening, het is niet verplicht gebruik te maken van een gekwalificeerde elektronische handtekening

2) Elektronische uitwisseling van gegevens via Electronic Data Interchange (EDI)
Electronic Data Interchange (EDI) is de geautomatiseerde, elektronische uitwisseling van gestructureerde en genormeerde berichten tussen computers van verschillende organisaties.

Een andere methode waarbij in ieder geval de authenticiteit van de herkomst en de integriteit van de inhoud is gewaarborgd is toegestaan mits deze is gemeld aan de inspecteur van de belastingdienst.

Bij het gebruik van een geavanceerde elektronisch handtekening geldt:
- de elektronische handtekening is op unieke wijze aan de ondertekenaar verbonden
- de elektronische handtekening maakt het mogelijk de ondertekenaar te identificeren
- de elektronische handtekening komt tot stand met middelen die de ondertekenaar onder zijn uitsluitende controle kan houden
- de elektronische handtekening is op zodanige wijze aan het elektronisch bestand waarop zij betrekking heeft verbonden, dat elke wijziging achteraf van de gegevens kan worden opgespoord.

De laatste jaren zijn een aantal vormen voor het aanbieden van digitale facturen meer in de belangstelling gekomen. Denk ondermeer aan Electronic Invoice Presentment (EIP) en het versturen van een factuur als een e-mailbericht of als bijlage bij een e-mail. In de consumentenmarkt is deze trend al jaren gaande (bijvoorbeeld: telefoon- en energierekeningen) en in de zakelijk markt vindt momenteel een behoorlijke inhaalslag plaats. Het aantal aanbieders van deze oplossingen voor de zakelijke markt is de laatste maanden enorm toegenomen. De belangrijkste vraag die gesteld moet worden is dan ook of deze vormen voldoen aan de eisen gesteld door de Belastingdienst.

(Wanneer) Voldoet Electronic Invoice Presentment (EIF) of Elektronische Factuurpresentatie aan de eisen gesteld door de Belastingdienst ?
Elektronische Factuurpresentatie wil zeggen dat de factuur aangeboden wordt aan afnemers via een website. Voor toepassing van deze vorm van elektronische facturering geldt dat enerzijds de afnemer van de factuur deze vorm moet aanvaarden en anderzijds dat de authenticiteit en integriteit van de factuur gewaarborgd wordt.

Een ander belangrijk aspect in dit verband is de factureringsverplichting. Ondernemers zijn in principe verplicht een op juiste wijze opgemaakte factuur uit te reiken over hun met btw belaste leveringen en diensten aan andere ondernemers. Om aan de term uitreiken, officieel overhandigen, te kunnen voldoen zal een aankondiging naar de klant gestuurd moeten worden waarin verteld wordt dat de factuur beschikbaar is op de website en daar geraadpleegd of opgehaald kan worden.

Het waarborgen van de authenticiteit en integriteit van de factuur kan gebeuren door gebruik te maken van een geavanceerde elektronische handtekening.

Is het versturen van een factuur als bijlage bij een e-mail toegestaan ?
Voor het versturen van een factuur als e-mail of het opnemen van een factuur als bijlage bij een e-mail blijven de regels gelden. De afnemer moet deze vorm aanvaarden en er moet gebruik gemaakt worden van een geavanceerde elektronische handtekening.

Tip: Op de website van Factuurwijzer.nl kunt u meer antwoorden vinden op fiscale vragen over elektronisch factureren.

Met deze nieuwe vormen van het uitreiken van facturen aan klanten ontstaan automatisch vragen over de opslag van elektronische facturen en uitbesteden van het opmaken en/of verzenden van facturen door derden.

Welke voorwaarden worden gesteld aan de opslag van Elektronische Facturen ?
De EU richtlijn maakt elektronisch factureren mogelijk maar de richtlijn laat in het midden hoe en hoe lang de leverancier en klant gegevens moeten bewaren.

In Nederland moet u als ondernemer alle gegevens uit uw geautomatiseerde administratie bewaren die belangrijk zijn voor de belastingheffing. Deze fiscale bewaarplicht geldt in principe voor een periode van zeven jaar. Bij de invoering van een systeem van elektronisch factureren is het dan ook belangrijk dat aandacht wordt besteed aan de wijze waarop de gegevens worden bewaard en hoe deze gegevens toegankelijk blijven.

De Belastingdienst heeft de brochure Uw geautomatiseerde administratie en de fiscale bewaarplicht” uitgebracht waarin beschreven staat waaraan voldaan moet worden. De Belastingdienst stelt dat facturen bewaard moeten worden in de vorm waarin de facturen zijn uitgestuurd of ontvangen. Elektronische facturen moeten dus als elektronisch bericht worden bewaard inclusief de digitale handtekening.

Welke voorwaarden worden gesteld aan het opmaken van een Elektronische Factuur ?
De Belastingdienst stelt eisen aan de manier waarop de factuur wordt opgemaakt. Opmaken van een factuur door een derde partij is toegestaan maar de leverancier blijft verantwoordelijk voor de juistheid van de factuur. Tevens blijft de leverancier er verantwoordelijk voor dat degene die de factuur opmaakt deze op de juiste manier bewaart.

Voor het laten verzorgen van de transformatie van facturen van een interne bestandsformaat naar een extern formaat door derden. Hierbij is het belangrijk dat partijen (klant, leverancier) duidelijke afspraken maken over de wijze waarop partijen elektronisch gaan communiceren, bijvoorbeeld bij het gebruik van EDI, maakt men gebruik van een interchange agreement. Het onderling elektronisch uitwisselen van berichten vormt de centrale bepaling (kernbeding) van de interchange agreement. Onderwerpen die worden geregeld in een interchange agreement zijn technische aspecten, zoals de berichtenstandaards en de benodigde telecommunicatievoorzieningen, beveiligingsaspecten, zoals de beveiliging van informatiesystemen en de encryptie van berichten, en juridische aspecten, zoals de bewijskracht van de elektronische registratie van berichten.

Tags: e-Factureren, Overheid

Last update: 26-11-2011