Beheermodel Semantisch Model e-factuur

Transcriptie

1 Beheermodel Semantisch Model e-factuur Versie 1.4 Datum Januari 2016 Status Concept

2 Colofon Stuurgroep Contactpersoon Organisatie Semantisch Model e-factuur Jaap van der Marel NEN Postbus GB Delft Documentbeheer Datum Versie Auteur Opmerkingen S. Westerfield Eerste gedeelde versie S. Westerfield Uitbreiding met hoofdstuk versiebeheer O. Rutten Tekstuele wijzigingen O. Rutten Verwerken van de reviews S. Westerfield Eerste publicatie S. Westerfield Div tekstuele wijzigingen M. van Drunen Wijzigingen consultatie Logius Finale controle JP Bakkers Concept versie ter bespreking versie JP Bakkers Definitieve versie Stuurgroep SMEF Vastgesteld door Stuurgroep concept M. Stornebrink Aanpassing nav nieuwe beheerorganisatie en feedback SG Pagina 2 van 15

3 Inhoud Colofon... 1 Inhoud Introductie en doelstelling Intellectueel eigendom Doelstelling beheer Scope beheer SMeF begrippenkader SMeF mappings Beheerorganisatie Stuurgroep Werkgroep Wijzigingsproces Wijzigingsproces Wijzigingsvoorstel Klachtenprocedure Publicatiekanalen Visie en financiering Visie Financiering Versiebeheer Uitgangspunten versiebeheer Tijdslijnen uitbrengen SMEF standaarden Onderhoud en support van oudere versies Statusveranderingen van de SMeF standaard Openbare consultatie Pagina 3 van 15

4 1 Introductie en doelstelling 1.1 Intellectueel eigendom Het Semantisch Model e-factuur (SMeF) wordt beschikbaar gesteld onder een Creative Commons zero (CC0) licentie. Deelnemers aan het beheerproces leveren onherroepelijk en royalty-vrij een bijdrage aan de ontwikkeling van het SMeF. 1.2 Doelstelling beheer SMeF is een begrippenkader waarin begrippen worden geïdentificeerd en gedefinieerd die noodzakelijk zijn voor elektronisch factureren (en in bredere zin communicatie). SMeF richt zich op het bevorderen van de interoperabiliteit tussen overheid en bedrijfsleven (B2G) en tussen bedrijven en overheden onderling (B2B, G2G). De bijdrage van SMeF in het oplossen van interoperabiliteitsproblemen is het eenduidig vastleggen van de semantiek van elementen in elektronische facturen en faciliteren van transformaties tussen verschillende standaarden (mappings). SMeF is het Nederlandse referentiemodel voor efacturatie. De doelstelling van het beheer is om de SMeF standaard tijdig en van voldoende kwaliteit ter beschikking te stellen aan de gebruikers van de standaard, conform openheidprincipes. SMeF en het beheer hiervan staan los van de implementatie in voorzieningen die gebruik maken van SMeF (bijvoorbeeld DigiInkoop). 1.3 Scope beheer Het begrippenkader is het hart van SMEF, maar ook mappings met factuurstandaarden, handleidingen en voorbeeld berichten zijn onderdeel van SMeF en vallen onder het beheer. De stuurgroep SMeF is verantwoordelijk voor het gehele beheer. SMeF BEHEER Mappings SMeF begrippenkader Handleidingen Voorbeeld berichten... Figuur 1: Beheer scope SMeF stuurgroep Het beheer van SMeF betreft daarnaast het bewaken van de juiste toepassing van de semantische standaard en de vertaling daarvan naar het syntactisch gebruik er van SMeF begrippenkader Het uitwisselen van elektronische berichten (bestellingen, facturen, et cetera) bij het uitvoeren van bedrijfsprocessen gebeurt al sinds de jaren 80. Om door een computer verwerkt te kunnen worden moet expliciet vastgelegd worden welke informatie in een bericht zit, en hoe deze Pagina 4 van 15

5 vastgelegd is. Een (factuur) bericht is feitelijk niet veel meer dan een verzameling (informatie) elementen die geordend zijn in een boomstructuur. In een berichtenstandaard zijn vastgelegd: De semantiek van het bericht. Voor elk element in het bericht staat (in natuurlijke taal) beschreven wat de betekenis van dit element is. De syntax van het bericht. Oftewel: wat is de structuur waarin de elementen uitgewisseld worden, waar staat welke informatie. Een standaard die XML gebruikt om de syntax in uit te drukken zal typisch voor elk element het X-path geven. Hiermee is het voor ontwikkelaars duidelijk waar in het bericht een element geplaatst kan worden. Een dergelijke standaard komt doorgaans in de vorm van een PDF of excel document (waarin voor elk element de semantiek vastgelegd is) en - bij XML gebaseerde standaarden- een XML schema (XSD). Dit geldt o.a. voor UBL, S@les, SimplerInvoicing, SETU, etc. Het grote verschil tussen SMeF en andere standaarden, is dat de SMeF standaard zelf alléén semantiek beschrijft en geen syntax. Voor laatst genoemde zijn de mappings beschikbaar naar andere standaarden (Simplerinvoicing, SETU, S@les, e.a.). SMeF richt zich primair op de kernfactuur -elementen, die onafhankelijk zijn van een specifieke sector. Dit in tegenstelling tot een sectorale standaard waarin ook sectorspecifieke zaken zijn beschreven SMeF mappings De bijdrage van SMeF in het oplossen van interoperabiliteitsproblemen is het eenduidig vastleggen van de semantiek voor factuurberichten. Dit is in zichzelf al waardevol, want bij (met name) internationale standaarden zoals UBL is de betekenis lang niet altijd duidelijk (in de Nederlandse context). Daarnaast kunnen zogenaamde mappings worden gemaakt van verschillende factuurstandaarden (UBL, SI, SETU, S@les) naar SMeF. Deze combinatie (begrippenkader én mappings) opent de volgende gebruiksmogelijkheden: Als éénmalig is uitgezocht / vastgelegd op welke wijze elementen uit SMeF terug moet komen in IT applicatie, dan is het veel eenvoudiger om nieuwe standaarden toe te voegen (als deze een mapping naar SMeF hebben). Immers: de grote complexiteit van het toevoegen van nieuwe standaarden in een IT systeem zit in het uitzoeken en overbruggen van semantische verschillen, maar dat is reeds gedaan bij het maken van de mapping tussen de standaard en SMeF De mapping van verschillende standaarden naar SMeF kan gebruikt worden om transformaties tussen formaten mogelijk te maken. SMeF is dan het gezamenlijk model (het zogenaamde canonical data model ). Opgemerkt wordt dat het opstellen van mappings naar andere (sectorale) standaarden wel geïnitieerd wordt vanuit SMeF, maar het beheer van deze mappings is belegd bij de beheerders van de (sectorale) standaard. Zij beschikken immers over sectorkennis. Ondersteuning daarbij door de beheerorganisatie van SMeF behoort wel tot de mogelijkheden. Pagina 5 van 15

6 Figuur 2: SMeF: Connecting einvoicing standards SMeF is hiermee de linking pin tussen generieke en sector specifieke initiatieven. Hiermee is SMeF dus ook nadrukkelijk niet alleen voor facturatie richting overheden (B2G), maar juist ook voor private ondernemingen bedoeld (B2B). Pagina 6 van 15

7 2 Beheerorganisatie De volgende rollen worden onderscheiden in de beheerorganisatie: Rol Beleidsopdrachtgever Definitie De Beleidsopdrachtgever is de opdrachtgever voor het beheer van SMeF, in casu het Ministerie van Economische Zaken (EZ). Stuurgroep De Stuurgroep neemt besluiten over de strategische richting van het model, de prioriteit en doorgang van wijzigingen, nieuwe versies en dergelijke. De Stuurgroep geeft sturing aan de Werkgroep. De beleidsopdrachtgever zit in de Stuurgroep. Werkgroep De Werkgroep bestaat uit een team van experts van de beheerder en vanuit Deelnemers - en verwerkt ingediende wijzigingsvoorstellen en produceert een nieuwe versie van de standaard. De Werkgroep wordt samengesteld op basis van de expertise rondom e-factureren, voorgezeten door de uitvoerend beheerder en werkt in opdracht van de Stuurgroep. Uitvoerend beheerder De uitvoerend beheerder, in casu NEN (inhoudelijk ondersteund door TNO), beheert SMeF en zorgt voor de taken rondom het strategisch, tactisch, operationeel beheer, voor de ondersteuning en voor de communicatie. De uitvoerend beheerder rapporteert aan de Stuurgroep. Deelnemer De Deelnemer neemt deel aan een van de onderdelen binnen de beheerorganisatie. Dit kan een overheidsorganisatie, kennisorganisatie, branche-organisatie of een bedrijf zijn die e- facturen verstuurt of ontvangt. Een deelnemer kan namens zich zelf of namens een derde wijzigingsvoorstellen op de standaard indienen. 2.1 Stuurgroep De Stuurgroep bestaat uit leden die SMeF kunnen uitdragen en organisaties aan zich kunnen binden. De Stuurgroep behartigt daarmee de belangen van de primaire stakeholders, in casu de industrie en de overheid. De Stuurgroep toetst periodiek de effectiviteit, continuïteit en afspiegeling. Een onafhankelijke deskundige is de voorzitter en de uitvoerend beheerder voert het secretariaat. De Stuurgroep besluit zelf over haar samenstelling. Stuurgroepleden hebben zitting voor bepaalde tijd. De Stuurgroep bewaakt de aansturing, samenstelling en adequaat functioneren van de Werkgroep. Pagina 7 van 15

8 De Stuurgroep komt drie keer per jaar bij elkaar. De Stuurgroep kan eventueel ook per conference call vergaderen of besluiten per nemen. Bij gelijk aantal voor- en tegenstemmen heeft de voorzitter de finale stem. 2.2 Werkgroep De Werkgroep bestaat uit de uitvoerend beheerder in de rol van voorzitter en experts vanuit deelnemers. Het staat de Werkgroep vrij om, indien nodig, extra expertise te betrekken. De Werkgroep werkt onder opdrachtaansturing van de Stuurgroep. In principe nemen Werkgroepleden niet plaats in de Stuurgroep of omgekeerd. De frequentie van de Werkgroep wordt bepaald door de Werkgroep zelf in relatie tot de opdracht die het van de Stuurgroep heeft gekregen. Bij knelpunten richt de Werkgroep zich tot de Stuurgroep of desbetreffend Stuurgroeplid. De Werkgroep wordt in overleg met de Stuurgroep ingesteld. Pagina 8 van 15

9 3 Wijzigingsproces Dit hoofdstuk beschrijft het proces ten aanzien van wijzigingsvoorstellen op SMeF. Het wijzigingsproces bestaat uit een functioneel / business aspect en een inhoudelijk / technisch aspect. De uitvoerend beheerder registreert alle wijzigingsverzoeken. Verzoeken tot uitbreidingen en verbredingen van de SMeF standaard en bijvoorbeeld Europese ontwikkelingen gaan altijd via de Stuurgroep. De Werkgroep geeft impactbepaling en het bijbehorende advies over voorliggende wijzigingsvoorstellen aan de Stuurgroep. De Stuurgroep bepaald het versiebeleid. De Werkgroep levert in opdracht van de Stuurgroep, op vaste momenten, één versie per jaar op tenzij anders bepaald. 3.1 Wijzigingsproces 1. Wijzigingsverzoeken (open voor iedereen) worden ingediend bij de Uitvoerend Beheerder (via de secretaris van de Stuurgroep, of via de Website). In een wijzigingsvoorstel staat een omschrijving van de reden van het verzoek en de verwachte (business) voordelen. 2. De Beheerder houdt een lijst van de wijzigingsverzoeken bij en specificeert de verzoeken. 3. De uitvoerend beheerder bepaalt de impact van een wijziging in termen van benodigde aanpassingen aan het Semantisch Model e- Factuur en kan daarbij de werkgroep betrekken, en stelt een advies voor de Stuurgroep op. 4. De Stuurgroep bepaalt de relevantie en de prioriteit van de wijzigingsverzoeken op basis van enkele criteria, waaronder de ondersteuning van huidige en toekomstige B2G en G2G processen, Europese ontwikkelingen op e-facturen vlak, backwards compatibiliteit en stabiliteit. De Stuurgroep wordt hierin geadviseerd door de Werkgroep. a. Indien de Stuurgroep een verzoek tot wijziging relevant vindt, krijgt de Werkgroep de opdracht om de wijziging door te voeren. De door de Stuurgroep bepaalde prioriteit is bepalend voor de volgorde waarin de wijzigingen worden ingepland. b. Indien de Stuurgroep een verzoek tot wijziging niet relevant vindt, wordt deze met een motivatie afgewezen. In de afwijzing staat helder aangegeven hoe de belangen/impact van alle betrokkenen zijn meegewogen. Een bezwaar in dienen tegen de afwijzing is niet mogelijk. Wel kan een indiener een nieuw wijzigingsvoorstel indienen met een andere/uitgebreidere onderbouwing. 5. De Beheerder zorgt voor publicatie van de nieuwe versie via de daarvoor ingerichte website en eventuele overige kanalen. Pagina 9 van 15

10 3.2 Wijzigingsvoorstel Een wijzigingsvoorstel kent de volgende informatie-elementen. Per element wordt aangegeven wie deze informatie aanlevert. Indiener Stuurgroep Werkgroep Uitvoerend beheerder Onderwerp X Aanleiding X Doelgroep X Verwachte X voordelen (kwalitatief en kwantitatief) Nummer X Impact Analyse (Advies) X Inhoudelijke oplossing (Advies) X Prioriteit X (Advies) Versie nummer X model Motivatie afwijzing X (Advies) 3.3 Klachtenprocedure De ingang voor klachten is de secretaris van de Stuurgroep. De klachten worden afgehandeld via de Stuurgroep. Pagina 10 van 15

11 4 Publicatiekanalen De uitvoerend beheerder maakt de nodige producten vanuit het SMeF stelsel openbaar en makkelijk toegankelijk. Het gaat daarbij om: het Semantisch Model e-factuurmodel (de huidige versie en eventuele voorgaande versies); het beheerproces: de wijze waarop wijzigingsvoorstellen kunnen worden ingediend, hoe erover wordt beslist en welke stappen worden genomen alvorens een wijziging wordt goedgekeurd of afgekeurd. (Dit document); de agenda en de notulen van de vergaderingen van de Stuurgroep rondom nieuwe versies en goedkeuringen of afwijzingen van wijzigingsvoorstellen; de resultaten van de Werkgroep; de tijdsplanning rondom een nieuwe versie en welke wijzigingen daarin worden meegenomen; de ingediende wijzigingsvoorstellen en de status van de voorstellen; een bezettingsoverzicht van de Stuurgroep- en Werkgroepleden met hun organisatie. De uitvoerend beheerder, maakt de genoemde informatie openbaar via de website van SMeF. Pagina 11 van 15

12 5 Visie en financiering 5.1 Visie De Stuurgroep stelt een visie vast met daarin de doelen voor een aantal jaar. Vanuit deze visie stelt de Stuurgroep jaarlijks een jaarplan vast. Het uitbrengen en onderhouden van het Semantische Model e-factuur is onderdeel van deze visie. De Stuurgroep kan uit deze visie de criteria afleiden die gebruikt gaan worden voor het nemen van besluiten over het uitbrengen van nieuwe versies van Semantisch Model e-factuur en de wijzigingen die daarin worden meegenomen. 5.2 Financiering Financiering voor het beheer van SMeF is tot en met 2017 verschaft door de beleidsopdrachtgever, het Ministerie van Economische Zaken. In 2017 wordt gekeken in welke vorm en met welke financiering het SMeF gecontinueerd wordt. Pagina 12 van 15

13 6 Versiebeheer Onder versiebeheer wordt het systematische proces van uitbrengen van standaarden, richtlijnen en aanbevelingen voor gebruik van de standaarden verstaan. Versiebeheer is ook het vernieuwen en het vervangen van uitgebrachte versies van deze documenten. 6.1 Uitgangspunten versiebeheer De volgende uitgangspunten gelden voor het uitbrengen van een nieuwe versie van SMeF: Een nieuw uit te brengen versie brengt verbeteringen met zich mee die van belang zijn voor de Nederlandse overheid en/of bedrijfsleven rondom het elektronisch factureren. Voor stabiliteit wordt de hoeveelheid nieuwe versies zoveel mogelijk beperkt. Het ontwikkelschema van SMeF beheer staat los van het ontwikkelschema van de verschillende factuur formaatstandaarden die gerelateerd zijn aan SMeF. Nieuwe versies van deze factuur formaatstandaarden, zoals UBL, SETU en CEN CII, zullen dus niet automatisch leiden tot een nieuwe versie van het SMeF. Het effect van deze nieuwe versies en de toegevoegde waarde voor de Nederlandse overheids- en bedrijfsleven met betrekking tot elektronisch factureren wordt daarvoor nagegaan. Wijzigingen in SMeF hebben impact op mappings en andere aanvullende documentatie. De uitvoerend beheerder zorgt er voor dat de wijzigingen goed gedocumenteerd zijn en dat de potentiële gevolgen van de wijzigingen voor de gebruiker zo goed mogelijk in kaart zijn gebracht. Dit betekent dat de relatie tussen de versie van een standaard eenduidig en duidelijk zijn vastgelegd. 6.2 Tijdslijnen uitbrengen SMEF standaarden De beheerorganisatie werkt met drie types releases van de standaard. Dit zijn de volledige, of major, releases (1.0, 2.0, enz.), punt releases (1.1, 1.2, enz.) en punt punt releases (1.1.1, 1.2.1, enz.). Punt releases zijn minor releases met aanpassingen en uitbreidingen ten opzichte van de volledige release. Dit kunnen bijvoorbeeld updates zijn. Punt punt releases kunnen bijvoorbeeld typefouten of toevoegingen van tekst en uitleg zijn. Punt releases zijn in principe backwards compatible met de voorgaande release waar ze bij horen. Dat betekent dat er in principe alleen functionaliteit kan worden toegevoegd. Volledige releases bevatten grote wijzigingen ten opzichte van de vorige volledige (of punt (punt)) release en zijn niet per definitie backwards compatible. Voor het uitbrengen van releases van de berichtenstandaard gelden een aantal richtlijnen met betrekking tot het te volgen tijdsschema: Er is maximaal één major release per twee jaar en één minor release per jaar, tenzij er een noodzaak bestaat tot meer releases. De Stuurgroep SMeF is in dit kader het besluitvormende orgaan; Een nieuwe major of minor release wordt ruim van tevoren aangekondigd; De input voor een nieuwe release wordt enige tijd voor het uitbrengen van de nieuwe versie stopgezet. Input welke te laat binnen komt wordt verwerkt in een volgende versie. Pagina 13 van 15

14 6.3 Onderhoud en support van oudere versies Na het uitbrengen van een nieuwe versie van de standaard, blijft de oude versie nog beschikbaar voor eventuele gebruikers. Deze wordt echter niet meer actief onderhouden. Een versie van SMeF dwingt daarmee niet direct een overstap af bij de eindgebruiker. Ten aanzien van onderhoud en support op een oude versie gelden de volgende uitgangspunten: Oude versies worden niet door de beheerder onderhouden. Wel worden deze in een archief beschikbaar gesteld. De beheerder ondersteunt in principe één versie van de SMeF standaard. Na uitbrengen van een nieuwe versie wordt geen nieuwe functionaliteit toegevoegd aan een oude versie. Verzoeken om aanpassing en wijziging omwille van het toevoegen van nieuwe functionaliteit op verouderde versies worden dan ook niet meer in behandeling genomen. Correctieve wijzigingen en veranderingen van wettelijke bepalingen die invloed hebben op de standaarden zullen worden doorgevoerd en leiden tot een punt-punt update. 6.4 Statusveranderingen van de SMeF standaard De ingebrachte wijzigingsvoorstellen tot aanpassingen en toevoegingen aan een standaard leiden tot SMeF werkproces waarbij een standaard van een huidige versie overgaat in een nieuwe versie. De SMeF standaard doorloopt daarbij een aantal statussen, voordat deze uiteindelijk een finale status krijgt en wordt gepubliceerd door de uitvoerend beheerder. In onderstaande tabel is dit proces in een aantal sequentiële stappen uitgewerkt en nader uitgelegd. Deze stappen leiden telkens tot een statusverandering van het document dat de standaard beschrijft: Status standaard PROPOSAL DRAFT FINAL DRAFT Beschrijving activiteiten De PROPOSAL is het eerste voorstel dat de Beheerder opstelt en beschikbaar is voor de Werkgroep. De oplossingen en uitwerkingen van beschikbare wijzigingsverzoeken zijn hierin opgenomen. Dit document komt beschikbaar na één of meerdere versies van de PROPOSAL. De Werkgroep stelt het aan alle Deelnemers van de Werkgroep beschikbaar om het te bespreken en te reviewen. De Werkgroep ontvangt het commentaar en verbetert de DRAFT totdat alle opmerkingen, discussiepunten en feedback van de Deelnemers zijn verwerkt. Mocht discussie leiden tot sterk vernieuwde of aangepaste inzichten, dan kan de Werkgroep besluiten een nieuwe PROPOSAL op te (laten) stellen. De Werkgroep geeft goedkeuring aan de DRAFT. De FINAL DRAFT komt beschikbaar na één of meerdere versies van de DRAFT. De Werkgroep biedt de FINAL DRAFT aan de Stuurgroep ter goedkeuring aan, waarna deze in openbare consultatie wordt gezet (zie volgende paragraaf). De Werkgroep ontvangt eventueel commentaar en opmerkingen en verbetert de FINAL DRAFT tot alle opmerkingen, discussiepunten en feedback zijn verwerkt. Mocht discussie leiden tot sterk Pagina 14 van 15

15 RELEASE vernieuwde of aangepaste inzichten, dan kan de Werkgroep besluiten een nieuwe DRAFT versie op te stellen. De RELEASE is de laatste actuele versie die de Stuurgroep heeft goedgekeurd en die uitvoerend Beheerder op de openbare website publiceert. Op deze versie wordt onderhoud gepleegd en support geleverd, totdat er een nieuwere versie verschijnt. 6.5 Openbare consultatie Nadat de werkgroep zijn goedkeuring heeft gegeven aan een (Final) Draft versie van een standaard, zal deze openbaar geconsulteerd worden. Het doel van de consultatie is om alle belanghebbenden de mogelijkheid te geven om op- en aanmerkingen te maken op de nieuwe versie, nog voordat deze vrijgegeven wordt. Alle opmerkingen uit de consultatie zullen in behandeling genomen worden, en kunnen mogelijk leiden tot aanpassingen van de Draft. Grote wijzigingen zullen met de werkgroep besproken worden. Een consultatieronde heeft de duur van één maand. Pagina 15 van 15