Forslag til endringer i format

Transkript

1 Forslag til endringer i format Fra: Bjørn Ravnestad [mailto:bjor@millum.no] Sendt: 25. november :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_{4681E ACE6-8FB7BBE84CED}.xml: error BEC2004: The element 'CustomContent' in namespace ' 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 ]]/> </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/ : 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=" xmlns:xsi=" xsi:schemalocation=" - <MessageHeader> <Version>1.0</Version> - <DocumentType> <DocumentCode>380</DocumentCode> <DocumentDescriptiveName>FAKTURA</DocumentDescriptiveName> </DocumentType> <MessageReference>Unknowen</MessageReference> <MessageOwner> </MessageOwner> <MessageType> </MessageType>

2 <MessageVersion>3.4</MessageVersion> <language>no</language> <DocumentContent>K</DocumentContent> <LineOfBusiness>9</LineOfBusiness> - <MessageOriginator> <Address> </Address> <SubAddress> </SubAddress> <AddressQualifier>OrgNr</AddressQualifier> </MessageOriginator> - <MessageRecipient> <Address> </Address> <SubAddress>Driftsavdeling</SubAddress> <AddressQualifier>GLN</AddressQualifier> </MessageRecipient> - <Attachment type="included"> <AttachmentType>pdf</AttachmentType> <AttachmentName> MEN pdf</AttachmentName> - <CustomContent> - <![CDATA[ Noe base64 tull ]]> </CustomContent> </Attachment> </MessageHeader> - <Invoice MessageOwner="e2b" MessageType="Invoice" MessageVersion="3.2"> <MessageNumber>123</MessageNumber> <MessageTimestamp> T13:26:16.0Z</MessageTimestamp> - <InvoiceHeader> <InvoiceType>380</InvoiceType> <InvoiceStatus>9</InvoiceStatus> <InvoiceNumber> </InvoiceNumber> <InvoiceDate> </InvoiceDate> - <Supplier> <LocationId /> <Name>Atea AS</Name> - <StreetAddress> <Address1>Brobekkvn. 115B</Address1> <PostalCode>0582</PostalCode> <PostalDistrict>Oslo</PostalDistrict> </StreetAddress> </Supplier> - <Buyer> <LocationId> </LocationId> <Name>Medirest Norge AS</Name> </Buyer> - <Invoicee> <LocationId> </LocationId> <Name>Medirest Servicekontoret</Name> </Invoicee> - <DeliveryPart> <LocationId> </LocationId> <Name>Medirest Servicekontoret</Name> </DeliveryPart> - <InvoiceReferences> <BuyersOrderNumber xmlns:xsi=" xmlns=" <BuyersProjectCode xmlns:xsi=" xmlns=" /> </InvoiceReferences> - <Payment>

3 <DueDate xmlns:xsi=" xmlns=" <Currency xmlns:xsi=" xmlns=" <KidNumber xmlns:xsi=" xmlns=" </Payment> <Attachments> MEN pdf</Attachments> - <Ref> <Code xmlns:xsi=" xmlns=" <Text xmlns:xsi=" xmlns=" </Ref> </InvoiceHeader> - <InvoiceDetails> - <BaseItemDetails xmlns:xsi=" xmlns=" <SuppliersProductId>Varer i henhold til vedlegg</suppliersproductid> <Description>Varer i henhold til vedlegg</description> <LineItemAmount> </LineItemAmount> <FreeText> HAR763852</FreeText> </BaseItemDetails> </InvoiceDetails> - <InvoiceSummary> - <InvoiceTotals xmlns:xsi=" xmlns=" <GrossAmount> </GrossAmount> <VatTotalsAmount>965.00</VatTotalsAmount> <NetAmount> </NetAmount> </InvoiceTotals> </InvoiceSummary> </Invoice> </Interchange>

4 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? 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.

5 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").

6 Juridisk innehaver som nytt felt i e2b-formatet Fra: Trine_Lise_Harms@bat.com [mailto:trine_lise_harms@bat.com] Sendt: 26. oktober :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> </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> </OrgNumber> <VatId>NO MVA</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?

7 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

8 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 " Spesifikasjon av avgiftspliktig og avgiftsfritt salg mv. Avgiftspliktig og avgiftsfritt salg, salg som nevnt i 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? 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.

9 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: e2b_invoice_interchange_v3p3.xsd (<Interchange xmlns=" xmlns:xsi=" xsi:schemalocation=" 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? 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.

10 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? Er det kun linjenivå som skal beholde fortegn? 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? 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? 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 Varelinje 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 + + +

11 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 Varelinje 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 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. 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.

12 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. 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.

13 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? 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

14 Prosjektnummer/arbeidsordrenummer Fra: Sendt: 11. november :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? 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å).