Loading…
Tilbage

Betaversion af ny OIOUBL version 2.1 og nye OIOUBL Schematroner version 1.12.DEV


Erhvervsstyrelsen/Nemhandel frigiver hermed en betaversion af ny OIOUBL version 2.1 og tilhørende OIOUBL schematroner i version 1.12.DEV.

Opdateringen af OIOUBL schematronerne er en minor versionsopdatering, der sikrer understøttelse af UBL 2.1 og åbner for ny frivillig funktionalitet samt indeholde en række mindre og større fejlrettelser i de nuværende OIOUBL schematroner.

Det overordnede formål med at opdatere OIOUBL dokumentstandarden, er at give mulighed for anvende miljømærker og andre produkt-certifikater i OIOUBL fakturaer og kreditnotaer, samt sikre, at OIOUBL dokumentstandarden kommer et skridt nærmere Peppol dokumentstandarderne således, at OIOUBL og Peppol kommer til at benytte samme UBL 2.1 standard.

Links til supplerende materialer:


Erhvervsstyrelsen/Nemhandel arbejder ud fra følgende overordnede tidsplan:

  • 15.03.2022: Release candidate frigives senest denne dato.
  • 15.04.2022: Release frigives senest denne dato.
  • 15.05.2022: Deadline for teknisk implementering af OIOUBL schematroner.

For systemleverandører/Nemhandel-aktører, der teknisk foretager schemavalidering (ved hjælp af XSD'erne) for modtagelse af dokumenter, er det vigtigt at forberede disse opdateringer således, at man pr. 15.05.2022 er parat at modtage fakturaer og kreditnotaer med miljømærke informationer.

Det er fremover planen, at releasecyklus for OIOUBL schematroner kommer til at følge releasecyklus for Peppol dokumenter og schematroner. Der vil på et senere tidspunkt blive lavet en samlet beskrivelse af den nye proces.
 
Evt. spørgsmål vedr. denne betaversion kan sendes til: support@nemhandel.dk 

 

Med venlig hilsen

Nemhandel teamet

Profilbillede

Betaversion af ny OIOUBL version 2.1 og nye OIOUBL Schematroner version 1.12.DEV - Opdateringer af supplerende materialer pr. 01.02.2022

Mogens Graversgaard Christensen

Som opfølgning de mange gode spørgsmål og kommentarer, har Nemhandel teamet opdateret supplerende materialer. Vi håber, at disse præcisering giver mere klarhed.

Links til supplerende materialer:

Med venlig hilsen

Nemhandel teamet

ændret af Mogens Graversgaard Christensen (01.02.2022)
Profilbillede

Update of http://www.oioubl.info/classes/da/index.html

Dmitriy Lapko

Hello Nemhandel Team

 

For OIOUBL 2.02, one of the important sources of information about OIOUBL is http://www.oioubl.info/classes/da/index.html - as it visualizes tag usage rules and gives some examples in convenient form.

In relation to OIOUBL 2.1 migration, are there any plans to update it to reflect new changes?

http://www.oioubl.info/guidelines/da/commonguidelines.html

At the moment it corresponds to actual OIOUBL rules, last downloadable version of e.g. Invoice OIOUBL schematron is "OIOUBL-2.02 Invoice, 2019-04-08, Version 1.11.1.35666", which matches last published resource at https://www.digitaliser.dk/resource/4487723 "OIOUBL Schematron gældende fra 08.04.2019 version 1.11.1"

It is a very useful source of knowledge about OIOUBL, and it would be great to have new guidelines about miljømærker and environmental codes there too.

Is there a link to a beta version of this site, which reflects OIOUBL 2.1 changes?

http://beta.oioubl.info/classes/da/index.html looks like still points to OIOUBL 2.02

 

Kind regards,

Dmitriy Lapko, Mercell A/S

 

Jeg er helt på linje med Dmitriy.

OIOUBL.info og den tilhørende dokumentation har været min "gud" og reference i alle årene. Jeg er ikke en XML -skema eller -skematron nørd, slet ikke. Jeg prøver at forhold mig til det forretningsmæssige. og Oioubl.info er et fantastisk sted som skaber den bro. Det vil være meget ønsket at der findes en tilsvarende opdateret "OIOUBL2.1" info side. 

/Klaus

Hej Nemhandel Team

Jeg kan se af releasenoterne, at schematronen stadig er under udvilking, men jeg håber I kan hjælpe med afklaring på et par spørgsmål allerede nu, så vi ved hvad der venter os:-)

Generelt kan jeg se, at der ikke er "lukket af" for de klasser og elementer som findes i UBL 2.1, men ikke i UBL 2.0 skemaet. Det betyder, at der er en risiko for, at et OIOUBL dokument fremover vil komme til at indeholde nye elementer, en risiko der måske ikke kun er teoretisk da flere af dem anvendes i Peppol. Mit spørgsmål er således, om der bliver lukket af herfor i schematronen, eller om det bliver op til modtageren?

I forhold til tilføjelsen af "Certificate" klassen til OIOUBL, så er der umiddelbart forskel på dokumentationen på GitLab og så det der ligger i Zipfilen. Kan I hjælpe med at afklare, hvad der er korrekt?

- Af dokumentationen på GitLab fremgår, at koden for mærkerne skal angives i "ID" elementet, men i regnearket i Zip-filen og i teksten i schematronen er det i "CertificateTypeCode"

<Description>[F-INV337] Invalid cac:CertificateTypeCode: '<xsl:text/>
                  <xsl:value-of select="."/>
                  <xsl:text/>' Must be a value from the codelist: PackagingMarkedLabelAccreditationCode from GS1 Global Data Dictionary.</Description>
               <Xpath>

- Af GitLab dokumentationen fremgår, at Certificate skal kunne anvendes i en række dokumenter (og ikke kun katalogdokumenterne og order agreement som i Peppol), men ud over at kodelisten er tilføjet, er Certificate-valideringen ikke tilføjet til andre dokumenter end Invoice og CreditNote. Da der omvendt heller ikke er lagt begrænsning på brugen af UBL 2.1 elementer i schematronen, kan man jo fint benytte Certificate - der er bare ikke nogen validering af, at man benytter kodelisten eller i øvrigt bruger klassen som specificeret i dokumentationen. Kan I oplyse, om der kommer ændringer her?

- I GitLab dokumentationen står i beskrivelsen af CertificateTypeCode "Bør som udgangspunkt udfyldes med værdien af den tilsvarende attribut i den kodeliste, der udarbejdes for miljømærker" - er den omtalte "tilsvarende attribut" noget der bliver tilføjet til kodelisten i forhold til det der er i beta'en på nuværende tidspunkt, eller hvad menes der her?

De indlejrede kodelister i UBL 2.0 har tidligere været nævnt som en grund til at overgå til UBL 2.1, bl.a. fordi nye valutakoder ikke kunne tilføjes. Er der planer om at opdatere kodelisten i schematronen hermed?

Af OIOUBL FAQ 75 fremgår, at koderne til at angive personfølsomme oplysninger vil blive ændret. Det ser ikke ud til, at det er med i schematronen. Kan vi forvente en ændring her?

I forhold til de øvrige ændringer på changelisten med status "udvikling i gang", er det så muligt at beskrive mere præcist, hvilke ændringer der påtænkes, og om der f.eks. er tale om "nye" regler eller validering af eksisterende? Da både moms og betaligner er nogle af de mere komplekse dele af OIOUBL, er det vigtigt i god tid at vide, hvis schematronopdateringen betyder, at der skal ændres noget i afsendersystemerne. 

På forhånd tak

Venlig hilsen

Charlotte Skovhus, mySupply

Hej Charlotte,

Tak for mange gode spørgsmål og kommentarer.

Generelt om nye klasser og elementer, der ikke findes i UBL 2.0

Der er ikke planlagt lukning for disse klasser og elementer i OIOUBL schematronerne. En afsender, der måtte benytte nye klasser og elementer, der ikke indgår i OIOUBL standarden og tilhørende teknisk dokumentation, kan ikke forvente, at en modtager vil afløfte disse informationer med mindre, at det er aftalt mellem modtager og afsender. Punktet notes på listen af punkter til fremtidigt afklaring ift. kommende versioner.

Certificate klassen

Vi er en gang med at opdatere dokumentation, som ikke har helt opdateret – inkl. opdatering vedr. anvendelse af OIOUBL fejl-koder.

Certificate klassen indgår Item klassen, og teknisk kan Certificate anvendes i alle OIOUBL dokumenter, der anvender en Item klasse.

På nuværende tidspunkt er der kun OIOUBL fakturaer og OIOUBL kreditnotaer, som er i fokus for "Certifikat" understøttelse.

Også her gælder det, at der ikke planlagt lukning for disse klasser og elementer i OIOUBL schematronerne.

Vi er bekendt med problemstillingen ift. Peppol dokumentstandarderne.

Ift. CertificateTypeCode bliver der ikke foretages nogen valideringen i den kommende OIOUBL schematron, da det er vurderingen, at det vil besværliggøre udbredelsen. Det er forventningen af kodeliste for miljømærker løbende opdateres, og informationsmodellen er forberedt på, at det kan implementeres flere valideringen i fremtiden, hvis/når det bliver relevant.

Indlejrede kodelister

VI har ikke planlagt at lave indlejrede kodelister i forbindelse med denne OIOUBL schematron version, men tak for input tiltag der tilføjes til listen af forbedringstiltag.

OIOUBL FAQ 75 – personfølsomme oplysninger

Denne rettelse kommer med i den kommende OIOUBL schematron version.

Øvrige ændringer på change listen

Vi er en gang med at opdatere change listen med mere præcise beskrivelser

Vi forventer at kunne komme med supplerende informationer / opdatering af dokumentintion i næste uge.

 

Med venlig hilsen

Nemhandel teamet

ændret af Mogens Graversgaard Christensen (25.01.2022)

Mht. OIOUBL FAQ 75 – personfølsomme oplysninger

Ifht Navision Stat er der ultra høj fokus på håndteringen af personfølsomme oplysninger. Følgelig vil det være et risikomoment hvis I ændrer på måden, hvorpå det angives i OIOUBLdokumentet, uanset hvorledes. Derfor vil jeg bede til at Man ikke rokker båden på dette punkt. Vores løsning i NS er kodet, så den aktuelt håndtere de hidtil kendte måder/koder fra OIOUBL2, og Peppol.

/Klaus

"En afsender, der måtte benytte nye klasser og elementer, der ikke indgår i OIOUBL standarden og tilhørende teknisk dokumentation, kan ikke forvente, at en modtager vil afløfte disse informationer med mindre, at det er aftalt mellem modtager og afsender."

I praksis tror jeg denne holdning kan medføre problemer. Vi er i OIOUBL sammenhæng vant til en meget grundig schematronvalidering, og jeg tror der mange steder er en opfattelse af at "går den gennem validatoren, så er den i orden". Derfor kan det være problematisk hvis det i praksis ikke valideres om man benytter klasser der ikke hører til i standarden - og som måske derfor benyttes forkert eller inkonsekvent (og ligeledes hvis produktcertifikater ikke valideres i andre dokumenttyper).

Ugyldige/forkerte dokumenter der ikke fanges af den tekniske validering, vil kræve manuel håndtering at afvise, og være langt tungere at håndtere da man skal henvise til standarder og argumentere med afsender, der sikkert vil indvende "men den går jo igennem validatoren".

Måske det er værd at genoverveje Charlottes input?

Mvh. Kasper

Hej Klaus,

Mht. OIOUBL FAQ 75 - personfølsomme oplysninger. Det eneste der er optænkt der at lave en teknisk konsekvensrettelse i OIOUBL schematronen, der afspejler det skal står i alle officielle vejledning i dag, og som i dag f.eks. af praksis på Fakturablanketten. Teknisk betyder det, at værdien 3 ikke længere vil være tilladt. 

Indeholdet af de officielle vejledning er lavet efter anbefaling fra jer. 

Med venlig hilsen 

Nemhandel teamet

@Faq 75. Tak for præsisionen. Jo jeg var med i arbjdet m Faq75 og reagerede mest på at der nu måske var et (nyt) issue. Men den påtænkte skærpelse er vi med på.

@ Kasper og Charlottes pointe om nye klasser, der ikke er en del af OIOUBL. Jeg tror grundlæggende jeg er enig i at man i systemer der modtager dokumenter, gerne er fri for de diskussioner det kan aflede at "en klasse" der ikke hører hjemme i OIOUBL, alligevel sendes med i OIOULB-dokumentet, "når man nu kan i Peppol". Det vil sikkert sket og kan give mange "punkt til punkt" diskussioner om "hvorfor dit og dat". Noget vi jo netop har muligheden for at udgå med en standard. Det er jo netop ikke "standard" hvis alt muligt andet kan slippes med ind. Senere kan man jo lave en kontrolleret indlemmelse af flere klasser, hvis der tegner sig et behov.

/Klaus

Hej Mogens 

Mange tak for tilbagemeldingen.

Lige et par afklarende spørgsmål:-)

I relation til Certificate klassen, vil validering af GS1 kodelisten fortsat være en del af schematron 1.12 og skal den i så fald angives i "ID" eller i "CertificateTypeCode"?

I relation til "indlejrede kodelister" - så gik mit spørgsmål mere på, om man påtænker at opdatere allerede eksisterende kodeliste til valutakoder i schematronen, med de værdier der ikke tidligere kunne tilføjes, på grund af indlejrede kodelister i UBL 2.0 skemaet. Ligsom I har gjort med mimecodes?

Venlig hilsen

Charlotte Skovhus

Vedr. oioubl.info

oioubl.info vil også blive opdateret med det nødvendige opdateringer i forbindelse med ny OIOUBL version 2.1 og nye OIOUBL schematroner version 1.12. Vi forventer, at det vil være tilgængelig, når vi frigiver release candidate senest 15.03.2022.

Derfor har vi valgt kun at fortage den fornødne opdateringer inden 15.03.2022. Det omfatter bl.a. de guidelines, som vi aktivt ændret i ifm. OIOUBL schematron version 1.12. 

Vi arbejder også med forskellige tiltag vedr. oioubl.info for at sikre en mere sammenhængende identitet mellem nemhandel.dk og oioubl.info samt sikre bedre efterlevelse af web tilgængelighedskrav. Det er pt. ikke nogen aftalt deadline for disse tiltag, men det bliver ikke klar til 15.03.2022.

Vi er bekendte med, at vi har nogle udestående vedr. engelske vejledninger, der pt. ikke er afklaret.

Vi kan ud fra de kommentarer her på digitialiser.dk se, at indholdet af oioubl.info er meget anvendt af udvalgte bruger. Hvis der er yderligere ønsker til ny funktionalitet eller andre forbedringer, hører vi gerne derom. Det vil være lettere at få disse forslag med, når der allerede er planlagt en række tiltag.

 

Med venlig hilsen

Nemhandel teamet.

Yderligere kommentering vedr. 

Generelt om nye klasser og elementer, der ikke findes i UBL 2.0

Vi har foretaget en del overvejelser inden frigivelse af betaversionen, og vi vil vurdere dette igen på en senere tidspunkt. Vi ønsker på nuværende tidspunkt dog ikke at lukke for disse nye klasser og elementer i OIOUBL schematronerne.

Problemstilling er ikke helt simpelt: Der er forskellige tilgange til validering/lukning af nye klasser og elementer. Den europæiske norm (CEN/TC-434), Peppol og f.eks. Norge har alle forskellige tilgange til dette. Hvilket i praksis nu besværliggør implementering af miljømærker (via anvendelse af certificate elementet). Punktet står relativt højt på afklaringslisten, men det bliver ikke inden næste OIOUBL schematrom release. Vi vil give den tekniske dokumentation en yderligere tjek for at skærpe anbefalinger vedr. brug af disse nye klasser og elementer.

Men venlig hilsen

Nemhandel teamet

ændret af Mogens Graversgaard Christensen (28.01.2022)

Hej NemHandel team

CEN/TC-434 UBL Schematronen der benyttes som en del af Peppol valideriengen og dermed også af schematronvalideringen af Faktrua/kreditnota i Norge validerer ret konsekvent for brugen af "felter som ikke er en del af data-modellen", så umiddelbart tænker jeg, tilgangen er den samme.  

Valideringenre er lavet som "warnings" hvilket naturligvis hænger samme med mulighederne for brug af "Extensions". Det betyder således også, at enhver udvidelse til TC-434 er reguleret gennem anvendelse af "Extensions" og det er således ikke tanken, at man blot kan udvide modellen. 

De øvrige dokumenter er jo (endnu) ikke reguleret af nogen Europæisk norm, men så vidt jeg kan se, så validerers der i både Peppol og i de norske EHF dokumenter også for brugen af klasser og elementer, som ikke er beskrevet som en del af modellen, ligesom man i øvrigt også gør i de nuværende OIOUBL schematroner, for de klasser og elementer i UBL 2.0 som er ekskluderet. 

Venlig hilsen

Charlotte Skovhus, mySupply