Implementeringsveileder Elektronisk handelsformat Purring

Transkript

1 Implementeringsveileder Elektronisk handelsformat Purring

2 Endringslogg Versjon Kommentar Forfatter Dato 1.0 Initial versjon Bao Nguyen, Difi Elektronisk handelsformat purring Side 2 av 21

3 Innhold 1 Innledning Bakgrunn og målsetning Målgruppe Dokumentstruktur Definisjoner Definisjon av purring Definisjon av leverandør Definisjon av kunde Definisjon av selger Definisjon av kjøper Definisjon av meldingsutsteder Definisjon av meldingsmottaker Definisjon av betalingsmottaker Prinsipper og forutsetninger for EHF Purring Generelt om purring Innholdskrav til EHF PURRING Validering Purringsprosess Avtale Retur av meldingen Adressering Konvolutt Framtidige endringer Bruken av en del viktige elementer i EHF purring Bruk av aktører MVA Faktura- Kreditnotareferanse Eksempel på en Purring Purring Tabell med Xpath til formatet XML eksempel Vedlegg Vedlegg 1 - Strukturtabell Elektronisk handelsformat purring Side 3 av 21

4 6.2 Vedlegg 2 - Meldingstabell Vedlegg 3 Kodelist og identifikatorer Vedlegg 4 - UBL 2.0 Schema Vedlegg 5 - XML og XSLT Vedlegg 8 - Testfiler Elektronisk handelsformat purring Side 4 av 21

5 1 INNLEDNING 1.1 BAKGRUNN OG MÅLSETNING Dette dokumentet er utarbeidet som en del av prosjektet elektronisk faktura som Direktoratet for Forvaltning og IKT (Difi) utfører etter oppdrag fra Fornyings- og Kirkedepartement. Det ble satt to viktige datoer. Mål Statlige etater og Helseforetak skal være i stand til å motta faktura elektronisk på standard format. Mål Alle offentlige virksomheter (også kommunal sektor) skal motta elektronisk faktura på standard format. Pålegg til næringsvirksomheter om å sende elektronisk faktura på standard format. Dette dokumentet beskriver Elektronisk handelsformat (EHF) purring for utveksling elektronisk mellom samhandlingspartner. Difi har valgt å basere disse formatene på CEN BII Core 1 og en syntaks implementering basert på Universal Business Language (UBL) 2 versjon 2.0. UBL er en fri tilgjengelig standard som ikke innebærer lisenskostnader. Det samme skal gjelde for EHF purring. EHF vedlikeholdes av Difi. Målsetning med dokumentet er å definere et felles format for purring og legger til rette for en effektiv innføring av og utbredelse av denne meldingen elektronisk. 1.2 MÅLGRUPPE Målgruppen for dokumentet (heretter omtalt som implementeringsveileder) er faglig og teknisk personell hos brukere som ønsker å sende og motta purring melding elektronisk. Dokumentet kan også benyttes av systemleverandør, ERP leverandør og meldingsformidler. 1.3 DOKUMENTSTRUKTUR Implementeringsveileder er inndelt i kapitlene og underkapitlene samt en vedleggsdel. Kapitel 1. Kort introduksjon som beskriver bakgrunn og målsetning med implementeringsveileder. Kapitel 2. Definerer viktige begreper som brukes i implementeringsveileder. Kapitel 3. Beskriver prinsipper og forutsetninger som legges til grunn for utforming av EHF Kapitel 4. Beskriver hvordan en del viktige elementer i formatet brukes. Kapitel 5. Viser XML og visualisering av meldingen. Kapitel 6. Vedleggsdelen Elektronisk handelsformat purring Side 5 av 21

6 Vedlegg 1 viser struktur til purringsmeldingen. Vedlegg 2 viser hvordan dataelementene i purring brukes. Vedlegg 3 viser kodelist som brukes i formatet. Vedlegg 4 viser UBL 2.0 Schema for purring. Vedlegg 5 viser XML og XSLT for purring. Vedlegg 6 viser testfiler for purring. Elektronisk handelsformat purring Side 6 av 21

7 2 DEFINISJONER 2.1 DEFINISJON AV PURRING Purring er et dokument som brukes for å minne kunden om at betalingen er forsinket. 2.2 DEFINISJON AV LEVERANDØR En person eller et firma som leverer varer og eller tjenester på egne eller på andres vegne. 2.3 DEFINISJON AV KUNDE Person eller organisasjon som kjøper en vare eller en tjeneste på egne eller på andres vegne. 2.4 DEFINISJON AV SELGER Person eller organisasjon som har til oppgave på egne eller andres vegne å slutte en avtale eller kontrakt om overdragelse av et produkt, en vare eller tjeneste mot et avtalt vederlag til en kjøper. 2.5 DEFINISJON AV KJØPER Person eller organisasjon som overtar råderett over en vare eller tjeneste mot betaling, for en bestemt pris. 2.6 DEFINISJON AV MELDINGSUTSTEDER En meldingsutsteder er en person eller organisasjon som utsteder meldingen selv eller på andres vegne. 2.7 DEFINISJON AV MELDINGSMOTTAKER En meldingsmottaker er en person eller organisasjon, på egne eller på andres vegne, som vil motta meldingen. 2.8 DEFINISJON AV BETALINGSMOTTAKER En betalingsmottaker er en person eller organisasjon som får betaling. Elektronisk handelsformat purring Side 7 av 21

8 3 PRINSIPPER OG FORUTSETNINGER FOR EHF PURRING For at det skal være enklere å forstå bruken av formatet er det en del prinsipper og forutsetninger som bør forklares. Disse punktene presenteres i dette kapitlet. 3.1 GENERELT OM PURRING Dersom kunden ikke betaler fakturaen innen oppgitt frist, kan man sende en purring. Dersom man skal kreve purregebyr, må man imidlertid følge reglene i Inkassoforskriftens 1-2. Forskriften gir kreditor rett til å ta purregebyr når purringen er sendt skriftlig, og tidligst 14 dager etter opprinnelig forfall. Purringen må dessuten ha en betalingsfrist på minst 14 dager. Det skal IKKE beregnes merverdiavgift på gebyr vedr. purring. Du kan sende så mange purrenotaer du vil, men det er begrenset hvor mange purregebyr du kan beregne deg. Ved innkreving av purregebyr må det gå minst 14 dager mellom purringene. Det kan kreves purregebyr enten for to purringer eller en purring og et inkassovarsel. Purregebyret kan være på maksimalt 1/10 av inkassosatsen. Inkassosatsen fastsettes hvert år i "Forskrift til inkassoloven". Maks sats for gebyr på purrenota er pr kr INNHOLDSKRAV TIL EHF PURRING Det fins ingen formel krav til innholdet i en purring i forhold til norske nasjonal regler. Tabellen under viser derfor innholdskravet i en purring i henhold til UBL 2.0, CEN BII Core, og norske offentlige krav. betyr at elementet må være med i standarden. Anbefalt betyr at elementet bør være med i standarden dersom det er mulig. Krav til innhold 1. I henhold til UBL 2.0 Schema 3 2. I henhold til CEN BII Core 3. I henhold til norske offentlige krav UBL versjonsidentifikasjon Tilpassningsidentifikasjon Profilidentifikasjon Purringsnummer Purringsdato Leverandørens navn 3 Elektronisk handelsformat purring Side 8 av 21

9 Leverandørens org. nr. Leverandørens adresse Leverandørens landkode Kundenummer (Kjøper ID) Kjøpers navn Kjøpers org. nr. Kjøpers adresse Kjøpers referanse MVA totalt Anbefalt Netto linjebeløp Totalsum som skal betales Linje ID. Faktureringsreferanse (enten til tidligere faktura og eller tidligere kreditnota) 3.3 VALIDERING For å oppnå optimal fleksibilitet blir purring validert på ulike nivåer og med ulikt fokus. Vi får følgende nivåer i valideringsprosessen: 1. UBL 2.0 Schema validerer følgende: Tagnavn og eventuelle attributter må være korrekt skrevet og i riktig rekkefølge i henhold til UBL 2.0 Alle obligatoriske tagnavn må være inkludert Innholdet i et element må ha lovlig verdi i henhold til type definisjon. 2. CEN BII Core Schematron validerer i henhold til internasjonale krav som foreksempel: Lovlige koder for valuta, land, avgifter etc. Logiske sammenhenger mellom informasjonselementer som at stardato må komme før sluttdato, forfallsdato etter fakturadato, subtotaler må summeres til korrekt totalsum, test på at faktorer som skal multipliseres får korrekt produkt etc. 3. EHF Schematron validerer om meldingen er i henhold norske offentlige krav. Elektronisk handelsformat purring Side 9 av 21

10 Bilateral avtale Validering for interoperabilitet Implementeringsveileder versjon: Bransjetillegg validerer spesifikke krav som er gjeldende for hver enkel bransje. Det er opp til den enkelte bransje å etablere en valideringstjeneste på dette nivået. 5. Selskapstillegg validerer spesifikke krav som gjelder for hvert enkelt selskap. Det er opp til det enkelte selskap å etablere validering på dette nivået. De tre første nivåene på valideringer vil være i henhold til tabellene i kapittel 3.1. Pyramiden under illustrerer de ulike valideringsnivåene. 5. Selskap spesifikk (Schematron) 4.Bransje spesifikk (Schematron) 3. Norsk offentlige krav (Schematron) 2. CEN BII Core (Schematron) 1. Teksnisk struktur (UBL 2.0 Schema) Figur 1 De ulike nivå i valideringen Tabellen under viser nivå på validering avhengig av utsteders opprinnelse og om mottaker er privat eller offentlig. Meldinger fra internasjonale leverandør til norsk offentlig vil kun bli validert på nivå 1 og 2, mens dersom det er fra en norsk leverandør så vil de norske krav bli gjeldene. Valideringen vil skje på nivå fra 1 til 3. Utsteder av purring Mottaker norsk privat Mottaker norsk offentlig Utenlandsk 1, 2 evt. 4 og 5 1, 2 Norsk 1, 2 evt. 4 og 5 1, 2, 3 Elektronisk handelsformat purring Side 10 av 21

11 Aktører som benytter seg av Difis Web Dokument Portal for manuell registrering får meldingen validert ved registrering. Resultat fra validering kan være et av følgende: Dokumentet inneholder både feil og advarsel Dokumentet inneholder feil Dokumentet inneholder advarsel Dokumentet inneholder ingen feil eller advarsel Dersom dokumentet inneholder feil i en av valideringsprosessene vil det bli avvist. Leverandøren vil bli informert slik at de kan sendes dokumentet på nytt. En advarsel er kun til informasjon og får ingen betydning for utvekslingen. 3.4 PURRINGSPROSESS Leverandøren starter prosessen med å sende en faktura som følge av varekjøp eller forbruk av tjenester fra en kjøper. Dersom betalingsfristen er forfalt uten at kjøper har betalt kan leverandør følge opp og sende en purring på utestående beløp. Sekvensdiagram nedenfor vises purringsprosessen. Denne prosessen er basert på profil 8 i CENBII (BII08 Billing with dispute and reminder) 4. Denne profilen forutsetter at både faktura og purring blir sendt elektronisk. Leverandør Kjøper Faktura Purring Figur 2 Purringsprosess 3.5 AVTALE Det er ikke nødvendig å inngå en formell avtale mellom utsteder og mottaker. I praksis må mottaker ha et system som kan behandle innkommende meldinger i henhold til spesifikasjon i denne implementeringsveileder. Utsteder må validere meldingen mot spesifikasjonene. 3.6 RETUR AV MELDINGEN Det er ikke lagt opp til retur av elektroniske purring. Dersom retur er ønskelig oppfordres det til manuelt behandling. 3.7 ADRESSERING For at leverandør skal kunne sende purring til riktig kjøper er det viktig at purringen inneholder organisasjonsnummer til riktig mottaker (juridisk mottaker). Det krever at det obligatoriske elementet kjøpers organisasjonsnummer blir angitt. 4 Elektronisk handelsformat purring Side 11 av 21

12 3.8 KONVOLUTT For effektiv og sikker adressering skal EHF benytte en definert konvolutt. Bruk av konvolutt muliggjør ruting av meldinger uten å lese selve innholdet i meldingen. Viktige elementer i en konvolutt er partenes unike utvekslingsadresse, dato, tid, og meldingstype. Konvolutt spesifikasjon er ikke klare ennå. 3.9 FRAMTIDIGE ENDRINGER Difi forbeholder seg retten til å endre nåværende format til et nytt format dersom behovet skulle oppstå. Overgang til et nytt format vil bli varslet minimum 18 måneder i forkant. Det kan også bli behov for oppgradering av nåværende format til nye versjoner. Difi vil i forkant gi brukerne 6 måneders varsel for oppgradering. Det er brukernes ansvar til å klargjøre oppgraderingen innen fristens utløp. Elektronisk handelsformat purring Side 12 av 21

13 4 BRUKEN AV EN DEL VIKTIGE ELEMENTER I EHF PURRING 4.1 BRUK AV AKTØRER Følgende aktører brukes i format Aktør Kommentarer AccountingSupplierParty Leverandør er obligatorisk informasjon i EHF purring AccountingCustomerParty Kjøper er obligatorisk informasjon i EHF purring PayeeParty Betalingsmottaker er valgfri informasjon i EHF purring 4.2 MVA MVA sats som brukes i Norge i dag er 0, 8, 14, 25 prosent med henholdsvis kodene E, AA, H og S i XML. MVA kan angis på hodenivå i prosent og i verdi. MVA grunnlaget kan også angis på hodenivå. Er varen eller tjenesten avgiftsfri skal MVA sats 0 benyttes. 4.3 FAKTURA- KREDITNOTAREFERANSE Det er obligatorisk å sende enten fakturareferanse og eller kreditnotareferanse på linjenivå. Elektronisk handelsformat purring Side 13 av 21

14 5 EKSEMPEL PÅ EN PURRING 5.1 PURRING Under er eksempel på hvordan en purring kan se ut. Figur 3 Purring Elektronisk handelsformat purring Side 14 av 21

15 Elektronisk handelsformat purring Side 15 av 21

16 5.1.1 TABELL MED XPATH TIL FORMATET Felt i purring Leverandørens navn Leverandørens gateadresse Leverandørens gatenummer Leverandørens postboks Xpath i BII Core purring AccountingSupplierParty/Party/PartyName/Name AccountingSupplierParty/Party/PostalAddress/StreetName AccountingSupplierParty/Party/PostalAddress/BuildingNumber AccountingSupplierParty/Party/PostalAddress/Postbox Leverandørens postnummer AccountingSupplierParty/Party/PostalAddress/PostalZone Leverandørens poststed Leverandørens org. nr. i foretaksregisteret Purringsnummer Purringsdato Purringssekvens Fritekst Kjøpers ref. Kjøper ID Kjøpers navn Kjøpers gateadresse Kjøpers gatenummer AccountingSupplierParty/Party/PostalAddress/CityName AccountingSupplierParty/Party/PartyLegalEntity/CompanyID ID IssueDate ReminderSequenceNumeric Note AccountingCustomerParty/Party/Contact/ID AccountingCustomerParty/Party/PartyIdentification/ID AccountingCustomerParty/Party/PartyName/Name AccountingCustomerParty/Party/PostalAddress/StreetName AccountingCustomerParty/Party/PostalAddress/BuildingNumber Kjøpers postnummer AccountingCustomerParty/Party/PostalAddress/PostalZone Kjøpers poststed Kjøpers org. nr. i fortaksregisteret Tekst Faktura referanse på linje Kreditnota referanse på linje Debet linjebeløp Kredit linjebeløp MVA prosent MVA grunnlag MVA beløp Totalt MVA Totalsum AccountingCustomerParty/Party/PostalAddress/CityName AccountingCustomerParty /Party/PartyLegalEntity/CompanyID ReminderLine/Note ReminderLine /BillingReference/InvoiceDocumentReference/ID ReminderLine /BillingReference/CreditNoteDocumentReference/ID ReminderLine /DebitLineAmount ReminderLine/CreditLineAmount TaxTotal/TaxSubtotal/TaxCategory/ID (ID=S=25%, ID=H=14%, ID=AA=8%, ID=E=0%) TaxTotal/TaxSubtotal/TaxableAmount TaxTotal/TaxSubtotal/TaxAmount TaxTotal/TaxAmount LegalMonetaryTotal/PayableAmount Elektronisk handelsformat purring Side 16 av 21

17 5.1.2 XML EKSEMPEL <?xml version="1.0" encoding="utf-8"?> <!--Sample XML file generated by XMLSpy v2010 rel. 3 sp1 ( <?xml-stylesheet type="text/xsl" href="ehf-purring_no.xslt"?> <Reminder xsi:schemalocation="urn:oasis:names:specification:ubl:schema:xsd:reminder-2 UBL-Reminder- 2.0.xsd" xmlns="urn:oasis:names:specification:ubl:schema:xsd:reminder-2" xmlns:xsi=" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:commonaggregatecomponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:commonbasiccomponents-2" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:commonextensioncomponents-2"> <cbc:ublversionid>2.0</cbc:ublversionid> <cbc:customizationid>urn: ationid> <cbc:profileid>urn: <cbc:id>123456</cbc:id> <cbc:issuedate> </cbc:issuedate> <cbc:remindertypecode>999</cbc:remindertypecode> <cbc:remindersequencenumeric>3</cbc:remindersequencenumeric> <cbc:note languageid="no">henvendelse angående purring rettes til Utstyr salg AS, tlf , faks , eller epost post@utstyrsalg.no</cbc:note> <cac:accountingsupplierparty> <cac:party> <cbc:endpointid schemeid="gln" schemeagencyid="9"> </cbc:endpointid> <cac:partyidentification> <cbc:id>supp123</cbc:id> </cac:partyidentification> <cac:partyname> <cbc:name>utstyr salg AS</cbc:Name> </cac:partyname> <cac:postaladdress> <cbc:postbox>vika 123</cbc:Postbox> <cbc:streetname>oslogate</cbc:streetname> <cbc:buildingnumber>1</cbc:buildingnumber> <cbc:cityname>oslo</cbc:cityname> <cbc:postalzone>0612</cbc:postalzone> <cbc:countrysubentity>vika området</cbc:countrysubentity> <cac:country> <cbc:identificationcode>no</cbc:identificationcode> </cac:country> </cac:postaladdress> <cac:partylegalentity> <cbc:registrationname>utstyr salg AS</cbc:RegistrationName> <cbc:companyid> </cbc:companyid> <cac:registrationaddress> <cbc:cityname>sørum</cbc:cityname> <cbc:countrysubentity>akershus</cbc:countrysubentity> <cac:country> <cbc:identificationcode listid="iso3166-1" listagencyid="6">no</cbc:identificationcode> </cac:country> </cac:registrationaddress> </cac:partylegalentity> </cac:party> </cac:accountingsupplierparty> <cac:accountingcustomerparty> <cac:party> <cbc:endpointid schemeid="gln" schemeagencyid="9"> </cbc:endpointid> Elektronisk handelsformat purring Side 17 av 21

18 <cac:partyidentification> <cbc:id>cus123</cbc:id> </cac:partyidentification> <cac:partyname> <cbc:name>barnehage AS</cbc:Name> </cac:partyname> <cac:postaladdress> <cbc:postbox>lindeberg 501</cbc:Postbox> <cbc:streetname>stasjonsveien</cbc:streetname> <cbc:buildingnumber>5</cbc:buildingnumber> <cbc:cityname>frogner</cbc:cityname> <cbc:postalzone>2016</cbc:postalzone> <cbc:countrysubentity>akershus</cbc:countrysubentity> <cac:country> <cbc:identificationcode>no</cbc:identificationcode> </cac:country> </cac:postaladdress> <cac:partylegalentity> <cbc:registrationname>barnehage AS</cbc:RegistrationName> <cbc:companyid> </cbc:companyid> <cac:registrationaddress> <cbc:cityname>frogner</cbc:cityname> <cbc:countrysubentity>akershus</cbc:countrysubentity> <cac:country> <cbc:identificationcode listid="iso3166-1" listagencyid="6">no</cbc:identificationcode> </cac:country> </cac:registrationaddress> </cac:partylegalentity> <cac:contact> <cbc:id>3159bbx</cbc:id> <cbc:telephone> </cbc:Telephone> <cbc:telefax> </cbc:Telefax> </cac:contact> </cac:party> </cac:accountingcustomerparty> <cac:payeeparty> <cac:partyidentification> <cbc:id schemeid="gln" schemeagencyid="9"> </cbc:id> </cac:partyidentification> <cac:partyname> <cbc:name>faktoring AS</cbc:Name> </cac:partyname> </cac:payeeparty> <cac:taxtotal> <cbc:taxamount currencyid="nok">25</cbc:taxamount> <cac:taxsubtotal> <cbc:taxableamount currencyid="nok">100</cbc:taxableamount> <cbc:taxamount currencyid="nok">25</cbc:taxamount> <cac:taxcategory> <cbc:id schemeid="un/ece 5305" schemeagencyid="6">s</cbc:id> <cac:taxscheme> <cbc:id schemeid="un/ece 5153" schemeagencyid="6">vat</cbc:id> </cac:taxscheme> </cac:taxcategory> </cac:taxsubtotal> </cac:taxtotal> <cac:legalmonetarytotal> <cbc:lineextensionamount currencyid="nok">160</cbc:lineextensionamount> Elektronisk handelsformat purring Side 18 av 21

19 <cbc:payableamount currencyid="nok">160</cbc:payableamount> </cac:legalmonetarytotal> <cac:reminderline> <cbc:id>1</cbc:id> <cbc:note>ny betalingsfrist til Konto med KID </cbc:Note> <cbc:debitlineamount currencyid="nok">100</cbc:debitlineamount> <cbc:creditlineamount currencyid="nok">0</cbc:creditlineamount> <cac:billingreference> <cac:invoicedocumentreference> <cbc:id>123456</cbc:id> </cac:invoicedocumentreference> <cac:creditnotedocumentreference> <cbc:id></cbc:id> </cac:creditnotedocumentreference> </cac:billingreference> </cac:reminderline> <cac:reminderline> <cbc:id>2</cbc:id> <cbc:note>purregebyr</cbc:note> <cbc:debitlineamount currencyid="nok">60</cbc:debitlineamount> <cbc:creditlineamount currencyid="nok">0</cbc:creditlineamount> <cac:billingreference> <cac:invoicedocumentreference> <cbc:id>123456</cbc:id> </cac:invoicedocumentreference> <cac:creditnotedocumentreference> <cbc:id></cbc:id> </cac:creditnotedocumentreference> </cac:billingreference> </cac:reminderline> </Reminder> Elektronisk handelsformat purring Side 19 av 21

20 6 VEDLEGG 6.1 VEDLEGG 1 - STRUKTURTABELL Strukturtabellene er vedlagt og viser alle dataelementer som finnes i formatene. 6.2 VEDLEGG 2 - MELDINGSTABELL Meldingstabellene er vedlagt og beskriver hvordan dataelementene i formatene brukes. 1. Beskrivelse XML TagNavn: XML tagnavnet som benyttes i standarden Definisjon: Eksempel: Krav: Definisjon av informasjonsinnholdet som skal overføres Det er eksempel på XML elementet Beskriver i hvilken grad det er et krav at elementet sendes. betyr at elementet må være med for å tilfredsstille kravet til XML syntaksen angitt i UBL 2.0 XML Schema og det norske kravet. Anbefalt betyr at elementet bør være med for å fremme effektivitet og service mellom partene. Valgfritt betyr at det ikke er et krav om elementet i formatet. Det er opp til avsender om de ønsker å sende elementet eller ikke. Kardinalitet: Det er informasjon om forekomsten av XML elementet betyr null eller en forekomst 0.. unbounded betyr null eller mange forekomster betyr en forekomst 1.. unbounded betyr en eller mange forekomster Regel: Kilde: Regelen som gjelder for valideringen av XML elementet Kilde forteler hvor regelen om elementet kommer fra Elektronisk handelsformat purring Side 20 av 21

21 6.3 VEDLEGG 3 KODELIST OG IDENTIFIKATORER Kodelist er vedlagt i vedlegg 3. Alle må bruke samme versjon av kodelistene. EHF baseres på bruk av vedlagte BII kodeliste BII_codelists-v1.00. Prosessering og sending av elektronisk dokumenter krever presise identifikatorer som organisasjonsnr., kontonr., referanser osv. Det er derfor viktig å beskrive krav i utvekslingen, hvem som er utsteder og hvor i formatet identifikator forekommer. Tabellen under beskriver hvilke identifikator som brukes i EHF purring. Henvisning til implementeringsveileder Krav Utsteder av Identifikator Avsender org.nr. i foretaksregisteret Brønnøysund enhetsreg Mottaker org.nr. i foretaksregisteret Brønnøysund enhetsreg Deres ref. Internt Vår ref. Anbefalt Internt Ordrenr. Anbefalt Internt Leverandørens Anbefalt Aktuell bank bankkontonr. KID nr. Anbefalt Internt 6.4 VEDLEGG 4 - UBL 2.0 SCHEMA UBL 2.0 Schema er vedlagt og viser den standarden som EHF er basert på. 6.5 VEDLEGG 5 - XML OG XSLT XML eksempel filene er vedlagt sammen med XSLT filene. Disse XSLT filene må ligge på samme mappe som XML filene for at visningen av XML skal bli riktig. XML filene kan åpnes i nettleseren eller med egnet programvare. 6.6 VEDLEGG 8 - TESTFILER Vedlegg 8 inneholder testfiler med oversikt over forventede resultater. Elektronisk handelsformat purring Side 21 av 21