Spørgsmål og svar om OIOUBL Denne side foklarer nogle af de mest efterspurgte emner på OIOUBL 27-11-2007 Profiler 1 I processen/profilen Sælgerskabt ordre bruges dokumentet Ordreændring, identisk med den oprindelige Ordrebekræftelse, som købers accept af sælgers fremsendte Ordrebekræftelse. Hvornår er en Ordreændring identisk med en Ordrebekræftelse? Hvilke oplysninger skal sammenlignes, og hvilke af dem skal være identiske? Alle informationsfelter i Ordrebekræftelsen skal som udgangspunkt genfindes i Ordreændringen. Der vil blive udarbejdet en mere komplet liste over, hvilke felter der skal matche for at en ordreændring anses for at være kundens bekræftelse af en Ordrebekræftelse. I den udvidede indkøbsproces (som kommer medio 2008) kan man i stedet starte ordreafgivelsen med et tilbud, og kommer derved ikke ind i samme problem. OIOUBL_GUIDE_PROFILER http://www.oioubl.info/documents/da/da/Guidelines/OIOUBL_GUIDE_PROFILER.pdf 13 Kommer NES profiler ind i dansk lovgivning? Det er der ikke planlagt noget om, men der vil være mulighed for at lave en mapning mellem OIO elektronisk regning og NES 15 Når vi registrerer i UDDI'et for en vilkårlig institution, at vi kan modtage på: Procurement-BilSimR, betyder det så også, at vi samtidig understøtter Procurement-BilSim, eller kræver dette, at vi både registrerer Procurement-BilSimR og Procurement-BilSim? Procurement-BilSimR er en anden registrering end Procurement-BilSim. Hvis man kan begge dele, skal man registrere begge. Hvis man registrerer sig med Procurement-BilSim, skal man så både kunne sende og modtage fakturaer elektronisk i OIOUBL formatet? En registrering er bundet til den rolle, man spiller i udvekslingen. Hvis man registrerer sig med Procurement-BilSim som en kunde, skal man kunne modtage fakturaer, hvis man registrerer sig som leverandør skal man kunne afsende fakturaer. Betaling 2 Hvad skal anføres i CreditAccount.ID, og hvordan skal CreditAccount benyttes? KreditorNummer anvendes til at angive kreditornummer på indbetalingskort med KortArtsKode 71, 73, 75. Kreditornummer har altid 8 numeriske tegn. OIOUBL_GUIDE_BETALING.pdf side 12 http://www.oioubl.info/documents/da/da/Guidelines/OIOUBL_GUIDE_BETALING.pdf side 12 Vareidentifikation 3 Ingen vareidentifikation er obligatorisk i en faktura. Hvilken en skal man anvende, og skal man virkelig tage højde for alle tilladte typer af vareidentifikationer? Item::SellersItemIdentification er ikke obligatorisk, da buyersItemIdentification eller standardItemIdentification kan være valgt i stedet for. Det er vigtigt, at tænke over, hvor identifikationen kommer fra for at få den rigtige mapning. Her er nogle hovedregler: Når du skal sende en faktura: vælg Item::SellersItemIdentification (hvis det vel og mærke er sælgers identifikation) Når du skal modtage (og kun skal bruge én), vælg den første af følgende som er defineret {Item::SellersItemIdentification, Item::BuyersItemIdentification, Item::StandardItemIdentification} Som udgangspunkt bør man i en faktura altid angive den vareidentifikation, der er anvendt i ordren. Skat 4 TaxTotal er obligatorisk på headerniveau i et kontoudtog. Hvad skal angives heri? Det er en fejl, at TaxTotal i et kontoudtog er obligatorisk, da der ikke betales moms for et kontoudtog. Medtag derfor et TaxTotal element med nulmoms. 5 TaxTotal er obligatorisk på headerniveau i en Rykker. Hvad skal angives heri? I rykkeren skal kun angives den moms, der betales af rykkergebyret. Adresser 6 Hvordan anvendes AddressTypeCode og AddressFormatCode? AdressFormatCode styrer hvilke elementer i adressen, der skal være angivet for at adressen er valid. Man kan i AdressFomatCode både anvende værdier fra OIOUBL kodelisten, urn:oioubl:codelist:addressformatcode eller UN/CEFACT listen 3477. AdressTypeCode beskriver hvor adressen hører hjemme, dvs. om det er en privat- eller forretningsadresse. OIOUBL_GUIDE_ADRESSE http://www.oioubl.info/documents/da/da/Guidelines/OIOUBL_GUIDE_ADRESSE.pdf Kodelister 7 Hvilke atributtter skal angives for kodeværdier i OIOUBL? Hovedreglen er, at listID og schemeID skal udfyldes. For kodeværdier, der er bilateralt defineret, dvs. hvor der ikke findes en kodeliste i OIOUBL, er det valgfrit, om man ønsker at angive en kodeliste. For kodeværdier, hvor UBL har defineret kodelister, anbefales det ikke at udfylde listID og schemeID, hvis værdien vel og mærke er defineret i denne liste. Hermed vil instansen nemlig umiddelbart kunne valideres som UBL. Dette er tilfældet for PaymentMeansCode, men skal dokumentet kun bruges inden for en dansk kontekst, kommer man aldrig galt afsted ved altid at udfylde listID og schemeID. 8 Må der anvendes andre koder end dem, der er angivet i OIOUBL? Generelt er det angivet, hvis bestemte kodelister skal anvendes. For nogle kodeværdier er flere kodelister tilladte. For de bilateralt aftalte kodelister er der frit valg af kodeliste. 9 Hvad gør man, hvis man ikke har en kodeliste for den pågældende kodeværdi? Det er ikke tilladt at angive dummy værdier i OIOUBL. Hvis det ikke er muligt at angive en værdi fra en kodeliste, skal man anvende den tilsvarende tekstværdi. 16 Findes kodelister som filer Nej, ikke endnu. Det bedste vi kan levere er regneark. De internationale kodelister findes i OASIS UBL 2.0 pakken, som XML filer (generic-code, under gc biblioteket). http://docs.oasis-open.org/ubl/os-UBL-2.0/cl/gc/ Værktøjer 10 Har I planer om at skrive en konverter, der kan konvertere fra OIOXML til OIOUBL? I så fald hvornår? Ja, den kan findes på www.OIOUBL.dk under punktet Værktøjer. Konvertering mellem OIOXML elektronisk regning og OIOUBL http://www.oio.dk/dataudveksling/ehandel/OIOUBL?o=4d7d65e28884e0ffaa2ec80ac067f1cf Namespace 11 Hvilke namespace skal man anvende og kan man "beregne" sig til, hvilke namespaces, der skal medtages i en XML-fil? Det virker ikke umiddelbart som om, der er nogen simpel relation mellem anvendte namespaces og dokumenttype og/eller profil. Namespace struktruren i UBL afspejler den opdeling i skemaer, der er valgt. I realiteten er det kun CommonAggregateComponents (cac) og CommonBasicComponents (cbc), man behøver at forholde sig til, da de øvrige skemaer afspejler UBLs afhængighed af CCTS. UBL skemaafhængigheder. http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.xml#IDAG1VAB Elektronisk signatur 12 Order.Signature har en OIOUBL kardinalitet på 0..1. Er der nogen logik bagved, at den ikke har kardinaliteten 0..n, som i de øvrige dokumenter)? Nej, egentlig ikke. Normalt vil der kun være en signatur, der er relevant for sælgeren, men vi vil sætte den 0..n i næste revision, så den er samstemmende med NES. CVR 14 Hvordan er formatet for CVR? I OIOUBL har vi vedtaget, at et CVR-nummer og et SE-nummer altid har en landekode foran nummeret og ikke indeholder skilletegn, dvs. med følgende format: DK12345678 Katalog 17 Hvordan angiver man i et katalog relaterede artikler, fx hvad en computer består af eller vare som man er nødt til at købe ved siden af Man skal bruge Related Item Klasser som findes i Catalogue - se afsnit 3.4 i vores guideline omkring varebeskrivelser. De tre mest relevante må være; AccessoryRelatedItem, til at beskrive tilkøbsydelser til en computer, fx headset og højtalere. RequiredRelatedItem til elementer, som ikke er en del af selve varen, men som man er nødt til også at bestille for at den virker, fx en strømforsyning. ComponentRelatedItem, til de dele som produktet indeholder, men som også kan købes separat, typisk som reservedele, fx harddisk og lydkort. http://www.oioubl.info/guidelines/da/OIOUBL_GUIDE_KATALOG_VAREBESKRIV.pdf. Parter 18 * Hvor angiver man ydelesesmodtagere i OIOUBL? En ydelsesmodtager kan fx være en person, som får beviliget et hjælpemiddel af kommunen, men som selv laver aftale om tilpasning osv. med en leverandør. Leverandøren fremsender faktura direkte til kommunen, som derefter kan afslutte bevillingssagen ud fra CPR-nummeret. Hvis en ydelselsemodtager overtager ejerskabet af varen (fx medicin, briller, fodtøj), angives ydelselsemodtagers CPR-nummer i Delivery.DeliveryParty.PartyLegalEntity.CompanyID og med schemeID="DK:CPR". Hvis en person blot låner et hjælpemiddel af kommunen eller er modtagelsesansvarlig for et hjælpemiddel, angives personens CPR-nummer i Delivery.DeliveryParty.PartyIdentification.ID og med schemeID="DK:CPR", evt. angives blot adressen i DeliveryLocation. En eventuel udlånserklæring i den forbindelse er faktureringen uvedkommende. DeliveryTerms 20 * DeliveryTerms i Order på linje niveau er ekskluderet, mens den ikke er det i OrderResponse. Konklusion: På kort sigt frarådes det at anvende DeliveryTerms i OrderResponse på linieniveau Totaler 22 * Hvad angiver TaxExclusiveAmount i LegalMonetaryTotal? Brugen af TaxExclusiveAmount er i OIOUBL ved en fejl forskellig fra brugen i UBL 2.0. I UBL 2.0 er det momsgrundlaget, mens det i OIOUBL er defineret til at være afgiftstotalen. Den danske udlægning fastholdes i version 2.01, men leverandører af administrative systemer skal være opmærksome på, at der er forskellig udlægning og tage hensyn hertil. Journalnummer mv. 23 * Hvordan angives Journalnummer, Sagsnummer, Projektnummer, Policenummer eller lignende. Et Journalnummer eller lignende referencenummer angives i klassen cac:AdditionalDocumentReference. Nummeret angives i cbc:ID, mens cbc:DocumentTypeCode sættes til ZZZ. Typen af nummeret, f.eks. Journalnummer, angives som fritekst i cbc:DocumentType. Nummeret kan angives både på headerniveau og/eller på linjeniveau. På linjeniveau anvendes klassen cac:DocumentReference. Nedenfor haves en række eksempler i XML eksemplet. Bemærk at sådanne numre ikke vil blive overført af det automatiske OIOXML nedkonverteringsscript. XML eksempel OIOUBL_INVOICE med Journalnummer http://www.oioubl.info/downloads/da/OIOUBL_Invoice_Journalnr_v2p1.xml Leveringsadresse mv. 24 * Hvordan angives et navn i en OIOUBL leveringsadresse? Hvis man har behov for at angive et navn i en OIOUBL leveringsadresse, anvendes feltet Delivery.DeliveryLocation.Address.MarkAttention. I OIOUBL skelnes der mellem en leveringspart og en leveringsadresse. En leveringspart bør kun anvendes hvis der er behov for at angive en juridisk part _ i de fleste tilfælde vil der blot være behov for at angive en eventuel leveringsadresse. Leveringsadressen skal angives i Delivery.DeliveryLocation.Address. Men i en UBL adresseklasse, kan man ikke angive et navn, f.eks. Den Lille Skole. I stedet anvendes feltet MarkAttention til dette navn. De øvrige adressefelter anvendes på helt normal måde, jf. guide G36, OIOUBL Adresser. Bemærk at der ikke altid vil være behov for et navn i en leveringsadresse, ofte angives f.eks. blot vej, nr, by og postnr. Hvis man har behov for samtidigt at angive et navn og en attention person, angives det således: Den Lille Skole, att. Hans Hansen XML eksempel med leveringsadresse http://www.oioubl.info/downloads/da/XML_eksempel_med_leveringsadresse.xml Leveringssted mv. 25 * Hvordan udpeger man et leveringssted med et ID i OIOUBL? Hvis man har behov for at angive et ID for et leveringssted, enten i stedet for en leveringsadresse, eller sammen med en leveringsadresse, angives det i feltet Delivery.DeliveryLocation.ID. Der kan være tale om et ID forankret i en offentlig liste, f.eks. et GLN nummer, eller et ID som er gensidigt aftalt parterne imellem. I det sidste tilfælde skal attributten schemeAgencyID udpege det lokale system der vedligeholder nummerserien, og schemeID sættes til ZZZ. Se det vedhæftede eksempel. I tilknytning til IDet, kan man angive en beskrivende tekst, f.eks. Varemodtagelsen, men dette felt er alene informativt, og der bør ikke stødes logik på dette. Teksten angives i feltet Delivery.DeliveryLocation.Description. XML eksempel med ID for leveringssted http://www.oioubl.info/downloads/da/XML_eksempel_med_id_for_leveringssted.xml