Notat Revisions- og opdateringsstrategi OIOUBL Indledning I henhold til erfaringerne med OIOXML elektronisk regning og de opdateringer, præciseringer mv. der har været, er det vurderingen, at der er behov for en officiel strategi for hvordan og hvornår, der må og kan ske opdateringer af OIOUBL - fælles standard for e-handelsdokumenter. Med opdateringer menes i dette dokument udelukkende ændringer i materiale, der tidligere har været udgivet i en færdig version. Udgivelser af supplerende vejledninger, svar på FAQ, versioner i andre formater (f.eks. word eller pdf) eller andre sprog anses ikke for at være en opdatering. Nærværende notat indeholder et oplæg til en sådan strategi for revisioner og opdateringer med henblik på at indhente kommentarer og ændringsforslag gennem en åben og offentlig høring på OIO. Der lægges op til tre former for opdateringer: Revisioner (hot fixes), mindre (minor) versionsskift og store (major) versionsskift. 6. august 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 Den grundlæggende holdning er, at der skal ske så få opdateringer som overhovedet muligt, og at opdateringer og versionsskift skal varsels bredt og i god tid inden ikrafttrædelse. Fejl og indbyrdes modsætninger skal registreres og rettes, når det vurderes belejligt, f.eks. når listen over rettelser er tilstrækkelig stor 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 rettes, inden standarden gøres obligatorisk. 1. Afklaring af begreber Når der i det følgende står anført, at noget er bagudkompatibelt, bruges det til at angive, hvor omsiggribende ændringerne er. Hvis en version er bagud kompatibel betyder det, at man i forhold til den foregående revision eller version ikke kan lave afgrænsninger, kun udvidelser. Det er således kun muligt at tilføje nye krav i frivillige felter og ikke i obligatoriske felter. Det betyder, at den vil være bagud kompatibel for afsender men ikke nødvendigvis for modtager, idet modtager risikerer at tabe information, hvis han bruger den gamle revision/version ved modtagelse. Med frigivelsesdag, menes den dag hvor revisionen eller versionen er blevet tilgængelig på www.oioubl.dk i sin endelige form.
2. Eksempler på ændringer De ændringer der foretages i forbindelse med en ny version af OIOUBL, vil som hovedregel falde indenfor fem områder: Forretningsregler En forrentningsregel 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, en lempelse vil omvendt betyde, at den er kompatible. Som eksempel hvis reglen om at navn altid skal udfyldes, hvis ikke der er et ID lempes således, at det altid er frivilligt om navnet udfyldes. Kodelister Alle ændringer i kodelisters navne betyder, at bagudkompatibiliteten forsvinder, idet de er case-sensitive, f.eks. ændring i stavemåde eller udskiftning af store bogstaver med små. Tilføjelse af nye kodelister eller nye værdier i en eksisterende kodeliste er derimod bagudkompatible ændringer. Nye elementer Såfremt nye elementer tilføjes til en klasse vil versionen være bagudkompatibel, forudsat, at elementerne placeres sidst i klassen, og at de ikke er obligatoriske/mandatory. Navneændringer Ændring af navne i UBL skemaerne vil medføre tab af bagudkompatibilitet. Hvis navne i OIOUBL dokumentationen ændres af den årsag, at der er uoverensstemmelse mellem disse og navnene i UBL skemaerne bibeholdes bagudkompatibiliteten. 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 f.eks. æ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 bagudkombabilliteten være operetholdt, men ikke den modsatte vej. 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 Det er varslet, at en ny version er påbegyndt. Version udvikles f.eks. ud fra kendt liste af ønsker. I høring Den udviklede version er sendt i høring og afventer kommentarer. Revisioner sendes ikke i høring. Høring afsluttet og standard frigivet En version kan være tilgængelig i lang tid uden at blive gjort obligatorisk Obligatorisk Standard gjort obligatorisk for en offentlig En version kan forblive 2
Bemyndiget Under afvikling Udgået myndighed at understøtte. Der kan stilles krav til private leverandører om at understøtte standarden (lovunderstøttelse). Bemyndigelses tidspunktet skal varsles min 6 mdr. før loven træder i kraft. 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. obligatorisk uden nogensinde at blive bemyndiget Sædvanligvis vil kun dele af en OIOUBL standard blive bemyndiget, f.eks. faktura og kreditnota. Afvikling sker typisk i forbindelse med offentliggørelse af en ny version. Transformationen må betales af enten afsender eller modtager Nedenstående tilstands diagram viser forholdene mellem de forskellige faser Planlagt Varsling Under udvikling Sendes i høring (min 1 måned efter varsling) Kun revisioner I høring Offentliggørelse (min 3 måneder fra start af høring) min 6-12 måneder Obligatorisk Min 1-3 måneder Bemyndiget Annoncer ophør fx. Ved offentliggørelse af en ny version Under afvikling Udgået 3
4. Revisioner (hotfix) 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. Om en revision er bagudkompatibel afhænger af de ændringer, der foretages, jfr. afsnit 2. En revision angives som et skift fra f.eks. 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å OIO.dk 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 OIO.dk. En liste over kendte ændringer i forhold til den tidligere version lægges på oio.dk, når revisionen varsles. Denne liste opdateres og udgives sammen med den nye version. Der skal gå mindst 6 mdr. fra den nye revision offentliggøres, til den kan blive obligatorisk og mindst en måned fra den er obligatorisk til den kan bemyndiges. Den tidligere revision erklæres under afvikling, så snart den nye er frigivet. En revision skal minimum være 6 måneder under afvikling. Mindre (minor) versionsskifte. Et mindre versionsskifte vil typisk indebære introduktion af nye skemaer, men kun mindre ændringer til eksisterende skemaer, og således at alle ændringer i de allerede eksisterende skemaer er bagud kompatible med foregående versioner. Anledningen til et mindre versionsskifte vil som oftest være nye forretningskrav i form af skemaer til nye områder af indkøbsprocessen, f.eks. tilbudsgivning eller transportdokumenter. Et mindre versionsskifte angives som f.eks. OIOUBL 2.01 til OIOUBL 2.1. Et mindre versionsskifte skal varsles minimum 4 mdr. før frigivelsen. Inden frigivelsen skal versionen have været i offentlig høring via OIO.dk. Høringsfasen skal påbegyndes minimum 3 mdr. før frigivelsen. En liste over forventede ændringer til eksisterende skemaer skal offentliggøres på oio.dk, på varslingstidspunktet. Denne liste vedligeholdes gennem høringen og frem til frigivelsen, hvor den offentliggøres sammen med den nye version. Inden frigivelsen skal versionen have været i offentlig høring via OIO.dk. Høringssvarene skal indarbejdes og det endelig produkt godkendes af Sektorstandardiseringsudvalget for e-handel inden frigivelse. 4
Der skal gå minimum 9 mdr. fra den nye version offentliggøres, til den kan gøres obligatorisk og yderligere minimum 3 mdr. til den kan bemyndiges. En tidligere minor version vil blive erklæret under afvikling, når den nye gøres obligatorisk. Afviklingen vil vare i 6 mdr. Store (Major) versionsskifte Et stort versionsskifte kan have samme omfang som et mindre versionsskifte, men den nye version er ikke bagud kompatibel med den tidligere. Anledningen til et stort versionsskifte vil være nye forretningskrav inden for et nyt paradigme, f.eks. en ny syntaks. Et stort versionsskifte er således kun semantisk kompatibelt med tidligere versioner. Et stort versionsskifte angives som f.eks. OIOUBL 2.1 til OIOUBL 3.0. Et stort versionsskifte skal varsles min 6 mdr. før frigivelsen. Inden frigivelsen skal versionen have været i offentlig høring via OIO.dk. Høringsfasen skal påbegyndes min. 4 mdr. før frigivelsen. Høringssvarene skal indarbejdes og det endelig produkt godkendes af Sektorstandardiseringsudvalget for e-handel og OIO Datastandardiseringskomiteen inden frigivelse. Der skal gå minimum 12 mdr. fra den nye major version offentliggøres, til den kan gøres obligatorisk. Der skal gå yderlige 3 mdr. til en major version kan bemyndiges. Tidsmæssige bindinger for versioner i de forskellige faser Nedenstående tabel viser de tidsmæssigbindinger for de enkelte faser, dvs. hvor lang tid en version som minimum skal befinde sig i de forskellige faser. Fase navn Revision Minor Major Under udvikling 1 mdr 1 mdr. 2 mdr I høring 3 mdr. 4 mdr 6 mdr 9 mdr. 12 mdr Obligatorisk 1 mdr 3 mdr. 3 mdr Bemyndiget Under afvikling 6 mdr 6 mdr. 9 mrd Udgået Bemyndigelses tidspunktet skal som nævnt varsles min 6 mdr. 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. 5
Sammenhæng mellem versioner Lige så snart en ny revision gøres tilgængelig, sættes den gamle version til under afvikling. Lige så snart en minor version gøres obligatorisk, sættes den tidligere version under afvikling. Når en ny major version gøres obligatorisk, kan den gamle version sættes under afvikling. Når den er sat under afvikling, vil der gå 12 måneder før den er udgået. At sætte en major version under afvikling kræver en høring i Sektorstandardiseringsudvalget for e-handel. To større versioner kan godt eksistere 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 gamle i en periode. Der må dog aldrig være mere end to større versioner i spil ad gangen. Findes der flere versioner end to vil den ældste af de tre udgå, når den nyeste er implementeret, dvs. seneste 15 måneder efter frigivelsen af den nyeste version. Nedenstående figur viser, hvorledes dette kan foregå. Det skal understreges, at tiderne og versionerne udelukkende er ment som eksempler. Juni 2009 2010 2011 2012 2013 OIOUBL 3.00 Under afvikling OIOUBL 3.01 obl Bemyndigende Under afvikling OIOUBL 3.1 obl Bemyndigende 6