Forslag til endringer i format …

Forslag til endringer i format
Fra: Bjørn Ravnestad [mailto:bjor@millum.no]
Sendt: 25. november 2010 14:27
Vi har støtt på et lite problem i forbindelse med vedlegg i e2b faktura.
Hvis dere ser på vedlegget til denne mailen så lar ikke CustomContent seg validere. Vi får
feilmeldingen...
Nets_MessageCommerceE2BInvoice_{4681E457-2631-4486-ACE6-8FB7BBE84CED}.xml: error BEC2004: The element
'CustomContent' in namespace 'http://www.e2b.no/XMLSchema' cannot contain text. List of possible elements expected: any
element in namespace '##local'.
Det er tydelig at CustomContent ikke kan inneholde tekst, men må ha et nytt element under
seg(definert med <Any>). Det er i og for seg greit, men i dokumentasjonen ”e2b Header Definition
v1p0.pdf” har dere et eksempel som sier:
<CustomContent>
<![CDATA[ -- EXCEL, formatted as “base 64” -- ]]/>
</CustomContent>
I vår xml har vi...
<CustomContent><![CDATA[Noe base64 blabla]]></CustomContent>
Sånn vi ser det bør vel CustomContent tillate å inneholde tekst for at CDATA definisjonen skal være
lovlig. Stemmer dette ?? Hvis så er tilfellet så er xsd definisjonen feil. Vi bruker forøvrig
e2b_Invoice_Interchange_v3p4.xsd til å validere eksemplet.
Vi kan unngå dette problemet ved å endre CustomContent i e2b_Common_Header_v1p01.xsd...
<xsd:element name="CustomContent" type="xsd:string" minOccurs="0"/>
...orginalt ser den slik ut...
<xsd:element name="CustomContent" type="CustomContentType" minOccurs="0"/>
…
<xsd:complexType name="CustomContentType">
<xsd:choice>
<!-- rev3-change/11.08.05: Change def. of customcontent -->
<xsd:any namespace="##local" processContents="skip" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:choice>
</xsd:complexType>
...men dette er selvsagt ikke ønskelig. Vi ønsker å bruke uendrede versjoner av xsdene.
- <Interchange xmlns="http://www.e2b.no/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.e2b.no/XMLSchemae2b_Invoice_Interchange_v3p3.xsd">
- <MessageHeader>
<Version>1.0</Version>
- <DocumentType>
<DocumentCode>380</DocumentCode>
<DocumentDescriptiveName>FAKTURA</DocumentDescriptiveName>
</DocumentType>
<MessageReference>Unknowen</MessageReference>
<MessageOwner>990224978</MessageOwner>
<MessageType>7080001064778</MessageType>
<MessageVersion>3.4</MessageVersion>
<language>NO</language>
<DocumentContent>K</DocumentContent>
<LineOfBusiness>9</LineOfBusiness>
- <MessageOriginator>
<Address>990224978</Address>
<SubAddress>990224978</SubAddress>
<AddressQualifier>OrgNr</AddressQualifier>
</MessageOriginator>
- <MessageRecipient>
<Address>7080001064778</Address>
<SubAddress>Driftsavdeling</SubAddress>
<AddressQualifier>GLN</AddressQualifier>
</MessageRecipient>
- <Attachment type="INCLUDED">
<AttachmentType>pdf</AttachmentType>
<AttachmentName>2311109009MEN206846.pdf</AttachmentName>
- <CustomContent>
- <![CDATA[
Noe base64 tull
]]>
</CustomContent>
</Attachment>
</MessageHeader>
- <Invoice MessageOwner="e2b" MessageType="Invoice" MessageVersion="3.2">
<MessageNumber>123</MessageNumber>
<MessageTimestamp>2010-11-23T13:26:16.0Z</MessageTimestamp>
- <InvoiceHeader>
<InvoiceType>380</InvoiceType>
<InvoiceStatus>9</InvoiceStatus>
<InvoiceNumber>900698232</InvoiceNumber>
<InvoiceDate>2010-10-26</InvoiceDate>
- <Supplier>
<LocationId />
<Name>Atea AS</Name>
- <StreetAddress>
<Address1>Brobekkvn. 115B</Address1>
<PostalCode>0582</PostalCode>
<PostalDistrict>Oslo</PostalDistrict>
</StreetAddress>
</Supplier>
- <Buyer>
<LocationId>7080001036140</LocationId>
<Name>Medirest Norge AS</Name>
</Buyer>
- <Invoicee>
<LocationId>7080001036140</LocationId>
<Name>Medirest Servicekontoret</Name>
</Invoicee>
- <DeliveryPart>
<LocationId>7080001036140</LocationId>
<Name>Medirest Servicekontoret</Name>
</DeliveryPart>
- <InvoiceReferences>
<BuyersOrderNumber xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">487365</BuyersOrderNumber>
<BuyersProjectCode xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema" />
</InvoiceReferences>
- <Payment>
<DueDate xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">2010-11-25</DueDate>
<Currency xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">NOK</Currency>
<KidNumber xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">9006982325</KidNumber>
</Payment>
<Attachments>2311109009MEN206846.pdf</Attachments>
- <Ref>
<Code xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">Deres_Ref</Code>
<Text xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">Kjetil</Text>
</Ref>
</InvoiceHeader>
- <InvoiceDetails>
- <BaseItemDetails xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">
<SuppliersProductId>Varer i henhold til vedlegg</SuppliersProductId>
<Description>Varer i henhold til vedlegg</Description>
<LineItemAmount>36876.05</LineItemAmount>
<FreeText>1211070008HAR763852</FreeText>
</BaseItemDetails>
</InvoiceDetails>
- <InvoiceSummary>
- <InvoiceTotals xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.e2b.no/XMLSchema">
<GrossAmount>4825.00</GrossAmount>
<VatTotalsAmount>965.00</VatTotalsAmount>
<NetAmount>3860.00</NetAmount>
</InvoiceTotals>
</InvoiceSummary>
</Invoice>
</Interchange>
Referanse-felter
Fra: Tom Kristian Thorsen - Mosoft AS/ Karl Christian Grønhaug
Spørsmål:
Nå har det kommet opp et spørsmål om "Vår referanse" i xml-filen. Dette kan typisk være navnet på
den som har laget fakturaen. Jeg finner ingenting i spesifikasjonen som forteller hvor det er lurt å
legge denne informasjonen.
Har du noen formening om hvordan dette er løst hos andre?
Svar:
Viser til henvendelse om referansefelter i formatet.
Feltene "Vår ref" og "Deres ref" kommer jo fra papirfakturaen og kan i prinsippet inneholde hva som
helst. I e2b formatet ønsket vi å ha spesifikke referansefelter og definerte derfor felter som
BuyersOrderNumber, SuppliersProjectCode, Buyer/ContactPerson/Name og
Supplier/ContactPerson/Name.
I e2b Basisprofil har man nærmet seg papirfakturaen igjen og sagt at BuyersOrderNumber tilsvarer
"Deres ref". I tillegg er det mulig å oppgi navn på Kjøper (Buyer/ContactPerson/Name). "Vår ref" er
imidlertid ikke med i Basisprofilen, men må eventuelt overføres i et PDF/TIFF-vedlegg.
Generelt i e2b Formatet kan "Vår ref" overføres i Supplier/ContactPerson/Name dersom det er navnet
på selger som skal angis.
Det har ikke vært diskutert å ta inn feltene "Vår ref" og "Deres ref" i e2b formatet. Men det er selvsagt
mulig å foreslå dette, så får Formatgruppen vurdere om dette skal tas inn i en ny versjon.
Flere koder til bruk i TypeTravel (bransjetillegg)
Truls Kjøniksen, ViaTravel
Spørsmål:
Vi har ett ønske om forbedring - i bransetillegget for reiseliv. I taggen <TypeTravelType> er det kun
definert 4 "produktgrupper" (eller type reise). Dette viser seg å være litt for snevert for oss - og våre
kunder.
>I dag finnes 4 verdier i valideringskjemaet;
>
><xsd:simpleType name="TypeTravelType">
>
<xsd:restriction base="xsd:token">
>
<xsd:enumeration value="bus"/>
>
<xsd:enumeration value="air"/>
>
<xsd:enumeration value="sea"/>
>
<xsd:enumeration value="trn"/>
>
</xsd:restriction>
></xsd:simpleType>
Er det mulig å få med noen flere grupperinger - vi har andre produkter som overhode ikke passer inn i
noen av de 4 som er definert. Vi har følgende ønsker - hva selve verdien blir er ikke så viktig for oss
bare vi får inn flere grupper;
Hotell
- "hot"
Billeie
- "car"
Forsikring - "ins"
Honorarer - "fee"
Annet
- "oth"
Som sagt - verdiene er ikke så viktige for oss (selv om jeg har satt opp noen forslag) - men vi trenger
sårt noen flere grupperingen.
Jeg har også satt opp en gruppe for "Annet" - som kanskje kan virke litt malplassert - men vi har f.eks.
mye sjømannstrafikk (mannskap som skal med fly - til gitte havner for å mønstre på skip) - disse
skaffer vi også visum for - og det er en del statlige gebyrer får å utstedt visum. Disse kostnadene er
ikke uvesentlige for våre marine kunder og de ønsker dem spesifisert (og da utenfor gruppen "air").
Juridisk innehaver som nytt felt i e2b-formatet
Fra: Trine_Lise_Harms@bat.com [mailto:Trine_Lise_Harms@bat.com]
Sendt: 26. oktober 2010 09:40
Reitan Servicehandel har ønsker om å få inn et nytt felt - Juridisk innehaver - i oversendelse av faktura
i XML format.
Dette behovet begrunnes med å kunne skille ut den juridiske innehaver etter overdragelsesrekkefølge,
der RSH selv kan overta drift av et utsalgssted i en periode inntil ny driver er på plass.
Dagens informasjon i seksjon "Buyer" i XML er:
- <Buyer>
<LocationId>7080000095810</LocationId>
<Name>NARVESEN 580 ENSJØ T-BANE</Name>
- <PostalAddress>
<Address1>ENSJØ T-BANESTASJON</Address1>
<PostalCode>0655</PostalCode>
<PostalDistrict>OSLO</PostalDistrict>
<CountryCode>NO</CountryCode>
</PostalAddress>
<OrgNumber>990565503</OrgNumber>
<VatId>NO990565503MVA</VatId>
</Buyer>
Våre faktura i papirformat er opplyst med Juridisk innehaver (Se vedlegg). Dette feltet er ønskelig
overført også på faktura i XML format.
Spørsmål i denne forbindelse :
• Hvor bør ny informasjon ligge - i seksjon "Buyer" eller må det lages opp en ny seksjon?
• Lar dette seg gjøre uten at det påvirker eller har konsekvenser for andre mottakere av faktura i
XML format?
Svar:
Vi har ikke Juridisk innehaver i e2b-formatet i dag, så det må eventuelt tas inn som som et nytt felt.
Slike endringer må behandles og godkjennes i e2b Formatgruppe, og vil da medføre en ny versjon av
formatet
Spesifisering av MVA
Universitetet i Bergen, Ingvild I. Larsen
Spørsmål:
Jeg har et spørsål vedr spesifisering av mva.
Ref bokføringsforskriften
"
§ 5-1-5. Spesifikasjon av avgiftspliktig og avgiftsfritt salg mv.
Avgiftspliktig og avgiftsfritt salg, salg som nevnt i § 5-1-1 nr. 7, samt salg som er unntatt
merverdiavgiftsloven etter bestemmelsene i merverdiavgiftsloven kapittel 3, skal fremgå hver for seg
og summeres særskilt. Det samme gjelder dersom avgiftspliktig omsetning avgiftsberegnes etter
forskjellige satser.
"
Ut fra dette har vi to ulike typer omsetning som begge gir 0%-mva, men som da skal spesifiseres
særskilt:
1. Omsetning innenfor mva-loven, men da med 0% mva (avgiftsfritt)
2. Omsetning utenfor mva-loven (unntatt).
Hvordan spesifiseres dette i e2b-formatet?
Svar:
I e2b er det teknisk mulig å angi flere Mva-totaler med samme prosentsats, men det er ikke mulig å
spesifisere hva disse gjelder for.
Det eneste som kan angis er Prosentsats, Mva-grunnlag og Mva-beløp. Så eventuelt må man ha en
regel som sier at den første forekomsten med 0% er omsetning innenfor Mva-loven og den andre er
omsetning utenfor Mva-loven.
BBS/bankene feil bruk av formatet
Stine Marconini Bjerke, Storebrand
Spørsmål:
Vi jobber med en efakturaløsning nå, i samarbeid med BBS. Vi bruker e2b-format versjon 3.3. Vi skal
inn i en testfase nå og i den forbindelse har vi kjørt validering av vår xml mot schema lastet ned fra
e2b.no:
http://www.e2b.no/XMLSchema e2b_Invoice_Interchange_v3p3.xsd
(<Interchange xmlns="http://www.e2b.no/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.e2b.no/XMLSchema e2b_Invoice_Interchange_v3p3.xsd">)
I dokumentasjonen for e2b lastet ned fra samme nettsted er feltet <InvoiceType> definert som type
String.
Men hvis jeg legger inn en String i dette feltet (som BBS ønsker) får jeg feilmelding ved validering mot
schema.
Feltet i xml’en:
<InvoiceType codetext="Invoice">INV11</InvoiceType>
Feilmeldingen:
INV11 is not a valid value for ‘integer’
Ser at verdiene 380 og 381 ligger i deres eksempel og det fungerer jo, men typen står jo til String og
det er det BBS benytter.
Er det et avvik mellom definisjon og schema eller har vi satt opp feltet feil?
Svar:
Du har oppdaget et avvik mellom Dokumentasjon og XML Schema for InvoiceType, så dette må vi
rette opp i neste utgivelse.
Men, dette har ikke noen praktisk betydning fordi de eneste lovlige verdiene i InvoiceType er 380 eller
381. Så bruk av ”INV11” ville uansett gitt feilmelding.
Og det bekymrer meg at bankene og BBS avviker fra standard i sin bruk av e2b-formatet.
Presiseringer av gjeldende format
Negative fortegn i faktura
Spørsmål:
Brødrene Dahl tilbyr idag våre kunder å motta e2b-faktura i versjon 3.4. Vi har imidlertid ikke hatt
negative fortegn i våre fakturaer, noe som skaper en del utfordringer for våre kunder. Vi har hittil gjemt
oss bak at e2b-formatet tidligere ikke støttet, og at vi ikke ønsket å skape "trøbbel" for allerede
etablerte e2b-kunder. Vi har også argumentert med at fakturatotalen er riktig, men får nå
tilbakemelding om at det ikke er ved godkjenning av fakturaen, men ved viderefakturering fortegnet er
viktig. Kunden vet ikke om de skal kreditere eller viderefakturere sine kunder. PDF-ene inneholder full
informasjon, men de kan ikke sitte å dobbeltsjekke hver faktura fra oss.
Dokumentasjonen til e2b sier følgende (2.5 Utfylling av beløpsfelter):
"Beløp på linjenivå som skal legges til Fakturatotalen skal være positive både for Faktura og
Kreditnota. Beløpet på linjenivå som skal trekkes fra Fakturatotalen skal ha negativt fortegn både på
faktura og kredittnota."
Men vi er litt usikre på hva håndteringen av negativt fortegn:
Er det kun linjenivå som skal beholde fortegn?
Og hva med ordrerabatter?
Hva gjøres på kredittnota? Der skal vel 381 styre at sluttsummen er negativ. Hva gjøres på
varelinjene?
Svar:
Er det kun linjenivå som skal beholde fortegn?
Svar: Et linjebeløp som skal legges til totalen skal alltid være positivt uavhengig av
om totalen skal faktureres eller krediteres. Negativt fortegn kan forekomme dersom
det f.eks. er en bestilling som ikke kan leveres og dette blir en motpostering i
fakturaen. Dette linjebeløpet vil da være negativt både i faktura og kreditnota.
Og hva med ordrerabatter?
Svar: En ordrerabatt er positiv og skal trekkes fra totalen.
Hva gjøres på kredittnota? Der skal vel 381 styre at sluttsummen er negativ. Hva gjøres på
varelinjene?
Svar: Et linjebeløp som skal legges til totalbeløpet for kreditering skal være positivt.
Konkrete eksempler for bruk av negativt fortegn i e2b
Enkel faktura
Eksempel: En enkel faktura som inneholder kun ordinære varelinjer, men ordrerabatt.
InvoiceType = 380
Kommentar
Dagens løsning
Vårt forslag
E2b sier
+
Varelinje 1
+
+
+
Varelinje 2
+
+
+
Ordrerabatt
+
+
Mva
+
+
Total sum
+
+
+
Enkel kreditnota
Eksempel: En enkel faktura som inneholder kun retur av varelinjer, men returgebyr.
InvoiceType = 381
Kommentar
Dagens løsning
Vårt forslag
E2b sier
+
Varelinje 1 i retur
+
+
+
Varelinje 2 i retur
+
+
+
Returgebyr
+
+
Mva
+
+
Total sum
+
+
+
Sammensatt faktura
Eksempel: Faktura som inneholder både vanlige varelinjer og retur av andre. Summen er positiv.
InvoiceType = 380
Kommentar
Dagens løsning
Vårt forslag
E2b sier
+
Varelinje 1
+
+
+
Varelinje 2
+
+
Varelinje 3 i retur
+
+
Returgebyr
+
+
Mva
+
+
Total sum
+
+
+
Sammensatt kredittnota
Eksempel: Kreditnota som inneholder både vanlige varelinjer og retur av andre. Summen blir negativ.
InvoiceType = 381
Kommentar
Dagens løsning
Vårt forslag
E2b sier
Varelinje 1
+
+
Varelinje 2 i retur
+
+
+
Varelinje 3 i retur
+
+
+
Returgebyr
+
+
Mva
+
+
Total sum
+
+
+
Oppfølgingsspørsmål:
Gjelder dette også dersom vi legger returgebyret og ordrerabatten som en varelinje? Slik dere foreslår
at det gjøres vil ikke sluttsummen bli riktig.
Svar:
Dersom dere legger returgebyr og ordrerabatt som varelinjer må dere ha med fortegn.
Sluttsummen bør jo bli riktig dersom dere tar høyde for at en rabatt skal trekkes fra totalen selv om det
ikke har negativt fortegn.
Fortegn på beløp og kode for kreditnota/faktura
Karl Christian Grønhaug, UniMicro
Spørsmål:
Fortegn på beløp og kode for om faktura er en kreditnota eller en faktura. Hvis jeg har forstått ting
korrekt så er det InvoiceType som styrer om det er kredittnota eller faktura, men hva hvis innholdet
(linjesummene som alltid skal være +/- i henhold til om de øker eller minsker totalbeløpet) ender opp
med et negativt tall? Vil jeg da i praksis ha en faktura som er en kredittnota pga. at totalsum av linjene
men som er flagget som en faktura? Se vedlegg "faktura_e2b_eksempel.pdf" for hvordan jeg tror det
slår ut, og korriger meg hvis jeg tar feil. Hodepinen her er hvorvidt jeg må ta stilling til om totalsum
ender over/under 0,- og ev. endre InvoiceType og ev. invertere alle beløp i henhold til sluttresultat på
utregningen.
Svar:
Det er ikke et krav i formatet at fakturatotalen skal være positiv, så dette må avtales bilateralt eller av
bransjer. Vi vet f.eks. at Dagligvare ikke godtar negative totaler, så her skal alle beløp snus og
InvoiceType settes til 381 dersom en faktura tilfeldigvis skulle få negativ fakturatotal som i eksempel 2.
Dersom man vet at det blir mange slike situasjoner er det viktig å definere klare regler for dette, og da
er Dagligvares regel veldig ryddig selv om den medfører noe ekstra programmering.
Valuta
Karl Christian Grønhaug, UniMicro
Spørsmål
Dersom fakturaen er i annen valuta enn NOK (for eksempel USD) skal da alle valutareferansefelt og
samtlige beløp være i USD med unntak av ExchangeInformation delen?
Eksempel:
-----------------------------------* Payment.Currency - "USD"
* InvoiceSummary. InvoiceTotals - Beløp I USD
* InvoiceDetails. BaseItemDetails. UnitPrice - Pris I USD
* InvoiceDetails. BaseItemDetails. LineItemAmount - Linjebeløp I USD
* InvoiceDetails. BaseItemDetails. LineItemAmount.ExchangeInformation.Currency - USD
* InvoiceDetails. BaseItemDetails. LineItemAmount.ExchangeInformation.ForeignAmount- Beløp I
NOK
* InvoiceDetails. BaseItemDetails. LineItemAmount.ExchangeInformation.ExchangeRate Vekslingskurs brukt (I tilfelle hvilken vei? Eksempelvis "5,9786" eller "0,1672" ?)
-----------------------------------Alternativt skal alt være i NOK med unntak av ExchangeInformation? Ev. en kombinasjon med NOK i
Payment og USD på linjer eller omvendt?
Svar:
1. Vekslingsinformasjon kan angis for den valuta som gjaldt på brukerstedet. Dersom dette er en
kortfaktura i USD og en av fakturalinjene gjelder bruk av kortet i Norge skal dette angis som følger:
* Payment.Currency = "USD" + at alle beløp skal angis i USD
* InvoiceDetails. BaseItemDetails. LineItemAmount.ExchangeInformation.Currency = "NOK"
* InvoiceDetails. BaseItemDetails. LineItemAmount.ExchangeInformation.ForeignAmount = Beløp i
NOK
* InvoiceDetails. BaseItemDetails. LineItemAmount.ExchangeInformation.ExchangeRate =
Vekslingskurs for omregning fra NOK til USD
Prosjektnummer/arbeidsordrenummer
Fra: finn.heggelund@solarnorge.no [mailto:finn.heggelund@solarnorge.no]
Sendt: 11. november 2010 00:28
Spørsmål:
e2b 3.x versjonen har i InvoiceReferences en tag for BuyersProjectCode. I Elektro-bransjen brukes
begrep som (overordnet) Prosjektnr. og (underliggende) Arbeidsordrenr. Det siste er ordrenr. brukt ut
mot sluttkunde. Det kan være flere Arbeidsordrenr. knyttet mot et Prosjektnr./Prosjekt-avtale. Det ser
ut som flere legger Arbeidsordrenr. i BuyerProjectCode. Er det riktig bruk ift. tag-beskrivelsen ? Hvor
skal da Prosjektnr. legges? RefWithCodeType ? Er det laget standardiserte verdier for Code-feltet
under REF-tag ?
Svar:
I e2b er det mulig å referere til en ordre/bestilling og eventuelt et prosjektnummer som bestillingen er
knyttet til.
Slik jeg tolker arbeidsordrenummer ville jeg anbefalt å legge det i BuyersOrderNumber og prosjektnr. i
BuyersProjectCode
Det er ikke laget standardiserte verdier for Ref/Code.
Oppfølgingsspørsmål:
Finn Heggelund [finn.heggelund@solarnorge.no]
Det er akkurat her det tolkes forskjellig fra kunde til kunde.
BuyersOrderNumber står beskrevet i 3.1 som Bestillingsnr., og er obligatorisk som "nøkkel"-ID ifm.
elektroniske ordre.
Jeg ser på det som et Bestillings/Innkjøps-nr., der det kan forekomme flere innkjøp pr. Arbeidsordrenr.
Jeg er enig at BuyersProjectCode burde vært brukt til prosjektnr., men her er det flere kunder som
ønsker Arbeidsordrenr. istedenfor.
Derfor bør e2b faktura-beskrivelsen gjøres mer tydelig på disse 2 referanse-felt, og evt. forklare hva
som menes med bestillingsnr., ordrenr. og prosjektnr.
Evt. om hvilke Ref-tags som skal brukes i tillegg (under Partner-nivå eller under Invoice-nivå).