Spørgsmål og svar om OIOUBLDenne side foklarer nogle af de mest efterspurgte emner på OIOUBL12-09-2014Profiler1I 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.
OIOUBL_GUIDE_PROFILER
http://www.oioubl.info/documents/da/da/Guidelines/OIOUBL_GUIDE_PROFILER.pdf
13Kommer NES profiler ind i dansk lovgivning?I OIOUBL bruger vi NES profil 5 og den er en del af lovgivningen. 15Nå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? og hvis man registrerer sig med Procurement-BilSim, skal man så både kunne sende og modtage fakturaer elektronisk i OIOUBL formatet?
Procurement-BilSimR er en anden registrering end Procurement-BilSim. Hvis man kan begge dele, skal man registrere begge.
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.
32* I OIOUBL 2.02 hvilken profileid kodeliste skal man bruge?urn:oioubl:id:profileid-1.2, altså 1.257* Hvilken version af NES profil 5 bruges i OIOUBL 2.02?urn:www.nesubl.eu:profiles:profile5:ver2.0Betaling2Hvad 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
Vareidentifikation3Ingen 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.Skat4TaxTotal 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. 5TaxTotal er obligatorisk på headerniveau i en Rykker. Hvad skal angives heri?I rykkeren skal kun angives den moms, der betales af rykkergebyret.Adresser6Hvordan 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
Kodelister7Hvilke 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. 8Må 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.9Hvad 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.16Findes kodelister som filerNej, 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/
60
* Skal der altid benyttes kodelister i OIOUBL?
Se nedenstående PDF for forklaring.
Kommentarer om kodelister
http://www.oioubl.info/downloads/da/FAQ60.pdf
Værktøjer10Har 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.info under menupunktet Visningsstylesheets.Namespace11Hvilke 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 signatur12Order.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.CVR14Hvordan 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
Katalog17Hvordan 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 afMan 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.
Parter18 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. 49* Hvordan håndterer man udenlandske ydelsesmodtagere i OIOUBL?
Se nedenstående PDF for forklaring.
Kommentarer om udenlandske ydelsesmodtagere
http://www.oioubl.info/downloads/da/FAQ49.pdf
DeliveryTerms20 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å linieniveauTotaler22Hvad 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.23Hvordan 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.25Hvordan 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
PriceTypeCode26* Brugen af cac:Price/cbc:PriceTypeCode
Ved en fejl er dette element sat til status _Aftales_ i OIOUBL Katalog, Ordre, OrdreÆndring og OrdreBekræftelse. Elementet skal have status _Afløftes_. I et Katalog anvendes elementet f.eks. til at angive en eventuel listepris, jf. guide OIOUBL_GUIDE_KATALOG_PRISER (G40) afsnit 4.5, og elementet skal også kunne angives jf. OIOUBL FAQ 27. Elementet skal altid angives med følgende kodeliste: cbc:PriceTypeCode listAgencyID="6" listID="UN/ECE 5387". Bemærk at elementet kun angives hvis man specifikt ønsker at fravige fra OIOUBLs default regel for prisangivelse. Bemærk også at eksemplet i G40 afsnit 4.5 anvender en forkert værdi for listID. Fejlene rettes ved næste revision af OIOUBL.
I OIOUBL er følgende kodeværdier relevante: DR (listepris) og ABE (enhedsprisen inkluderer ikke den specificerede punktafgift).
Se også: FAQ 27
XML eksempler
http://digitaliser.dk/resource/556773
Punktafgifter mv.27* Angivelse af enhedspriser med punktafgifter i OIOUBL
I OIOUBL skelnes der mellem gebyrer og punktafgifter, jf. guide OIOUBL_GUIDE_SKAT (G27) afsnit 1.2. Eventuelle punktafgifter skal i øvrigt specificeres jf. guide G27, dog med følgende undtagelse i afsnit 3.7 -angivet i vedhæftede dokument.
Se også FAQ 26 samt disse eksempler.
Punktafgifter detaljeret beskrivelse
http://www.oioubl.info/downloads/da/OIOUBL_Punktafgifter.pdf
Miljømærker mv.28* Hvordan angiver man et miljømærke i OIOUBL?
Miljømærker angives jf. guide OIOUBL_GUIDE_KATALOG_VAREBESKRIV (G38) afsnit 3.1.2.1. For at sikre en ensartet måde at angive de forskellige miljømærker på, er der udarbejdet en vejledende liste, jf. nedenfor. Det er vigtigt at understrege at IT- og Telestyrelsen ikke kan påtage sig at vedligeholde denne liste, og at den alene er vejledende. Det anbefales at anvende Kode for mærke som værdi i elementet Value, f.eks. således: cac:AdditionalItemProperty cbc:Name Mærkning /cbc:Name cbc:Value>bdih /cbc:Value /cac:AdditionalItemProperty (her vist for BDIH-mærket).
.
Se også FAQ 29 eksempler.
Opdateret miljømærkeliste
http://media.wix.com/ugd/dfcfbf_ac70a948adb84096846e648425b7e265.pdf
Miljømærke XML eksempel29* Hvordan angiver man miljømærke i XML?
Se eksemplet nedenfor i genericode
Miljømærkeliste
http://www.oioubl.info/downloads/Label-1.0.xml
CatalogueLine/ID30* Hvordan laver man en unik identifikation af kataloglinjen i CatalogueLine/ID?
Se beskrivelsen i vedhæftede dokument.
CatalogueLine/ID
http://www.oioubl.info/downloads/UniqueID.pdf
Afløftes31* Hvad betyder det, når der står Ja i kolonnen Afløftes for de enkelte felter?
Når et felt i OIOUBL er markeret som Afløftes (vises også med grå farve i OIOUBL dokument strukturen på www.OIOUBL.info), betyder det, at modtageren af dokumentet er forpligtiget til at læse indholdet af felterne, såfremt afsenderen har skrevet noget heri.
I bekendtgørelsen (Bilag 1) skelnes således mellem følgende fire typer af information:
1.Obligatorisk information skal være til stede i en elektronisk regning, for at modtageren kan anvende meddelelsen. (Felterne er altid markeret til Afløftes, og har (brug = 1))
2. Betinget information skal - såfremt de forudsætninger, der betinger den er opfyldt - være til stede i en meddelelse. (Gælder fx i forbindelse med angivelse af betalingsmåde i en faktura, hvor registreringsnummer og kontonummer skal udfyldes, såfremt man har angivet, at der er tale om en kontooverførsel)
3. Frivillig information kan være til stede i en elektronisk regning, - og modtageren har pligt til at checke om informationen er til stede, samt til at lade informationer indgå i sagsbehandlingen. (Her er der tal om de felter der er markeret til Afløftes, og som modtageren af dokumentet skal forholde sig til, såfremt der er information i felterne)
4. Aftalt information kan være til stede i en meddelelse - men modtageren har kun pligt til at checke om informationen er til stede, samt til at lade informationen indgå i sagsbehandlingen, såfremt modtageren på forhånd har erklæret sig indforstået hermed. (Markeret med Aftales)
5. Bemærk at notefeltet skal afløftes, hvilket stiller krav til modtageren af dokumentet, da indholdet er ukendt og derfor ofte ikke kan behandles maskinelt. Det betyder at Note felter kun skal benyttes, såfremt der ikke findes et dedikeret felt i OIOUBL der kan anvendes, og kun hvis indholdet har betydning for modtageren.
klassen PartyLegalEntity i klassen CustomerAccountingParty33* Hvis man har en offentlig kunde og ikke kender deres CVR/SE nummer hvad skal man så gøre?
Hvis man ikke har en offentlig kundes CVR/SE nummer er det ikke noget problem, man skal blot slette klassen PartyLegalEntity så validerer fakturaen ok i schematronen og dermed også på online validatoren.
Man er dog nødt til at fjerne hele klassen PartyLegalEntity. Validatoren vil ikke acceptere et tomt tag i CompanyID.
Afgiftskodelisten35* Er der planer om at opdatere afgiftskodelisten?
Vi undersøger behovet og vender tilbage.
Rettelser til indlejrede bilag36Kommer der forklaring til indlejrede bilag? Se linkIndlejrede bilag
http://www.oioubl.info/downloads/Indlejrede_bilag.zip
Rettelser til betalingsguideline37Kommer der rettelser til betalingsguideline? Se linkRettelser til betalingsguideline
http://www.oioubl.info/downloads/Rettelser_til_betalingsguideline.zip
Rettelser til billedet på fakura vedrørende PartyLegalEntity i CustomerAccountingParty39* Er der planer om at rette billedet vedr. PartyLegalEntity?
Der er en fejl i billedet vedr. PartyLegalEntity i CustomerAccountingParty, således at det fejlagtigt fremstår som obligatorisk. Det vil blive rettet ved en senere lejlighed. Feltet er ikke obligaorisk - jfr. spørgsmål 33 i denne FAQ .
Unit of Measure - Enhedsbetegnelser34* Er der planer om at oversætte alle enhedsbetegnelser til dansk?
Foreningen af Offentlige Indkøbere og GS1 har sammen med en række vare- og systemleverandører udarbejdet og offentliggjort danske betegnelser for de mest anvendte Unit of Measure Koder (koder for bestillingsenheder) i OIOUBL.
Koder for bestillinsenheder
https://digitaliser.dk/resource/2701453
40* Hvor finder jeg kodelisten for Unit of Measure?
På UN CEFACTs hjemmeside - se link.
UN CEFACT Unit of Measure
http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_rev3_Annex2e.pdf
44Ønsker gode råd til UOM OK - se forklaringEkstra vejledning til UOM
http://www.oioubl.info/downloads/da/FAQ44.pdf
Generelle krav til OIOUBL XML filer41Hvad er anbefaling vdrørende alias-variabel på root-elementet? Se forklaringGenerelle krav til OIOUBL XML filer
http://www.oioubl.info/downloads/da/Generellekrav.pdf
Schematron validering42* Er schematron valideringen komplet i forhold til alle offentlige regler?
Nej - se forklaring.
Kommentarer til Schematron validering
http://www.oioubl.info/downloads/da/Schematron.pdf
Dummy Data43* Er det tilladt at lave dummy data i OIOUBL?
Nej det er ikke tilladt at lave dummy data - se forklaring.
Kommentarer om Dummy data
http://www.oioubl.info/downloads/da/DummyData.pdf
Negative beløb46* Hvor må man angive negative beløb i faktura og kreditnota i OIOUBL?
Se nedenstående PDF for forklaring.
Kommentarer om Negative beløb
http://www.oioubl.info/downloads/da/FAQ46.pdf
Samlefakturaer47* Må man aflevere samlefakturaer i OIOUBL?
Se nedenstående PDF for forklaring.
Kommentarer om samlefakturaer
http://www.oioubl.info/downloads/da/FAQ47.pdf
Factoring48* Hvordan angives Factoring i OIOUBL?
Se nedenstående PDF for forklaring.
Kommentarer om Factoring
http://www.oioubl.info/downloads/da/FAQ48.pdf
SE-numre50* Hvordan angives momsnumre i OIOUBL faktura og kreditnota?
Se nedenstående PDF for forklaring.
Kommentarer om momsnumre
http://www.oioubl.info/downloads/da/FAQ50.pdf
Afrundinger51* Hvad er tilladte decimaler i OIOUBL faktura og kreditnota?
Se nedenstående PDF for forklaring.
Kommentarer om afrundinger
http://www.oioubl.info/downloads/da/FAQ51.pdf
LegalMonetaryTotal52* Hvilke elementer under LegalMonetaryTotal bør benyttes?
Se nedenstående PDF for forklaring.
Kommentarer om afrundinger
http://www.oioubl.info/downloads/da/FAQ52.pdf
Udfasning af ISO 652354* Hvad skal der ske med ISO 6523?
Se nedenstående PDF for forklaring.
Kommentarer om ISO 6523
http://www.oioubl.info/downloads/da/FAQ54.pdf
Indskannede fakturaer55* Hvordan kan man se at en fakutra er blevet indskannet?
Se nedenstående PDF for forklaring.
Kommentarer om indskannede fakturaer
http://www.oioubl.info/downloads/da/FAQ55.pdf
Whitespaces56* Må man bruge whitespaces i OIOUBL?
Se nedenstående PDF for forklaring.
Kommentarer om whitespaces
http://www.oioubl.info/downloads/da/FAQ56.pdf
Flere momssatser og TaxTotal58* Kan man ikke have flere momssatser i OIOUBL?
Se nedenstående PDF for forklaring.
Kommentarer om TaxTotal
http://www.oioubl.info/downloads/da/FAQ58.pdf
Minimumsafgift59* Hvordan angives den nye Minimumsafgift i OIOUBL?
Se nedenstående zip for forklaring.
Kommentarer om Afgifter
http://www.oioubl.info/downloads/da/FAQUTSafgifter.zip
Omvendt betalingspligt61
* Hvilke konsekvenser har de nye regler omkring omvendt betalingspligt for brugen af OIOUBL?
Se nedenstående zip for forklaring.
Kommentarer om omvendt betalingspligt
http://oioubl.info/downloads/da/FAQ61.zip
Technical Accept62
* Hvordan kan man bruge Technical Accept i OIOUBL?
Se nedenstående zip for forklaring.
Kommentarer om Technical Accept
http://oioubl.info/downloads/da/FAQ62.pdf
PictureURL63
* Hvordan skelner man i OIOUBL mellem billeder angivet som filnavn og som URL?
Se nedenstående zip for forklaring.
Kommentarer om PictureURL
http://oioubl.info/downloads/da/FAQ63.zip
Konsignationslagerordre64
* Hvordan defineres en konsignationslagerordre?
Se nedenstående PDF for forklaring.
Vejledning om konsignationslagerordre
http://oioubl.info/downloads/da/FAQ64.pdf
Hasteordre65
* Hvordan defineres en hasteordre?
Se nedenstående PDF for forklaring.
Vejledning om hasteordre
http://oioubl.info/downloads/da/FAQ65.pdf
DocumentReference66
* Hvordan fungerer DocumentReference?
Se nedenstående PDF for forklaring.
Vejledning om DocumentReference
http://oioubl.info/downloads/da/FAQ66.pdf
forskel i grafik mellem oioubl.info og guidelines67
* Hvilken grafik er den rigtige?
Se nedenstående PDF for forklaring.
Forskel i grafik
http://oioubl.info/downloads/da/FAQ67.pdf
Kodelister68
* Hvor finder man nyeste kodelister?
Se nedenstående PDF for forklaring.
Nyeste kodelister
http://oioubl.info/downloads/da/FAQ68.pdf
Business Intelligence69
* Hvordan kan man forberede Compliance og BI?
Se nedenstående PDF for forklaring.
BI
http://oioubl.info/downloads/da/FAQ69.pdf
Fakturablanketten70
*
Hvordan kan man se, at en faktura er sendt via Fakturablanketten på Virk.dk?
Se nedenstående PDF for forklaring.
Fakturablanketten
http://oioubl.info/downloads/da/FAQ70.pdf
BaseQuantity72
* Brug af BaseQuantity og OrderableUnitFactorRate
Se nedenstående PDF for forklaring.
BaseQuantity
http://www.oioubl.info/downloads/da/FAQ72.pdf
TaxCurrencyCode73
* Ændringer til brugen af TaxCurrencyCode
Se nedenstående PDF for forklaring.
TaxCurrencyCode
http://www.oioubl.info/downloads/da/FAQ73.pdf
Tolkeservice74
* Hvordan håndterer man tolkeservice?
Se nedenstående PDF for forklaring.
Tolkeservice
http://www.oioubl.info/downloads/da/FAQ74.pdf
Følsommeoplysninger75
* Hvordan håndteres følsomme oplysninger i en faktura?
Se nedenstående PDF for forklaring.
Følsommeoplysninger
http://www.oioubl.info/downloads/da/FAQ75.pdf
BIS3parter76
* Identifikation af parter og endepunkter i en BIS3 faktura?
Se nedenstående PDF for forklaring.
BIS3parter
http://www.oioubl.info/downloads/da/FAQ76.pdf