brukerhåndbok autogiro - efaktura · web viewtechnical manual – due payment in xml format di ag...

Technical manual – Due payment in XML format

of 28

Technical manualDue payment in XML format

Version 2.0


of 28

Technical manual – Due payment in XML formatContents

1. INTRODUCTION .............................................................. FEIL! BOKMERKE ER IKKE DEFINERT.

1.1 ABOUT THIS DOCUMENT .........................................................FEIL! BOKMERKE ER IKKE DEFINERT.1.2 TARGET GROUP .....................................................................FEIL! BOKMERKE ER IKKE DEFINERT.1.3 LIMITATIONS .............................................................................................................................. .3

2 FUNCTIONALITY............................................................................................................................ .42.1 DESCRIPTION.........................................................................FEIL! BOKMERKE ER IKKE DEFINERT.2.2 TRANSMISSION ......................................................................FEIL! BOKMERKE ER IKKE DEFINERT.2.3 ASSIGNMENT .........................................................................FEIL! BOKMERKE ER IKKE DEFINERT.2.4 TRANSACTION LEVEL ...................................................................................................................42.5 XML STANDARD ........................................................................................................................ .42.6 FLOWCHART .............................................................................................................................. .42.7 TABLES USED IN THIS DOCUMENT .................................................................................................7

3 SPECIFICATION FOR INCOMING TRANSMISSION .....................................................................83.1 TRANSMISSION LEVEL ................................................................................................................ .83.2 ASSIGNMENT LEVEL ................................................................................................................... .93.3 ATTACHMENTS.......................................................................FEIL! BOKMERKE ER IKKE DEFINERT.

3.3.1 Incoming transmission - due payment file structure(example1) ...........................................93.3.2 Incoming transmission - due payment file structure (example2) ........................................11

3.4 XML Schema …………………................................................................................................11

4 OVERVIEW OVER MESSAGES THAT CAN BE SENT IN AN INCOMING TRANSMISSION ....134.1 PAYMENTRQ ............................................................................................................................13

4.1.1 Scenario for exchange of due payment (PaymentAdd)......................................................14

5 SPECIFICATIONS FOR OUTGOING TRANSMISSIONS (TRANSMISSION RECEIPT) .............15

5.1 TRANMSISSION LEVEL................................................................................................................155.2 ASSIGNMENT LEVEL ..................................................................................................................165.3 ATTACHMENTS.......................................................................FEIL! BOKMERKE ER IKKE DEFINERT.

5.3.1 Outgoing transmissions - Example of 1st level receipt, transmission denied(524 = Error in ServiceProviderFileDate) ..........................................................................18

5.3.2 Outgoing transmission - Example of 2nd level receipt, assignment denied(509 = Invalid ContentProviderFileReference) ...................................................................19

5.3.3 Outgoing transmissin - Example of 2nd level receipt, 1 denied transaction(503 = Due payment without active agreement) ...............................................................20

5.4 XML Schema ..........................................................................................................................20

6 OVERVIEW OVER MESSAGES THAT CAN BE SENT IN AN OUTGOING TRANSMISSION ...226.1 1ST

LEVEL & 2ND LEVEL RECEIPT ..................................................................................................22

6.1.1 Scenario for 1st level & 2nd level receipt..............................................................................226.1.2 Explanation for 1st level receipt...........................................................................................226.1.3 Explanation for 2nd level receipt ........................................................................................236.1.4 Reason for denied 1st level receipt ....................................................................................246.1.5 Reason for denied 2nd level receipt ...................................................................................24

6.2 PAYMENTRS ............................................................................................................................266.2.1 Reason for denial on transaction level ...............................................................................27

7 AMENDMENT LOG FOR THIS MANUAL ..........................................................................................28


of 28

1 Introduction

1.1 About this documentThis document has been made to show which file structures the issuer must use when communicating with NETS when handling due payments. When using this document the issuer/partner will be able to send transmissions to NETS and receive transmissions from NETS.

1.2 Target groupThis document is meant for issuer/eBilling hotel and other partners involved in implementing local invoice storage.

1.3 LimitationsThis document describes the format for incoming and outgoing transmissions between NETS and eBilling hotel/issuer when using local invoice storage.


of 28

2 Functionality

2.1 DescriptionThe eBilling hotel/issuer sends a transmission to NETS that consists of 3 levels. The 3 levels identify the eBilling hotel, issuer and which transactions issuer wants to carry out.

NETS’ outgoing transmissions consist of the same items as the incoming transmissions. The outgoing transmissions will contain a transmission level, an assignment level and a transaction level. The eBilling hotel/issuer must use this transmission to check that the entire incoming transmission was processed in NETS, and if not, correct the errors.

2.2 TransmissionA transmission is the first level and there may only be one of these per file. The transmission level must always be filled in.

2.3 AssignmentThere may be one or more assignment levels per transmission level, but most likely just one per issuer. An assignment identifies a set of transactions belonging to one issuer. The assignment level must always be filled in.

2.4 Transaction levelThe transaction level contains information about each transaction. There may be from 1 to x amount of detailed transactions on this level.

2.5 XML StandardThe format for incoming and outgoing transmissions for local invoice storage is XML 1.0. The specifications for XML 1.0 are found at ww w . w 3 . o r g

Be aware of that:

• the XML standard is case sensitive, that is; lower case letters and capitol letter must be used as directed in this document.

2.6 Flow chartIn the local invoice storage there are 3 possible scenarios for generating due payments and who sends the due payment to NETS. These are described in the following drawings.


Diagram 1

4. Nettbankapplikasjonen henter URLsom peker til fakturadetaljer

1. FakturaHotell sender betalingskravsfilen til BBS

5. BBS-server returnerer

signert URL

2.BBS sender kvittering

til FakturaHotell

7. URLpeker

6. Forbruker re-routes tilURL'ens innhold (fakturadetaljer)

3. Forbruker ønskerå se på fekturadetaljer

FakturaHotell

BBS

Nettbank

Forbruker

of 28

4. Internet bank application fetchesURL which points to invoice details

5. Nets-server returns signed URL

Nets 2. Nets sends receipt to eBilling Hotel

1. eBilling Hotel sends due payment file to Nets

Internet bank

6. User is re-routed to the URL’s content (invoice details)

7. URLlink

eBilling Hotel

3. User wants to see the invoice details

User

This flowchart shows the eBilling hotel as the only party involved in the due payment process. In this scenario, the eBilling hotel generates the due payment file and sends the due payments to Nets in XML-format.


Diagram 2


2. FakturaHotell senderbetalingskravsfilen til BBS

6. BBS-server returnerer

signert URL

3.BBS sender kvittering

til FakturaHotell

8. URLpeker


4. Forbruker ønsker å se på fekturadetaljer

FakturaHotell

BBS

Nettbank

Forbruker

Utsteder1. Utsteder sender fakturainfo

til fakturahotel

of 28



Nets 3. Nets sends receipt to eBilling Hotel

2. eBilling Hotel sends due payment file to Nets

Nettbank

7. User is re-routed to the URL’s content (invoice details)

8. URLlink

eBilling Hotel

4. User wants to see the invoice detailsForbruker

Issuer

1. Issuer sends invoice info to eBilling Hotel

This flowchart shows a scenario where the eBilling hotel receives the payment information from an issuer and the eBilling hotel sends the due payment file to Nets.



5. BBS-serverreturnerer

signert URL

2.BBSsender

kvittering til utsteder


3. Forbruker ønsker å se på fekturadetaljer

BBS

Nettbank

Forbruker

Utsteder

1. Utsteder sender betalingskravsfilen til BBS

7. URLpeker

of 28

Diagram 3


Nets


1. Issuer sends due payment file to Nets

2. Nets sends receipt to issuer

Nettbank

6. User is re-routed to URL’s content (invoice details)

7. LinkUtsteder

3. User wants to see the invoice details

Forbruker

This flowchart shows a scenario where issuer is the only party involved in the due payment process. Issuer generates the due payment and sends it to NETS.

2.7 Tables used in this documentThe tables used to describe the transmission, assignment and detail levels are described as follows:

TAG DESCRIPTION FORMAT

Describes the tagused in XML

Describes the purpose of the tag. Describes the format of the tag.


of 28

3 Specifications for incoming transmission

3.1 Transmission levelThe transmission level is the top level in a file. It states which eBilling hotel/issuer that sends the detail transactions.

TAG BESKRIVELSE FORMAT

<?xml version="1.0" encoding="ISO-8859-1"?>

This code must be at the top of the file to ensure correct formatting/ character set inthe XML file.

-

<Message> Message marks the start and end of themessage.

-

<Request> Header information about the invoice. -<FromInfo> Information under FromInfo states who sent

the file.-

<ServiceProviderId> Data field that states the sender of the file. Unique sender ID in the eBilling hotel.

For example NOR123456789-1

• Alfa numerical, 14 characters

• Format = NOR<unique ID with NETS>-1

<ServiceProviderFileDate>

Data field that states when the file was sent. • No space• No period• Format =

DDMMYYYY<ServiceProviderFileReference>

Data field that states the file’s unique reference.

The field will be checked for duplicates atNETS.

For example: 20020615001

• Numerical, 11 characters

• Format: YYYYMMDDXXX

• All dates greater than10 days ahead or back in time will bedenied.

Explanation:• YYYY = year• MM = month• DD = day• XXX = unique serial

number, ascending from 001

<ServiceProviderFileStatus>

Data field that states if this is a test transmission or a production transmission.


• Format =1 = Production0 = Test

<ToInfo> Information under ToInfo states who the fileis for.

-

<ServiceProviderId> States who shall receive the file. • Always 8080


of 28

3.2 Assignment levelThe assignment level contains information about which issuer that is sending the transaction details. The following table shows which elements that are required to define an assignment.

TAG BESKRIVELSE FORMAT

<ContentProviderRQ> There may be several issuers in one file. Every assignment is defined by a<ContentProviderRQ> per issuer.

-

<ContentProviderInfo>

Information about issuer that sent the information.

-

<ContentProviderId> Issuer’s unique issuer ID with NETS. For example: NOR123456789-1.


• Format = NOR< uniqueID with NETS>-1

<ContentProviderDate>

States the date the assignment was generated.

• No space• No period• Format = DDMMYYYY

<ContentProviderFileReference>

Data field that states the assignments unique reference.

The field will be checked for duplicates withNETS.

For example: 200206150001


• Format: YYYYMMDDXXXX

• All dates greater than10 days ahead or back in time will be denied.

Explanation:• YYYY = year• MM = month• DD = day• XXXX = unique serial

number, ascending from 0001

3.3 Attachments

3.3.1 Incoming transmission – due payment file structure (example 1)<?xml version="1.0" encoding="ISO-8859-1"?><Message><Request>

<FromInfo>

<ServiceProviderId><![CDATA[]]>

</ServiceProviderId><ServiceProviderFileDate><![CDATA[]]>

</ServiceProviderFileDate><ServiceProviderFileReference><![CDATA[]]>

</ServiceProviderFileReference>



of 28

<![CDATA[]]></ServiceProviderFileStatus>

</FromInfo><ToInfo>

<ServiceProviderId><![CDATA[]]>

</ServiceProviderId></ToInfo>

</Request><ContentProviderRQ>

<ContentProviderInfo><ContentProviderId><![CDATA[]]>

</ContentProviderId >< ContentProviderDate><![CDATA[]]>

</ContentProviderDate ><ContentProviderFileReference><![CDATA[]]>

</ContentProviderFileReference></ContentProviderInfo><PaymentRQ>

<PaymentRQInfo><ProductId><![CDATA[]]>

</ProductId><NumberOfTransactions>

<![CDATA[]]></NumberOfTransactions></PaymentRQInfo><PaymentAdd><Reference>

<![CDATA[]]></Reference><CustomerAgreementReference>

<![CDATA[]]></CustomerAgreementReference><Kid>

<![CDATA[]]></Kid><DueDate>

<![CDATA[]]></DueDate><AmountDue>

<![CDATA[]]></AmountDue><MinimumAmountDue>

<![CDATA[]]></MinimumAmountDue><CreditAccountNumber><![CDATA[]]>

</CreditAccountNumber><BrandName><![CDATA[]]>

</BrandName><PaymentType>

<![CDATA[]]></PaymentType><DetailReference>

<![CDATA[]]></DetailReference>

</PaymentAdd></PaymentRQ>

</ContentProviderRQ></Message>

of 28

3.3.2 Incoming transmission – due payment file structure (example 2)

3.4 XML Schema

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<xs:element name="Message">

<xs:complexType><xs:sequence>


of 28

<xs:element ref="Request"/><xs:element ref="ContentProviderRQ" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType>

</xs:element><xs:element name="Request">


<xs:element ref="FromInfo"/><xs:element ref="ToInfo"/>


</xs:element><xs:element name="FromInfo">

<xs:complexType><xs:complexContent>

<xs:extension base="ServiceProviderId"><xs:sequence>

<xs:element ref="ServiceProviderFileDate"/><xs:element ref="ServiceProviderFileReference"/><xs:element ref="ServiceProviderFileStatus"/>

</xs:sequence></xs:extension>

</xs:complexContent></xs:complexType>

</xs:element><xs:element name="ServiceProviderFileDate" type="xs:integer"/><xs:element name="ServiceProviderFileReference" type="xs:integer"/><xs:element name="ServiceProviderFileStatus" type="xs:integer"/><xs:element name="ToInfo" type="ServiceProviderId"/><xs:element name="ContentProviderRQ">


<xs:element ref="ContentProviderInfo"/><xs:element ref="PaymentRQ"/>


</xs:element><xs:element name="ContentProviderInfo">


<xs:element ref="ContentProviderId"/><xs:element ref="ContentProviderDate"/><xs:element ref="ContentProviderFileReference"/>


</xs:element><xs:element name="ContentProviderId" type="xs:NCName"/><xs:element name="ContentProviderDate" type="xs:integer"/><xs:element name="ContentProviderFileReference" type="xs:integer"/><xs:element name="PaymentRQ">


<xs:element ref="PaymentRQInfo"/><xs:element ref="PaymentAdd" maxOccurs="unbounded"/>


</xs:element><xs:element name="PaymentRQInfo">


<xs:element ref="ProductId"/><xs:element ref="NumberOfTransactions"/>



of 28

</xs:element><xs:element name="ProductId" type="xs:integer"/><xs:element name="NumberOfTransactions" type="xs:integer"/><xs:element name="PaymentAdd">


<xs:element ref="Reference"/><xs:choice minOccurs="1">

<xs:element ref="EfakturaIdentifier"/><xs:element ref="CustomerAgreementReference"/>

</xs:choice><xs:element ref="Kid"/><xs:element ref="DueDate"/><xs:element ref="AmountDue"/><xs:element ref="MinimumAmountDue" minOccurs="0" maxOccurs="1"/><xs:element ref="CreditAccountNumber"/><xs:element ref="BrandName"/><xs:element ref="PaymentType"/><xs:element ref="DetailReference"/>


</xs:element><xs:element name="Reference" type="xs:NMTOKEN"/><xs:element name="EfakturaIdentifier">

<xs:simpleType><xs:restriction base="xs:string">

<xs:maxLength value="9"/><xs:minLength value="9"/><xs:pattern value="[0-9]{9}"/>

</xs:restriction></xs:simpleType>

</xs:element><xs:element name="CustomerAgreementReference" type="xs:NMTOKEN"/><xs:element name="Kid" type="xs:integer"/><xs:element name="DueDate" type="xs:integer"/><xs:element name="AmountDue" type="xs:NMTOKEN"/><xs:element name="MinimumAmountDue" type="xs:NMTOKEN"/><xs:element name="CreditAccountNumber" type="xs:integer"/><xs:element name="BrandName" type="xs:string"/><xs:element name="PaymentType" type="xs:integer"/><xs:element name="DetailReference" type="xs:anyURI"/><xs:complexType name="ServiceProviderId">

<xs:sequence><xs:element ref="ServiceProviderId"/>

</xs:sequence></xs:complexType><xs:element name="ServiceProviderId" type="xs:NMTOKEN"/>

</xs:schema>

4 Overview over notifications that may be sent in the incoming transmission

The transaction level states the type of transactions an assignment contains. The following table shows an overview over the elements necessary to define a due payment.

4.1 PaymentRQ



of 28

<PaymentRQ> The start of a new payment. New tags will appear here if there arenew types of “documents”.For example: insurance policies.

-

<PaymentRQInfo> Information of which services this payment information is regarding.

-

<ProductId> The service code for eInvoice. • Numerical• Always 42

<NumberOfTransactions> Number of transactions in a transmission

• Numerical

<PaymentAdd> Due payment information distributed to issuer’s customer via the internetbank.

-

<Reference> Unique reference for this payment transaction. The reference will bereturned in a receipt file.

The field will be checked for duplicated with NETS.

For example: 200206150000001

• Numerical, 15 characters• Format:

YYYYMMDDXXXXXXX

Explanation:• yyyy = year• mm = month• dd = day• xxxxxxx = unique serial

number, ascending from0000001

<CustomerAgreementReference>

Customer’s eInvoice reference/document reference

One of <CustomerAgreement Reference> or <EfakturaIdentifier> may be used.

• Alfa numerical• No space• No period• Max 32 characters

<EfakturaIdentifier> Customer’s unique identifier.

One of <CustomerAgreement Reference> or <EfakturaIdentifier> may be used.

• Numerical• 9 digits

<Kid> KID or other customer reference valid in modulus 10 or 11.

• Numerical• No space• No period• Max 25 characters

<DueDate> Invoice due date. • No space• No period• Format = DDMMYYYY• Max 8 characters

<AmountDue> Invoice amount due. • Period marks thousand• Comma before decimals• Two decimals

<MinimumAmountDue> The minimum amount that must be paid for this invoice. This element is optional

• Period marks thousand• Comma before decimals• Two decimals


of 28

<CreditAccountNumber> Creditor’s account number. Usedwhen paying bills.

Account into which the issuer wants to receive customer’s payment.

• Numerical• No space• No period• Must be valid in modulus• Max 11 characters

<BrandName> Issuer/product name. Shows whichissuer/product the bill concerns.

• Alfa numerical• Max 40 characters

<PaymentType> Describes payment type. Two types of payment; Nettgiro and ATG.

• 0 (Nettgiro)• 1 (ATG)• Max 2 characters

<DetailReference> URL that points to a specific invoice/ document.

• Alfa numerical• Max 500 characters Must start with : h tt p s : / /< w ebad r ess e > For example:h tt p s : / / ww w . u ts ted e r. n o / s e r v l e t 1 / t es t ? … . k orh tt p s : / / u t s ted e r . f a k t u r a . n o /se r v l e t 1 /t e s t ?… . k

4.1.1 Scenario for exchange of due payment (PaymentAdd)

• eBilling hotel/issuer sends a transmission with <PaymentRQ> <PaymentAdd>.• NETS validates the transmission level first and sends a 1st level receipt.• NETS validates the assignment information (ContentProviderRQ) and each of the

due payments (PaymentAdd) and returns an eBilling hotel/issuer 2nd level receipt.

The eBilling hotel/issuer must handle the 1st and 2nd level receipts from NETS and correct any errors. Errors must be reported in the 1st and 2nd level receipts.


of 28

5 Specifications for outgoing transmissions (receipt for transmission)

5.1 Transmission levelThe transmission level is the top level in the message. It contains information about sender and receiver of the outgoing transmission.


<?xml version="1.0"encoding="ISO-8859-1"?>

The code must be at the top of the file toensure correct formatting/character set in theXML file.

-

<Message> Marks the start and end of the message. -

<Response> Header information about the message. -<FromInfo> Contains information about sender. -<ServiceProviderId> Sender • Numerical , 4 characters

• Always = 8080

<ServiceProviderFileDate>

Date when message was sent. • Format : DDMMYYYY• No period• No space

<ServiceProviderFileReference>

Data field that states the file/transmission’sunique reference from NETS to

sender. For example: 20020615001


YYYYMMDDXXX




Describes if the file contains test or production data. Ref. same tag in incomingtransmission with local invoice storage.

0 = Test1 = Production

• Numerical, 1 character

• 0 = Test• 1 = Production

<ToInfo> Contains information about recipient. -<ServiceProviderId> Recipient • Alfa numerical, 14

characters• Format = NOR<issuer’s

id with NETS><FileReceptionReceipt>

Header for 1 level receipt. Only appears on1st level receipts.

Contains information about validation on 1st level.XML syntax/ DTD check.Elements have been correctly filled in on transmission level for incoming transmissions.

-


of 28


Reference to the transmission sent fromissuer that this transmission from NETS is a response to.

The same value as the ServiceProviderFileReference in the incoming transmissions.


YYYYMMDDXXX


number, ascending from001.

<StatusCode> Code for denial, if any, in 1st level receipt(validation of XML format Vs. DTD). Applies to the <ServiceProviderFileReference> check.

Covers oxo response

See chapter : 6.1.4


<DuplicateStatus> This field explains the duplicate transmission to NETS (this transmission number has been used previously). The transmission istherefore denied. The ”StatusCode” field will also show that this is a duplicatetransmission with the correct status code.


5.2 Assignment levelThe assignment level is a response to the assignments in the transmission. It will contain information about which assignments they respond to and which assignment they belong.


<ContentProviderRS> An incoming transmission can have multipleassignments/issuers. The<ContentProviderRS> is a response to theContentProviderRQ in the incoming transmission.

-

<ContentProviderInfo>

Information about the issuer/assignment. -

<ContentProviderId> Shows which issuer this assignment is for. • Alfa numerical , 14 characters

• Format : NORx-y• For example:

NOR123456789-1<ContentProviderDate>

Date for the assignment in the incomingtransmission.

• No period.• No space.• Format : DDMMYYYY


of 28


Reference to the incoming transmission fromissuer that the outgoing transmission fromNETS is a response to.

Same value as the ServiceProviderFileReference for the incoming transmission.


YYYYMMDDXXX



<ContentProviderFileReference>

Reference to the incoming transmission fromissuer that the assignment in the outgoing transmission from NETS is a response to.

Same value as the ContentProviderFileReference for the incoming transmission.


YYYYMMDDXXXX

Explanation:• YYYY = year• MM = month• DD = day• XXXX = unique serial


<ContentProviderFileStatus>

States if the assignment is approved or denied. Even if the assignment is approved,parts of it may be denied.

• Numerical, 1 character• 0 = Assignment OK• 1 = Entire assignment

denied


of 28

5.3 AttachmentsExamples of how 1st level receipts, 2nd level receipts (for denied assignments) and 2nd level denied transactions will appear in the outgoing transmission.

5.3.1 Outgoing transmission - Example of 1st level receipt with denied transmission (524 = Error in ServiceProviderFileDate)

of 28

Technical manual- Due payment in XML format

5.3.2 Outgoing transmission- Example of 2nd level receipt for denied assignment(509 =Invalid ContentProviderFileReference)

<?xml version="1.0" encoding="IS0-8859-1" ?>- <Message>- <Response>- <Fromlnfo>

- <ServiceProviderld><![CDA TA[ 8080 ]]>

</ServiceProviderld>- <ServiceProviderFileDate>

<![CDATA[ 20012 002 ]]></ServiceProviderFileDate>

- <ServiceProviderFileReference><![CDA TA[ 2 JJ>

</ServiceProviderFiIeReference>- <ServiceProviderFileStatus>

<![CDATA[ 1 JJ></ServiceProviderFileStatus>

</Fromlnfo>- <Tolnfo>

- <ServiceProviderld><![CDA T A [ NOR999999999 ]]>

</ServiceProviderld></Tolnfo>

</Response>- <ContentProviderRS>- <ContentProviderlnfo>

- <ContentProviderld><![CDATA[ NOR123456789-1 JJ >

</ContentProviderld>- <ContentProviderDate>

<![CDATA [ 25022 002 JJ ></ContentProviderDate>

- <ServiceProviderFileReference><![CDA TA[ 1 JJ>

</5erviceProviderFiIeReference>- <ContentProviderFileReference>

<![CDA TA[ AA1 ]]></ContentProviderFileReference>

- <ContentProviderFileStatus><![CDA TA[ 509 JJ >

</ContentProviderFileStatus></ContentProviderlnfo>

</ContentProviderRS></Message>


Page 20 of 28

5.3.3 Outgoing transmission – Example of 2nd level receipt with 1 denied transaction (503 = Due payment with no active agreement)

5.4 XML Schema

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="Message"><xs:complexType>

<xs:sequence>

Page 21 of 28

<xs:element name="Response" type="ResponseType"/><xs:element name="ContentProviderRS" type="ContentProviderRSType"

minOccurs="0" maxOccurs="unbounded"/></xs:sequence>

</xs:complexType></xs:element><xs:complexType name="ResponseType">

<xs:sequence><xs:element name="FromInfo">


<xs:element name="ServiceProviderId" type="xs:string"/><xs:element name="ServiceProviderFileDate"

type="xs:string"/><xs:element name="ServiceProviderFileReference"

type="xs:string"/><xs:element name="ServiceProviderFileStatus"

type="xs:string"/></xs:sequence>

</xs:complexType></xs:element><xs:element name="ToInfo">


<xs:element name="ServiceProviderId" type="xs:string"/></xs:sequence>

</xs:complexType></xs:element><xs:element name="FileReceptionReceipt" minOccurs="0">


<xs:element name="ServiceProviderFileReference" type="xs:string"/>

<xs:element name="StatusCode" type="xs:string"/><xs:element name="DuplicateStatus" type="xs:string"/>


</xs:element></xs:sequence>

</xs:complexType><xs:complexType name="ContentProviderRSType">

<xs:sequence><xs:element name="ContentProviderInfo" type="ContentProviderInfoType"/><xs:element name="PaymentRS" type="PaymentRSType" minOccurs="0"/>

</xs:sequence></xs:complexType><xs:complexType name="ContentProviderInfoType">

<xs:sequence><xs:element name="ContentProviderId" type="xs:string"/><xs:element name="ContentProviderDate" type="xs:string"/><xs:element name="ServiceProviderFileReference" type="xs:string"/><xs:element name="ContentProviderFileReference" type="xs:string"/><xs:element name="ContentProviderFileStatus" type="xs:string"/>

</xs:sequence></xs:complexType><xs:complexType name="PaymentRSType">

<xs:sequence><xs:element name="PaymentRSInfo">


<xs:element name="ProductId" type="xs:string"/><xs:element name="NumberOfAcceptedTransactions"

type="xs:string"/>


Page 22 of 28

<xs:element name="NumberOfRejectedTransactions" type="xs:string"/>


</xs:element><xs:element name="PaymentAdd" type="PaymentAddType" minOccurs="0"

maxOccurs="unbounded"/></xs:sequence>

</xs:complexType><xs:complexType name="PaymentAddType">

<xs:sequence><xs:element name="Reference" type="xs:string"/><xs:element name="CustomerAgreementReference" type="xs:string"/><xs:element name="Kid" type="xs:string"/><xs:element name="DueDate" type="xs:string"/><xs:element name="AmountDue" type="xs:string"/><xs:element name="MinimumAmountDue" minOccurs="0" maxOccurs="1"/><xs:element name="CreditAccountNumber" type="xs:string"/><xs:element name="BrandName" type="xs:string"/><xs:element name="PaymentType" type="xs:string"/><xs:element name="StatusCode" type="xs:string"/>

</xs:sequence></xs:complexType><xs:simpleType name="zeroOrOne">

<xs:restriction base="xs:token"><xs:pattern value="0|1"/>

</xs:restriction></xs:simpleType>

</xs:schema>

6 Overview over messages that can be sent in the outgoing transmission

An outgoing transmission may contain 2 receipt types (1st level and 2nd level). In the future, this format will also be used to exchange other types of information.

6.1 1st level and 2nd level receiptsIn the outgoing transmission format there are 2 receipt types. Both messages will have the sameDTD and use some of the same tags and some tags that are unique to each receipt type.

1st l evel recei pt

• Syntax validation of incoming transmission according to DTD• NETS validates that the transmission information for incoming transmissions is filled

in according to specifications in this document.• Incoming transmissions are checked for duplicates in the <ServiceProviderFileReference>

field.

If the incoming transmission does not fulfill these requirements, the entire transmission will be denied with an error message in the 1st level receipt.

2nd l evel recei pt

• Validation of assignment information in incoming transmission• Validation of PaymentAdd in incoming transmission.• Assignment/transaction information is filled in correctly according to specifications.• Status for number of approved/denied PaymentAdd in the incoming transmission is found in


Page 23 of 28

PaymentRSInfo.

If there are any errors in the assignment information or single transactions, these will be returned in the 2nd level receipt.

6.1.1 Scenario for 1st level & 2nd level receiptsThe scenario for exchange of receipt information between the eBilling hotel and NETS:

1. The eBilling hotel sends a transmission to the local invoice storage with a due payment:<PaymentRQ> <PaymentAdd>

NETS returns the transmission with a 1st level receipt confirming that the format is OK and the file transmission is not a duplicate.

2. NETS validates the due payment : <PaymentRQ> <PaymentAdd> in the incoming transmission with the local invoice storage.

NETS returns the 2nd level receipt with denied <PaymentRQ> <PaymentAdd> in <PaymentRS><PaymentAdd> and a status of approved/denied PaymentAdd in the PaymentRSInfo.

6.1.2 Explanation for 1st level receiptCr it er ia f or 1st level r eceipt :

• There will be one <FileReceiptionReceipt>


Page 24 of 28

• There will be no <ContentProviderRS>

The 1st level receipt will only contain a transmission level with <FileReceiptionReceipt>. Not an assignment or a transaction level. If denied in 1st level, the entire transmission is denied.

Main tags with elements that will be a part of a 1st level receipt:

No elements Tags that both receipts have in common are in blue Main tags that deviate from 2nd level receipts are in red Comments in bold

<?xml version=”1.0” encoding=”ISO-8859-1”?>

<Message><Response>

<FromInfo></FromInfo><ToInfo></ToInfo><FileReceiptionReceipt> Svar på validering av forsendelsesnivå</FileReceiptionReceipt>

</Response></Message>

6.1.3 Explanation for 2nd level receiptCr it er ia f or 2nd level r eceipt :

• <FileReceiptionReceipt> will NOT appear on transmission level.• The assignment level (ContentProviderRS) will appear as many times as the

ContentProviderRQ in the incoming transmissions• Denied PaymentAdd : <PaymentRQ> <PaymentAdd> will be returned in <PaymentRS>

<PaymentAdd>

Main tags with elements that will be a part of a 2nd level:

No elements Tags that both receipts have in common are in blue Main tags that deviate from 2nd level receipts are in red Comments in bold

<?xml version=”1.0” encoding=”ISO-8859-1”?><Message>

<Response><FromInfo></FromInfo><ToInfo></ToInfo>

</Response><ContentProviderRS>

<PaymentRS><PaymentRSInfo> svar på oppdragsnivå for oppdrag 1

.

. svar på avviste transaksjoner Utsteder/oppdrag 1


Page 25 of 28

.</PaymentRSInfo>

</PaymentRS></ContentProviderRS><ContentProviderRS>

<PaymentRSInfo> svar på oppdragsnivå for oppdrag 2.. svar på avviste transaksjoner Utsteder/oppdrag 2.

</PaymentRSInfo></ContentProviderRS>

</Message>

For a more detailed example, see chapter 6.2.

6.1.4 Reasons for denying 1st level receiptsThe 1st or 2nd level receipts will have different reasons for denial in error situations.

Errorcodes

Description

000 Transmission received ok in NETS, transmission still being handled001 Transmission is ok and has been handled524 Invalid date for incoming transmission (ServiceProviderFileDate)525 Invalid reference for incoming transmission (ServiceProviderFileReference)526 Test data in production (ServiceProviderFileStatus)527 Invalid recipient for incoming transmission (ServiceProviderId)528 Xml format for incoming transmission is not according to DTD529 Duplicate incoming transmission (ServiceProviderFileReference)

6.1.5 Reasons for denial for 2nd level receiptsContains status for assignment and transaction levels

Codes that may occur in the ContentProviderFileStatus element under the main tag ofContentProviderInfo :

Error codes

Description

000 Assignment ok (may contain denied single transactions).001 Transmission is ok and has been handled.101 Error in zip file102 Missing summary.xml103 Error in summary.xml104 Error when opening the file105 Error when reading number200 Xml is invalid according to schema201 The transmission is a duplicate202 Error in number of files400 The customer has not stated valid organization number.410 The customer does not have an agreement.507 Invalid issuer/assignment id (ContentProviderId)508 Invalid date for the assignment (ContentProviderFileDate)509 Invalid reference for the assignment in the incoming transmission


Page 26 of 28

(ContentProviderFileReference)510 Invalid product id (ProductId)511 Error in number of transactions in the assignment (NumberOfTransactions)512 Duplicate assignment (ContentProviderFileReference)*If one of these error codes occurs, the entire assignment will be denied.


Page 27 of 28

6.2 PaymentRS

The transaction level identifies which transactions the assignment contains. The following table shows an overview of the elements that may appear in a reply to an assignment in an incoming transmission.


<PaymentRS> Reply to the tag: <PaymentRQ> -

<PaymentRSInfo> -<ProductId> Contains the service code that

describes which NETS service this applies to.

• Numerical, 2 characters• eInvoice = 42

<NumberOfAcceptedTransactions>

Number of approved payment transactions in the incoming transmission.For now; PaymentAdd


<NumberOfRejectedTransactions>

Number of denied payment transactions inthe assignment in the incoming transmission. For now; PaymentAdd


<PaymentAdd> Response to denied <PaymentAdd> in the incoming transmission

-

<CustomerAgreementReference>

The customer’s eInvoice reference withissuer.


• No space• No period

<Reference> Reference to the sent transaction from issuer that this out going transmission from NETS isa response to.

The same value as in Reference for transactions in the incoming transmission.


YYYYMMDDXXXXXXX

Explanation:• YYYY = year• MM = month• DD = day• XXXXXXX = unique

serial number, ascending from 001

<BrandName> The name of the product the payment is for. • Alfa numerical , 30 characters

<Kid> KID for payments that use KID. If no KID is used, do not fill in this field.


<CreditAccountNumb er>

Credit card number • Numerical, characters 11

<DueDate> Invoice due date • Numerical, 8 characters• Format : DDMMYYYY

<AmountDue> Amount • Numerical, characters 17• Comma = øre marker• Period = thousand

marker.


Page 28 of 28

<MinimumAmountDue>

MinimumAmountDue. Optional element • Numerical, characters 17• Comma = øre marker• Period = thousand marker.

<PaymentType> 0 = eInvoice payment1 = ATG notice

• Numerical, characters 2

<DetailReference> URL for eInvoice details. • Alfa numerical, characters 500

<StatusCode> Code for denied due payment. See chapter6.2.1 for possible codes.

• Numerical, characters 3

6.2.1 Reasons for denial on transaction levelCodes that may appear in the Reason element under the main tag; Payment Add:

MISSING_PDF_IN_PAIR ("301"), MISSING_XML_IN_PAIR ("302"), INCORRECT_NUMBEROFFILES ("303");

Errorcodes

Description

054 Due date has incorrect format (DueDate)055 Invalid due date (DueDate)056 Stated amount has incorrect format (AmountDue)057 Stated amount is negative (AmountDue)058 Stated minimum amount has incorrect format (MinimumAmountDue)059 Stated minimum amount is negative (MinimumAmountDue)103 Stated due date too far ahead (DueDate)145 Credit card number has incorrect format (CreditAccountNumber)301 pdf missing in pdf/xml pair302 Xml missing in pdf/xml pair303 Erroneous number of files in the transmission325 KID is invalid (Kid)354 Transaction received too late (DueDate)501 Invalid code in PaymentType (PaymentType)502 Invalid credit card number (CreditAccountNumber)503 Due payment denied due to lack of active agreement

(CustomerAgreementReference, EfakturaIdentifier)504 Reference missing/not filled in correctly (Reference)505 Duplicate reference (Reference)506 DetailReference missing/not filled in correctly (DetailReference)550 Warning – BrandName not filled in (BrandName)

(NB! Invoice will not be denied)


Page 29 of 28

7 Amendment log for this manual

In charge of documents: Rodi Kristiansen

Amendment log

Ver. Chap Description Sign. auth. Sign. person incharge

Date

1.0 Changed tag names andstructure. XML file format must be checked.

Terje Dahl Rodi Kristiansen 28.01.02

1.9 3.1

3.2

Changed requirements for organization number in ServiceProviderId.Org.number in<ServiceProviderId>is no longer required, and validation of valid of org. number in this field is removed.

Changed requirements for org. Number in ContentProviderId. Org.number in<ContentProviderId> is no longer required, and validationof valid org. number in thisfield is removed.

Terje Dahl Terje Dahl 15.04.2008

1.9.1 6.1.5 New error codes added (200,201, 202, 400, 410) in 2nd level receipts. Especially for invoice print.

Hans PetterVadset

Terje Dahl 30.06.2008

2.0 Heal transition in this usermanual

Heidi Haarbye Heidi Haarbye Mars 2010

2.1 3.4

4.1

5.1

6.2.1

Replaced DTD with xml schema for incoming transmissions.

Added support for minimum amount to be paid. Added EfakturaIdentifier.

Replaced DTD with xml schema for receipts.

New error codes 58 and 59 in 2nd level receipts.

Espen Brøm 04.10.2016

brukerhåndbok autogiro - efaktura · web viewtechnical manual – due payment in xml format di ag...

Documents