Teknisk håndbok efaktura Spesifikasjon Påmelding i XML-format Innhold

Transkript

1 Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat Innhold Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 1 33

2 1 FUNKSJONALITET OVERORDNET BESKRIVELSE... 3 REQUEST FIL (FORESPØRSEL FRA KUNDE OG KVITTERINGER)... 3 RESPONSE FIL (SVAR FRA UTSTEDER) FORSENDELSE OPPDRAG TRANSAKSJONSNIVÅ XML STANDARD (REQUEST/RESPONSE) FLYTSKJEMA TABELLER SOM BENYTTES I DETTE DOKUMENT SPESIFIKASJON AV REQUEST FILEN FRA BBS FORSENDELSESNIVÅ OPPDRAGSNIVÅ VEDLEGG Forespørsel om ny efaktura avtale i request fra BBS Melding om sletting av eksisterende efakturaavtale i request fra BBS DTD OVERSIKT OVER MELDINGER SOM KAN SENDES I REQUEST FILEN FRA BBS ENROLLMENTADD (NY EFAKTURA AVTALE), ENROLLMENTCHANGE (ENDRING EFAKTURA AVTALE), ELLER ENROLLMENTDELETE (MELDING OM SLETTING AV EFAKTURA AVTALE) Ulike meldingstyper & krav til utsteder's behandling av disse Behandling av felter i Request filen Svarfrist, purring & sletting av efaktura avtale Kvittering / verifikasjon i requestfil SPESIFIKASJON AV RESPONSE FILEN FRA UTSTEDER FORSENDELSESNIVÅ OPPDRAGSNIVÅ VEDLEGG Svar på forespørsel om ny efakturaavtale i response fra utsteder Svar på forespørsel om endring av eksisterende efakturaavtale i repsonse fra BBS DTD XSD SCHEMA OVERSIKT OVER MELDINGER SOM KAN SENDES I RESPONSE FILEN ENROLLMENTADD ELLER ENROLLMENTCHANGE Hvordan svare på request fil i response filen Krav til felter som må fylles ut i response filen ENDRINGSLOGG FOR DENNE BRUKERHÅNDBOKEN Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 2 33

3 1 Funksjonalitet 1.1 Overordnet beskrivelse Request fil (forespørsel fra kunde og kvitteringer) En xmlfil kalt requestfil sendes fra BBS til utsteder. Filen inneholder/ kan inneholde: Forespørsel om nye efakturaavtale fra kunde i nettbank Forespørsel om endring av eksisterende efakturaavtale fra kunde i nettbank Melding om at kunde har slettet sin efakturaavtale Kvittering / verifikasjon på at BBS har oppdatert efaktura avtale status i sitt system på bakgrunn av svar fra utsteder (responsefilen). Dette gjelder svar på forespørsel om ny efakturaavtale eller forespørsel om endring av efakturaavtale. 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 efakturaavtale fra kunde (utsteder validerer & godkjenner kunde) Svar på forespørsel om ny efakturaavtale fra kunde (utsteder validerer & avviser kunde) Svar på forespørsel om endring på eksisterende efakturaavtale fra kunde (utsteder validerer & godkjenner) Svar på forespørsel om endring på eksisterende efakturaavtale fra kunde (utsteder validerer & avviser) 1.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. 1.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. 1.4 Transaksjonsnivå Transaksjonsnivå inneholder informasjon om den enkelte transaksjon. Det kan være fra 1 til x antall detaljtransaksjoner på dette nivå. 1.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å 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. Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 3 33

4 1.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 efakturasystemet. Avtale vises i nettbank som "avventende" BBS 3. BBS sender requestfil til utsteder 5. I nettbank vises avtale som godkjent eller avslått 6.BBS sender kvittering til utsteder 4. Utsteder sender responsefil til BBS Nettbank Utsteder 1. Forbruker registrerer at han ønsker å motta efaktura fra en utsteder Forbruker Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 4 33

5 1.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 Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 5 33

6 2 Spesifikasjon av request filen fra BBS 2.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="iso8859 1"?> <Message> Koden skal stå øverst i filen for å sikre rett formatering/ tegnsett på Xmlfilen. Message markerer start og slutt på meldingen. <Request> Header informasjon om fakturaen. <FromInfo> Informasjon under FromInfo forteller hvem som sendte fila. <ServiceProviderName> Alltid verdien : 8080 ServiceProviderName skal fylles ut med <ToInfo> Informasjon under ToInfo forteller hvem fila skal til. numerisk, 4 posisjoner Alltid 8080 <ServiceProviderID> Forteller hvem som skal motta filen. Alfanumerisk, 15 posisjoner Foretaksnummer F.eks. NOR <ServiceID> Alltid 1 Numerisk, 1 posisjon Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 6 33

7 2.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. 2.3 Vedlegg Ny efakturaavtale forespørsel i request filen Forespørsel om endring på eksisterende efakturaavtale i request filen Sletting av efakturaavtale i request filen Forespørsel om ny efaktura avtale i request fra BBS Forespørsel om ny efakturaavtale Denne forespørselen inneholder efaktura avtaleinformasjon 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="iso88591"?> <Message> <Request> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> <![CDATA[NOR ]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> </Request> <EnrollmentRQ> <EnrollmentAdd> <AccountInfoRecord> <PortalInfo> <PortalEnrollmentStatus> <![CDATA[A]]> </PortalEnrollmentStatus> </PortalInfo> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerUserName /> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 7 33

8 <BillerPassword /> <BillerEnrollmentStatus> <![CDATA[P]]> </BillerEnrollmentStatus> </BillerInfo> <UserInfo> <FirstName> <![CDATA[Fornavn]]> </FirstName> <LastName> <![CDATA[Etternavn]]> </LastName> <DayPhone /> < /> <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[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfg876df68 = =]]> </ThorUserId> </ThorInfo> <ThorUserKey/> </AccountInfoRecord> </EnrollmentAdd> </EnrollmentRQ> </Message> Kvittering fra BBS på godkjent forespørsel om ny efakturaavtale Utsteder har godkjent forespørsel om ny efakturaavtale 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="iso88591"?> <Message> <Request> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 8 33

9 <![CDATA[NOR ]]> </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> <FirstName /> <LastName /> <DayPhone /> < /> <UserAddress> <Address1 /> <Address2 /> <City /> <State /> <PostalCode /> <Country /> </UserAddress> </UserInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfgsdgsd87454 = =]]> </ThorUserId> </ThorInfo> <ThorUserKey /> </AccountInfoRecord> </EnrollmentChange> </EnrollmentRQ> </Message> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s. 9 33

10 Kvittering fra BBS på avvist forespørsel om ny efakturaavtale Utsteder har sendt response med avslag av forespørsel om ny efakturaavtale 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="iso88591"?> <Message> <Request> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> <![CDATA[NOR ]]> </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> <FirstName /> <LastName /> <DayPhone /> < /> <UserAddress> <Address1 /> <Address2 /> <City /> <State /> <PostalCode /> <Country /> </UserAddress> </UserInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[ddfgdfgfd56dfg876df68 = =]]> </ThorUserId> </ThorInfo> <ThorUserKey /> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

11 </AccountInfoRecord> </EnrollmentChange> </EnrollmentRQ> </Message> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

12 2.3.2 Melding om sletting av eksisterende efakturaavtale i request fra BBS Kunde har slettet sin efakturaavtale 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 Melding til utsteder om sletting av aktiv efakturaavtale <?xml version="1.0" encoding="iso88591"?> <Message> <Request> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> <![CDATA[NOR ]]> </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]]> </BillerEnrollmentStatus> </BillerInfo> <UserInfo> <FirstName /> <LastName /> <DayPhone /> < /> <UserAddress> <Address1 /> <Address2 /> <City /> <State /> <PostalCode /> <Country /> </UserAddress> </UserInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg8s7876df86sd8sdf6 = =]]> </ThorUserId> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

13 </ThorInfo> <ThorUserKey /> </AccountInfoRecord> </EnrollmentDelete> </EnrollmentRQ> </Message> 2.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, , UserAddress)> <!ELEMENT FirstName (#PCDATA)> <!ELEMENT LastName (#PCDATA)> <!ELEMENT DayPhone (#PCDATA)> <!ELEMENT (#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)> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

14 3 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. 3.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å fremtidig funksjonalitet. PortalEnrollmentStatus vil i normalsituasjoner ha en bokstav som verdi. Alfanumerisk, 1 posisjon Alltid = A <BillerInfo> Utsteder informasjon om avtalen <BillerAccountNumber> Kundens kundenummer hos Alfanumerisk, 32 utstederen posisjoner Viktig at utsteder returnerer samme verdi fra dette feltet i response filen. <BillerUserName> Kundens brukernavn hos utstederen. For fremtidig bruk. <BillerPassword> Kundens passord hos utstederen. For fremtidig bruk <BillerEnrollmentStatus> Gyldige statuser : P = forespørsel om ny eller endring av efaktura avtale Vil være blankt. 0 posisjoner Vil være blankt. 0 posisjoner 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 Dette feltet bør benyttes i validering mot utsteder kunderegister. Alfanumerisk, 50 posisjoner Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

15 <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 /> < > Fylles ikke ut. Vil være blankt. Ikke ibruk Tagg forekommer : < /> <UserAddress> Informasjon om kundens adresse <Address1> Vanligvis kundens gateadresse Alfanumerisk, 50 posisjoner <Address2> Benyttes dersom man behøver et ekstra felt til adressen. Vil ofte være tom. Alfanumerisk, 50 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> <ThorContentProviderId> Utsteder's organisasjonsnummer Viktig at utsteder sender samme verdi Alfanumerisk, 14 posisjoner F.eks. NOR tilbake til BBS i response fil. <ThorUserId> Kundens Id i efaktura systemet. Dette feltet inneholder en kryptert verdien. Alfanumerisk, 35 posisjoner <ThorUserKey> 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 />. Ikke ibruk Hvis det eventuelt kommer en verdi i dette feltet trenger ikke den å behandles av utsteder 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 efaktura avtale. Utsteder stopper efaktura for kunde. EnrollmentDelete BillerEnrollmentStatus = D Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

16 5 AvtaleKvittering Request Kvittering på avvist forespørsel om endring Ny = 4 AvtaleKvittering Request Kvittering på godkjent Endring = forespørsel om ny avtale 5 eller endring av avtale 4 AvtaleKvittering Request Kvittering på avvist forespørsel om ny efakturaavtale Tabell 1 EnrollmentChange 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) Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

17 Når utsteder leser requestfilen 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 responsefilen. Hvis Nei: Send informasjon til BBS om at kunde er nektet efakturaavtale samt en begrunnelse for dette i responsefilen. 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 efakturareferansen 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 responsefilen. Hvis Nei: Send informasjon til BBS om at forespørsel om endring er avvist samt en begrunnelse for dette i responsefilen. Mulig begrunnelser for avslag er beskrevet i spesifikasjon av response filen. Når utsteder avviser forespørsel om endring av efakturaavtale 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 efakturatjenesten. 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 Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

18 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 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 kundeinformasjon 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> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

19 3.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å requestfil 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. Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

20 3.1.4 Kvittering / verifikasjon i requestfil 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 efakturaavtale eller endring av eksisterende efakturaavtale, godkjenner avtalen / endringen i response fil til BBS. BBS svarer i neste requestfil med kvittering/verifikasjon på at BBS har oppdatert sitt efaktura avtale register på bakgrunn av responsefil 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 efakturaavtale, 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 responsefil 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 requestfil med forespørsel om endring av allerede aktiv efakturaavtale, og avslått denne i responsefil til BBS. BBS sender kvittering på at efakturaavtalen er deaktivert i BBS sitt system. Utsteder s handling: Utsteder må stoppe efaktura for denne kunden. Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

21 4 Spesifikasjon av response filen fra utsteder 4.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="iso8859 1"?> <Message> Koden skal stå øverst i filen for å sikre rett formatering/ tegnsett på Xmlfilen. Message markerer start og slutt på meldingen. <Response> Header informasjon om fakturaen. <FromInfo> Informasjon under FromInfo forteller hvem som sendte fila. <ServiceProviderName> Alltid verdien : 8080 ServiceProviderName skal fylles ut med 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. numerisk, 4 posisjoner Alltid 8080 <ServiceProviderID> Forteller hvem som skal motta filen. Alfanumerisk, 15 posisjoner Foretaksnummer F.eks. NOR <ServiceID> Alltid 1 Numerisk, 1 posisjon Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

22 4.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. 4.3 Vedlegg Svar på forespørsel om ny efakturaavtale i response filen Svar på forespørsel om endring på eksisterende efakturaavtale i response filen Svar på forespørsel om ny efakturaavtale i response fra utsteder Svar på Forespørsel om ny efakturaavtale (Utsteder godkjenner avtalen) Utsteder kan velge å godta eller avslå denne forespørselen. Dette er vist i eksempel nedenfor <?xml version="1.0" encoding="iso88591"?> <Message> <Response> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> <![CDATA[NOR ]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> <Status/> </Response> <EnrollmentRS> <EnrollmentAdd> <AccountInfoRecord> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerEnrollmentStatus> <![CDATA[A]]> </BillerEnrollmentStatus> <BillerReason/> <BillerMessage/> </BillerInfo> <ThorInfo> <ThorContentProviderId> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

23 <![CDATA[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dsfg35676df68 = =]]> </ThorUserId> </ThorInfo> <ThorUserSignature> </ThorUserSignature> </AccountInfoRecord> </EnrollmentAdd> </EnrollmentRS> </Message> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

24 Svar på Forespørsel om ny efakturaavtale (Utsteder avviser avtalen) <?xml version="1.0" encoding="iso88591"?> <Message> <Response> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> <![CDATA[NOR ]]> </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[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[dfhgdfgdfg45345 ==]]> </ThorUserId> </ThorInfo> <ThorUserSignature /> </AccountInfoRecord> </EnrollmentAdd> </EnrollmentRS> </Message> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

25 4.3.2 Svar på forespørsel om endring av eksisterende efakturaavtale i repsonse fra BBS I efaktura tjenesten kan kunde endre sin allerede eksisterende efakturaavtale. Meldingsflyt for slike endringer mellom BBS og utsteder er beskrevet i dette kapittelet Svar på forespørsel om endring av efakturaavtale (Utsteder godkjenner endringen) <?xml version="1.0" encoding="iso88591"?> <Message> <Response> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> <![CDATA[NOR ]]> </ServiceProviderID> <ServiceID> <![CDATA[1]]> </ServiceID> </ServiceProvider> </ToInfo> <Status/> </Response> <EnrollmentRS> <EnrollmentChange> <AccountInfoRecord> <BillerInfo> <BillerAccountNumber> <![CDATA[999]]> </BillerAccountNumber> <BillerEnrollmentStatus> <![CDATA[A]]> </BillerEnrollmentStatus> <BillerReason/> <BillerMessage/> </BillerInfo> <ThorInfo> <ThorContentProviderId> <![CDATA[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfg876df = =]]> </ThorUserId> </ThorInfo> <ThorUserSignature/> </AccountInfoRecord> </EnrollmentChange> </EnrollmentRS> </Message> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

26 Svar på forespørsel om endring av efakturaavtale (Utsteder avviser endringen) Utsteder har avvist forespørsel om endring av eksisterende efakturaavtale. <?xml version="1.0" encoding="iso88591"?> <Message> <Response> <FromInfo> <ServiceProviderName> <![CDATA[8080]]> </ServiceProviderName> </ServiceProvider> </FromInfo> <ToInfo> <ServiceProviderID> <![CDATA[NOR ]]> </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> <![CDATA[NOR ]]> </ThorContentProviderId> <ThorUserId> <![CDATA[defg876dfg245876df68 = =]]> </ThorUserId> </ThorInfo> <ThorUserSignature/> </AccountInfoRecord> </EnrollmentChange> </EnrollmentRS> </Message> 4.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)> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

27 <!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)> 4.5 XSD Schema Filvedlegget under fungerer ikke hvis du sitter med denne filen I PDFformat. 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="iso88591"?> <! Denne xsd er ment for distribusjon til utstedere dvs innsendere av response filer. > <xs:schema xmlns:xs=" <xs:element name="message"> <xs:element name="response" minoccurs="1" maxoccurs="1"> <xs:element name="fileinfo" minoccurs="0" maxoccurs="1"> <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:element name="frominfo" minoccurs="1" maxoccurs="1"> <xs:element name="serviceprovider" minoccurs="1" maxoccurs="1"> <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:sequence> <xs:element name="toinfo" minoccurs="1" maxoccurs="1"> <xs:element name="serviceprovider" minoccurs="1" maxoccurs="1"> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

28 <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:sequence> <xs:element name="status" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> <xs:element name="enrollmentrs" minoccurs="1" maxoccurs="unbounded"> <xs:element name="contentproviderinfo" minoccurs="0" maxoccurs="1"> <xs:element name="contentproviderfilereference" type="xs:string" minoccurs="0" maxoccurs="1"/> </xs:sequence> <xs:element name="enrollmentadd" minoccurs="0" maxoccurs="unbounded"> <xs:element name="accountinforecord" minoccurs="1" maxoccurs="1"> <xs:element name="billerinfo" minoccurs="1" maxoccurs="1"> <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=" "/> </xs:restriction> </xs:simpletype> <xs:element name="billermessage" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> <xs:element name="thorinfo" minoccurs="1" maxoccurs="1"> <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:element name="thorusersignature" type="xs:string" minoccurs="1" maxoccurs="1" /> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

29 </xs:sequence> </xs:sequence> <xs:element name="enrollmentchange" minoccurs="0" maxoccurs="unbounded"> <xs:element name="accountinforecord" minoccurs="1" maxoccurs="1"> <xs:element name="billerinfo" minoccurs="1" maxoccurs="1"> <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=" "/> </xs:restriction> </xs:simpletype> <xs:element name="billermessage" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> <xs:element name="thorinfo" minoccurs="1" maxoccurs="1"> <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:element name="thorusersignature" type="xs:string" minoccurs="1" maxoccurs="1" /> </xs:sequence> </xs:sequence> </xs:sequence> </xs:sequence> </xs:schema> Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

30 5 Oversikt over meldinger som kan sendes i response filen 5.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 Alfanumerisk, 32 posisjoner <BillerEnrollmentStatus> <BillerReason> <BillerMessage> 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 BillerReason er en tallkode som forteller årsaken til avslaget på søknaden. Lovlige verdier er; 01, 02, 03 Skal fylles ut hvis BillerEnrollmentStatus = N Alfanumerisk,1 posisjon Alfanumerisk, 2 posisjoner Alfanumerisk, max 100 posisjoner BillerMessage er et tekstfelt som med ord beskriver årsaken gitt i BillerReason. Lovlige verdier er; <ThorInfo> <ThorContentProviderId> 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) Utsteder's organisasjonsnummer Benytt samme verdi som mottatt på request filen. Alfanumerisk, 14 posisjoner F.eks. NOR Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

31 <ThorUserId> Kundens Id i efaktura systemet. Dette feltet vi inneholde denne verdien kryptert. 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 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 efaktura avtale. EnrollmentAdd 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. 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. Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

32 5.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 efakturaavtale 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 efakturaavtalen 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. NOR <ThorUserId> Skal Inneholde samme verdi som mottatt i requestfilen. Dette er forbrukerens id i BBS sitt system og brukes til å identifisere avtalen som skal oppdateres. F.eks. l2kj45l2kj52lkj452lk5j = = Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s

33 6 Endringslogg for denne brukerhåndboken Dokumentansvarlig: Terje Dahl Ver. Kap. Beskrivelse av endring Sign. forf. Sign. dok.ansv. Dato Alle endringer fra 1.0 til 2.0 (fjernet fra endringslogg) Tormod Engen Rodi Kristiansen ServiceProviderName skal fylles ut med Men i en overgangsfase vil allikevel Thor sendes ut fra BBS, og BBS aksepterer dette som gyldig verdi fra eksisterende utstedere 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 TAG for EnrollmentDelete manglet i DTD for requestfil 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 Terje Dahl Terje Dahl Terje Dahl Fjernet dette kapitelet, da 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.8 Gjennomgang av dokumentet Terje Dahl hha hha Mars 2010 Teknisk håndbok efaktura Spesifikasjon Påmelding i XMLformat versjon 2.9 s