Scope en breder gebruik van het factuurmodel
|
|
- Godelieve Irma Bogaerts
- 8 jaren geleden
- Aantal bezoeken:
Transcriptie
1 Memorandum Aan Menno van Drunen, Sierd Westerfield, Logius Jan Julianus, Erik Wijnen, Min. EL&I Van Onderwerp Suggesties voor vervolgstappen semantisch factuurmodel Capitool PL Enschede T F jack.verhoosel@tno.nl Aanleiding TNO heeft in opdracht van Logius een Aanzet tot een semantische specificatie voor e-facturen ([ASSEF]) gemaakt en zich daarbij conform de opdracht gebaseerd op de functionele specificaties van facturen zoals beschreven in [FMEBF] en (vooral) de wet (op de Omzetbelasting). Daarnaast heeft TNO gekeken naar een afbeelding van het functionele factuurmodel uit [FMEBF] naar een Europees Core Invoice factuurmodel dat door CEN is vastgelegd [CEN-CI]. Doorkiesnummer We hebben vastgesteld dat de specificaties uit [FMEBF] ontoereikend zijn om aan de wet (op de Omzetbelasting) te voldoen. De specificaties lijken gebaseerd te zijn op minder geschikte ontwerpparadigma s en vertonen inconsistenties met andere ontwerpdocumenten 1. Daarnaast zijn er de nodige verschillen tussen het NL factuurmodel en het CEN-CI factuurmodel die in een volgende versie opgelost zouden moeten worden. Dit is voor Menno van Drunen (Projectmanager DigiInkoop / e-factureren) aanleiding geweest TNO te vragen aanbevelingen te doen ter verbetering. Deze memo bevat de visie en aanbevelingen van TNO met betrekking tot een vervolgversie. Scope en breder gebruik van het factuurmodel Volgens het Besluit Digipoort voor e-facturen [BDeF] moeten elektronische facturen (e-facturen) vanaf 1 januari 2011 via Digipoort ontvangen kunnen worden en in behandeling genomen door het ministerie dat het aangaat. De specificatie voor e-facturen, die volgens [BDeF] door de Staat wordt bepaald, bevat alle regels (eisen, afspraken) waaraan betrokkenen zich dienen te houden teneinde e-facturen te kunnen verwerken. Bijgevolg moet zo n specificatie tenminste een syntactische en een semantische component bevatten (zie hoofdstuk 1.3 [ASSEF] voor meer details hieromtrent en hoofdstuk 1.1 voor de problematiek). Het doel van dit Besluit is dus om afspraken te maken voor standaarden voor e-factureren om zodoende de semantische interoperabiliteit en de samenwerking tussen facturerende/betalende partijen te optimaliseren. 1 Deze en andere ervaringen zijn (deels) beschreven in de Discussie paragrafen van [ASSEF].
2 De semantische component bevat regels die de betekenis specificeren van (factuur)gegevens in termen van wat ermee moet kunnen worden gedaan. Semantische regels stammen uit verschillende bronnen, waaronder: 2/9 afspraken zoals we die in de B.V. Nederland met elkaar hebben gemaakt en (dus) wettelijk zijn vastgelegd. Voorbeeld: een factuurdatum is de datum waarop de factuur is c.q. wordt uitgereikt (bron: Wob68). afspraken die voor een of meer belanghebbenden nodig zijn om een of meer processen uit te kunnen voeren. Voorbeeld: een factuurdatum is de datum waarop de factuur is aangemaakt (belanghebbende = leverancier; bron = diens facturatie proces). Ander voorbeeld: een factuurdatum is de datum waarop de factuur is ontvangen (belanghebbende = klant; bron = diens betalingsproces). afspraken c.q. voorwaarden die door de ene belanghebbende aan een andere worden opgelegd en als zodanig ook bekend staan als voorwaarden ; vaak hebben die met het afdekken van risico s te maken. Voorbeeld: de factuur moet binnen 30 dagen na de factuurdatum zijn betaald (belanghebbenden zijn leverancier en klant; de regel beoogt liquiditeitsproblemen bij de leverancier te voorkomen door de klant te verplichten tijdig te betalen). Dit soort (ook semantische) regels kun je generiek vastleggen, of je kunt ervoor kiezen deze per geval af te spreken, bijvoorbeeld door ze als voorwaarde in de factuur of in een contract op te nemen. Het probleem van semantische interoperabiliteit kan op basis hiervan als volgt worden geformuleerd. Elke verwerker van facturen kent een eigen semantiek, bestaande uit alle regels volgens welke (gegevens uit) de factuur door hem wordt verwerkt (aangemaakt, gebruikt, veranderd of verwijderd). Deze regels komen uit de wetgeving waaraan die specifieke verwerker moet voldoen, uit het bedrijfsproces waarin door middel van facturen verrekend wordt en uit maatregelen die de verwerker besloten heeft te implementeren teneinde risico s die aan de verwerking kleven, te mitigeren. Twee verwerkers zijn semantisch interoperabel met betrekking tot facturen als elke factuur die zij elkaar sturen voldoet aan zowel alle semantische regels van de een als aan die van de ander en dat ze deze regels kennen, begrijpen en er naar handelen. In de praktijk wordt de term factuur voor semantisch verschillende concepten gebruikt. Een zogenaamde pro-forma factuur bijvoorbeeld hoeft niet aan de semantische specificaties (voor facturen) van de belastingdienst te voldoen; datzelfde geldt voor een voorstel factuur. Hieruit concluderen we dat het opschrijven van een volledig dekkende semantische beschrijving, als losstaand document niet nuttig en dus ook onwenselijk is. Immers, er zijn diverse processen waarin verschillende vormen van facturen gebruikt worden en het hebben van één enkele volledig dekkende beschrijving zou werk opleveren voor elke partij die iets met e-facturen doet. Dat is niet geheel in lijn met onder meer het in [BSF2009] genoemde besluit om de regels voor elektronisch factureren sterk te vereenvoudigen en de vormgeving en implementatie van oplossingen voor elektronisch factureren aan marktpartijen over te laten.
3 Het is aan te raden om de semantische specificaties zodanig op te stellen dat het leeuwendeel van de facturen, dat relatief eenvoudig is, ook eenvoudig gespecificeerd kan worden zoals aangegeven in [WEEF] of met behulp van een sjabloon als [FFUBL]. Wel moet het mogelijk zijn om specialisaties van deze eenvoudige semantiek te definiëren, zoals voor producten c.q. diensten waarvoor (ook) specifiekere wetgeving bestaat (bijvoorbeeld energielevering), of als overheidspartijen of partijen uit het bedrijfsleven processen hebben van waaruit additionele eisen aan facturen gesteld moeten kunnen worden (zoals bij import). 3/9 Op basis van het voorgaande bevelen we aan om verschillende soorten e- Factuurmodellen te ondersteunen voor specifieke doeleinden en die modellen specialisaties te laten zijn van één basis factuurmodel. Een factuurmodel structuur hiervoor voldoet aan de volgende criteria (eisen, specificaties): C1: Voor elk type factuur bestaat precies één (expliciete) specificatie van: (a) het doel dat met facturen van dat type wordt nagestreefd (i.e. waartoe zulke facturen bestaan) (b) de verzameling van factuur types waarvan het een specialisatie is; (c) de verzameling van (soorten) belanghebbenden en processen voor welke de specificatie relevant is; (d) de syntactische en semantische regels die, naast alle syntactische en semantische regels van elk factuur type waarvan het gespecificeerde factuur type een specialisatie is (zoals bedoeld onder (b)), specifiek voor het gespecificeerde factuurtype gelden. C2: Er bestaat precies één type factuur die geen specialisatie is van enige andere factuur (de zgn. basisfactuur ). C3: Elke factuur is een instantie van precies één factuur type en moet daarom voldoen aan alle specificaties (syntax en semantiek) van dat factuur type (inclusief die welke zijn overgeërfd van de factuurtypes waarvan dat type een specialisatie is). Het volgen van een dergelijke e-factuurmodel structuur maakt het volgende mogelijk: De verantwoordelijkheid voor en het beheer van elk type factuur, d.w.z. van de (expliciete) specificatie daarvan, is eenvoudig en eenduidig te beleggen. Als bijvoorbeeld het e-inkoop proces van de Dienst Justitiële Inrichtingen (DJI) specifieke eisen zou willen stellen aan facturen die zij geacht wordt te betalen, dan kunnen zij een factuur van het type DJI-factuur specificeren, die een specialisatie is van (bijvoorbeeld) Overheidsfactuur, en daarbij de syntactische en semantische regels vastleggen die DJI-facturen van Overheidsfacturen onderscheidt. Dit soort specialisaties dienen dan alleen gebruikt te worden indien de basis e-factuur niet voldoet. Daar hebben alleen die belanghebbenden last van (c.q.: baat bij) die facturen naar DJI sturen. Deze eigenschap beperkt niet alleen de beheerlast tot het noodzakelijke, maar belegt deze ook daar waar de kennis is om dat te doen.
4 Het technisch beheer en het ontsluiten van de specificaties kan, voor de verschillende soorten facturen, centraal worden geregeld. Dat kan bijvoorbeeld door het inrichten van een repository, waarbij belanghebbenden voor elk type factuur de complete set specificaties kan krijgen, d.w.z. de specificaties die specifiek voor dat type factuur zijn gedefinieerd alsmede de specificaties van alle factuur types waar het een (directe of afgeleide) specialisatie van is. Op deze wijze weet elke belanghebbende voor elke factuur die hij verwerkt steeds aan welke syntactische en semantische regels moet worden voldaan; daarop kan hij zijn IT inrichten. Dat geldt zowel voor overheidsinstanties als voor andere partijen. 4/9 Er zijn (bestaande) e-factuur modellen 2 die reeds handvatten bevatten voor het omgaan met deze semantische problematiek. Zo kent UBL ([UBL20]) bijvoorbeeld het element cbc:customizationid, waarmee de factuur typering zoals hiervoor beschreven kan worden geïmplementeerd: er kan worden aangegeven wat de naam is van zo n factuurtype (schemename), welke partij het factuurtype beheert (schemeagencyid, schemeagencyname), de versie van de specificatie voor het betreffende factuur type (schemeversionid), en de locatie van de specificatie (schemeuri, schemedatauri). Op eenzelfde wijze kent CEN-CI ([CEN-CI]) de data-elementen Customization identifier en Business process identifier. UBL zelf specificeert al syntax (en een beetje semantiek) van facturen. De syntax is echter erg uitgebreid, kennelijk omdat de opstellers ervan menen dat ze alle mogelijke soorten facturen ermee zouden moeten kunnen representeren. Voor de syntax specificaties lijkt dat misschien een goed idee, maar vanuit semantisch oogpunt is dat niet realistisch: de semantiek van facturen zal altijd kunnen verschillen, afhankelijk van de contexten waarin deze wordt verwerkt. De (weinige) semantische regels die UBL voor facturen specificeert, in het bijzonder de multipliciteitsregels, lijken geen beperkingen op te leggen die het werken op de door ons voorgestelde wijze verhinderen. Aansluiting bij het CEN-CI factuurmodel De focus van deze sectie is op de semantische vergelijking van het factuurmodel (zoals min of meer beschreven in [ASSEF]) en het CEN-CI factuurmodel [CEN-CI CWA-2]. Indien relevant, is in de onderbouwing van de observaties in dit document ook de syntactische vergelijking gedaan tussen corresponderende dataelementen uit beide modellen. Het Logius factuur datamodel EBF verschilt in omvang aanzienlijk van het CEN-CI datamodel. EBF bevat 57 data-elementen, CEN-CI bevat 102 data-elementen. Dit verschil in aantal data-elementen geeft al een duidelijke indicatie dat een 1-op-1 afbeelding tussen de data-elementen uit beide datamodellen niet mogelijk is. Onderstaande tabel geeft aan wat het gevolg is van de wijze waarop in het 2 Deze modellen zijn evenwel geen semantische modellen in de zin zoals wij die bedoelen: ze specificeren syntax en op zijn best suggereren ze stukken semantiek
5 elektronisch factuurmodel wordt omgegaan met de data-elementen waarvoor de mapping tussen EBF en CEN-CI ambigu is. Mapping tussen EBF en CEN-CI Data-elementen uit EBF zonder mapping naar een data-element uit CEN-CI Data-elementen uit CEN-CI zonder mapping naar een data-element uit EBF Data-elementen uit EBF met discutabele semantische mapping naar een data-element uit CEN-CI en vice versa Afwegingen Voor deze data-elementen dient te worden afgewogen of er voldoende reden is om deze in het EBF op te (blijven) nemen. Voor deze data-elementen dient te worden afgewogen of er voldoende reden is om deze alsnog in het EBF op te nemen. Voor deze data-elementen dient het gebruik van de mapping tussen beide datamodellen met zorgvuldigheid te worden uitgevoerd, omdat de aspecten waarover deze dataelement gaan verschillend kunnen zijn t.g.v. verschillen in de semantische beschrijving. 5/9 Data-elementen uit EBF met goede mapping naar een data-element uit CEN-CI met kleine (semantische of syntactische) definitieverschillen en vice versa Per data-element dient een aanpassing / oplijning van de definitie te worden heroverwogen. Voor deze data-elementen zijn de verschillen niet zodanig dat een heroverweging van de definitie nodig is, maar wel zorgvuldigheid is geboden bij de (automatische) mapping tussen beide datamodellen. In het vervolg van deze sectie wordt een aantal gedetailleerde bevindingen uit de vergelijking beschreven met bijbehorende aanbeveling. Het CEN-CI data-model bevat data-elementen (INV001 Customization identifier en INV002 Business process identifier ) om een invoice te relateren aan een specifieke gebruikscontext en/of business proces. Dit geeft ook de mogelijkheid om beter toegesneden en specifieke invullingen en syntax voor de efactuur te gebruiken voor een specifieke toepassing of context. EBF biedt hiervoor niet de structuur: het bevat geen overeenkomstige data-elementen voor gebruikscontext en voor procesverwijzingen. Dit beperkt de verdere mogelijkheden voor het flexibel inzetten en aanpassen van het datamodel voor gerelateerde processen. EBF bevat wel het data-element factuursoort dat eventueel gebruikt kan worden om een workflow mee te identificeren. Het is aan te bevelen om het opnemen van vergelijkbare data-elementen in EBF te overwegen, zodat deze ook de structuur borgt om deze flexibel voor diverse gebruiks- en procescontexten te kunnen gebruiken. Merk op dat dit data element een e-factuur model structuur ondersteunt zoals we dat in voorgaand hoofdstuk hebben gespecificeerd. De structuur voor het indelen en beschrijven van de data-elementen verschilt tussen diverse datamodellen voor de efactuur (inclusief een eerdere versie van EBF (v1.1)):
6 Het CEN-CI data-model document [CEN-CI CWA-2] beschrijft de dataelementen in een platte lijst zonder daarin een verdere opdeling naar categorieën (hiërarchische niveaus). De efactuur v1.1 beschrijving [E-Factv1.1] gebruikt een hiërarchische structuur met op het hoogste niveau de entiteit Bericht, met daaronder het tweede niveau met de entiteiten: Persoon (Debiteur), Persoon (Afnemer), Persoon (Crediteur), Persoon (Leverancier), Factuur. Op de volgende niveaus worden de individuele data-elementen hierbinnen verder benoemd. [FMEBF] heeft een tussenvorm als structuur, met slechts twee niveaus ( Algemeen en Factuurregel ) Dat de hiërarchische structuur die de auteurs van deze documenten voor ogen staat mogelijk toch aanwezig is, blijkt uit de mappings naar UBL (varianten) die in andere documenten beschikbaar is. Wij bevelen aan om een hiërarchische structuur te handhaven en te overwegen deze verder op te lijnen met de hiërarchische structuur zoals die blijkt uit de syntactische mapping documenten voor CEN-CI [CEN-CI CWA-3]. 6/9 We hebben per data-element uit het EBF v.1.6 datamodel een semantische mapping gemaakt op gerelateerde elementen uit het CEN CI datamodel, en vice versa. De gedetailleerde resultaten van deze mappings in beide richtingen zijn vastgelegd in de MS Excel spreadsheet Mapping EBF v1.6 and CEN CI.xlsx [MAP]. Door het grote verschil in aantal data-elementen tussen het Logius EBF e- Factuur datamodel en het CEN-CI e-factuur datamodel is er niet een eeneenduidige semantische mapping tussen overeenkomende data-elementen uit beide e-factuur datamodellen.. Het gevolg is hiervan dat er verschil is tussen EBF en CEN-CI in de mate van uitgebreidheid waarin verschillende eigenschappen per factuur en factuurregel kunnen worden opgenomen. Dit is een potentiële beperking van de functionaliteit van EBF. We bevelen aan te heroverwegen voor welke eigenschappen onderscheidende data-elementen tussen het niveau van de factuur en het niveau van de factuurregel dienen te worden opgenomen. Een eerdere versie van EBF (EFV1.1 3 ) maakt in de rollen onderscheid tussen Debiteur, Afnemer, Crediteur en Leverancier. Daarbij wordt dus onderscheid gemaakt tussen enerzijds de rollen die afnemen/leveren (de beslissende rollen) en anderzijds de rollen die betalen/innen (de administrerende rollen). EBF doet dat niet, alleen klant en leverancier, waarbij voor de klant weer wel een onderscheid wordt gemaakt in het factuuradres en het afleveradres. CEN-CI onderscheidt wel de buyer en de seller. Wij bevelen aan de onderscheiden zoals CEN-CI die maakt, te volgen. Er is in de EBF een aantal data-elementen waarvoor een een een-eenduidige semantische mapping met een data-element uit CEN-CI [CEN-CI CWA-2] ontbreekt. Dit betreft de data-elementen: identificatie laatste factuur 3 Het EFV1.1 is formeel buiten de scope van de vergelijking tussen datamodellen. Het onderscheid in de vier partijen ervan wordt hier echter gebruikt om het verschil in aanpakken tussen de verschillende datamodellen voor efacturen inzichtelijk te maken.
7 leveringsconditie opdrachtgever belastingen belastingcategorie belastingpercentage Wij bevelen aan om voor deze data-elementen te heroverwegen om deze in het EBF op te (blijven) nemen. 7/9 Er is in CEN-CI een groot aantal data-elementen waarvoor niet een mapping is met een data-element uit de EBF. Een aantal van deze data-elementen benoemen we hier omdat ze van groter belang worden geacht voor de inhoud van een invoice: INV034, INV035, INV036 en INV037 m.b.t. Buyer Contact INV012, INV083 en INV084 m.b.t. Contract INV001 m.b.t. Customization Zie hiervoor het eerdere punt met betrekking tot de flexibiliteit en herbruikbaarheid van het datamodel voor de efactuur in verschillende contexten en processen. Wij bevelen aan om voor deze data-elementen te heroverwegen om deze in het EBF op te nemen. Er is een aantal data-elementen waarvoor het EBF één enkel overkoepelend dataelement benoemt, terwijl het CEN-CI dit verder uitsplitst in meer gedetailleerde data-elementen. Dit geldt bijvoorbeeld voor de data-elementen: Voor het data-element adres gebruikt EBF één enkel data-element ( adres, voor leverancier) of het data-element ( factuuradres en afleveradres, voor klant). CEN-CI splitst dit veel verder uit naar de data-elementen straat, huisnummer, postcode, plaats, etc. - Maar: in de UBL en HR-XML standaarden is het generieke dataelement voor adres ook verder opgedeeld naar deelelementen. De mapping van deze uitsplitsing naar de corresponderende CEN-CI data-elementen is goed uitvoerbaar. Voor het data-element bankgegevens gebruikt EBF één enkel data-element CEN-CI splitst dit verder uit naar de data-elementen Account identifier, Seller financial institution branch ID en Financial institution branch identifier. Voor het data-element contactpersoon gebruikt EBF één enkel data-element CEN-CI splitst dit verder uit naar de data-elementen Seller contact person name, Seller contact telephone number, Seller contact fax number en Seller contact address. Voor de data-elementen kortingindicator en toeslagindicator gebruikt EBF één enkel data-element CEN-CI splitst deze verder uit naar de dataelementen Document level allowance or charge details, Allowances and charges detail text en Allowances and charges reason code. - Maar ook UBL heeft ook aanvullende velden voor "AllowanceCharge" om meer beschrijvende elementen toe te voegen. De mapping van
8 deze uitsplitsing naar de corresponderende CEN-CI data-elementen is goed uitvoerbaar. Wij bevelen aan te overwegen de werkwijze van CEN-CI hierin te volgen. 8/9 Algemene aanbevelingen Vanuit het voorafgaande hebben we de volgende aanbevelingen: 1. Specificeer een (Nederlandse) Basisfactuur zoals bedoeld in criterium C2 (zie hierboven), die de meest eenvoudige subset is van de UBL basisfactuur en alleen de hoogst noodzakelijke semantische specificaties bevat. Het eigenaarschap van deze specificatie zou kunnen worden belegd bij Logius. 2. Specificeer een 80%-factuur als specialisatie van die basisfactuur, die voor verreweg de meeste gevallen gebruikt kan worden, analoog aan [FFUBL]. Het eigenaarschap van dit type factuur zou kunnen worden belegd bij de eigenaar van het e-inkoop proces. 3. Specificeer een factuur type voor elk proces dat e-facturen verwerkt die niet met een reeds bestaand type factuur uit de voeten kan, conform de criteria C1 t/m C3 op pagina 3. Beleg het eigenaarschap van dit factuurtype bij de proceseigenaar resp. een groep van belanghebbenden (waar de proceseigenaar dan onderdeel van uitmaakt). 4. Maak een lijst van andere noties, zoals Order, Aanmaningen, Vrachtbrief, enzovoorts, en ga na in hoeverre voornoemde aanbevelingen ook relevant zijn voor deze noties. Voor de realisatie van zo een e-factuur structuur kunnen de volgende acties worden uitgezet: 1. Richt een repository in voor factuur specificaties, met daarin de specificatie van de Basisfactuur en de 80%-factuur. Eigenaarschap en beheer van de repository zou belegd kunnen worden bij Logius. 2. Richt een interface in op de repository die belanghebbenden kunnen gebruiken om de voor hen relevante factuur specificaties te kunnen zoeken en raadplegen. 3. Richt een interface in op de repository die door beheerders van factuur specificaties gebruikt kan worden voor het aanmaken, wijzigen en uitfaseren van (versies van) factuur specificaties. 4. Richt een opleiding in voor eigenaren van processen waarin facturen worden verwerkt, zodat zij a. kunnen (laten) bepalen of en wanneer het nodig is factuur types te specificeren c.q. aan te passen (vanuit belangen van hun processen); b. factuur types adequaat kunnen (laten) specificeren, zowel syntactisch als semantisch, teneinde specifieke procesbelangen te dienen c.q. proces risico s te mitigeren.
9 5. Richt ondersteuning in voor eigenaren als bedoeld in de vorige aanbeveling bij het maken c.q. beheren van de daar bedoelde specificaties. 9/9 Referenties ASSEF R. Joosten, Aanzet tot een semantische specificatie voor e- Facturen, TNO-rapport, 28 oktober BDeF Besluit Digipoort voor e-facturen (nr. WJZ/ ). BSF2009 Besluit van de staatssecretaris van Financiën d.d. 12 februari 2009, betrekking hebbende op Omzetbelasting, administratieve en factureringsverplichtingen. CEN-CI CEN: MUG - 'Core' Cross Industry Invoice European Message Implementation Guideline Project CEN CI CEN Workshop Agreement (CWA) , Guide for a European CWA-2 CORE INVOICE data model with UN/CEFACT CII Implementation Guideline - Part 2: European CORE INVOICE data model, CEN CI CWA-3 CHESSS E-Factv1.1 FFUBL MAP UBL20 WEEF September 2011 CEN Workshop Agreement (CWA) , Guide for a European CORE INVOICE data model with UN/CEFACT CII Implementation Guideline - Part 3: European CORE INVOICE syntax mapping, September 2011 CEN's Horizontal European Service Standardization Strategy, i.h.b. Module 6. default.aspx Logius (M. van Drunen en R. Hommes), efactuur Functioneel Ontwerp, versie 1.1, 15 September 2010 Factuur formulier (UBL) is een praktisch hulpmiddel voor het maken van facturen. formulieren/2010/12/17/factuurformulier/factuur-formulier-ubl.pdf TNO, Semantische mapping van EBF v1.6 en CEN CI, Mapping EBF v1.6 and CEN CI.xlsx, TNO deliverable i.o.v. Logius, Oktober OASIS: Universal Business Language v2.0 Standard, 12 December aangevuld met van mei Belastingdienst, Wettelijke eisen aan elektronische facturen. elektronisch_factureren-06.html#p50_4962 Wob68 Wet op de omzetbelasting
FORUM STANDAARDISATIE Aanmelding Functioneel model e-factuur
--- Van: @logius.nl Verzonden: maandag 15 november 2010 9:03 Aan: Bart Knubben Onderwerp: Aanmelding functioneel model e-factuur -------- #1 : Geslacht #2 : Voornaam #3 : Tussenvoegsel(s) #4 : Achternaam
Nadere informatieAdvies voor het plaatsen van nieuwe versies van de standaarden SETU en Semantisch Model e-factuur op de pas toe of leg uit -lijst
FS150225.2B FORUM STANDAARDISATIE 25 februari 2015 Agendapunt 2. Open standaarden, lijsten Stuknummer 2B. Concept Notitie SETU en SMeF Betreft: Advies voor het plaatsen van nieuwe versies van de standaarden
Nadere informatieCanonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans
Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor
Nadere informatieDigiInkoop Efficiënter zaken doen met de Rijksdienst
DigiInkoop Efficiënter zaken doen met de Rijksdienst Digitaal Bestuur Congres 20 januari 2011 Menno van Drunen - Logius Aan deze presentatie kunnen geen rechten worden ontleend. Even voorstellen: wij zijn
Nadere informatieDigiInkoop berichtstroomspecificaties voor leveranciers
DigiInkoop berichtstroomspecificaties voor leveranciers Versie 1.3 Datum 7 mei 2013 Status Definitief Colofon Product DigiInkoop Versienummer 1.3 Organisatie Logius Postbus 96810 2509 JE Den Haag servicecentrum@logius.nl
Nadere informatieEN Kernfactuur
EN 16931 Kernfactuur elektronisch factureren in de praktijk 13 december 2017 Fred van Blommestein This presentation expresses the position of the above mentioned presenter. Not of CEN nor NEN. Aanleiding
Nadere informatieSemantisch model e-factuur
Semantisch model e-factuur Versie 1.3 Datum 16-09-2013 Status Voorlopig Colofon Projectnaam Semantisch model e-factuur Versienummer 1.3 Contactpersoon O. Rutten Organisatie Logius Postbus 96810 2509 JE
Nadere informatieDigitaal factureren de ontwikkelingen
Digitaal factureren de ontwikkelingen Peter Veld Directeur Generaal Belastingdienst, Ambassadeur digitaal factureren Leveranciersdag, 29 november 2013 Agenda Voordelen digitaal factureren Strategie NL
Nadere informatieBeheermodel Semantisch Model e-factuur
Beheermodel Semantisch Model e-factuur Versie 1.3 Datum Maart 2014 Status Definitief Colofon Projectnaam Semantisch Model e-factuur Versienummer 1.3 Contactpersoon Jean-Paul Bakkers Organisatie Logius
Nadere informatieElektronisch factureren in de praktijk
Elektronisch factureren in de praktijk Een automatische administratie voor iedereen Wij zijn de standaard voor e-facturatie everbinding is simpel en voor iedereen Wij zijn niet bang om anders te zijn Waarom
Nadere informatieOpname NLCIUS (standaard voor e-factureren) op de lijst met open standaarden
FS 180425.3E Forum Standaardisatie Wilhelmina v Pruisenweg 104 2595 AN Den Haag Postbus 84011 2508 AA Den Haag www.forumstandaardisatie.nl Opname NLCIUS (standaard voor e-factureren) op de lijst met open
Nadere informatieSemantisch model e-factuur
Semantisch model e-factuur Versie 1.2.7 Datum 22-05-2013 Status Voorlopig Colofon Projectnaam Semantisch model e-factuur Versienummer 1.2.7 Contactpersoon S. Westerfield Organisatie Logius Postbus 96810
Nadere informatieSETU Wijzer. U wilt met de SETU-standaard werken, maar waar moet u beginnen?
SETU Wijzer U wilt met de SETU-standaard werken, maar waar moet u beginnen? Deze wijzer biedt u een overzicht van de SETU-standaarden en wat SETU voor u kan betekenen. Alle lichtblauwe kaarten bevatten
Nadere informatieFiche 3: Mededeling electronisch factureren. 1. Algemene gegevens
Fiche 3: Mededeling electronisch factureren 1. Algemene gegevens Titel voorstel Mededeling van de Commissie aan het Europees Parlement, de Raad, het Europees Economisch en Sociaal Comité en het Comité
Nadere informatieDigiInkoop: eenvoudig, efficiënt en betrouwbaar inkopen!
DigiInkoop: eenvoudig, efficiënt en betrouwbaar inkopen! Informatie over DigiInkoop en de wijze van aansluiten Logius Team Implementatie Support DigiInkoop Aanleiding DigiInkoop Eén Rijksbreed inkoopsysteem
Nadere informatieCORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties
CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties Hoe zorgen we ervoor dat we nieuwe diensten en producten soepel in onze bedrijfsvoering op kunnen nemen? Hoe geven we betere invulling
Nadere informatieFactuureisen Defensie. Versie 2.0 Datum 19 januari 2018 Status Definitief
Factuureisen Defensie Versie 2.0 Datum 19 januari 2018 Status Definitief Colofon Versie 2.0 Auteur Ministerie van Defensie Bijlagen A: Verplichte velden e-factuur Defensie Pagina 3 van 17 Inhoud 1 Inleiding
Nadere informatieELEKTRONISCH FACTUREREN MET UBL IN EEN EUROPEES KADER. Dennis Krukkert
ELEKTRONISCH FACTUREREN MET UBL IN EEN EUROPEES KADER Dennis Krukkert EVEN VOORSTELLEN.. Elektronisch factureren TC434 WS5 HET E-FACTUREREN SPEELVELD (2014) INHOUD PRESENTATIE Aanleiding Organisatie en
Nadere informatieAdvies voor het verwijderen van Dimensions v1.0 van de pas toe of leg uit lijst en het wijzigen van het functioneel toepassingsgebied van XBRL v2.
Forum Standaardisatie Advies voor het verwijderen van Dimensions v1.0 van de pas toe of leg uit lijst en het wijzigen van het functioneel toepassingsgebied van XBRL v2.1 Concept ter openbare consultatie
Nadere informatieContext Informatiestandaarden
Context Informatiestandaarden Inleiding Om zorgverleners in staat te stellen om volgens een kwaliteitsstandaard te werken moeten proces, organisatie en ondersteunende middelen daarop aansluiten. Voor ICT-systemen
Nadere informatieHieronder staat een voorstel voor het kennismodel voor de vernieuwde EAR wiki.
Kennismodel EAR wiki Het doel is een rijksbrede informatie-infrastructuur: De kaders en de generieke diensten en producten op het terrein van informatievoorziening en ICT die worden aangeboden aan organisaties
Nadere informatieAanmelding van een nieuwe standaard voor de pas toe of leg uit -lijst
aanmelddatum: 6 november 2011 Aanmelding van een nieuwe standaard voor de pas toe of leg uit -lijst Voor dit type aanmelding geldt dat alle criteria van toepassing zijn en alle vragen beantwoord dienen
Nadere informatiePROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D
PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT
Nadere informatieFactuureisen Defensie. Versie 1.0 Datum 8 december 2017 Status Definitief
Factuureisen Defensie Versie 1.0 Datum 8 december 2017 Status Definitief Colofon Versie 1.0 Auteur Ministerie van Defensie Bijlage A: Verplichte velden e-factuur Defensie Pagina 3 van 19 Inhoud 1 Kader
Nadere informatieENERGIE BEDRIJVEN EN ICT
ENERGIE BEDRIJVEN EN ICT De energiemarkt in Nederland is continu in beweging. Nieuwe toetreders veroveren marktaandeel en slimme meters, sectorwijzigingen en splitsing zorgen voor veranderingen. Energiebedrijven
Nadere informatieElektronisch factureren
Elektronisch factureren UWV vraagt leveranciers om hun facturen elektronisch te sturen. Wat betekent dat voor u? En hoe verstuurt u elektronische facturen? Twee factuurstromen UWV onderscheidt twee factuurstromen:
Nadere informatiePlan van aanpak om te komen tot best-practic e-factureren via e-mail of webservices.
Plan van aanpak om te komen tot best-practic e-factureren via e-mail of webservices. Versie 0.1 datum: 2012.02.27 door:jelle Attema Versie 0.2 datum: 2012.03.08 door: Jelle Attema Achtergrond. Elektronisch
Nadere informatieTweede Kamer der Staten-Generaal
Tweede Kamer der Staten-Generaal 2 Vergaderjaar 2010 2011 22 112 Nieuwe Commissievoorstellen en initiatieven van de lidstaten van de Europese Unie Nr. 1130 BRIEF VAN DE STAATSSECRETARIS VAN BUITENLANDSE
Nadere informatieUitwerking onderdelen werkplan
Uitwerking onderdelen werkplan Het Nationaal Platform Data Model (NPDM) heeft een werkplan opgesteld om richting te geven aan de activiteiten voor de komende maanden en inzicht te krijgen in de benodigde
Nadere informatieIntelligente Verkeers Regel Installatie (ivri) Fase 1. Deliverable I: Data portal voorstel
Intelligente Verkeers Regel Installatie (ivri) Fase 1 Deliverable I: portal voorstel Organisatiemodel met beschrijving informatiestromen, rollen en verantwoordelijkheden in de informatieketen voor het
Nadere informatieSjaak Groeneveld (SG) (Min. IenM) Jaap Jan Nienhuis (JJN) (SIDN/Simpler Invoicing) Bas van Schaik (BS) (Min. VenJ) Patrick Stokkers (PS) (Min.
Notulen Aan Werkgroep Semantic Model efactuur Van M.H.M. Stornebrink Onderwerp Notulen werkgroepbijeenkomst 03 december 2015 Locatie TNO New Babylon, Anna van Buerenplein 1, Den Haag Aanwezig/afwezig Patrick
Nadere informatieFS FORUM STANDAARDISATIE 25 februari 2015 Agendapunt 3:Adoptie open standaarden Stuknummer 3: Oplegnotitie adoptie
FS 150225.3 FORUM STANDAARDISATIE 25 februari 2015 Agendapunt 3:Adoptie open standaarden Stuknummer 3: Oplegnotitie adoptie Van: De stuurgroep adoptie open standaarden Bijlagen: A Monitor duiding en adoptiemaatregelen
Nadere informatieAanmelding van een nieuwe standaard voor de pas toe of leg uit -lijst
Aanmelding van een nieuwe standaard voor de pas toe of leg uit -lijst Voor dit type aanmelding geldt dat alle criteria van toepassing zijn en alle vragen beantwoord dienen te worden. U wordt als eerst
Nadere informatieE-factureren: Laat de rekening niet liggen voor een ander!
NUP Leveranciersbijeenkomst 27 oktober 2010 Workshop E-factureren: Laat de rekening niet liggen voor een ander! Tanaquil Arduin Accountmanager e-factureren Logius Agenda Welkom en introductie Even voorstellen:
Nadere informatieGeneriek framework voor administratieve toepassingen in een webgeörienteerde omgeving
Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder Administratief 12 mei 2007 Inhoud Aanleiding Administratieve systemen REA model Aspect Oriented
Nadere informatieFS C. FORUM STANDAARDISATIE 13 december Advies. Agendapunt: 4C Betreft: Concept intake-advies voor NLCIUS Aan:
FS 171113.4C Forum Standaardisatie Wilhelmina van Pruisenweg 52 2595 AN Den Haag Postbus 96810 2509 JE Den Haag www.forumstandaardisatie.nl FORUM STANDAARDISATIE 13 december 2017 Agendapunt: 4C Betreft:
Nadere informatieSCSN4STEEL. Smart Connected Supplier Network
SCSN4STEEL Smart Connected Supplier Network HET TNO TEAM Niet aanwezig vandaag: Linda Oosterheert Consultant Interoperabiliteit Matthijs Punter Researcher Smart Industry & Datadeling Laura van den Aarssen
Nadere informatieHoe kan ik een e-factuur naar de Rijksoverheid sturen?
Vanaf 1 januari 2017 zijn leveranciers van de Rijksoverheid verplicht om bij nieuwe inkoopovereenkomsten e-facturen te sturen. Deze mijlpaal is afgestemd met koepel- en brancheorganisaties uit het bedrijfsleven..
Nadere informatieFunctionele Specificatie van GRCcontrol. Rieks Joosten
Functionele Specificatie van GRCcontrol Rieks Joosten (rieks.joosten@tno.nl) 4 september 2014 Inhoudsopgave 1 Inleiding 2 2 Gemeenschappelijke taal 3 2.1 Automatiseerbare samenhangen...................
Nadere informatieGebruikershandleiding VT12 alfa Vastgoedrapportage
Gebruikershandleiding VT12 alfa Vastgoedrapportage Opgesteld en vastgesteld door: Financiële Rapportages Coöperatief B.A. www.sbrbanken.nl Amsterdam 21 december 2017 INHOUDSOPGAVE 1 Algemeen... 3 1.1 Inleiding...
Nadere informatieFS150422.7A. A: Beschrijving van de voorgestelde werkwijze B: Toelichting op het MSP en identificatie proces
FS150422.7A FORUM STANDAARDISATIE 22 april 2015 Agendapunt: 7. Internationaal Stuk 7A. Notitie omgang met standaarden van het Europese Multistakeholder Platform on ICT Standardisation Bijlage A: Beschrijving
Nadere informatieNieuw in KUBUS Spexx 5
Nieuw in KUBUS Spexx 5 KUBUS Spexx5 is een grote update ten opzichte van haar voorganger in diverse opzichten. De belangrijkste vernieuwing is de flexibiliteit bij het kiezen van de gewenste data-bronnen
Nadere informatieSoftware Test Plan. Yannick Verschueren
Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1
Nadere informatieGebruikershandleiding VT12 Vastgoedrapportage
Gebruikershandleiding VT12 Vastgoedrapportage Opgesteld en vastgesteld door: Financiële Rapportages Coöperatief B.A. www.sbrbanken.nl Amsterdam 16 maart 2018 INHOUDSOPGAVE 1 Algemeen... 3 1.1 Inleiding...
Nadere informatieDe impact van de nieuwe Europese basisfactuur. Fred van Blommestein, Flowcanto
De impact van de nieuwe Europese basisfactuur Fred van Blommestein, Flowcanto 1 Aanleiding De Europese Commissie schat dat elektronisch factureren EU-breed jaarlijks 40 miljard aan besparingen oplevert
Nadere informatieInvoice reporter Veelgestelde vragen
Invoice reporter Veelgestelde vragen Kan ik de bestanden in Invoice Reporter beschouwen als een vorm van e-invoicing? De bestanden vervangen geenszins de papieren factuur. Deze traditionele factuur blijft
Nadere informatieVoorwaarden elektronisch factureren Bijlage bij aanbestedingsdocumenten en inkoopovereenkomsten
Voorwaarden elektronisch factureren Bijlage bij aanbestedingsdocumenten en inkoopovereenkomsten Versie 1.0 Datum 31 januari 2017 Status Colofon Afzendgegevens Auteurs Directie Informatisering en Inkoop
Nadere informatieDATAMODELLERING ARCHIMATE DATAMODELLERING
DATAMODELLERING ARCHIMATE DATAMODELLERING Inleiding In dit whitepaper wordt de datamodelleervorm ArchiMate datamodellering beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.
Nadere informatieTechnisch Ontwerp W e b s i t e W O S I
Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept
Nadere informatieTwinfield change list v6.3.0
Twinfield change list v6.3.0 Eerste beschikbaarheid: 26 oktober 2011 Twinfield International NV De Beek 9-15 3871 MS Hoevelaken Nederland V6.3.0 2 van 5 Boekhouding Invoer Fout 12586 De datum controle
Nadere informatieAanmelding Model van zorginformatiebouwstenen (zib s) aan de Basisinfrastructuur
Aanmelding Model van zorginformatiebouwstenen (zib s) aan de Basisinfrastructuur 0. Vormvereisten 0.1 Is het formulier volledig ingevuld? O. JA O. NEE 0.2 Alvorens een intakegesprek wordt ingepland voert
Nadere informatieTwinfield Handleiding
Twinfield Handleiding Auteur: Website: E-mail : Martijn Mengerink www.biedmeer.nl support@biedmeer.nl Datum Versie Opmerking 27-12-2013 V1.0 Initiële opzet Pagina 2 Inhoudsopgave 1. Inleiding 4 2. Instellingen
Nadere informatieImplementatie elektronisch factureren
Implementatie elektronisch factureren Ervaringen en uitdagingen Michiel van de Sande Enterprise Architect SCOBDO Seminar, 8 december 2017 EZK in de rol van ontvanger Economische Zaken en Klimaat is verantwoordelijk
Nadere informatieFunctioneel ontwerp. Regisseur
Functioneel ontwerp Regisseur Datum: Woensdag 2 maart 2005 Auteur: L. Kuunders Versie: 0.3 E-mail: leon@kuunders.info Functioneel Ontwerp Regisseur Pagina: 1 Inhoudsopgave INLEIDING... 3 FUNCTIONALITEIT
Nadere informatieSnel te implementeren. Inpasbaar in uw situatie
Everything4Office ProjectManager Software voor Project Management Snel te implementeren Inpasbaar in uw situatie Economisch zeer verantwoord Everything4Office Software, Tolnasingel 1, 2411 PV Bodegraven
Nadere informatieVoorstel voor wijziging Informatiemodel ZTC
Voorstel voor wijziging Informatiemodel ZTC Van: Arjan Kloosterboer Datum: 5-9-2013 Ter bespreking in Expertgroep Informatiemodellen dd. 12-9-2013 In maart 2013 is de ZTC 2.0 gepubliceerd. Een onderdeel
Nadere informatieChainWise Factuur Export Functionele documentatie Twinfield API Koppeling
ChainWise Factuur Export Functionele documentatie Twinfield API Koppeling Auteur: ChainWise Datum: 09-04-2018 Versie: 1.3 Functionele documentatie 1 / 11 1 Versies Versie Auteur Datum Opmerkingen 0.1 Tien-Loong
Nadere informatieUBL inleiding, UBL Ketentest en EN Onderwerpen. 1. UBL Inleiding. 2. UBL Ketentest. 3. Europese standaard EN 16931
Onderwerpen 1. UBL Inleiding 2. UBL Ketentest 3. Europese standaard EN 16931 Door: Gerard Bottemanne, Onderzoeksbureau GBNED 13 september 2017 UBL Inleiding UBL (Universal Business Language) is een internationale
Nadere informatieActualisatie marktscan Generieke inrichting Digikoppeling adapter d.d. 22 november 2018
Actualisatie marktscan Generieke inrichting Digikoppeling adapter d.d. 22 november 2018 Inhoudsopgave 1. Inleiding... 3 2. Marktscan... 4 2.1 Procedure... 4 2.2 Inleverdatum... 4 2.3 Planning... 4 2.4
Nadere informatieVernieuwing gegevens en berichtenstandaarden. Plan van aanpak vernieuwing standaarden - Project breakdown - Voorgestelde route 2017
Vernieuwing gegevens en berichtenstandaarden Plan van aanpak vernieuwing standaarden - Project breakdown - Voorgestelde route 2017 Regiegroep gegevens en berichten standaarden Utrecht 5 oktober 2016 Wat
Nadere informatieDECLARATIEBERICHT EN FACTUURBERICHT IWMO303 EN IJW303. Veel gestelde vragen over het gebruik van de standaardberichten 303D en 303F
DECLARATIEBERICHT EN FACTUURBERICHT IWMO303 EN IJW303 Veel gestelde vragen over het gebruik van de standaardberichten 303D en 303F Versie 1 December 2016 Declaratiebericht en factuurbericht (iwmo303 en
Nadere informatieSimplerInvoicing: E-factureren voor iedereen Tony van Oorschot
SimplerInvoicing: E-factureren voor iedereen Tony van Oorschot Agenda Huidig landschap e-factureren SimplerInvoicing: Het 4-rollen model Use-cases Deliverables Deelnemers Planning & Organisatie Project
Nadere informatieSoftware Configuration Management Plan
Software Configuration Management Plan Michiel De Keyser Configuration Manager van Software Engineering groep 3 December 14, 2010 Versie Datum Beschrijving 0.1 3 November 2010 Eerste ruwe versie 0.2 3
Nadere informatieSamenwerken en elkaar begrijpen
Samenwerken en elkaar begrijpen over semantische interoperabiliteit Forum Standaardisatie Minder lasten, meer efficiëntie en een betere dienstverlening aan burgers en bedrijven. Door slimme ICT oplossingen.
Nadere informatieD V1 van de browse en zoek applicatie
D 1.1.2 V1 van de browse en zoek applicatie Hennie Brugman Auteur : Hennie Brugman 16/09/2010 09:09:00 AM page 1 of 10 1 Documenteigenschappen Rapportage datum: 16 september 2010 Rapportage periode: October
Nadere informatieStuurgroep open standaarden Datum: 27 mei 2016 Versie 1.0
FS 160608.3B Forum Standaardisatie www.forumstandaardisatie.nl forumstandaardisatie@logius.nl Bureau Forum Standaardisatie gehuisvest bij Logius Postadres Postbus 96810 2509 JE Den Haag Bezoekadres Wilhelmina
Nadere informatieNotitie Doel en noodzaak conceptueel (informatie)model
Notitie Doel en noodzaak conceptueel (informatie)model Deelprogramma Digitaal Stelsel Omgevingswet Contactpersoon A.J. Sloos Inleiding Het conceptuele model waar behoefte aan is, is het diepste representatieniveau
Nadere informatieDATAMODELLERING SIPOC
DATAMODELLERING SIPOC Inleiding In dit whitepaper wordt de datamodelleervorm Sipoc beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil je een beeld krijgen van
Nadere informatieGenerieke interface energielabels
Handleiding Generieke interface energielabels In opdracht van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties (Directie Woningbouw) 1 Inleiding 3 1.1 Doel 3 1.2 Korte omschrijving 3 1.3 Indeling
Nadere informatieDeel 3 - Handboek voor beheerders
1 Inhoud Deel 3 - Handboek voor beheerders... 3 Configuratie van Kleos-accounts en -profielen... 4 Configuratie van extra velden... 6 Configuratie van e-mail... 8 Configuratie van de sjablonen/modellen...
Nadere informatieBeheermodel Semantisch Model e-factuur
Beheermodel Semantisch Model e-factuur Versie 1.4 Datum Januari 2016 Status Concept Colofon Stuurgroep Contactpersoon Organisatie Semantisch Model e-factuur Jaap van der Marel (jaap.vandermarel@nen.nl)
Nadere informatieBevordering van Interoperabiliteit tussen Overheidsorganisaties
Bevordering van Interoperabiliteit tussen Overheidsorganisaties Fineke Beukema Mariska Scherphof Pim Keizer Justitiële Informatiedienst Ministerie van Veiligheid en Justitie Almelo, Nederland ABSTRACT:
Nadere informatieEen digitale Vlaamse overheid
Een digitale Vlaamse overheid Onderzoeker: Stijn Wouters Promotor: prof. dr. ir. Joep Crompvoets Herman Teirlinck, Brussel. 17 september 2018 Een digitale Vlaamse overheid Hoofdonderzoeksvraag: Hoe kan
Nadere informatieProcesbeschrijving Punch out aansluiting DigiInkoop
Procesbeschrijving Punch out aansluiting DigiInkoop Versie 1.1 Datum 28 mei 2014 Status Definitief Colofon Projectnaam DigiInkoop Versienummer 1.1 Contactpersoon Centraal Functioneel Beheer DigiInkoop
Nadere informatieDoel. Context VSNU UFO/INDELINGSINSTRUMENT FUNCTIEFAMILIE ICT FUNCTIONEEL (INFORMATIE) BEHEERDER VERSIE 1 MEI 2012
Functioneel (informatie) beheerder Doel Zorgdragen voor het inrichten, aanpassen, vernieuwen en onderhouden van de informatievoorziening (processen, procedures en/of systemen), passend binnen het informatiebeleid
Nadere informatieDATAMODELLERING BEGRIPPENBOOM
DATAMODELLERING BEGRIPPENBOOM Inleiding In dit whitepaper wordt de datamodelleervorm begrippenboom inclusief de begrippenlijst beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.
Nadere informatieDigiInkoop berichtstroomspecificaties voor inkooporganisaties
DigiInkoop berichtstroomspecificaties voor inkooporganisaties Versie 1.3 Datum 7 mei 2013 Status Definitief Colofon Product DigiInkoop Versienummer 1.3 Organisatie Logius Postbus 96810 2509 JE Den Haag
Nadere informatieHERGEBRUIK VAN REQUIREMENTS
HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...
Nadere informatieDATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING
DATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING Inleiding In dit whitepaper wordt de datamodelleervorm ArchiMate data- & applicatiemodellering beschreven. Deze modelleervorm staat in verhouding
Nadere informatieUBL selfbilling factuur
Definitie UBL selfbilling factuur Datum: 04-03-2013 Versie: 1.0 Inhoudsopgave 1. Inleiding 3 1.1. Gebruik van dit document 3 1.2. Uitgangspunten 3 1.3. Ondersteunde processen 4 2. Definitie UBL selfbilling
Nadere informatieNieuw modules. Scherm met lijst
Nieuw modules In de nieuwe modules wordt gebruik gemaakt van een nieuwe vormgeving die beter aansluit bij die van bekende sites. In dit gedeelte worden de verschillende onderdelen in deze vormgeving uitgelegd
Nadere informatieDebiteuren Handleiding
Debiteuren Handleiding Pagina 1 Voorwoord. In deze debiteuren handleiding leest u hoe u gebruik kunt maken van de debiteurenmodule. Omdat de mogelijkheden en werkwijze vrijwel eindeloos zijn zullen wij
Nadere informatieDe nieuwe elektronische basisfactuur en bijbehorende documenten Frequently asked questions over e-facturatie
De nieuwe elektronische basisfactuur en bijbehorende documenten Frequently asked questions over e-facturatie 1. Waarom zijn de nieuwe elektronische basisfactuur EN 16931-1 en bijbehorende standaarden ontwikkeld?
Nadere informatieRelease notes:
Applicatie: Alle Module: Algemeen (geen specifieke module) 62528 Statuslogs - contactpersoon - medewerker koppelingen Gecorrigeerde functionaliteit Voor de verschillende status logs is de medewerker /
Nadere informatieSupplier Kit verzenden elektronische facturen voor leveranciers van SITA Nederland
Supplier Kit E-Facturatie Supplier Kit verzenden elektronische facturen voor leveranciers van SITA Nederland Introductie E-Facturatie Verschillende verzendopties E-Factuur vereisten en informatie 2 (5)
Nadere informatieGebruikershandleiding Digikoppeling Serviceregister
Gebruikershandleiding Digikoppeling Serviceregister Versie 1.0 Datum 07/11/2014 Status Definitief Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555 4555 (10 ct p/m) e. servicecentrum@logius.nl
Nadere informatieCOLLEGE STANDAARDISATIE CS B
CS 13-11-07B Forum Standaardisatie Opname Semantisch Model Elektronische Factuur op de lijst voor pas toe of leg uit Wilhelmina v Pruisenweg 52 2595 AN Den Haag Postbus 84011 2508 AA Den Haag www.forumstandaardisatie.nl
Nadere informatieSLIM 3.0. Sluit Nederland aan op Internationale Metadatastandaarden ONDERDEEL: RDA. NOTITIE 2f Work records SLIM 3.0
Sluit Nederland aan op Internationale Metadatastandaarden ONDERDEEL: RDA 2012 NOTITIE 2f Work records Datum 6 januari 2013 Documentgeschiedenis 10 oktober 2012: 1 e versie Peter Schouten 18 november 2012
Nadere informatie[functie] De functie die verantwoordelijk is voor het beheren van applicaties. [zaak] Een methode of maatregel om een risico te managen.
Applicatiebeheer het beheren van applicaties. [functie] De functie die verantwoordelijk is voor het beheren van applicaties. Beheer (beheren) Control Onder de activiteit applicatiebeheer valt de ontwikkeling,
Nadere informatieHandleiding Punch out (SAP OCI)
Handleiding Punch out (SAP OCI) Koppeling webshop leveranciers met DigiInkoop Versie 1.1 Datum 24 juli 2014 Status Definitief Colofon Projectnaam DigiInkoop Versienummer V1.1 Contactpersoon Centraal Functioneel
Nadere informatieOVERSTAPPEN NAAR E-FACTURATIE IN 5 STAPPEN: HET KAN DEZE WEEK NOG
OVERSTAPPEN NAAR E-FACTURATIE IN 5 STAPPEN: HET KAN DEZE WEEK NOG Hoewel de voordelen van e-facturatie inmiddels wel bekend zijn, worstelen veel bedrijven nog steeds met de vraag: kost het mij niet teveel
Nadere informatieMemorandum. TNO Informatie- en Communicatietechnologie Wireline E-IT Colosseum 27 7521 PV Enschede. Onderwerp Scenario's evalidator
Memorandum Onderwerp Scenario's evalidator TNO Informatie- en Communicatietechnologie Wireline E-IT Colosseum 27 7521 PV Enschede 1 Scenarios evalidator Dit document bevat een aantal eenvoudige scenario
Nadere informatieadministratieve software, de vergeten doelgroep bij e-factureren?
administratieve software, de vergeten doelgroep bij e-factureren? 30 oktober 2008, Kenniscongres Administratieve Software Friso de Jong, Factuurwijzer, Platform ELFA, EEI Platform Platform ELFA Westervoortsedijk
Nadere informatieTools voor canonieke datamodellering Bert Dingemans
Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze
Nadere informatieInhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.'
Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.' Versie Concept 0.2 Datum 15-11-2007 Inhoudsopgave 1 Inleiding...2 2 Inhoudelijke
Nadere informatieE Invoicing, wat is het nu precies en wat zijn de ontwikkelingen? dé P2P specialist van Nederland
E Invoicing, wat is het nu precies en wat zijn de ontwikkelingen? dé P2P specialist van Nederland Welkom Proquro klanten! Agenda 10.00 11:30 Ontwikkelingen, visie en productlancering Proquro e Facturen
Nadere informatieBeheer en onderhoud GPH
Beheer en onderhoud GPH Afkomstig van: Sandra van Beek-Jacobs Versie: 1.0 Datum: 25-7-2014 Inhoudsopgave 1. Documenthistorie 3 2. Inleiding 4 2.1 Opbouw document 4 2.2 Doel document 4 2.3 Beheer van het
Nadere informatie