Teknisk håndbok SPESIFIKASJON Påmelding i XML-FORMAT versjon 2.9-1 -
Dokumentansvarlig: Terje Dahl Endringslogg Ver. Kap. Beskrivelse av endring Sign. forf. Sign. dok.ansv. Dato 1.0 2.0 Alle endringer fra 1.0 til 2.0 (fjernet fra endringslogg) Tormod Engen Rodi Kristiansen 01.01.01 2.3 3.1 5.1 ServiceProviderName skal fylles ut med 8080. Men i en overgangsfase vil allikevel Thor sendes ut fra BBS, og BBS aksepterer dette som gyldig verdi fra eksisterende utstedere. 2.4 4.1 Endret beskrivelse av TAG er for Country og State. Det presiseres nå at feltet kan komme utfylt fra BBS, hvis kunde/nettbank har fylt ut feltet ved avtaleinngåelse. 2.5 3.4 TAG for EnrollmentDelete manglet i DTD for requestfil. 2.6 5.4 Endret DTD: Fra <!ELEMENT ServiceProvider (ServiceProviderName, ServiceProviderID?, ServiceID?)> til <!ELEMENT ServiceProvider (ServiceProviderName, ServiceProviderID, ServiceID)> Som gjør at ServiceProviderID, ServiceID blir valgfrie da de kun skal benyttes I toinfo Terje Dahl 05.11.02 Terje Dahl 20.03.03 Terje Dahl 26.10.04 Terje Dahl 25.02.08 2.7 3.3.2. Fjernet dette kapitelet, da Terje Dahl 24.02.09 2
det ikke lenger sendes ut endringsmeldinger på aktive avtaler. Aktive avtaler hvor status ikke endres blir ikke sendt ikke til utsteder, da disse allerede er validert OK 2.9 3.1 Gyldig verdi for ServiceProviderName endres fra 8080 til THOR Rita Nordtug 29.05.13 3
1 INNLEDNING... 5 1.1 FORMÅL MED DOKUMENTET... 5 1.2 MÅLGRUPPE... 5 1.3 KONTAKTPERSONER I BBS... 5 2 FUNKSJONALITET... 6 2.1 OVERORDNET BESKRIVELSE... 6 2.2 FORSENDELSE... 6 2.3 OPPDRAG... 6 2.4 TRANSAKSJONSNIVÅ... 6 2.5 XML STANDARD (REQUEST/RESPONSE)... 7 2.6 FLYTSKJEMA... 8 2.7 TABELLER SOM BENYTTES I DETTE DOKUMENT... 9 3 SPESIFIKASJON AV REQUEST FILEN FRA BBS... 11 3.1 FORSENDELSESNIVÅ... 11 3.2 OPPDRAGSNIVÅ... 12 3.3 VEDLEGG... 13 3.3.1 Forespørsel om ny efaktura avtale i request fra BBS... 13 3.3.1.1 Forespørsel om ny efaktura-avtale... 13 3.3.1.2 Kvittering fra BBS på godkjent forespørsel om ny efaktura-avtale... 16 3.3.1.3 Kvittering fra BBS på avvist forespørsel om ny efaktura-avtale... 18 3.3.2 Melding om sletting av eksisterende efaktura-avtale i request fra BBS... 20 3.3.2.1 Melding til utsteder om sletting av aktiv efaktura-avtale... 20 3.4 DTD... 22 4 OVERSIKT OVER MELDINGER SOM KAN SENDES I REQUEST FILEN FRA BBS... 24 4.1 ENROLLMENTADD (NY EFAKTURA AVTALE), ENROLLMENTCHANGE (ENDRING EFAKTURA AVTALE), ELLER ENROLLMENTDELETE (MELDING OM SLETTING AV EFAKTURA AVTALE)... 24 4.1.1 Ulike meldingstyper & krav til utsteder's behandling av disse... 27 4.1.2 Behandling av felter i Request filen... 30 4.1.3 Svarfrist, purring & sletting av efaktura avtale... 31 4.1.4 Kvittering / verifikasjon i request-fil... 32 5 SPESIFIKASJON AV RESPONSE FILEN FRA UTSTEDER... 33 5.1 FORSENDELSESNIVÅ... 33 5.2 OPPDRAGSNIVÅ... 34 5.3 VEDLEGG... 35 5.3.1 Svar på forespørsel om ny efaktura-avtale i response fra utsteder... 35 5.3.1.1 Svar på Forespørsel om ny efaktura-avtale (Utsteder godkjenner avtalen)... 35 5.3.1.2 Svar på Forespørsel om ny efaktura-avtale (Utsteder avviser avtalen)... 37 5.3.2 Svar på forespørsel om endring av eksisterende efaktura-avtale i repsonse fra BBS... 39 5.3.2.1 Svar på forespørsel om endring av efaktura-avtale (Utsteder godkjenner endringen)... 39 5.3.2.2 Svar på forespørsel om endring av efaktura-avtale (Utsteder avviser endringen)... 41 5.4 DTD... 43 5.5 XSD SCHEMA... 43 6 OVERSIKT OVER MELDINGER SOM KAN SENDES I RESPONSE FILEN... 47 6.1 ENROLLMENTADD ELLER ENROLLMENTCHANGE... 47 6.1.1 Hvordan svare på request fil i response filen... 49 6.1.2 Krav til felter som må fylles ut i response filen... 51 4
1 Innledning 1.1 Formål med dokumentet Dokumentet er opprettet for å vise hvilken filstruktur utstedere må forholde seg til i kommunikasjonen med BBS for å kunne behandle koblingsfiler. Utsteder/ partner vil med hjelp av dette dokumentet kunne lage en automatisk rutine som leser og prosesserer requestfiler, og på bakgrunn av prosesseringen lage en response-fil som kan sendes tilbake til BBS. 1.2 Målgruppe Målgruppen til dette dokumentet er de personer hos utsteder og eventuelle samarbeidspartnere som skal involveres i arbeidet med å vurdere og lage en automatisk rutine for godkjenning og avvisning av efaktura-avtaler. 1.3 Kontaktpersoner i BBS Har du spørsmål til funksjonalitet omtalt i dette dokumentet: Utsteder ta kontakt med Biller Team. 5
2 Funksjonalitet 2.1 Overordnet beskrivelse Request fil (forespørsel fra kunde og kvitteringer) En xml-fil kalt request-fil sendes fra BBS til utsteder. Filen inneholder/ kan inneholde: Forespørsel om nye efaktura-avtale fra kunde i nettbank Forespørsel om endring av eksisterende efaktura-avtale fra kunde i nettbank Melding om at kunde har slettet sin efaktura-avtale Kvittering / verifikasjon på at BBS har oppdatert efaktura avtale status i sitt system på bakgrunn av svar fra utsteder (response-filen). Dette gjelder svar på forespørsel om ny efaktura-avtale eller forespørsel om endring av efaktura-avtale. Response fil (svar fra utsteder) Utsteder sender en xml fil kalt response filen til BBS. Filen inneholder / kan inneholde: Svar på forespørsel om ny efaktura-avtale fra kunde (utsteder validerer & godkjenner kunde) Svar på forespørsel om ny efaktura-avtale fra kunde (utsteder validerer & avviser kunde) Svar på forespørsel om endring på eksisterende efaktura-avtale fra kunde (utsteder validerer & godkjenner) Svar på forespørsel om endring på eksisterende efaktura-avtale fra kunde (utsteder validerer & avviser) 2.2 Forsendelse En forsendelse er øverste nivå og skal kun forekomme 1 gang pr. fil. Forsendelsesnivå inneholder informasjon om avsender, mottaker og dato for forsendelsen. Forsendelsesnivå skal alltid fylles ut. 2.3 Oppdrag Oppdrags nivå forekommer en til flere ganger under forsendelsesnivå, typisk en gang per utsteder. Et oppdrag identifiserer et sett med transaksjoner tilhørende en utsteder. Oppdragsnivå skal alltid fylles ut. 2.4 Transaksjonsnivå Transaksjonsnivå inneholder informasjon om den enkelte transaksjon. Det kan være fra 1 til x antall detaljtransaksjoner på dette nivå. 6
2.5 XML Standard (request/response) Formatet på request / response filer for kundevalidering er XML 1.0. Request & response filen skal behandles i.h.h.t dtd og følge xml 1.0 standarden. Spesifikasjonene for XML 1.0 finner du på www.w3.org. Vi gjør spesielt oppmerksom på at: XML standarden er case sensitive, dvs at store og små bokstaver må benyttes som henvist i dette dokumentet. 7
2.6 Flytskjema Her kommer et flytskjema som beskriver flyten mellom de ulike aktører og forklarer prosessen fra en kunde gjør en forespørsel om ny eller endring av efaktura avtale med utsteder og utsteder validerer og enten godkjenner / avviser forespørsel fra kunde. BBS sender kvittering til utsteder på at BBS har behandlet svaret. Når denne prosessen er utført er utsteder klar til å sende efaktura til kunde (hvis godkjent efaktura avtale). Figur 1 2. Nettbank registrerer avtale i efaktura-systemet. Avtale vises i nettbank som "avventende" BBS 3. BBS sender request-fil til utsteder 5. I nettbank vises avtale som godkjent eller avslått 6.BBS sender kvittering til utsteder 4. Utsteder sender response-fil til BBS Nettbank Utsteder 1. Forbruker registrerer at han ønsker å motta efaktura fra en utsteder Forbruker 8
2.7 Tabeller som benyttes i dette dokument Tabellene som benyttes for å beskrive forsendelse, oppdrag og detaljnivå forklares på følgende måte. TAG BESKRIVELSE FORMAT Beskriver tag som benyttes i xml Beskriver hva tag gjør Beskriver hvilket format innholdet av tag 9
3 Spesifikasjon av request filen fra BBS 3.1 Forsendelsesnivå Forsendelsesnivå er øverste nivå i en fil. Forsendelsesnivået forteller noe om hvilket fakturahotellet/utsteder som sender inn detaljtransaksjonene. TAG BESKRIVELSE FORMAT <?xml version="1.0" encoding="iso-8859-1"?> Koden skal stå øverst i filen for å sikre rett formatering/ tegnsett på Xml-filen. <Message> Message markerer start og slutt på meldingen. - <Request> Header informasjon om fakturaen. - <FromInfo> Informasjon under FromInfo forteller hvem som sendte fila. - <ServiceProvider> - - <ServiceProviderName> <ToInfo> <ServiceProvider> Alltid verdien : THOR ServiceProviderName skal fylles ut med THOR. Informasjon under ToInfo forteller hvem fila skal til. numerisk, 4 posisjoner Alltid THOR - - <ServiceProviderID> Forteller hvem som skal motta filen. Alfanumerisk, 15 posisjoner Foretaksnummer F.eks. NOR123456789-1 <ServiceID> Alltid 1 Numerisk, 1 posisjon 11
3.2 Oppdragsnivå Oppdragsnivå inneholder informasjon om hvilken utsteder som sender inn detaljtransaksjonene. Følgende tabell gir en oversikt over hvilke elementer som er nødvendig for å definere et oppdrag. TAG BESKRIVELSE FORMAT <EnrollmentRQ> Inneholder flere transaksjoner. En transaksjon kan være en forespørsel om ny efaktura avtale eller endring av efaktura avtale eller kvittering på oppdatert efaktura avtale fra BBS på vegne av utsteder. - 12
3.3 Vedlegg Ny efaktura-avtale forespørsel i request filen Forespørsel om endring på eksisterende efaktura-avtale i request filen Sletting av efaktura-avtale i request filen 3.3.1 Forespørsel om ny efaktura avtale i request fra BBS 3.3.1.1 Forespørsel om ny efaktura-avtale Denne forespørselen inneholder efaktura avtale-informasjon fylt ut av kunde i nettbank. Denne informasjonen må utsteder benytte for å validere om kunde virkelig er kunde hos utsteder. Utsteder kan enten godta eller avslå denne forespørselen i response til BBS <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Request> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> </Request> <EnrollmentRQ> <EnrollmentAdd> <AccountInfoRecord> <PortalInfo> <PortalEnrollmentStatus> <![CDATA[A]]> </PortalEnrollmentStatus> 13
</PortalInfo> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerUserName /> <BillerPassword /> <BillerEnrollmentStatus> <![CDATA[P]]> </BillerEnrollmentStatus> </BillerInfo> <UserInfo> <FirstName> <![CDATA[Fornavn]]> </FirstName> <LastName> <![CDATA[Etternavn]]> </LastName> <DayPhone /> <Email /> <UserAddress> <Address1> <![CDATA[adr1]]> </Address1> <Address2> <![CDATA[]]> </Address2> <City> <![CDATA[Oslo]]> </City> <State /> <PostalCode> <![CDATA[0045]]> </PostalCode> <Country> <![CDATA[NO]]> </Country> </UserAddress> </UserInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfg876df68 = =]]> </ThorUserId> </ThorInfo> 14
<ThorUserKey/> </AccountInfoRecord> </EnrollmentAdd> </EnrollmentRQ> </Message> 15
3.3.1.2 Kvittering fra BBS på godkjent forespørsel om ny efaktura-avtale Utsteder har godkjent forespørsel om ny efaktura-avtale sendt i response fil til BBS. BBS sender kvittering på at BBS har godkjent efaktura avtalen på vegne av utsteder, tilbake til utsteder. Denne kvitteringen skal utsteder bruke til å starte efaktura for kunden. <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Request> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> </Request> <EnrollmentRQ> <EnrollmentChange> <AccountInfoRecord> <PortalInfo> <PortalEnrollmentStatus> <![CDATA[A]]> </PortalEnrollmentStatus> </PortalInfo> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerUserName /> <BillerPassword /> <BillerEnrollmentStatus> <![CDATA[A]]> </BillerEnrollmentStatus> </BillerInfo> <UserInfo> 16
<FirstName /> <LastName /> <DayPhone /> <Email /> <UserAddress> <Address1 /> <Address2 /> <City /> <State /> <PostalCode /> <Country /> </UserAddress> </UserInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfgsdgsd87454 = =]]> </ThorUserId> </ThorInfo> <ThorUserKey /> </AccountInfoRecord> </EnrollmentChange> </EnrollmentRQ> </Message> 17
3.3.1.3 Kvittering fra BBS på avvist forespørsel om ny efaktura-avtale Utsteder har sendt response med avslag av forespørsel om ny efaktura-avtale til BBS. BBS sender kvittering på at BBS har avvist avtalen og gitt kunde beskjed om avvisningsårsak på vegne av utsteder. <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Request> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> </Request> <EnrollmentRQ> <EnrollmentChange> <AccountInfoRecord> <PortalInfo> <PortalEnrollmentStatus> <![CDATA[A]]> </PortalEnrollmentStatus> </PortalInfo> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerUserName /> <BillerPassword /> <BillerEnrollmentStatus> <![CDATA[N]]> </BillerEnrollmentStatus> </BillerInfo> <UserInfo> 18
<FirstName /> <LastName /> <DayPhone /> <Email /> <UserAddress> <Address1 /> <Address2 /> <City /> <State /> <PostalCode /> <Country /> </UserAddress> </UserInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> <![CDATA[ddfgdfgfd56dfg876df68 = =]]> </ThorUserId> </ThorInfo> <ThorUserKey /> </AccountInfoRecord> </EnrollmentChange> </EnrollmentRQ> </Message> 19
3.3.2 Melding om sletting av eksisterende efaktura-avtale i request fra BBS Kunde har slettet sin efaktura-avtale med utsteder i sin nettbank. Melding om sletting blir sendt fra BBS til utsteder.utsteder må da slette efaktura avtalen og sende vanlig papir faktura til kunde. 3.3.2.1 Melding til utsteder om sletting av aktiv efaktura-avtale <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Request> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> </Request> <EnrollmentRQ> <EnrollmentDelete> <AccountInfoRecord> <PortalInfo> <PortalEnrollmentStatus> <![CDATA[A]]> </PortalEnrollmentStatus> </PortalInfo> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerUserName /> <BillerPassword /> <BillerEnrollmentStatus> <![CDATA[D]]> 20
</BillerEnrollmentStatus> </BillerInfo> <UserInfo> <FirstName /> <LastName /> <DayPhone /> <Email /> <UserAddress> <Address1 /> <Address2 /> <City /> <State /> <PostalCode /> <Country /> </UserAddress> </UserInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg8s7876df86sd8sdf6 = =]]> </ThorUserId> </ThorInfo> <ThorUserKey /> </AccountInfoRecord> </EnrollmentDelete> </EnrollmentRQ> </Message> 21
3.4 DTD <!-- Definitions Request files --> <!ELEMENT Message (Request, EnrollmentRQ+)> <!ELEMENT Request (FromInfo, ToInfo)> <!ELEMENT FromInfo (ServiceProvider)> <!ELEMENT ServiceProvider (ServiceProviderName, ServiceProviderID, ServiceID)> <!ELEMENT ServiceProviderName (#PCDATA)> <!ELEMENT ServiceProviderID (#PCDATA)> <!ELEMENT ServiceID (#PCDATA)> <!ELEMENT ToInfo (ServiceProvider)> <!ELEMENT EnrollmentRQ (EnrollmentAdd?, EnrollmentDelete?, EnrollmentChange?)> <!ELEMENT EnrollmentAdd (AccountInfoRecord)> <!ELEMENT EnrollmentDelete (AccountInfoRecord)> <!ELEMENT EnrollmentChange (AccountInfoRecord)> <!ELEMENT AccountInfoRecord (PortalInfo, BillerInfo, UserInfo, ThorInfo, ThorUserKey)> <!ELEMENT PortalInfo (PortalEnrollmentStatus)> <!ELEMENT PortalEnrollmentStatus (#PCDATA)> <!ELEMENT BillerInfo (BillerAccountNumber, BillerUserName, BillerPassword, BillerEnrollmentStatus )> <!ELEMENT BillerAccountNumber (#PCDATA)> <!ELEMENT BillerUserName (#PCDATA)> <!ELEMENT BillerPassword (#PCDATA)> <!ELEMENT BillerEnrollmentStatus (#PCDATA)> <!ELEMENT UserInfo (FirstName, LastName, DayPhone, Email, UserAddress)> <!ELEMENT FirstName (#PCDATA)> <!ELEMENT LastName (#PCDATA)> <!ELEMENT DayPhone (#PCDATA)> <!ELEMENT Email (#PCDATA)> <!ELEMENT UserAddress (Address1, Address2, City, State, PostalCode, Country)> <!ELEMENT Address1 (#PCDATA)> <!ELEMENT Address2 (#PCDATA)> <!ELEMENT City (#PCDATA)> <!ELEMENT State (#PCDATA)> <!ELEMENT PostalCode (#PCDATA)> <!ELEMENT Country (#PCDATA)> <!ELEMENT ThorInfo (ThorContentProviderId, ThorUserId)> <!ELEMENT ThorContentProviderId (#PCDATA)> <!ELEMENT ThorUserId (#PCDATA)> <!ELEMENT ThorUserKey (#PCDATA)> 22
23
4 Oversikt over meldinger som kan sendes i request filen fra BBS Transaksjonsnivå forteller noe om hvilken type transaksjoner et oppdrag inneholder. Følgende tabell gir en oversikt over hvilke elementer som er nødvendig for å definere et betalingsoppdrag. 4.1 EnrollmentAdd (ny efaktura avtale), EnrollmentChange (Endring efaktura avtale), eller EnrollmentDelete (Melding om sletting av efaktura avtale) TAG BESKRIVELSE FORMAT <EnrollmentAdd> eller <EnrollmentChange> eller <EnrollmentDelete> Add = Ny avtale forespørsel Change = Endring forespørsel Delete = kunde sletter avtale - <AccountInfoRecord> Informasjon om avtalen grupper i : - PortalInfo BillerInfo (utsteder) UserInfo (Kunde) <PortalInfo> Portal informasjon om avtalen - <PortalEnrollmentStatus> Er implementert mest med tanke på Alfanumerisk, 1 posisjon fremtidig funksjonalitet. PortalEnrollmentStatus vil i normalsituasjoner ha en bokstav som verdi. Alltid = A <BillerInfo> Utsteder informasjon om avtalen - <BillerAccountNumber> Kundens kundenummer hos utstederen <BillerUserName> <BillerPassword> Viktig at utsteder returnerer samme verdi fra dette feltet i response filen. Kundens brukernavn hos utstederen. For fremtidig bruk. Kundens passord hos utstederen. For fremtidig bruk Alfanumerisk, 32 posisjoner Vil være blankt. 0 posisjoner Vil være blankt. 0 posisjoner 24
<BillerEnrollmentStatus> Gyldige statuser : P = forespørsel om ny eller endring av efaktura avtale Alfanumerisk, 1 posisjon A = kvittering på godkjent forespørsel om ny eller endring av efaktura avtale N = kvittering på avvist forespørsel om ny efaktura avtale D = kvittering på avvist forespørsel om endring av efaktura avtale Dette feltet må benyttes i validering mot utsteder kunderegister. <UserInfo> Informasjon om kunde - <FirstName> Kundens fornavn Alfanumerisk, 50 posisjoner Dette feltet bør benyttes i validering mot utsteder kunderegister. <LastName> Kundens etternavn Alfanumerisk, 50 posisjoner Dette feltet bør benyttes i validering mot utsteder kunderegister. <DayPhone> Fylles ikke ut. Vil være blankt. Ikke ibruk Tagg forekommer : <DayPhone /> <Email> Fylles ikke ut. Vil være blankt. Ikke ibruk Tagg forekommer : <Email /> <UserAddress> Informasjon om kundens adresse - <Address1> Vanligvis kundens gateadresse Alfanumerisk, 50 posisjoner <Address2> Benyttes dersom man behøver et ekstra Alfanumerisk, 50 felt til adressen. Vil ofte være tom. posisjoner <City> Kundens poststed Alfanumerisk, 50 posisjoner <State> I dagens løsning kan det sendes data Alfanumerisk, 30 med denne taggen, men det er ikke noe krav. Taggen må imidlertid alltid sendes med. Enten på formatet <State></State> eller <State/>. <PostalCode> Kundens postnummer Alfanumerisk, 20 posisjoner <Country> I dagens løsning kan det sendes data Alfanumerisk, 30 med denne taggen, men det er ikke noe krav. Taggen må imidlertid alltid sendes med. Enten på formatet <Country></Country> eller <Country/>. <ThorInfo> - 25
<ThorContentProviderId> <ThorUserId> <ThorUserKey> Utsteder's organisasjonsnummer Viktig at utsteder sender samme verdi tilbake til BBS i response fil. Kundens Id i efaktura systemet. Dette feltet inneholder en kryptert verdien. Viktig at utsteder sender samme verdi tilbake til BBS i response fil. I dagens løsning sendes ikke data med denne taggen. Taggen må imidlertid likevel sendes med. Enten på formatet <ThorUserKey></ ThorUserKey > eller < ThorUserKey />. Alfanumerisk, 14 posisjoner F.eks. NOR123456789-1 Alfanumerisk, 35 posisjoner Ikke ibruk Hvis det eventuelt kommer en verdi i dette feltet trenger ikke den å behandles av utsteder. 26
4.1.1 Ulike meldingstyper & krav til utsteder's behandling av disse Tabellen under beskriver de ulike meldingstyper med tilhørende status som utsteder kan motta fra BBS i request filen. Videre nedenfor beskrives hvilke krav utsteder må følge ved prosessering av de ulike meldingene. Case MedlingsType Fil Forklaring Status 1 AvtaleLages Request Forespørsel om ny efaktura avtale EnrollmentAdd BillerEnrollmentStatus = P 2 AvtaleEndres Request Forespørsel om endring av efaktura avtale EnrollmentChange BillerEnrollmentStatus = P 3 AvtaleSlettes Request Melding om sletting av EnrollmentDelete efaktura avtale. Utsteder BillerEnrollmentStatus = D stopper efaktura for kunde. 5 AvtaleKvittering Request Kvittering på avvist EnrollmentChange Ny = 4 Endring = 5 Tabell 1 forespørsel om endring AvtaleKvittering Request Kvittering på godkjent forespørsel om ny avtale eller endring av avtale 4 AvtaleKvittering Request Kvittering på avvist forespørsel om ny efaktura-avtale BillerEnrollmentStatus = D EnrollmentChange BillerEnrollmentStatus = A EnrollmentChange BillerEnrollmentStatus = N (Forklaring til case Ny4 & endring=5: Dette fordi kvittering på godkjent forespørsel om ny avtale eller endring av eksisterende avtale sendes med samme tag og samme BillerEnrollmentStatus = A) 27
Når utsteder leser request-filen skal følgende gjøres: Prosessere informasjon i <ToInfo> & <FromInfo> Lese avtaler, sjekke om de enten er : Ref. Tabell 1 : Case 1 (EnrollmentAdd) BillerEnrollmentStatus = P : Sjekk om efakturabruker er kunde av utsteder. Utsteder må validere informasjon i forespørselen om kunden er kunde av utsteder og at informasjonen stemmer. Hvis Ja: Godkjenn avtalen og send informasjon om dette til BBS i response-filen. Hvis Nei: Send informasjon til BBS om at kunde er nektet efaktura-avtale samt en begrunnelse for dette i response-filen. Mulig begrunnelser for avslag er beskrevet i spesifikasjon av response filen. Ref. Tabell 1: Case 2 (EnrollmentChange) BillerEnrollmentStatus = P : Når utsteder mottar en endringsforespørsel skal efaktura-referansen sjekkes mot utsteder's register. Hvis kunde er merket som efaktura bruker i utsteder's register: Godkjenn endringen. Hvis kunde ikke er merket som efaktura bruker i utsteder register : Behandle endringsforespørsel som det var en ny avtale. Validere kunde og Sjekk om efakturabruker er kunde av utsteder. Hvis Ja: Godkjenn avtalen og send informasjon om dette til BBS i response-filen. Hvis Nei: Send informasjon til BBS om at forespørsel om endring er avvist samt en begrunnelse for dette i response-filen. Mulig begrunnelser for avslag er beskrevet i spesifikasjon av response filen. Når utsteder avviser forespørsel om endring av efaktura-avtale vil kundens efaktura avtale opphøre og utsteder må oppdatere sitt register og stoppe efaktura for denne kunden. Konsekvens: Kunde vil ikke lenger ha mulighet til å betale sine utestående efaktura betalingskrav i efaktura-tjenesten. 28
Ref. Tabell 1: Case 3 (EnrollmentDelete) BillerEnrollmentStatus = D : Sjekk om kunde er registrert som efaktura bruker i utsteder register. Hvis Ja: Stopp efaktura for denne kunden og send papir faktura i fremtiden. Dette er melding om at kunde ikke lenger ønsker og få sin regning sendt som efaktura men vil ha den på vanlig papir. Eksisterende ubetalte/betalte efaktura krav vil ikke lenger være tilgjengelig for kunde. Hvis Nei: Overse søknaden. Ref. Tabell 1: Case 4 (EnrollmentChange) BillerEnrollmentStatus = A eller N : Hvis BillerEnrollmentStatus = A: Utsteder kan starte/opprettholde efaktura for denne kunden. Neste regning sendes som efaktura. Hvis BillerEnrollmentStatus = N: Kvittering på at BBS har avvist forespørsel om efaktura avtale og gitt kunde beskjed om avvisningsårsak på vegne av utsteder. Ref. Tabell 1: Case 5 (EnrollmentChange) BillerEnrollmentStatus = A eller D : Hvis BillerEnrollmentStatus = A: Utsteder kan starte/opprettholde efaktura for denne kunden. Neste regning sendes som efaktura. Hvis BillerEnrollmentStatus = D: Kvittering på at BBS har avvist forespørsel om endring av efaktura avtalen og gitt kunde beskjed om avvisningsårsak på vegne av utsteder. Utsteder må stoppe efaktura for denne kunden. 29
4.1.2 Behandling av felter i Request filen Det er viktig at utsteder behandler alle felter i request filen etter spesifikasjonen av request filen. Spesielt viktig er : <BillerAccountNumber>, <ThorContentProviderId & ThorUserId Disse 3 feltene er til sammen identifikator for avtalen hos BBS. For at BBS skal vite hvilken avtale utsteder svarer på må utsteder: BillerAccountNumber: Ved mottak/returnering av BillerAccountNumber hos utsteder skal det taes høyde for feltlengde på 32 karakterer. Det er viktig at utsteder returnerer eksakt samme verdi som de mottar. ThorContentProviderId: Ved mottak/returnering av ThorContentProviderId hos utsteder skal det taes høyde for feltlengde på 14 karakterer. ThorUserId: Ved mottak/returnering av ThorUserId hos utsteder skal det taes høyde for feltlengde på 35 karakterer. Det er viktig at hele verdien returneres BBS. Ellers vil ikke BBS oppdatere avtalen. Validering av kunde-informasjon på request fil mot utstederens kunderegister: Feltet BillerAccountNumber må benyttes i valideringsprosessen mot utsteder kunderegister. I tillegg bør det valideres mot enten feltet fornavn eller etternavn eller begge deler. Dette for at utsteder skal forsikre seg om at kunden er den han oppgir seg for å være. Tagger det gjelder: MÅ benyttes: <BillerAccountNumber> sammens med <FirstName> eller <LastName> 30
4.1.3 Svarfrist, purring & sletting av efaktura avtale Utsteder s svarfrist Svarfrist på forespørsler om ny efaktura avtale eller endring på eksisterende efaktura avtale: Utstedere må svare på request-fil ihht. avtale med BBS. BBS sender purring Hvis utsteder ikke svarer på forespørsler om ny efaktura avtale eller endring på eksisterende efaktura avtale ihht. til avtale med BBS vil BBS sende purring på de efakrua avtaler det gjelder. Purringene vil bli sendt på akkurat samme format i request filen som de ble sendt første gang til utsteder. Melding om sletting av efaktura avtale Når kunde sletter sin avtale med utsteder fra sin nettbank, sender BBS melding om sletting av efaktura avtale til utsteder request filen. Utsteder må da slette denne kunde i sitt efaktura register og stoppe efaktura for denne kunden. Utsteder skal ikke returnere svar på dette til BBS. 31
4.1.4 Kvittering / verifikasjon i request-fil Utsteder skal ikke svare på kvitteringer. Kvittering vil bli sendt utsteder i 3 tilfeller: 1. Ref. Tabell 1: Case 4 eller 5 (EnrollmentChange) BillerEnrollmentStatus = A : Beskrivelse av Scenario: Utsteder har tidligere mottatt forespørsel om ny efaktura-avtale eller endring av eksisterende efaktura-avtale, godkjenner avtalen / endringen i response fil til BBS. BBS svarer i neste request-fil med kvittering/verifikasjon på at BBS har oppdatert sitt efaktura avtale register på bakgrunn av response-fil fra utsteder. Utsteder s handling: Utsteder skal bruke denne kvitteringen til å starte efaktura eller videreføre efaktura for kunden. 2. Ref. Tabell 1: Case 4 (EnrollmentChange) BillerEnrollmentStatus = N : Beskrivelse av Scenario: Utsteder har tidligere mottatt forespørsel om ny efaktura-avtale, avslår forespørselen om ny efaktura avtale i response fil til BBS. BBS svarer med kvittering på at BBS har oppdatert sitt efaktura avtale register på bakgrunn av response-fil fra utsteder. Utsteder s handling: Kunde som sendte forespørsel er ikke kunde av utsteder. Utsteder skal ikke utføre noen handling ved mottak av denne kvitteringen. 3. Ref. Tabell 1: Case 5 (EnrollmentChange) BillerEnrollmentStatus = D : Beskrivelse av Scenario: Utsteder har tidligere mottatt request-fil med forespørsel om endring av allerede aktiv efaktura-avtale, og avslått denne i response-fil til BBS. BBS sender kvittering på at efakturaavtalen er deaktivert i BBS sitt system. Utsteder s handling: Utsteder må stoppe efaktura for denne kunden. 32
5 Spesifikasjon av response filen fra utsteder 5.1 Forsendelsesnivå Forsendelsesnivå er øverste nivå meldingen. Forsendelsesnivå inneholder informasjon om avsender og mottaker av ut forsendelsen. TAG BESKRIVELSE FORMAT <?xml version="1.0" encoding="iso-8859-1"?> Koden skal stå øverst i filen for å sikre rett formatering/ tegnsett på Xml-filen. <Message> Message markerer start og slutt på meldingen. - <Response> Header informasjon om fakturaen. - <FromInfo> Informasjon under FromInfo forteller hvem som sendte fila. - <ServiceProvider> - - <ServiceProviderName> Alltid verdien : 8080 ServiceProviderName skal fylles ut med 8080. Men i en overgangsfase vil allikevel Thor sendes ut fra BBS, og BBS vil akseptere dette som gyldig verdi fra eksisterende utstedere i denne fasen. <ToInfo> Informasjon under ToInfo forteller hvem fila skal til. <ServiceProvider> numerisk, 4 posisjoner Alltid 8080 - - <ServiceProviderID> Forteller hvem som skal motta filen. Alfanumerisk, 15 posisjoner Foretaksnummer F.eks. NOR123456789-1 <ServiceID> Alltid 1 Numerisk, 1 posisjon 33
5.2 Oppdragsnivå Oppdragsnivå er et svar på de oppdrag som kom på inn forsendelsen. Her vil det ligge informasjon om hvilket oppdrag det er svar på og fra hvilken inn forsendelse oppdraget tilhører. TAG BESKRIVELSE FORMAT <EnrollmentRS> Inneholder flere transaksjoner (EnrollmentAdd eller EnrollmentChange). En transaksjon kan være en forespørsel om ny avtale eller endring av avtale eller kvittering på oppdatert avtale fra BBS på vegne av utsteder. - 34
5.3 Vedlegg Svar på forespørsel om ny efaktura-avtale i response filen Svar på forespørsel om endring på eksisterende efaktura-avtale i response filen 5.3.1 Svar på forespørsel om ny efaktura-avtale i response fra utsteder 5.3.1.1 Svar på Forespørsel om ny efaktura-avtale (Utsteder godkjenner avtalen) Utsteder kan velge å godta eller avslå denne forespørselen. Dette er vist i eksempel nedenfor <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Response> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> <Status/> </Response> <EnrollmentRS> <EnrollmentAdd> <AccountInfoRecord> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerEnrollmentStatus> <![CDATA[A]]> </BillerEnrollmentStatus> 35
<BillerReason/> <BillerMessage/> </BillerInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dsfg35676df68 = =]]> </ThorUserId> </ThorInfo> <ThorUserSignature> </ThorUserSignature> </AccountInfoRecord> </EnrollmentAdd> </EnrollmentRS> </Message> 36
5.3.1.2 Svar på Forespørsel om ny efaktura-avtale (Utsteder avviser avtalen) <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Response> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> <Status/> </Response> <EnrollmentRS> <EnrollmentAdd> <AccountInfoRecord> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerEnrollmentStatus> <![CDATA[N]]> </BillerEnrollmentStatus> <BillerReason> <![CDATA[01]]> </BillerReason> <BillerMessage> <![CDATA[Oppgitt efaktura referanse er ugyldig (se papirfaktura)]]> </BillerMessage> </BillerInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> 37
<![CDATA[dfhgdfgdfg45345 ==]]> </ThorUserId> </ThorInfo> <ThorUserSignature /> </AccountInfoRecord> </EnrollmentAdd> </EnrollmentRS> </Message> 38
5.3.2 Svar på forespørsel om endring av eksisterende efaktura-avtale i repsonse fra BBS I efaktura tjenesten kan kunde endre sin allerede eksisterende efaktura-avtale. Meldingsflyt for slike endringer mellom BBS og utsteder er beskrevet i dette kapittelet. 5.3.2.1 Svar på forespørsel om endring av efaktura-avtale (Utsteder godkjenner endringen) <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Response> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> <Status/> </Response> <EnrollmentRS> <EnrollmentChange> <AccountInfoRecord> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerEnrollmentStatus> <![CDATA[A]]> </BillerEnrollmentStatus> <BillerReason/> <BillerMessage/> </BillerInfo> 39
<ThorInfo> <ThorContentProviderId> <![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfg876df346568 = =]]> </ThorUserId> </ThorInfo> <ThorUserSignature/> </AccountInfoRecord> </EnrollmentChange> </EnrollmentRS> </Message> 40
5.3.2.2 Svar på forespørsel om endring av efaktura-avtale (Utsteder avviser endringen) Utsteder har avvist forespørsel om endring av eksisterende efaktura-avtale. <?xml version="1.0" encoding="iso-8859-1"?> <Message> <Response> <FromInfo> <ServiceProvider> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProvider> <ServiceProviderID> <![CDATA[NOR999999999-1]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> <Status/> </Response> <EnrollmentRS> <EnrollmentChange> <AccountInfoRecord> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerEnrollmentStatus> <![CDATA[N]]> </BillerEnrollmentStatus> <BillerReason> <![CDATA[01]]> </BillerReason> <BillerMessage> <![CDATA[Oppgitt efaktura referanse er ugyldig (se papirfaktura)]]> </BillerMessage> </BillerInfo> <ThorInfo> <ThorContentProviderId> 41
<![CDATA[NOR999999999-1]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfg245876df68 = =]]> </ThorUserId> </ThorInfo> <ThorUserSignature/> </AccountInfoRecord> </EnrollmentChange> </EnrollmentRS> </Message> 42
5.4 DTD <!-- Definitions Response files --> <!ELEMENT Message (Response, EnrollmentRS+)> <!ELEMENT Response (FromInfo, ToInfo, Status)> <!ELEMENT FromInfo (ServiceProvider)> <!ELEMENT ServiceProvider (ServiceProviderName, ServiceProviderID?, ServiceID?)> <!ELEMENT ServiceProviderName (#PCDATA)> <!ELEMENT ServiceProviderID (#PCDATA)> <!ELEMENT ServiceID (#PCDATA)> <!ELEMENT ToInfo (ServiceProvider)> <!ELEMENT Status (#PCDATA)> <!ELEMENT EnrollmentRS (EnrollmentAdd?, EnrollmentChange?)> <!ELEMENT EnrollmentAdd (AccountInfoRecord)> <!ELEMENT EnrollmentChange (AccountInfoRecord)> <!ELEMENT AccountInfoRecord (BillerInfo, ThorInfo, ThorUserSignature)> <!ELEMENT BillerInfo (BillerAccountNumber, BillerEnrollmentStatus, BillerReason, BillerMessage)> <!ELEMENT BillerAccountNumber (#PCDATA)> <!ELEMENT BillerEnrollmentStatus (#PCDATA)> <!ELEMENT BillerReason (#PCDATA)> <!ELEMENT BillerMessage (#PCDATA)> <!ELEMENT ThorInfo (ThorContentProviderId, ThorUserId)> <!ELEMENT ThorContentProviderId (#PCDATA)> <!ELEMENT ThorUserId (#PCDATA)> <!ELEMENT ThorUserSignature (#PCDATA)> 5.5 XSD Schema Filvedlegget under fungerer ikke hvis du sitter med denne filen I PDF-format. Ellers kan du dobbeltklikke for å se på filen. Innholdet i XSD for de som mottar spesifikasjonen som PDF, ligger som liten tekst under for kopiering til annen editor.. <?xml version="1.0" encoding="iso-8859-1"?> <!-- Denne xsd er ment for distribusjon til utstedere dvs innsendere av response filer. --> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema"> <xs:element name="message"> <xs:complextype> <xs:sequence> 43
<xs:element name="response" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="fileinfo" minoccurs="0" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="consignmentid" type="xs:string" minoccurs="1" maxoccurs="1"/> <xs:element name="commissionid" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> </xs:complextype> <xs:element name="frominfo" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="serviceprovider" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="serviceprovidername" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:pattern value="8080 Thor THOR"/> </xs:restriction> </xs:simpletype> </xs:sequence> </xs:complextype> </xs:sequence> </xs:complextype> <xs:element name="toinfo" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="serviceprovider" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="serviceproviderid" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:minlength value='14'/> <xs:maxlength value='14'/> </xs:restriction> </xs:simpletype> <xs:element name="serviceid" type="xs:string" minoccurs="1" maxoccurs="1" /> <xs:element name="serviceproviderfilereference" type="xs:string" minoccurs="0" maxoccurs="1" /> </xs:sequence> </xs:complextype> </xs:sequence> </xs:complextype> <xs:element name="status" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> </xs:complextype> <xs:element name="enrollmentrs" minoccurs="1" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="contentproviderinfo" minoccurs="0" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="contentproviderfilereference" type="xs:string" minoccurs="0" maxoccurs="1"/> </xs:sequence> </xs:complextype> <xs:element name="enrollmentadd" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="accountinforecord" minoccurs="1" maxoccurs="1"> <xs:complextype> 44
<xs:sequence> <xs:element name="billerinfo" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="billeraccountnumber" type="xs:string" minoccurs="1" maxoccurs="1" /> <xs:element name="billerenrollmentstatus" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:pattern value='a N'/> </xs:restriction> </xs:simpletype> <xs:element name="billerreason" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:pattern value="01 02 03 "/> </xs:restriction> </xs:simpletype> <xs:element name="billermessage" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> </xs:complextype> <xs:element name="thorinfo" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="thorcontentproviderid" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:minlength value='14'/> <xs:maxlength value='14'/> </xs:restriction> </xs:simpletype> <xs:element name="thoruserid" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:minlength value='1'/> </xs:restriction> </xs:simpletype> </xs:sequence> </xs:complextype> <xs:element name="thorusersignature" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> </xs:complextype> </xs:sequence> </xs:complextype> <xs:element name="enrollmentchange" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="accountinforecord" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="billerinfo" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="billeraccountnumber" type="xs:string" minoccurs="1" maxoccurs="1" /> <xs:element name="billerenrollmentstatus" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:pattern value='a N'/> </xs:restriction> </xs:simpletype> <xs:element name="billerreason" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> 45
<xs:pattern value="01 02 03 "/> </xs:restriction> </xs:simpletype> <xs:element name="billermessage" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> </xs:complextype> <xs:element name="thorinfo" minoccurs="1" maxoccurs="1"> <xs:complextype> <xs:sequence> <xs:element name="thorcontentproviderid" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:minlength value='14'/> <xs:maxlength value='14'/> </xs:restriction> </xs:simpletype> <xs:element name="thoruserid" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:whitespace value="collapse"/> <xs:minlength value='1'/> </xs:restriction> </xs:simpletype> </xs:sequence> </xs:complextype> <xs:element name="thorusersignature" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> </xs:complextype> </xs:sequence> </xs:complextype> </xs:sequence> </xs:complextype> </xs:sequence> </xs:complextype> </xs:schema> 46
6 Oversikt over meldinger som kan sendes i response filen 6.1 EnrollmentAdd eller EnrollmentChange TAG BESKRIVELSE FORMAT <EnrollmentAdd> eller <EnrollmentChange> Add = Ny avtale forespørsel Change = Endring forespørsel Delete = kunde sletter avtale - <AccountInfoRecord> Informasjon om avtalen grupper i : PortalInfo BillerInfo (utsteder) UserInfo (Kunde) <BillerInfo> Utsteder informasjon om avtalen - <BillerAccountNumber> Kundens kundenummer hos utstederen <BillerEnrollmentStatus> <BillerReason> Viktig!! at utsteder returnerer samme verdi fra dette feltet i response filen. Dette fordi BBS ellers ikke vil klare å oppdatere avtale forespørsel med utsteder's svar. Enten Status A eller N A = Utsteder godkjenner forespørsel N = Utsteder avviser forespørsel Skal fylles ut hvis BillerEnrollmentStatus = N Alfanumerisk, 32 posisjoner Alfanumerisk,1 posisjon Alfanumerisk, 2 posisjoner - <BillerMessage> BillerReason er en tallkode som forteller årsaken til avslaget på søknaden. Lovlige verdier er; 01, 02, 03 Skal fylles ut hvis BillerEnrollmentStatus = N BillerMessage er et tekstfelt som med ord beskriver årsaken gitt i BillerReason. Lovlige verdier er; Oppgitt efaktura referanse er ugyldig (se papirfaktura) (BillerReason 01) Oppgitte personopplysninger er ikke i samsvar med Kunderegister (se papirfaktura) (BillerReason 02) Det tilbys ikke efaktura for dette produktet (BillerReason 03) Alfanumerisk, max 100 posisjoner 47
<ThorInfo> <ThorContentProviderId> <ThorUserId> Utsteder's organisasjonsnummer Benytt samme verdi som mottatt på request filen. Kundens Id i efaktura systemet. Dette feltet vi inneholde denne verdien kryptert. - Alfanumerisk, 14 posisjoner F.eks. NOR123456789-1 Alfanumerisk, 35 posisjoner <ThorUserSignature> Viktig at utsteder sender eksakt samme verdi tilbake til BBS i response fil. I dagens løsning sendes ikke data med denne taggen. Taggen må imidlertid likevel sendes med. Enten på formatet < ThorUserSignature ></ ThorUserSignature > eller < ThorUserSignature />. Ikke ibruk 48
6.1.1 Hvordan svare på request fil i response filen Her beskrives hvilke statuser og meldingstyper utsteder skal benytte for å enten godkjenne / avvise : Forespørsler om ny efaktura avtale Forespørsler om endring av efaktura avtale Case meldingstype Fil Forklaring Status 1 AvtaleLages Response Godkjent forespørsel om ny EnrollmentAdd efaktura avtale. BillerEnrollmentStatus = A 2 AvtaleLages Response Avvist forespørsel om ny efaktura avtale. EnrollmentAdd BillerEnrollmentStatus = N 3 AvtaleEndres Response Godkjent forespørsel om endring av efaktura avtale. EnrollmentChange BillerEnrollmentStatus = A 4 AvtaleEndres Response Avvist forespørsel om endring av efaktura avtale. EnrollmentChange BillerEnrollmentStatus = N Tabell 2 Ref. Tabell 2: Case 1 (EnrollmentAdd) BillerEnrollmentStatus = A : Utsteder har mottatt forespørsel om ny efaktura avtale i request fra BBS og ønsker å godkjenne denne i response fil til BBS. Utsteder må vente til kvittering fra BBS på å starte efaktura for denne kunden. Ref. Tabell 2: Case 2 (EnrollmentAdd) BillerEnrollmentStatus = N : Utsteder har mottatt forespørsel om ny efaktura avtale i request fra BBS og ønsker å avvise denne i response fil til BBS. Utsteder vil motta kvittering fra BBS på at forespørselen om efaktura avtalen er avvist og avvisningsårsak blitt meddelt kunde. Ref. Tabell 2: Case 3 (EnrollmentChange) BillerEnrollmentStatus = A : Utsteder har mottatt forespørsel i request fil fra BBS om endring av eksisterende efaktura avtale og ønsker å godkjenne denne forespørselen. Hvis forespørselen gjelder en tidligere avvist avtale skal utsteder vente på kvittering fra BBS for så å starte efaktura for denne kunden. Hvis forespørselen gjelder en allerede aktiv avtale skal utsteder fortsette efaktura som vanlig for denne kunden. 49
Ref. Tabell 2: Case 4 (EnrollmentChange) BillerEnrollmentStatus = D : Utsteder har mottatt forespørsel i request fil fra BBS om endring av eksisterende efaktura avtale og ønsker å avvise denne forespørselen. Hvis forespørselen gjelder en tidligere avvist avtale skal utsteder ikke gjøre noen ting. Hvis forespørselen gjelder en allerede aktiv avtale skal utsteder stoppe efaktura for denne kunden. 50
6.1.2 Krav til felter som må fylles ut i response filen Det er viktig at alle felter i response filen blir fylt ut ihht. spesifikasjonen for response filen. Spesielt gjelder dette feltene : <BillerEnrollmentStatus>, <BillerReason> og <BillerMessage> Disse feltene skal benyttes av utsteder til å godkjenne eller avvise forespørsler utsteder mottar og eventuelt (ved avvisning) gi kunde en avvisningsårsak. <BillerEnrollmentStatus> Status A for godkjent forespørsel om ny eller endring av efaktura-avtale Status N for avslått forespørsel om ny eller endring av efaktura- avtale <BillerReason> Skal fylles ut hvis <BillerEnrollmentStatus> = N <BillerMessage> Skal fylles ut hvis <BillerEnrollmentStatus> = N <BillerAccountNumber>, <ThorContentProviderId> og <ThorUserId> Disse 3 feltene er til sammen identifikator for avtalen hos BBS. For at BBS skal vite hvilken avtale utsteder svarer på må utsteder: <BillerAccountNumber> Skal inneholde efaktura koblingsbegrep for den efaktura-avtalen det gjelder. Hvis kunden har fylt ut feil efaktura referanse skal hele efaktura referanse som er feil returneres i response filen. <ThorContentProviderId> Skal Inneholde samme verdi som i spesifisert i ThorContentProviderId i request filen. (Utsteder s organisasjonsnummer) Dette er utsteder s id i BBS sitt system og brukes til å identifisere avtalen som skal oppdateres. F.eks. NOR123456789-1 <ThorUserId> Skal Inneholde samme verdi som mottatt i request-filen. Dette er forbrukerens id i BBS sitt system og brukes til å identifisere avtalen som skal oppdateres. F.eks. l2kj45l2kj52lkj452lk5j = = 51