Teknisk workshop OIOUBL spor Finn Christensen fch tradeshift com

Teknisk workshop OIOUBL spor Finn Christensen fch@tradeshift. com 1. marts 2011

Vision for Nem. Handel skal være lige så let som at sende en e. Mail

Agenda OIOUBL profiler Obligatoriske og andre profiler Pause OIOUBL dokumenttyper Vigtige klasser og felter Reference eksempler Forskelle i forhold til OIOXML Udvikling og aftestning Typiske faldgruber Værktøjer Spørgsmål

OIOUBL profiler Formål og baggrund Navngivning Typer Et eksempel Konklusion

Fra faktura til forretningsprocesser OU 001 V 01 in g yderligere forretningsprocesser to m at is er den udvidede indkøbsproces Au den basale indkøbsproces e-faktura papirfaktura

Oversigt over typiske profiler te da p n. U e tio at se ple ica pd if U t im n pon ec g io S on es se nse e Sp ricin elet Res ati qu e g ell on o n D em P te er ent ue. R ue sp esp han anc e. It gue atio o d e q g u N e C er der. R der. C der oic edit min atem talo alog talo plic d r a Ca Ap profil Or Or O Inv Cr Re St Ca Ca Cat C ”NES profil 5” X X X X X Procurement-Pay. Bas-1. 0 X X X Procurement-Bil. Sim-1. 0 X X Procurement-Bil. Bas-1. 0 X X X X Procurement-Ord. Sim. R-Bil. Sim-1. 0 X X Procurement-Ord. Adv-Bil. Sim-1. 0 X X Cataloque-Cat. Bas-1. 0 X X X Cataloque-Cat. Sim-1. 0 X X X Cataloque-Cat. Ext-1. 0 X X X Cataloque-Cat. Adv-1. 0

Introduktion af OIOUBL-2. 02 profiler n En profil er en overordnet beskrivelse af en eller flere sammenhørende forretningsprocesser, der hver især består af et eller flere forretningsdokumenter n En profil er et udtryk for en aftale om udveksling af dokumenter, herunder: n Hvilken rolle en part (Party) indtager i forretningsprocessen n Hvilke dokumenter en given part kan sende og modtage i den elektroniske forretningsproces n Hvilke dokumenter en given part skal kunne sende og modtage n Profilerne i OIOUBL er udarbejdet på grundlag af den overordnede forretningsmodel for UBL 2. 0, men tilpasset danske forhold

Introduktion af OIOUBL-2. 02 profiler (fortsat) n OIOUBL profiler er et framework der gør det muligt at: n Strukturere forretningsprocesser nu og i fremtiden n Angive aftaleforhold for de gængse forretningsprocesser uden brug af forudgående udvekslingsaftale n At håndtere specielle forretningsprocesser (f. eks. en branchespecifik) n Opbygge og vedligeholde et fælles katalog over hvilke forretningsprocesser de forskellige parter understøtter n Specificere hvad en part skal foretage sig i forskellige fejlsituationer n Øge graden af automatisering f. eks. ved dokumentmodtagelse n Øge graden af genbrug idet kendte forretningsgange kan indgå i forskellige profiler n Indbygge forretningslogikken i forretningssystemerne n Specificere obligatoriske (minimums), frivillige og aftalte processer n Indføre e-handel gradvist hen over tid

Profiler er sammensat af en eller flere processer n Profilerne er sammensat af en eller flere processer ud fra et byggeklodsprincip n Hver enkelt proces er selvstændig og kan anvendes isoleret set Profil Proces 1 Proces 2 Proces 3

Profiler navngives på en ensartet måde n Alle OIOUBL-2. 02 profiler er tildelt et navn (Profile. ID) n Profile. ID er sammensat af navnet på et profilområde + identifikation af de processer, der indgår i profilen adskilt ved en bindestreg + versionsnummer. n Såfremt der ønskes en kvittering (Response) for den forretningsmæssige behandling af dokumentet inden for en given proces angives dette i Profile. ID med et ”R”. Procurement-Ord. Sim. R-Bil. Sim-1. 0 Øh… Procurement Ord Sim R Bil Sim 1. 0 profilområde procesvariant kvittering ønskes Bemærk: Ovennævnte gælder ikke NES profiler profilens versionsnr

Profilområde, proces og procesvariant n Profilområde: n Procurement n Catalogue n (Transportation) – måske i fremtiden n Proces: n Catalogue n Ordering n Billing n Payment

Profilområde, proces og procesvariant (fortsat) n Procesvariant: n Basic u Den basale dokumentproces n Simple u Den enkle forretningsproces, der indeholder det minimale sæt af dokumenttyper n Extended u Et procesniveau med brug af flere dokumenttyper end det simple n Advanced u Det højeste procesniveau der kan understøttes i OIOUBL-2. 02 n SEL u Sælgerinitieret proces n Opdelingen i procesvarianter har taget udgangspunkt i, at den elektroniske forretningsproces skal understøtte såvel den simple forretningsproces som den mere avancerede

OIOUBL-2. 02 profiler kan opdeles i tre hovedtyper n Profilerne i OIOUBL kan opdeles i tre hovedtyper: n Minimums profiler (Obligatoriske) u Profiler, som man skal understøtte for at kunne sige, at man anvender OIOUBL. n Frivillige profiler u Profiler, som det er skønnet at der er et bredt behov for, og derfor defineret i OIOUBL. n Aftalte profiler u Profiler, som aftales bilateralt eller inden for en given branchen. Disse indgår ikke i OIOUBL's officielle kodeliste over profiler.

Regler for anvendelse af OIOUBL-2. 02 profiler n Såvel den offentlige organisation som leverandør skal registrere hvilke profiler de understøtter i Nem. Handel registeret (dokumentmodtagelse). n Et OIOUBL-2. 02 dokument skal altid indeholde en værdi for Profile. ID n Det er altid den part, der starter processen, der beslutter hvilket Profile. ID, der anvendes. Afsenderen skal dog altid vælge den mest avancerede profil som begge parter understøtter n Profilerne er opbygget så et højere niveau af en forretningsproces f. eks. en avanceret proces også understøtter dokumenterne i en simple proces. Der kan dog være valideringsmæssige forhold i dokumentet, som kan være forskellig fra profil til profil n Hvis f. eks. en leverandør, sender en faktura med Profile. ID ”Procurement. Bil. Bas-1. 0”, og modtageren kun understøtter profilen ”Procurement-Bil. Sim 1. 0” skal fakturaen afvises, og der skal fremsendes en ny faktura med angivelse af et Profile. ID, som modtageren understøtter

Et eksempel: Procurement-Ord. Sim. R-Bil. Sim-1. 0 n Profilen understøtter den simple ordreproces og den simple faktureringsproces n Anvendes hvor der haves et sammenhængende ordre-til-faktura flow. Faktura og kreditnota vil derfor have reference til en ordre. n Der kan udveksles følgende dokumenttyper: n n n Ordre (Order) Ordrebekræftelse (Order. Response. Simple) Faktura (Invoice) Kreditnota (Credit. Note) Rykker (Reminder) Kvittering (Application. Response) n Mellem følgende parter: n n n Kunde (Buyer. Customer. Party) Leverandør (Seller. Supplier. Party) Kreditor (Accounting. Supplier. Party) Debitor (Accounting. Customer. Party) Afsender (Sender) Modtager (Receiver)

Profildiagram

Proces: Ordering Simple (diagram)

Proces: Billing Simple (diagram)

Profiler, konklusion For hver OIOUBL-2. 02 profil findes der således en detaljeret beskrivelse af brug af dokumenterne og hvilke forretningsregler der gælder i praksis! Ved elektronisk opslag i Nem. Handel registeret fremgår det hvilke profiler den givne part supporterer!

Pause 13: 45 – 14: 10 Pause!

OIOUBL dokumenttyper Vigtige klasser og felter Reference eksempler Forskelle i forhold til OIOXML

Struktur for et OIOUBL-2. 02 dokument Order Cac, cbc, ccts, sdt og udt UBL-Order-2. 0. xsd <rodelement> <namespace> <xsd-reference> UBLExtensions UBLVersion. ID Customization. ID Profile. ID … ID UUID <dokument referencer> … Signature … <linjesektion> … Extensible content 2. 0 OIOUBL-2. 02 Procurement-Ord. Sim. R-Bil. Sim-1. 0 Dokument ID UUID: 9756 b 468 -8815 -1029 -857 a-e 388 fe 63 f 399 Interne + eksterne referencer Digital signatur

OIOUBL generelt n Validering n Schema – validerer UBL 2. 0 syntax n Schematron – validerer semantik (og OIOUBL-2. 02 delmængde) n Elementer/Attributter <cbc: Price. Amount currency. ID="DKK">760. 00</cbc: Price. Amount> n Kodelister – angiver udfaldsrum <cbc: Address. Format. Code list. Agency. ID=“ 320“ list. ID=“urn: oioubl: codelist: addressformatcode-1. 1“>Structured. DK</cbc: Address. Format. Code> n ID-lister <cbc: Endpoint. ID scheme. ID=“DK: CVR">DK 45656787</cbc: Endpoint. ID> n Header/Linje information n Header information er fælles for hele dokumentet n Linje information er specifik for linjen

Namespace <Order xmlns ="urn: oasis: names: specification: ubl: schema: xsd: Order-2" xmlns: cac ="urn: oasis: names: specification: ubl: schema: xsd: Common. Aggregate. Components-2" xmlns: cbc ="urn: oasis: names: specification: ubl: schema: xsd: Common. Basic. Components-2" xmlns: ccts="urn: oasis: names: specification: ubl: schema: xsd: Core. Component. Parameters-2" xmlns: sdt ="urn: oasis: names: specification: ubl: schema: xsd: Specialized. Datatypes-2" xmlns: udt ="urn: unece: uncefact: data: specification: Unqualified. Data. Types. Schema. Module: 2" xmlns: xsi = http: //www. w 3. org/2001/XMLSchema-instance xsi: schema. Location= "urn: oasis: names: specification: ubl: schema: xsd: Order-2 UBL-Order-2. 0. xsd">

UBL extensions

Dokument referencer

Digital signatur

Part begrebet i UBL 2. 0 n UBL 2. 0 introducerer et nyt part (party) begreb i forhold til UBL 0. 7 og 1. 0 n OIOUBL-2. 02 anvender dette n Grundlæggende er der tale om to (abstrakte) parter: n Customer (køber) n Supplier (sælger) n Disse parter er abstrakte da de først skal tildeles en rolle før de kan optræde i et UBL 2. 0 dokument n Et eksempel: n Når køber i et dokument har rollen som kunde, specificeres parten i UBL klassen som: Buyer. Customer. Party n Men når køber har rollen som debitor, specificeres parten som: Accounting. Customer. Party

Part begrebet i UBL 2. 0 – (fortsat) Catalogue Basic Catalogue Simple Catalogue Extended Catalogue Advanced Sourcing Provider. Party Receiver. Party Ordering Simple Ordering Advanced Ordering Seller. Supplier. Party Buyer. Customer. Party Fulfilment Customer Supplier Delivery. Customer. Party Despatch. Supplier. Party Billing Simple Billing Basic Billing Accounting. Customer. Party Payment Basic Payment Accounting. Supplier. Party

Part begrebet i UBL 2. 0 – (fortsat) n En køber kan typisk antage følgende roller: n Initierende - Originator. Customer. Party n Kunde - Buyer. Customer. Party n Debitor – Accounting. Customer. Party n Leveringskunde – Delivery. Party n Receiver. Party – en eventuel tredjepart n En sælger kan typisk antage følgende roller: n Leverandør - Seller. Supplier. Party n Kreditor – Accounting. Supplier. Party n Despatch. Party – den part hvor varen fysisk befinder sig n Provider. Party – en eventuel tredjepart n Betalingsmodtager – Payee. Party (*) n Til brug for kvitteringer haves følgende: n Afsender - Sender. Party n Modtager - Receiver. Party

Party begrebet i UBL 2. 0 – (fortsat) n I mange tilfælde indgår der kun to reelle parter i et e-handelsforløb. Den samme part vil derfor gå igen i de forskellige roller og i de forskellige klasser n Men det er denne fleksibilitet der gør det muligt at håndtere komplekse scenarier f. eks. ved handel mellem store organisationer n I et OIOUBL dokument skal afsenderpart og modtagerpart altid specificeres n Rent praktisk er den første partangivelse i et dokument altid afsenderen og den efterfølgende modtageren (*)

Nøglefelter i klassen Party n Endpoint n Dette felt benyttes til angivelse af elektronisk adresse for dokumentudveksling. Den elektronisk adresse skal være registreret i Nem. Handel registeret n Skal udfyldes for modtager og afsender af dokumenter, samt for parter som indgår i efterfølgende elektronisk udveksling af dokumenter n Afsenders Endpoint er en vigtig forudsætning for elektroniske kvitteringer n Party. Identification n Entydig identifikation af en part i form af CVR, SE, P, eller CPR. n Party. Name n Navn for den pågældende part. Er krævet hvis Party. Identification ikke er udfyldt. Navnet skal være identisk med virksomhedens og/eller personens officielt registrerede navn i det centrale virksomhedsregister eller personregistret. For udenlandske virksomheder skal anvendes virksomhedens officielle virksomhedsnavn

Nøglefelter i klassen Party – (fortsat) n Party. Legal. Entity n Angiver den juridiske enhed udtrykt ved enten CVR eller CPR nummer n Party. Tax. Scheme n En handelspartner identificeret ved et CVR nummer kan vælge at håndtere forskellige afgifter (pligtkoder) under forskellige SE numre. Handelspartneren kan derfor angive en eller flere instanser af klassen Party. Tax. Scheme, hvor der for et SE nummer specificeres en pligtkode. Dette afspejler den registrering, som handelspartneren har fået foretaget hos SKAT n Hvis en virksomhed kun er registreret med ét afgiftsnummer hos SKAT, er CVR nummer og SE nummer identisk. Det er imidlertid altid SE nummer der anvendes som registreringsnummer under Party. Tax. Scheme n Contact n Ved afsendelse af faktura til offentlige myndigheder skal der her angives personreference som et udtryk for den person, der er tilknyttet partneren n Person n Anvendes som reference til en person hos parten

Delivery n Det er ikke et krav at klassen skal angives n Kan gentages for hver delleverance der måtte ønskes n Kan forekomme både på headerog linjeniveau n Giver mulighed for angivelse af følgende oplysninger: n Leveringsmængder n Leveringstidspunkt (dato og tid) n Leveringsperiode n Et antal forretningsparter n Et antal adresseoplysninger

Delivery – (fortsat) n Rent forretningsmæssigt er det vigtigt at skelne mellem leveringsadresse* og leveringspart: n Leveringspart er den forretningspart der er ansvarlig for modtagelsen af den leverede vare, men adressen på leveringsparten behøver ikke være den adresse hvor varen skal afleveres. Hvis varen skal afleveres på en anden adresse, specificeres den i leveringsadresse n Et eksempel kunne være et hjælpemiddel til en privat borger, som skal leveres på borgerens bopæl, men hvor hospitalets lager for hjælpemidler er leveringspart n Forsendelsespart: n Angiver en eventuel forretningspart hvor varen fysisk befinder sig og hvorfra den skal sendes/transporteres til leveringspart eller leveringsadresse * leveringsadresse = Delivery. Location. Address

Tax. Total n Tax er et godt eksempel på hvordan OIOUBL er tilpasset danske forhold: n En virksomhed registrerer sig hos Skat under et eller flere SE numre n Virksomheden kan vælge at håndtere forskellige afgifter (pligtkoder) under forskellige SE numre n En afgift kan være momsfri (66: Registreringsafgift for motorkøretøjer) n En afgift kan have forskellige satser (moms: 25%, 0%, ? ? %) n En virksomhed kan have behov for at gruppere afgiftsbeløb under de danske toldkoder (punktafgiftskoder) jf. Skats Toldvejledning 2006 -3, bilag 123 Punktafgifter n Hvor svært kan dét være? n To vigtige regler! n Tre danske kodelister!

Tax. Total – husk 2 regler Klassen Tax. Total gentages for hver pligtkode hvor der ønskes angivet et afgiftsgrundlag og en afgift sum og klassen Tax. Subtotal gentages inden for Tax. Total for hver beregningsformel der måtte være angivet i afgiftskategorien Klassen Tax. Total skal indeholde alle skatter, moms og afgifter (punktafgifter), der afregnes til Skat. Afgifter, der afregnes virksomheder i mellem, angives i klassen Allowance. Charge

Tax. Total – eksempel på alm. momsgrundlag

Tax. Total – eksempel på momsfri ydelse

Legal. Monetary. Total n Linjetotal uden moms n Momstotal n Totalbeløb + forudbetalt beløb n Rabatsum n Gebyrsum n Evt. forudbetalt beløb n Evt. afrundingsbeløb n Totalbeløb n Hvor er momsgrundlaget?

Prisoplysninger n Prisklassen er det centrale omdrejningspunkt for de andre klasser og felter, når priser og mænger skal beregnes n Kompliceret sammenhæng mellem basispris, bestillingsenhed, leveringsenhed etc. n Men det giver support for specielle situationer (forholdsvis afregning, sampak, anbrud etc. ) Price. Amount / Base. Quantity * (Base. Quantity * Orderable. Unit. Factor. Rate) = Prisen for en bestillingsenhed. Dette udtryk kan reduceres til Price. Amount * Orderable. Unit. Factor. Rate = Prisen for en bestillingsenhed.

Prisoplysninger (fortsat) Ordering units Delivery units Packing units Ordering. Unit Batch. Quantity Pack. Quantity Content. Unit. Quantity Consumer. Unit. Quantity Pack. Size. Numeric Order. Quantity. Increment Numeric Minimum. Order. Quantity Maximum. Order. Quantity Base units Minimum. Quantity Maximum. Quantity Price. Amount Base. Quantity Orderable. Unit. Factor. Rate

Vareoplysninger - momspligt Varen er underlagt 25% momspligt (pligtkode=63) Bemærk: er ikke krævet på en ordre

Vareoplysninger - vare n En OIOUBL varelinje indeholder en mængde muligheder n Klassen går igen i de forskellige dokumenter n Man skal kun anvende de felter der er relevante… OBS: max 40 karakterer

Vareoplysninger – vare (avanceret)

Payment. Means n Hvis ikke der er angivet nogen betalingsmåde, anvendes den normale betalingsbetingelse, der er gældende mellem en kreditor og debitor n Der kan angives mere end én betalingsmåde Elektronisk betalingsform Betalings. Måde. Kode International kontooverførsel 31 Indenlandsk kontooverførsel 42 Betalings- eller leverandørservice (incl. Direct Debit) 49 Giroindbetalingskort 50 01, 04 og 15 Fælles indbetalingskort 93 71, 73 og 75 Bilateralt defineret 97 Nem. Konto Kort. Arts. Kode

Payment. Means - eksempel reference til betalingsmåde (og betingelser) Betalings. Måde. Kode betalingsdato Indenlandsk kontooverførsel

Payment. Terms n Hvis ikke der er angivet nogen betalingsbetingelse anvendes den normale betalingsbetingelse, der er gældende mellem en kreditor og debitor n Der kan angives mere end en betalingsbetingelse n Betalingsbetingelserne angives efter vigtighed eller efter forfaldstid (rater) Bemærk referencen til betalingsmåde

Allowance. Charge n Klassen Tax. Total skal indeholde alle afgifter (punktafgifter) og moms, der afregnes med Skat. Afgifter, der afregnes virksomheder i mellem, angives i klassen Allowance. Charge = Gebyrer og rabatter! n Allowance. Charge på linieniveau medtages ikke i Legal. Monetary. Total, idet også indgår i Line. Extension. Amount, og dermed ville blive medregnet to gange. I Legal. Monetary. Total medtages alene Allowance. Charge på headerniveau n Årsagen til rabat eller gebyr angives som en forklarende tekst n En bestemt beregningsrækkefølge kan understøttes n Angivelse af momspligt

Allowance. Charge - eksempel tillæg eller fradrag årsag beregning momspligt

OIOUBL-2. 02 Kvittering (Application. Response)

Application. Response - formål n En Application. Response har flere formål: n Kan bruges som forretningsmæssig kvittering for alle OIOUBL-2. 02 dokumenter (undtaget ordre) n Kan bruges til elektronisk at afvise et forretningsdokument pga. forretningsmæssige fejl eller mangler (undtaget ordre) n Skal bruges til at afvise et OIOUBL-2. 02 dokument med et Profile. ID som modtageren ikke understøtter n Skal bruges til at afvise et OIOUBL-2. 02 dokument med valideringsfejl

De vigtigste klasser og elementer n Profile. ID n Normalt svarende til den ”igangværende profil” n Men ved afvisning af et dokument med ukendt profil eller valideringsfejl skal profilen angives til: ”NONE” n Sender. Party n Receiver. Party n Document. Response n Response u Her skal angives en kode samt en beskrivelse n Document. Reference u En reference til det dokument der gives respons på n Line. Response (optionel) u Her kan angives detaljerede oplysninger relateret til en eller flere linjer i det oprindelige dokument

Response. Code og Line. Response. Code n Response. Code gælder altid for hele dokumentet n En afvisning eller en kvittering gælder altid hele dokumentet n Line. Response. Code kan bruges til at informere om hvilke dele af et dokument der (forretningsmæssigt) er ok og hvilke der ikke er n Response. Code kan antage følgende værdier: n Technical. Accept (bruges ej i praksis) n Technical. Reject n Profile. Accept (bruges ej i praksis) n Profile. Reject n Business. Accept n Business. Reject n Line. Response. Code kan antage følgende værdier n Business. Accept n Business. Reject

Document. Response - overblik

Application. Response i praksis n En kvittering (=accept) skal altid referere til det højeste niveau (Business. Accept) n En afvisning refererer til det niveau hvor fejlen opdages n En Application. Response kan også indeholde fejl n Og afsender af en Application. Response kan også anmode om en kvittering n En afvisning på teknisk og profil niveau sendes altid med Profile. ID = ”NONE” n Det er et krav* i OIOUBL-2. 02 at en modtager kan sende en Application. Response og at en afsender kan modtage en n Det stiller krav til: Endpoint. ID, postkasse og IT infrastruktur n Men kravet om brug af Application. Response gør det muligt maskinelt at håndtere en lang række af fejlsituationer…

Application. Response - reference eksempel OIOUBL_Application. Response_v 2 p 1. xml

OIOUBL-2. 02 Ordre

Ordre - formål n e-handel på procesniveau (fra faktura til forretningsprocesser) n Høste besparelser ved elektronisk match af ordrer mod fakturaer n OIOUBL-2. 02 order er en ”bred” ordre: n Katalogbaseret ordre n Tekstbaseret ordre n Alternativt tilbud n Sælgerinitieret ordre n Stående ordre n Vareopfyldning på baggrund af rammeaftale n Internethandel n International handel n Avanceret part (Party) håndtering n Tilknytning til OIOUBL profiler

De vigtigste klasser og elementer n Profile. ID forretningsproces n ID ordrenr n Buyer. Customer. Party kunde n Seller. Supplier. Party leverandør n Delivery n Tax. Total ønsket leveringsdato momsberegning n Anticipated. Monetary. Total forventet totalbeløb n Order. Line en eller flere varelinjer n Quantity n Price n Item

Profile. ID n Procurement-Ord. Sim-**** n Obligatorisk brug af ordre (simpelt procesniveau): u. Order. Response. Simple u. Application. Response n Procurement-Ord. Adv-**** n Frivillig brug af ordre (avanceret procesniveau): u. Order. Response. Simple u. Order. Change u. Order. Cancellation u. Order. Response u. Applicationresponse n Procurement-Ord. Sel-**** (OBS: ingen ordre ) n Sælger initieret ordre: u. Order. Response. Simple u. Order. Change u. Order. Cancellation u. Order. Response – starter processen u. Applicationresponse

Parter i en ordre n Obligatoriske: n Buyer. Customer. Party n Seller. Supplier. Party n Optionelle: n Originator. Customer. Party n Freight. Forwarder. Party n Accounting. Customer. Party n Delivery/Delivery. Party n Delivery/Despatch. Party n Linjeniveau: n Originator. Party n Delivery/Delivery. Party n Delivery/Despatch. Party

Order. Line linjenr antal og enhed Linjetotal inklusiv gebyrer og rabatter men eksklusiv moms prisoplysninger vareoplysninger

Order - reference eksempler OIOUBL_Order_v 2 p 1. xml OIOUBL_Order. Cancellation_v 2 p 1. xml OIOUBL_Order. Change_v 2 p 1. xml OIOUBL_Order. Response. Simple_v 2 p 1

OIOUBL-2. 02 Faktura

Faktura - formål n Fakturadokumentet i OIOUBL-2. 02 er en videreudbygning af formatet for OIOXML elektronisk regning (e-faktura) n Fakturaen i OIOUBL-2. 02 giver de samme anvendelsesmuligheder som e-faktura samt en hel del flere n OIOUBL-2. 02 invoice er en ”bred” faktura: n n n Mangler i nuværende e-faktura er (forsøgt ) fjernet Forsinket betaling Håndtering af tredjepartshandel (avanceret part (Party) håndtering) Rykker og rentenota med i processen Håndtering af forudbetaling Reference til leveringen Rige muligheder for at referere til andre dokumenter Bedre muligheder for ordre/faktura match Kortbetalinger Internethandel International handel Selvafregning (Selfbilled Invoice og Creditnote frigives efter behov) n Tilknytning til OIOUBL profiler

De vigtigste klasser og elementer n Profile. ID forretningsproces n ID fakturanr n Accounting. Supplier. Party kreditor n Accounting. Customer. Party debitor n Delivery faktisk leveringsdato n Payment. Means n Payment. Terms n Allowance. Charge n Tax. Total betalingsmåde betalingsbetingelser gebyr og rabat beregning n Legal. Monetary. Total n Invoice. Line n Quantity n Price n Item momsberegning fakturatotaler en eller flere fakturalinjer

Profile. ID n NES profil 5 (urn: www. nesubl. eu: profiles: profile 5: ver 2. 0) n Uden kvittering etc. (basalt procesniveau): u Invoice u Creditnote n Procurement-****-Bil. Sim n Obligatorisk brug af faktura (simpelt procesniveau): u Invoice u Creditnote u Reminder u Application. Response

Parter i en faktura n Obligatoriske: n Accounting. Supplier. Party n Accounting. Customer. Party n Optionelle: n Payee. Party n Buyer. Customer. Party n Seller. Supplier. Party n Delivery/Delivery. Party n Delivery/Despath. Party (bruges ej) n Linjeniveau: n Originator. Party n Delivery/Delivery. Party n Delivery/Despatch. Party

Invoice. Line linjenr antal og enhed linjetotal inklusiv gebyrer og rabatter men eksklusiv moms reference til ordrelinje momstotal (informativ) vareoplysninger prisoplysninger

Invoice - reference eksempler OIOUBL_Invoice_v 2 p 1. xml OIOUBL_Credit. Note_v 2 p 1. xml

OIOUBL-2. 02 Katalogdokumenter

OIOUBL-2. 02 katalogdokumenter n Catalogue Request n Afsendes af kunden, og bruges til at efterspørge et katalog hhv. et nyt katalog eller en opdatering til et eksisterende katalog. Det er i Catalogue Request muligt at afgrænse efterspørgslen, således at kun relevante varer modtages i kataloget. n Catalogue n Bruges til at oprette et nyt katalog eller til at tilføje, opdatere eller slette varelinjer i et eksisterende katalog. n Catalogue Item Specification Update n Kan anvendes, hvis kun vare specifikationen skal opdateres i et eksisterende katalog. n Catalogue Pricing Update n Kan anvendes, hvis kun oplysninger relateret til prisen skal opdateres i et eksisterende katalog. n Catalogue Deletion n Sletning af et helt katalog

De vigtigste klasser og elementer n Profile. ID n ID forretningsproces katalog-ID n Issue. Date udgivelsesdato n Revision. Date revisionsdato n Version. ID evt. versionsnr n Validity. Period gyldighedsperiode n Referenced. Contract evt. kontraktreference n Provider. Party katalogudbyderen n Receiver. Party katalogmodtageren n Trading. Terms evt. betingelser n Catalogue. Line eventuelle kataloglinjer n Action. Code tilføj, opdater, slet

Fordeling på OIOUBL-2. 02 profiler e t da p n. U e io at dat le e c p ns ifi Up n m t c i o n s pe cing etio esp e se. S tio ue S ri s q la R m el on pon nge cel Re e te ue. P e. D tion p s t I e u te er u a u o es e ha an en ue g r r. R er. C ice dit. N ind tem aloq alog talo alog plic e e t t t p ta Ca rd rd rd nvo re em ta Ca A O O I R S O C Ca Ca Ca profil-ID X X www. nesubl. eu-profiles: profile 1 -ver 1. 0 X X Cataloque-Cat. Bas-1. 0 X X X Cataloque-Cat. Sim-1. 0 X www. nesubl. eu-profiles: profile 2 -ver 1. 0 X X X X X Cataloque-Cat. Ext-1. 0 X X X Cataloque-Cat. Adv-1. 0

Parter i et katalog n Obligatoriske: n Provider. Party n Receiver. Party n Seller. Supplier. Party (obs) n Optionelle: n Contractor. Customer. Party n Linjeniveau: n Seller. Supplier. Party n Contractor. Customer. Party Håndtering af tredje part er således mulig

Catalogue – the Catalogue. Line line ID action code, the whole Catalogue. Line is added, replaced or deleted! the unit that can be ordered (in relation to Base. Quantity)

Catalogue – item description (long) the name of the item (max. 40 characters) words used to optimize the search the suppliers item identification classification

Catalogue. Request n Catalogue. Request is send from the Receiver. Party to the Provider. Party n Different request parameters: n Items from a particular supplier n Items from one or more categories n Particular items n Request a Catalogue. Item. Specification. Update or a Catalogue. Pricing. Update n Request a particular language n Request that the items are classified according to a particular standard n The Catalogue. Request can be very complex n Profile Catalogue-Cat. Sim-1. 0 only allows three request parameters: n Supplier n Category n Item number

Catalogue update documents - generel n Purpose: To get simpler documents if only prices or item specifications should be updated. n Update documents can only be used, if a catalogue already exist. n The two update documents are (almost) subsets of the Catalogue document. The differences are: n Default language on the header level n Related catalogue reference – to the catalogue that must be updated n The update documents have their own line type

Catalogue. Deletion – rules n Catalogue. Deletion deletes a full catalogue n If only single items must be deleted, the Catalogue document is used n If a catalogue provider sends a new catalogue to replace an existing catalogue, it is considered good practice to delete the old catalogue in advance using a Catalogue. Deletion n The consequence of receiving a Catalogue. Deletion should be, that the items in the catalogue is no longer orderable n A Catalogue. Deletion can not be rejected by the receiver, unless it is in discrepancy with a contract between the parties.

Katalog - reference eksempler OIOUBL_Catalogue_v 2 p 1. xml OIOUBL_Catalogue. Deletion_v 2 p 1. xml OIOUBL_Catalogue. Item. Specification. Update_v 2 p 1. xml OIOUBL_Catalogue. Pricing. Update_v 2 p 1. xml OIOUBL_Catalogue. Request_v 2 p 1. xml

Øvrige - reference eksempler OIOUBL_Reminder_v 2 p 1. xml OIOUBL_Statement_v 2 p 1. xml

OIOUBL-2. 02 Utility. Statement (UTS)

Ny OIOUBL dokumenttype: Utility. Statement (UTS). n Forsyningsbranchen har med stort flertal besluttet at anvende UTS som efterfølger til OIOXML FSV n Høringsproces gennemført med godt resultat n Ændringsønsker er medtaget n UTS er forankret i UBL 2. 1 Utility. Statement (draft), tilpasset danske krav, og med dansk namespace n UTS skal (senest) køre produktion når OIOXML udfases n Branchen er indstillet på at kombinere overgangen til OIOUBL faktura/kreditnota med overgangen til UTS. n UTS pakken består af: n Dokumentguideline n Valideringspakke (XSD og Schematron) n Kodelister n Visningsstylesheets (html og MS Excel) n Eksempelfiler

Forretningsmodellen n UTS kan håndtere specifikationer for en lang række forsyningstyper samt scenarier: n Forsyning af EL, varme, vand, gas, olie etc. n Håndtering af renovation, spildevand, afledning og affald. n Teleafregninger herunder fastnet-telefon, mobiltelefon, bredbånd, video/TV, fiber etc. n Udvidet samtalespecifikation (samtlige kald fra et givent tlfnummer). n Specifikationer relateret til acontoregning, årsopgørelse, slutopgørelse, flytteopgørelse, regulering, annullering etc. n Specifikation med multiple underleverandører (f. eks. én leverandør af EL og en anden af ledningsnettet). n Specifikationer med energimærke indikering, forbrugsudvikling, gennemsnitspriser og energispareråd. n Samlefaktureringer af multiple forbrugssteder og/eller abonnementer. n Håndtering af multiafregninger (f. eks. en kommunes samlede specifikation for vand, afledning, varme og renovation). n Specifikation med ustrukturede enhedspriser (ifbm. Tele specifikationer).

UTS i forhold til FSV OIOXML PIE / PCM OIOUBL Invoice / Kreditnote OIOUBL_D_INV_20081107. xml 1 0. . n OIOUBL Utility. Statement (UTS) FSV OIOUBL_D_UTS_20081107. xml Indlejring Selvstændigt dokument

Forretningsmodellen (fortsat) UTS header 1. . n Subscriber. Consumption 0. . n Supplier. Consumption

Forretningsmodellen (fortsat) Subscriber. Consumption 1 Utility. Consumption. Point 1 Consumption 0. . n Supplier. Consumption 0. . n Utility. Meter 1 Consumption 1. . n Consumption. Line

Forretningsmodellen (fortsat) Consumption 0. . 1 Energy. Water. Supply 1 totals etc. 0. . 1 Telecommunications. Supply

Forretningsmodellen (fortsat) Energy. Water. Supply 0. . n Consumption. Report 0. . n Consumption. Average 0. . n Energy. Tax. Report 0. . n Energy. Water. Correction

Forretningsmodellen (fortsat) Telecommunications. Supply 1. . n Telecommunications. Supply. Line 1. . n Telecommunications. Service 0. . n Call. Duty 0. . n Time. Duty

Forskelle i forhold til OIOXML Forretningsmæssigt indhold Namespace Struktur

Et anderledes forretningsmæssigt indhold n Et anderledes part (Party) begreb n En anderledes håndtering af skatter og afgifter n En anderledes håndtering af gebyrer og rabatter n En anderledes angivelse af betalingsmåde- og frist n Brug af Orderable. Unit. Factor. Rate ved pris- og mængdeangivelser n Nye felter i fakturatotal

Sammenhæng med OIOXML parties OIOXML OIOUBL Originator. Customer. Party Buyer. Party (fakturering) Buyer. Party (juridisk) Buyer. Customer. Party Accounting. Customer. Party Delivery. Party Destination. Party Delivery. Address Payee. Party Seller. Party (Betaling) Seller. Party (Vareafsendelse) Accounting. Supplier. Party Seller. Supplier. Party

Et anderledes XML format n Namespace n Attributter n Kodelister n Nye klasser og elementer n Brug af CDATA i notefelt ej mere lovligt n Schematron validering n Extensible Content (kun på headerniveau) n Øgede muligheder for dokumentreferencer og indlejring

Fra e-faktura til OIOUBL-2. 01 faktura - eksempel OIOXML OIOUBL-2. 01 OU 001 V 01

Struktur for en OIOXML faktura / kreditnota Invoice Com og main Pielax. xsd <rodelement> <namespace> <xsd-reference> … ID … Type. Code … <linjesektion> … Validated. Signature Extensible. Content Dokument ID PIP, PCP, PIE, PCM etc. Digital signatur Extensible content

Pause (uofficiel) Pause!

Udvikling og aftestning Nem. Handel processen Metode fra start til slut Validering Typiske faldgruber Værktøjer

Nem. Handel proces klient henter e-Dokumentet klient laver opslag i Nem. Handel registeret 4 60 16 04 00 8 ERP-system danner e-Dokument 9 57 Udgående Nem. Handel klient ERP Nem. Handel registeret oplyser leveringssted og certifikat k. d e nd ku k@ klient sender e-Dokumentet til leveringsstedet over internettet k@kunde. dk Kvittering Indgående Modtagerens klient sender kvittering for modtagelse klient henter EAN lokationsnummer fra e-Dokumentet

Metode: Implementer dokumenter n Hvilke dokumenter skal sendes fra mit system? n Hvilke dokumenter skal jeg kunne modtage? n Skal jeg have indlæst modtagne dokumenter direkte i mit indkøbsog økonomisystem, eller vil jeg behandle dem manuelt? n Hvordan vil jeg håndtere Kvitteringen (Application. Response)? n Download dokumentation for de dokumenter, der skal implementeres på www. oioubl. info n Anvender jeg egne eller internationale standarder for mængdeenheder? n Har jeg behov for mapning fra mine interne dokumentformater til OIOUBL formatet? n Sikre at dannede dokumenter er valide

Metode: Registrering i Nem. Handel register n Kun nødvendig hvis der skal modtages dokumenter n Registreringsinformationer n Medarbejdercertifikat og kvittering for accept at betingelser n Virksomhedens navn og CVR-nummer n Hvilke profiler og dokumenter, der understøttes n Hvilken rolle (kunde eller leverandør) n Hvilke endepunkter (EAN eller CVR), der anvendes n Hvilken kommunikationstype (e-mail eller http), der anvendes n Funktionscertifikat

Metode: Test n Test genererede dokumenter n On. Line validator uhttp: //xmltools. oio. dk/oioonlinevalidator/ uhttp: //www. oioubl. info/validator/default. aspx n Test Nem. Handel systemet n Aftale mellem afsender og modtager om test n Benyt diverse Nem. Handel test-endepunkter n Benyt evt. det dedikerede Nem. Handel test-miljø

Metode: Indgå aftaler med kunder / leverandører n Hvilke krav har vi til aftaler med vores kunder/ leverandører? n Hvem indgår aftalen? n Hvem tester og sikrer at Nem. Handel bliver implementeret korrekt? n Dokumentation for mapping af kunde. ID’er, leveringssted, mængdeenheder o. lign. ? n Er der sammenhæng mellem vores kunde-/ leverandørbegreb og kundens/ leverandørens brug af dokumenterne?

Metode: Høst gevinsterne

OIOUBL validering n. Validering n Schema – validerer UBL 2. 0 syntax n Schematron – validerer semantik (og OIOUBL-2. 02 delmængde) n. OIOUBL schematron validerer følgende: n Kardinalitet for felter der er excluded i OIOUBL-2. 02 n Kardinalitet for felter der er mandatory i OIOUBL-2. 02 (men ikke i UBL 2. 0) n Feltværdier n Brug af attributter og udfaldsrum n OIOUBL-2. 02 generelle forretningsregler n OIOUBL-2. 02 profilafhængige forretningsregler n Kontrolcheck (sammentællinger, beløbsfelter etc. ) n P. t. haves 420 check i en OIOUBL-2. 02 faktura

OIOUBL schematron - arkitektur schematron kildetekst ID forretningsregel + ID schematron check(s) . XLS OIOUBL dokument guideline ID forretningsregel . XLS design . XML schematron dokumentation Build . XSL OIOUBL testinstans . XML valideringsresultat Parser . XML runtime schematron stylesheet

OIOUBL schematron – output fra validering context version + rodelement (dokumenttype) severity ID fejltekst Xpath

OIOUBL schematron - dokumentation forankring i XML struktur ID

OIOUBL schematron – indhold af kittet n 15 stk. stylesheets n Readme-filer på DK og UK n Dokumentation i form af regneark n XML parser (msxsl. exe) n 15 stk. reference dokument-instanser

OIOUBL schematron – eksekvering n Via msxsl. exe (haves i kittet) n Online validator (oioubl. info) n RASP klient / toolkit n Nemt at indbygge i scripts, programmer etc. : n Open source n. Net n VBscript (drag-and-drop til ikon på skrivebordet) n Kun fantasien sætter grænser

De værste faldgruber n Valg af systemløsning i forhold til forretningsmæssig behov n Hvis du skal kunne modtage fra det offentlige skal du kunne køre http n Vælg de rigtige profiler

De værste faldgruber (fortsat) n Dataindhold n OIOXML og OIOUBL dokumenter har forskellig struktur og indhold n Forståelse for partbegrebet og de forskellige part ID’er n Både afsender og modtager skal have et Endepunkt (EAN, CVR) n Konsistens i dataindhold ved ordre-til-faktura profiler n Håndtering af bilag n ”DK” foran SE- og CVR- numre n Adresseangivelser n Skat- og afgifter n Gebyrer n Max 40 tegn i varenavn n Enhedsbetegnelser (Unit. Of. Measure. Code-2. 0. gc) n Rabat / gebyrer på linjeniveau (er alene informative) n Afrundingsfejl

De værste faldgruber (fortsat) n XML basics n Namespace (forkert eller distribueret) n Tegnsæt (UTF-8) n Reference til xsd filen n XML tekster (escaping) n Brug af OIOUBL attributter n CDATA ej mere lovligt (ej understøttet) n Undgå tomme elementer (og klasser)

De værste faldgruber (fortsat) n Valideringsresultat kan være vanskelig at forstå n Valideringen fanger ikke alle fejl! n Forskelle mellem forskellige XSLT parsere n Noget valideres i schema (XSD) og noget i Schematron n Nedkonvertering til OIOXML n Ikke alle felter nedkonverteres! n Test derfor inden start (hent stylesheetet fra oioubl. info)

Spørgsmål Finn Christensen fch@tradeshift. com