Notat Opdaterings- og Versioneringsstrategi for OIOUBL fælles standard for e- handelsdokumenter Indledning I henhold til erfaringerne med OIOXML elektronisk regning samt de opdateringer og præciseringer, der har været heraf, har i samarbejde med Sektorstandardiseringsudvalget for e-handel, udarbejdet indeværende opdaterings- og versioneringsstrategi for OIOUBL - fælles standard for e-handelsdokumenter. Strategien har været i offentlig høring og kommentarerne fra høringen er indarbejdet heri. 1 Den grundlæggende holdning er, at der skal ske så få opdateringer som overhovedet muligt, og at opdateringer og dermed versionsskift skal varsles bredt og i god tid inden ikrafttrædelse. Fejl og indbyrdes modsætninger skal registreres og rettes, når det vurderes belejligt, fx når listen over rettelser er tilstrækkelig lang til at det kan forsvares, eller hvis der findes en fejl, der blokerer for anvendelsen af standarden. Fejlrettelser skal i videst muligt omfang koordineres med brugerne og ske, inden standarden gøres obligatorisk. Med opdateringer menes i denne strategi udelukkende ændringer i materiale, der tidligere har været udgivet i en færdig version. Udgivelser af supplerende vejledninger, svar på FAQ, udgivelser i andre formater (fx Word eller PDF) eller andre sprog anses ikke for at henhøre under opdateringer. 23. oktober 2007 Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Datastandardiseringskontoret Helle Schade-Sørensen Telefon 3337 9282 E-post hss@itst.dk 1. Definition af bagudkompatibilitet Når der i det følgende står anført, at en version er bagudkompatibel, bruges det til at angive, hvor omsiggribende ændringerne er. Hvis en version er bagudkompatibel i forhold til tidligere version(er), betyder det, at en dokumentinstans af den tidligere version vil validere fejlfrit i den nye version. Det betyder, at man i forhold til den tidligere version ikke kan lave afgrænsninger, kun udvidelser. Hvis modtager af et dokument har implementeret en version, som er bagudkompatibel med den afsender anvender, vil modtager validere dokumentet fejlfrit og kunne læse dokumentet. 2. Eksempler på ændringer og opdateringer De ændringer og opdateringer der foretages i forbindelse med en ny version af OIOUBL, vil som hovedregel falde indenfor fem områder: 1 Bemærk at strategien i den forbindelse har skiftet navn fra Revisions- og opdateringsstrategi for OIOUBL til Opdaterings- og Versioneringsstrategi for OIOUBL.
Forretningsregler En forretningsregel beskriver de regler, der knytter sig til forretningsinformationen. Forretningsregler er normative og vil indgå i valideringen af det pågældende dokument. En stramning af en forretningsregel vil som udgangspunkt betyde, at den nye version ikke er bagudkompatibel med den tidligere, mens en lempelse omvendt vil betyde, at den er kompatibel. Eksempelvis hvis reglen om, at navn altid skal udfyldes, hvis ikke der er angivet et ID lempes således, at det altid er frivilligt om navnet angives. Kodelister Kodelister refereres via deres navn. En ændring i navnet svarer således til en ny kodeliste, herunder også ændring i stavemåde eller skift fra store til små bogstaver. Det er væsentligt at bemærke, at også Kodelistens versionsnummer indgår i navnet, fx urn:oioubl:codelist:taxtypecode-1.1. Tilføjelse af nye værdier i en eksisterende kodeliste betragtes som bagudkompatible ændringer. Nye elementer i en klasse Såfremt nye elementer tilføjes til en klasse, fx Adresse, vil versionen være bagudkompatibel, forudsat, at elementerne placeres sidst i klassen, og at de ikke er obligatoriske. Navneændringer Det er hensigten, at OIOUBL dokumentationen afspejler navnene i UBL skemaerne. Hvis en eventuel fejl findes og rettes i OIOUBL dokumentationen, således at den bringes i overensstemmelse med UBL skemaerne, betragtes dette som en bagudkompatibel rettelse. Ændring af navne i de internationale UBL skemaer vil derimod medføre tab af bagudkompatibilitet, også i OIOUBL. Kardinalitet Kardinalitet bestemmer antallet af forekomster for en klasse eller et element. Ved ændring af en kardinalitet, vil standarden være bagudkompatibel, så længe kravet løsnes. Hvis man fx ændrer en kardinalitet fra 1 til 0..1, fra 1..n til 0..n, fra 0..1 til 0..n og fra 1 til 1..n vil bagudkompatibiliteten være opretholdt. 3. Faser i en version En version af en OIOUBL standard gennemgår følgende faser, i dens levetid: Fase navn Beskrivelse Bemærkning Under udvikling I høring Tilgængelig Obligatorisk Det er varslet, at arbejdet med en ny version er påbegyndt. Den udviklede version er sendt i høring og afventer kommentarer. Høring er afsluttet, og en ny version af standarden er gjort tilgængelig via internettet. Standarden er gjort obligatorisk for en offentlig myndighed at understøtte. Versionen udvikles fx ud fra kendt liste af fejl og ønsker. Revisioner (se senere) sendes ikke i høring. En version kan være tilgængelig i lang tid uden at blive gjort obligatorisk. En version kan forblive obligatorisk uden nogensinde at blive bemyndiget. 2
Bemyndiget Under afvikling Udgået Når en standard er bemyndiget (lovunderstøttet), er de private leverandører forpligtet til at understøtte standarden, når de udveksler e-handelsdokumenter med den offentlige sektor. Det er blevet meddelt, at versionen udgår. Det vil ikke være muligt for nye virksomheder at registrere understøttelse af en version under afvikling. Versionen kan kun understøttes via transformation. Sædvanligvis vil kun dele af en OIOUBL standard blive bemyndiget. Bemyndigelsestidspunktet skal varsles min. 6 mdr. før loven træder i kraft. Afvikling sker typisk i forbindelse med offentliggørelse af en ny version. Transformationen må betales af enten afsender eller modtager Nedenstående tilstandsdiagram viser forholdene mellem de forskellige faser Planlagt Varsling Under udvikling Sendes i høring (tidligst 1 måned efter varsling) Kun revisioner I høring Offentliggørelse (tidligst 3 måneder fra start af høring) Tilgængelig Minimum 6-12 måneder Obligatorisk Minimum 3 måneder Bemyndiget Under afvikling Minimum 6-12 måneder Udgået 3
4. Tre former for opdateringer Der lægges op til tre former for opdateringer af OIOUBL, som kan afstedkomme en ny version af standarden: Revisioner, mindre (minor) versionsskift og store (major) versionsskift. Revisioner Revisioner vil typisk ske for at rette op på fejl og mangler, som forhindrer en korrekt anvendelse af standarden. En revision vil samtidig ofte blive anvendt som lejlighed til at foretage præciseringer i den måde standarden anbefales anvendt på. Revisioner i OIOUBL kan aldrig indeholde skemaændringer, og de vil altid være bagudkompatible i forhold til den foregående version. En revision angives som et versionsskift fra fx OIOUBL 2.01 til 2.02. En revision vil typisk ske ved, at der laves ændringer til dokumentation, kodelister og schematronvalideringen for de pågældende dokumenter. Der vil på IT- og Telestyrelsens hjemmeside blive offentliggjort en samlet liste over de ændringer, der er foretaget i forbindelse med en ny revision. En revision sendes ikke i høring. En revision varsles senest 1 måned før frigivelse via s hjemmeside. En liste over kendte ændringer i forhold til den tidligere version lægges på s hjemmeside, når revisionen varsles. Denne liste opdateres og udgives sammen med revisionen. Der skal gå mindst 6 måneder fra den nye revision offentliggøres, til den kan blive obligatorisk og mindst 3 måneder fra den er obligatorisk til den kan bemyndiges. Den tidligere revision erklæres under afvikling, så snart den nye er gjort obligatorisk. En revision skal minimum være 6 måneder under afvikling. Mindre (minor) versionsskifte Et mindre (minor) versionsskifte vil typisk indebære introduktion af nye skemaer og mindre ændringer til eksisterende skemaer. Dog således at alle ændringer i de allerede eksisterende skemaer er bagudkompatible med den foregående version. Anledningen til et mindre (minor) versionsskifte vil som oftest være nye forretningskrav i form af skemaer til nye områder af indkøbsprocessen, fx tilbudsgivning eller transportdokumenter. Et mindre (minor) versionsskifte angives som fx OIOUBL 2.01 til OIOUBL 2.1. Et mindre (minor) versionsskifte skal varsles minimum 4 måneder før frigivelsen. Inden frigivelsen skal versionen have været i offentlig høring via s hjemmeside. Høringsfasen skal påbegyndes minimum 3 måneder før frigivelsen. 4
Høringssvarene skal indarbejdes og det endelig produkt godkendes af Sektorstandardiseringsudvalget for e-handel inden frigivelse. En liste over forventede ændringer til eksisterende skemaer skal offentliggøres på s hjemmeside, på varslingstidspunktet. Denne liste vedligeholdes gennem høringen og frem til frigivelsen, hvor den offentliggøres sammen med den nye version. Der skal gå minimum 9 måneder fra den nye version offentliggøres, til den kan gøres obligatorisk og yderligere minimum 3 måneder til den kan bemyndiges. En tidligere mindre (minor) version vil blive erklæret under afvikling, når den nye version gøres obligatorisk. En revision skal minimum være 6 måneder under afvikling. Der kan forekomme mindre (minor) versioner i form af branchetilpasninger af OIOUBL, som bliver gjort tilgængelige, men ikke gjort obligatoriske. Det pålægger de respektive brancher selv at vedligeholde disse versioner. De er hermed også undtaget fra reglerne i indeværende revisionsstrategi, men det anbefales at de opbygger deres egen versioneringsstrategi i overensstemmelse med opdateringsog versioneringsstrategien for OIOUBL. Store (major) versionsskifte Et stort (major) versionsskifte kan have samme omfang som et mindre versionsskifte, men den nye version er ikke bagudkompatibel med den tidligere version. Da OIOUBL er baseret på den internationale UBL standard, vil et stort (major) versionsskifte af OIOUBL typisk skyldes en grundlæggende ændring af UBL standarden. Det vil derfor normalt ikke være bagudkompatibelt. Et stort (major) versionsskifte angives som fx OIOUBL 2.1 til OIOUBL 3.0. Et stort (major) versionsskifte skal varsles min 6 måneder før frigivelsen. Inden frigivelsen skal versionen have været i offentlig høring via s hjemmeside. Høringsfasen skal påbegyndes min. 4 måneder før frigivelsen. Høringssvarene skal indarbejdes og det endelige produkt godkendes af Sektorstandardiseringsudvalget for e-handel inden frigivelse. Der skal gå minimum 12 måneder fra den nye store (major) version offentliggøres, til den kan gøres obligatorisk. Der skal gå yderligere minimum 3 måneder til en stor (major) version kan bemyndiges. Når en ny stor (major) version gøres obligatorisk, kan den gamle version sættes under afvikling. Når den er sat under afvikling, vil der gå minimum 12 måneder før den er udgået. At sætte en stor (major) version under afvikling kræver en høring i Sektorstandardiseringsudvalget for e-handel. 5. Tidsmæssige bindinger for versioner i de forskellige faser Nedenstående tabel viser de tidsmæssige bindinger for de enkelte faser, dvs. hvor lang tid en version som minimum skal befinde sig i de forskellige faser. 5
Fase navn Revision Mindre (Minor) Stor (Major) Under udvikling 1 mdr. 1 mdr. 2 mdr. I høring 3 mdr. 4 mdr. Tilgængelig 6 mdr. 9 mdr. 12 mdr. Obligatorisk 3 mdr. 3 mdr. 3 mdr. Bemyndiget 2 Under afvikling 6 mdr. 6 mdr. 12 mdr. Udgået Bemyndigelsestidspunktet skal, som nævnt varsles min 6 måneder før loven træder i kraft. Der tages forbehold for politisk eller international udvikling som gør, at de angivne perioder i skemaet må kortes ned. Når der fastsættes frister for, hvornår en version bliver hhv. obligatorisk og bemyndiget, skal der tages hensyn til, hvornår It-leverandørerne forventes klar til at understøtte standarden i deres systemer. Beslutninger om fastsættelse af den faktiske dato for obligatoriske og bemyndigede versioner kan alene ske efter aftale mellem og Økonomistyrelsen (på vegne af Finansministeriet). 6. Sammenhæng mellem versioner Når en ny revision gøres obligatorisk, sættes den tidligere version under afvikling. Når en mindre (minor) version gøres obligatorisk, sættes den tidligere version under afvikling 3. To større (major) versioner kan godt være obligatoriske samtidig, idet der skal være mulighed for at de, der ikke ønsker/har behov for de udbyggede muligheder i den nye version kan forblive på den tidligere i en periode. Der må dog aldrig være mere end to større (major) versioner obligatoriske ad gangen. Findes der flere major versioner end to, vil den ældste af de tre udgå, senest 12 måneder efter den nyeste version er gjort obligatorisk. 7. Ikrafttrædelse Indeværende Opdaterings- og Versioneringsstrategi træder i kraft 1. november 2007 og gælder for alle fremtidige revisioner og versioner efter OIOUBL version 2.01. 2 Konsekvenserne af bemyndigelsen vil blive offentliggjort på samme tidspunkt som versionen gøres obligatorisk. 3 Jf. dog afsnit 4 omkring branchetilpasninger 6