English / Dutch [+/-]

Business-to-Business (B2B), Enterprise Service Bus (ESB), Service Oriented Architecture (SOA)
Inter Enterprise Business Hub (IEBH), Project Management, Open Source Solutions
Electronic Invoicing, Electronic Invoice Presentment & Payment (EIPP), E-Procurement, E-Commerce
De wereld van Internetapplicaties en Open Source Oplossingen.
The world of Internet applications and Open Source Solutions.
Find the Electronic Business Knowledge Village (EBKV) on Linkedin
Join Platform eZakendoen on LinkedIn


Verzeker u van 2 GB gratis opslagruimte.

Get Mozy Free


Creative Commons License
Op dit werk is een Creative Commons Licentie van toepassing.

December 2009
M T W T F S S
« Oct    
 123456
78910111213
14151617181920
21222324252627
28293031  
View danga's profile on LinkedIn




Gratis Opslagruimte voor Windows

Get 2 GB of 100% free backup space.

Get Mozy Free


Platform eZakendoen voor en door gebruikers van elektronisch bestellen en factureren!

Het platform Elektronisch Zakendoen wil de brug slaan tussen bedrijven, overheden, aanbieders van oplossingen en standaardisatieinstellingen. De belangrijkste doelstelling van het plaform is het stimuleren en bevorderen van Elektronisch Bestellen en Factureren.


Join het Platform eZakendoen on LinkedIn

De laatste jaren hebben vooral de Overheid en de aanbieders van oplossingen en diensten verschillende initiatieven gelanceerd om Elektronisch Zakendoen te stimuleren. Ondermeer de vereenvoudiging van de fiscale regels voor elektronisch factureren en het openstellen van de website www.e-factureren.info zijn gericht op het stimuleren van grootschalige toepassing.

Maar ondanks al de aandacht kent eZakendoen voorlopig nog niet de hoge vlucht die velen hadden verwacht. Met name het bedrijfsleven is nog steeds op zoek naar betrouwbare, onafhankelijke en objectieve antwoorden op vragen over juridische, fiscale en technische (oplossingen, standaarden) aspecten.

Het platform Elektronisch Zakendoen wil alle betrokkenen informeren en op de hoogte stellen van de ontwikkelingen op het gebied van Elektronisch Bestellen en Factureren. Het Platform eZakendoen is toegankelijk voor iedereen en heeft als doel:
- het stimuleren van open communicatie tussen alle betrokkenen

- het verhogen van het bewustzijn en draagvlak voor eZakendoen bij het bedrijfsleven

- het bieden van een forum voor interactie en discussie over genoemde aspecten

- het uitwisselen van kennis en ervaring tussen deelnemers

- het evalueren van de verschillende initiatieven op het gebied van elektronisch zakendoen

- het organiseren van business en technology workshops

Wilt U een bijdrage leveren aan de toename van eZakendoen of bent U op zoek naar onpartijdige informatie over juridische, fiscale en technische aspecten dan heten wij U welkom. Het enige wat wij van U verwachten is actieve deelname aan en promotie van het platform.

Bent u klaar voor een ritje op de elektronisch business snelweg ?

Vision on electronic invoicing (business) in the future
The most important theme on the agenda of companies and government bodies at this moment is electronic invoicing. Many companies see electronic invoicing as an instrument to realise cost savings and to improve the socially responsible undertaken - image. Not always will electronic invoicing lead to cost savings but generally it is assumed it will.

My advice is to conduct a thorough investigation of the impact on the organisation, systems, applications, processes and information. Such a study should provide a view on the vision on electronic invoicing within the company and deliver information for drawing up the Business Case. Do not forget Electronic Invoicing is part of the end-to-end trade process (Electronic Business). The study will have to mind the overall trade process including purchase-to-pay and order-to-cash.

In addition Electronic Business refers to Exchange Services (exchange of messages) between customers and suppliers. An activity that takes place in the Exchange Domain, the domain area with focus on interoperability and not on the purchase and sales process.

end-to-end-trade-process

Based on several investigation and implementation projects combined with extensive study of technological developments and innovative business concepts a vision emerged on the future of Electronic Business, more specific Electronic Invoicing.

“My vision on Electronic Invoicing is of an electronic business highway located in the cloud above us.”

electronic-business-highway

My vision on Electronic Invoicing is of an electronic business highway in the cloud above us. Emerging technologies and growing electronic business networks are shaping the future of Electronic Business into an open an intelligent information service highway wherein Electronic Invoicing fits as a tiny little exchange instance that enables smart and fast reach to connected partners.

ebusiness-vision-on-electronic-invoicing

Actually I mean that intelligent instances on the electronic business highway make it possible to exchange information and establish processes to work together with others that are also using the highway. Companies will focus more and more on the reason of their existence and move core-functions like generate and send, receive and process invoices to the outside or transfer to third parties whome are specialised therein.

The electronic business highway will become a shielded area of the Internet or another IP-network comparable to Internettelephony (Voice over IP). The electronic business highway will be an open and for everyone accessibe instance that is in no way identical to the Value Added Network (VAN) from the EDI age.

Visie op elektronisch factureren (zakendoen) in de toekomst
Het belangrijkste thema op de agenda van bedrijven en overheidsinstanties van het moment is elektronisch factureren. Veel bedrijven zien elektronisch factureren als een middel om kostenbesparingen te realiseren en het maatschappelijk verantwoord ondernemen (MVO) - imago te verbeteren. Het is niet altijd gezegd dat elektronisch factureren tot kostenbesparingen leidt maar algemeen gesproken wordt hier wel van uitgegaan.

Mijn advies is om voorafgaande (uitgebreid) onderzoek te verrichten naar de impact op organisatie, systemen en applicaties, processen en informatie. Zo’n studie moet inzicht verschaffen in de visie op elektronisch factureren binnen het bedrijf en informatie leveren voor het opstellen van de Business Case. Vergeet daarbij niet dat Elektronisch Factureren een onderdeel is van het end-to-end handelsproces (Elektronisch Zakendoen). De studie zal daarom het geheel in ogenschouw moeten nemen zowel het purchase-to-pay als het order-to-cash proces.

Daarnaast richt Elektronisch Zakendoen zich op Exchange Services (uitwisseling van berichten) tussen klanten en leveranciers. Een activiteit die plaatsvindt in het Exchange Domain, het domeingebied waar de nadruk ligt op de interoperabiliteit en niet op het inkoop- en verkoopproces.

end-to-end-trade-process

Op basis van diverse onderzoeks- en implementatietrajecten gecombineerd met uitgebreide bestudering van technologische ontwikkelingen en van innovatieve bedrijfsconcepten is een visie ontstaan op de toekomst van Elektronisch Zakendoen, meer specifiek Elektronisch Factureren.

“My vision on Electronic Invoicing is of an electronic business highway located in the cloud above us. ”

electronic-business-highway

Mijn visie op Elektronische Factureren is die van een elektronische business snelweg in de wolken boven ons. Opduikende technologiën en evoluerende elektronische business netwerken formeren de toekomst van Elektronisch Zakendoen in een open en intelligente informatie-diensten-snelweg waarin Elektronisch Factureren past als een berichtinstantie en voorziet in slimme en snelle bereikbaarheid van aangesloten partners.

ebusiness-vision-on-electronic-invoicing

Feitelijk bedoel ik dat intelligente instanties op de elektronische business snelweg het mogelijk maken om informatie uit te wisselen en processen te laten samenwerken met anderen die eveneens gebruik maken van de snelweg. Bedrijven zullen zich meer en meer gaan richten op de reden van hun bestaan en niet-kernfuncties zoals het genereren en versturen, ontvangen en verwerken van facturen overbrengen naar de buitenkant of overdragen aan derden die daarin gespecialiseerd zijn.

De elektronische business snelweg gaat een afgeschermd gebied van het Internet of een ander IP-netwerk innemen vergelijkbaar met Internettelefonie (Voice over IP). Het wordt geen Value Added Network (VAN) zoals wij die kennen vannuit het EDI tijdperk maar een open en voor iedereen toegankelijke instantie.

Read more — Meer lezen

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.

In februari 2003 werd de eerste versie 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 standaardisatieinstellingen, 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):

ubl-two-phase-validation-process

- 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.

Read more — Meer lezen

the XAware Sandbox EDIFACT project requirements

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

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

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

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

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

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

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

Read more — Meer lezen

Beknopte beschrijving van de UN/EDIFACT berichtstructuur

Het uitbreiden van Open Source gereedschappen met functionaliteit voor het definiëren en uitvoeren van berichttransformaties van EDIFACT naar andere standaarden en omgekeerd vereist een goed begrip van de UN/EDIFACT standaard.

Ik zal hierna beknopt de UN/EDIFACT Standaaard proberen uit te leggen. Achtereenvolgens zullen de volgende onderwerpen aan bod komen:
- enkele belangrijke karakters
- de verschillende structuurelementen
- een beschrijving van de structuur
- de positiebepaling, status en herhalende factor van structuurelementen
- de compressieregels

enkele belangrijke karaktertekens
- Segment einde teken = apostrophe ‘

- Segment tag en data element separator = plus sign +

- Component data element separator = colon :

- Release character = question mark ? herstelt de betekenis van het daaropvolgend teken
Voorbeeld: 10?+10=20 betekent 10+10=20

de structuurelementen
De structuur van een EDIFACT bericht is vastomlijnd en bestaat uit een aantal verplichte en optionele elementen. De belangrijkste bouwsteen van een EDIFACT bericht is het segment en de structuur waaraan een bericht moet voldoen is daarom vastgelegd in segment tabellen. Deze tabellen beschrijven welke segmenten in een bericht voorkomen en in welke volgorde.

Een eenvoudig voorbeeld van zo’n segment tabel ziet er als volgt uit:

Extending Open Source tools with functionality for defining and executing message transformations from EDIFACT to other standards and back requires a good understanding of the UN/EDIFACT Standard.

Hereafter I will briefly explain the UN/EDIFACT standard and discuss the following topics:
- the different elements of the structure
- a description of the structure
- the position, status and repetition factor of the structure elements
- the compression rules

important character sets
- Segment terminator = apostrophe ‘

- Segment tag and data element separator = plus sign +

- Component data element separator = colon :

- Release character = question mark ? immediately preceding one of the characters ‘ + : ? restores their normal meaning.
Example: 10?+10=20 means 10+10=20

the structure elements
The structure of an EDIFACT message is fixed and contains a number of mandatory and conditional elements. The most important building block of an EDIFACT message is the segment and hence the structure is defined in segment tables. These tables show which segments are used in the message and the order in which the segments must occur.

A simple example of such a segment table looks as follows:

edifact-segment-table

Segmenten die bij elkaar horen kunnen worden gegroepeerd in een segment groep. Een segment groep bevat altijd een trigger segment en ten minste één of meer segmenten of segment groepen. Het trigger segment is een verplicht segment en moet eenmaal voorkomen. Het trigger segment is bovendien het eerste segment in de groep. Een segment wordt eenduidig geïdentificeerd door een segment tag en de positie in een bericht.

In bovenstaand voorbeeld is het segment met de segment tag RFF een trigger segment voor de segment groep 1 en eveneens voor de segment groep 3.

Een segment is een geordende verzameling van functioneel bij elkaar horende stand-alone of composite data elementen. Het segment BGM, zie voorbeeld hieronder, bestaat uit twee composite data elementen en twee stand-alone data elementen. Een composite data element is een samengesteld data element en bestaat uit een opeenvolging van data elementen.

Segments that belong together can be grouped in a segment group. A segment group always contains a trigger segment and at least one or more segments or segment groups. The trigger segment is a mandatory segment and must appear once. The trigger segment is always the first segment in the group.

A segment is uniquely identified using a segment tag and the position in the message.

In the above example the segment with the segment tag RFF is a trigger segment of the segment group 1 and also of the segment group 3.

A segment is a collection of logically related stand-alone or composite data elements in a fixed, defined sequence. The segment BGM, see example below, contains two composite data elements and two stand-alone data elements. A composite data element contains a combination of several data elements.

edifact-segment-bgm

Read more — Meer lezen

Transformatie van EDIFACT berichten met Open Source gereedschappen

De Economische Commissie voor Europa van de Verenigde Naties UN/ECE (United Nations Economic Commission for Europe) is midden de jaren ‘80 gestart met de ontwikkeling van de UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce and Transport) standaard voor EDI. In 1988 is de UN/EDIFACT standaard door de Internationale Organisatie voor Standaardisatie (ISO) overgenomen onder de ISO standard ISO 9735.

De UN/EDIFACT standaard is daarna gaandeweg uitgegroeid tot de internationale standaard voor Electronic Data Interchange. Maar met de opkomst van XML standaarden staat EDIFACT al enkele jaren sterk onder druk. Niettemin blijkt dat de UN/EDIFACT standaard wereldwijd nog steeds veelvuldig gebruikt en geïmplementeerd wordt.

De UN/EDIFACT standaard heeft zich naast de syntax vooral gericht op inhoudelijke standaardisatie, de semantiek. Daarin schuilt dan ook de kracht van EDIFACT.

De XML standaarden hebben vooral problemen met functionele standaardisatie. Een universele methodiek voor standaardisatie zoals de Core Components van de UN/CEFACT is nog niet algemeen geaccepteerd en doorgevoerd. Lees hierover meer in mijn bloart Hoe lossen we het interoperabiliteitsvraagstuk op ?. Hierdoor ontstaan verschillende onsamenhangende en incompatibele alsook gefragmenteerde standaarden.

De benadering die gevolgd wordt door ontwikkelaars van XML standaarden is scheiding van functionaliteit en techniek. De voorbije jaren heeft vooral de techniek van XML volop aandacht gekregen en de hoeveelheid Open Source gereedschappen voor het werken met XML is gigantisch toegenomen. Open Source transformatiegereedschappen waaronder XAware en Chainbuilder bieden helaas geen ondersteuning voor de UN/EDIFACT standaard of daarvan afgeleide standaarden. De aandacht voor de techniek van XML is de voornaamste reden hiervoor.

De noodzaak naar ondersteuning van de UN/EDIFACT standaard zal echter de komende jaren blijven bestaan. Vrij regelmatig wordt ik dan ook gevraagd wanneer deze functionaliteit beschikbaar komt. Open Source transformatiegereedschappen die hierin voorzien gaan sneller geadopteerd worden. Tevens zal de noodzaak naar commerciële EDIFACT vertaalsoftware dan verdwijnen.

Mogelijk zullen de aanbieders van deze commerciële transformatiesoftware overwegen, waarschijnlijk gebeurt dat nu al, om hun producten onder een Open Source licentie beschikbaar te stellen. Zo zouden bedrijven als Sun Microsystems en IBM een flink aandeel op dit domeingebied in de Open Source markt kunnen veroveren wanneer zij hun transformatiegereedschappen voor JCAPS (Sun) en voor WebSphere (IBM) zouden vrijgeven. De eerste stappen in die richting worden gezet. Sun Microsystems, de grote sponsor achter het Open Source project OpenESB, geeft aan in de toekomst componenten van OpenESB op te nemen in Java CAPS. Met de start van het Open Source project Fuji wordt een begin gemaakt met het ontwikkelen van Sun’s next generation open source integration runtime.

XAware en Chainbuilder zouden weleens het standaard transformatiegereedschap voor OpenESB kunnen worden. Ik heb me zelf opgeworpen om binnen de XAware community de kar te trekken voor de realisatie van EDIFACT transformatiefuncties en misschien is het mogelijk om gelijktijdig de oplossing voor Chainbuilder te realiseren.

The United Nations Economic Commission for Europe UN/ECE started in the mid’ 80 with the development of the UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce and Transport) standaard for EDI. In 1988 the UN/EDIFACT standaard has been adopted by the International Organisation for Standaardisation (ISO) under the ISO standard ISO 9735.

The UN/EDIFACT standard has gradually grown to the international standard for Electronic Data Interchange. But with the rise of XML standards EDIFACT is under pressure for several years now. However the UN/EDIFACT standard is still frequently being used and implemented globally.

The UN/EDIFACT standard has especially aimed, beside the syntax, on content standardisation, the semantics. In it the real power of EDIFACT hides.

The XML standards have especially problems with functional standardisation. A universal method for standardisation like the Core Components from UN/CEFACT has not been generally accepted and implemented. Please read more in my bloart How do we solve the interoperability question ?

Because of this several incoherent and incompatible as well as fragmented standards arise.

The approach that is followed by developers of XML standards is separation of functionality and technique.

The past years especially the technique of XML has got all the attention and the number of Open Source tools for working with XML has increased tremendous. Open Source transformation tools such as XAware en Chainbuilder unfortunately do not support the UN/EDIFACT standard or related standards. The attention for the technique of XML is the main reason for this.

The need for the UN/EDIFACT support standard will remain for the next few years. People ask me on a regular basis when this functionality will become available. Open Source transformation tools that provide this capability will be adopted much faster. The need for commercial EDIFACT translation tools will disappear.

Potentially vendors of commercial transformation software will consider, probably this already happens now, to make their products available under an Open Source license. Companies like Sun and IBM could gain a significant market share in this field area on the Open Source market if they would open up their transformation tools for JCAPS (Sun) and WebSphere (IBM). The first steps in that direction are made. Sun Microsystems, the important sponsor behind the Open Source project OpenESB, has announced to incorporate components of OpenESB in Java CAPS in the future. With the start of the Open Source project Fuji a beginning is made with the development of Sun’s next generation open source integration runtime.

XAware and Chainbuilder could eventually become the standard transformation tool for OpenESB. I have put myself forward in the XAware community (as ’sponsor’ in) driving this to realize EDIFACT transformation functions and perhaps in the meantime it is possible to realize a solution for Chainbuilder as well.

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.

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 invocing:
- 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.

Read more — Meer lezen

UN/EDIFACT BIM Framework

Het UN/EDIFACT BIM Framework (Business and Information Modelling Framework) is een gestructureerde aanpak voor de ontwikkeling en beschrijving van EDI berichten. Het Framework richt zich alleen op die aspecten van bedrijfsprocessen waarbij twee of meer partners interactie hebben binnen een specifiek domein.

Electronic Data Interchange (EDI), is een generieke term en betekent de elektronische of geautomatiseerde uitwisseling van gestructureerde gegevens tussen twee onafhankelijk van mekaar ontworpen informatiesystemen. EDI gaat niet enkel over het doorzenden van gegevens maar veronderstelt de automatische verwerking, integratie, van deze gegevens in het informatiesysteem van de ontvangende partij, zonder menselijke tussenkomst.

Het BIM Framework is ontwikkeld door de UN/EDIFACT Business Information Modelling group. Voor de ontwikkeling van berichtdefinities is gekozen voor een top-down benadering om te komen van bedrijfsprocessen tot formele gestructureerde activiteiten en gegevens.

Het Framework bestaat uit 3 fasen:
1. Business Analyse fase
2. EDI Requirements fase
3. Message Design fase

In de Business Analyse fase worden de eisen en wensen gesteld vanuit het bedrijfsproces in kaart gebracht en vastgelegd in conceptuele modellen. De modellen beschrijven een systeem- en organisatie- overschrijdend proces (inter-enterprise business process).

De interactie tussen verschillende partners in organisaties wordt weergegeven in een Activity Model en in een Data Model.

In het activiteitenmodel worden de stappen waaruit het proces bestaat, de informatie die per stap moet worden uitgewisseld en de verschillende actoren (rollen) weergegeven. Het activiteitenmodel bevat de bedrijfsfuncties en de informatiestromen. Initieel worden de bedrijfsfuncties op een hoog niveau vastgelegd en daarna verder uitgewerkt tot op het activiteitenniveau.

Het informatiemodel beschrijft de objecten (entiteiten), de attributen (eigenschappen) en de onderlinge relaties (associaties). De relaties tussen de verschillende objecten kunnen in een entiteit-relatiemodel worden weergegeven maar kunnen ook eenvoudig in woorden worden uitgedrukt. Belangrijk is dat voldoende aandacht wordt besteed aan de cardinaliteit, hoeveel entiteiten of instanties kunnen met een andere entiteit verbonden zijn. Vooral de maximale cardinaliteit is essentieel, meestal is deze 1 of N.

Wanneer we het inkoop- en verkoopproces van producten beschouwen dan zien we op hoog niveau de bedrijfsfuncties: inkoop, verkoop, logistiek en financiën. Deze kunnen verder uitgesplitst worden naar de processtappen: aanvragen van offertes, offreren, bestellen, leveren, ontvangen, factureren en betalen.

De informatiestromen / documenten die voortkomen uit de verschillende processtappen zijn respectievelijk: offerteaanvraag, offerte, bestelaanvraag, inkooporder, orderbevestiging, pakbon, ontvangstmelding, factuur en betaalopdracht.

De voornaamste objecten zijn: klant, leverancier, inkooporder, verkooporder, product, levering, factuur.

De mogelijke relaties zijn: elke inkooporder resulteert in één verkooporder, elke factuur bevat slechts één inkooporder, elke levering bestaat uit één of meer inkooporders. De relaties tussen inkooporder, verkooporder en factuur wordt vaak opgelegd door de beperkingen van informatiesystemen. Zo is het in een aantal ERP - systemen niet mogelijk om meerdere inkooporders te koppelen aan één verkooporder en omgekeerd.

In de EDI Requirements fase worden de modellen van de voorgaande fase verder uitgediept voor de activiteiten die ondersteund moeten worden door EDI Berichten.

De resultaten van de EDI Requirements fase zijn: EDI Supported Activity Model en EDI Message Data Model.

Het EDI Supported Activity Model specificeert welke activiteiten gegevens genereren en gebruiken, de volgorde waarin dat gebeurt en de regels die verbonden zijn aan de uitwisseling van gegevens. Het EDI Supported Activity Model bevat alle door EDI ondersteunde activiteiten en is in feite een grafisch overzicht van het EDI Scenario tussen twee of meer partners.

Het EDI Message Data Model definieert de gegevens, de attributen en de relaties die moeten worden opgenomen in de EDI berichten. In het EDI Message Data Model wordt aangegeven welke gegevenselementen verplicht, optioneel of conditioneel zijn en de minimum / maximum cardinaliteit.

Het EDI Supported Activity Model voor het inkoop- en verkoopproces ziet er zo uit:
edisupportedactivities

Een EDI Message Data Model voor de inkooporder bevat ondermeer volgende gegevens:
- OrderNummer (M, 1/1)
- OrderDatum (M, 1/1)
- KlantNummer (M, 1/1) volgens afgesproken codering
- LeverancierNummer (M, 1/1) volgens afgesproken codering
- ContractNummer (O, 0/1)
- OfferteNummer (O, 0/1)
- Inkoper ID (M, 1/1)
- OrderValuta (M, 1/1)
- AfleverAdres (M, 1/1)
- FactuurAdres (M, 1/1)
- FactuurValuta (C, 0/1)
De FactuurValuta is conditioneel en wordt alleen meegegeven als deze afwijkt van de OrderValuta.
- Totaal Factuurbedrag (M, 1/1) uitgedrukt in OrderValuta
- Totaal BTW-bedrag (M, 1/1)
- Betalingsconditie (M, 1/1)
- Betalingstermijn (M, 1/1)

(m = mandatory, o = optioneel, c = conditioneel)

In de Message Design fase worden de UN/EDIFACT Message Design Guidelines toegepast om de EDI Data Requirements te vertalen naar een UN Standard Message (UNSM). Het EDI Supported Activity Model wordt gebruikt om het doel en het bereik van de UNSM te benoemen. De resultaten van de Message Design fase zijn de UN/EDIFACT Message (UNSM), segmenten, (samensgestelde) data elementen, codes (value sets) en gebruikersdocumentatie.

Continue verbetering van de modellen:
Het activiteitenmodel en het datamodel worden tijdens elke fase van het Business Modelling Framework vergeleken met voorgaande fasen en waar nodig vinden aanpassingen plaats. Gedurende het proces worden de resultaten continue getoetst aan de wensen en eisen vanuit de bedrijfswereld om ervoor te zorgen dat de modellen een juiste en volledige weergave zijn van de werkelijkheid.

Het spreekt voor zich dat gedurende het proces verschillende disciplines een bijdrage leveren aan het tot stand komen van de modellen. In de eerste fase zijn dat vooral mensen uit het bedrijfsleven met kennis van het specifieke domein, daarbij geholpen door een business analist. De tweede fase is het werkterrein van een informatieanalist. Terwijl de derde fase wordt afgehandeld door de UN/EDIFACT Message Design expert.

Het Business Information Modelling Framework dateert van januari 1996 en is overigens gebaseerd op de EDIFICE (the European B2B Forum for the Electronics Industry) Business and Information Modelling Guideline van 1994.
EDIFICE heeft in 1994

My Zimbio I Flock
Copyright © 2000 - DanGa Design