This document describes the new version of EHF Payment Request (called "EHF Betalingsforespørsel" in Norwegian). The document is part of Norwegian Agency for Public and Financial Management (DFØ) standardization work related to electronic commerce.

1. Process and typical Use Cases

1.1. Process Diagram

The following diagram illustrates the basic EHF Payment Request process.

processdiagram
Figure 1. EHF Payment Request process diagram.

1.2. Typical use cases

1.2.1. Use case 1 - Victims of violence

Description

This use case illustrates the use of Payment Request, where a victim of violent receives financial compensasion.

Parties involved

Applicant
Payment Party
Party on behalf of applicant
Review Party

Assumptions

  1. A victim of violence (applicant) has been physically injured after a violence episode.

  2. A court order decide that the applicant receives 100000 Kr in financial compensation.

Flow: . The Norwegian National Courts Administration (Party on behalf of applicant and Review Party) sends EHF Payment Request to their accounting system (Payment party). . The payment party receives the electronic message and prepare a payment to the victim of violent (applicant). . The payment party sends payment to the victim of violent (applicant).

Result

  1. The victim of violent receives financial compensation in few days after a court decision.


1.2.2. Use case 2 - Research project funds

Description

This use case illustrates the use of Payment Request, where a research project from University of Tromso apply for funding.

Parties involved

Applicant
Payment Party
Party on behalf of applicant
Review Party

Assumptions

  1. An applicant apply for research project funding.

  2. This research project is related to University of Tromso (Party on behalf of applicant).

  3. The Norwegian Ministry of Education and Research (Review Party) provide 10000kr in funding for research projects that fulfil the criterias.

Flow

  1. An applicant apply for research funds through the party on behalf of applicant (University of Tromso).

  2. The University (Party on behalf of applicant) sends an application to The Norwegian Ministry of Education and Research (Review Party).

  3. The Review party evaluate the application and compare against a list of criteria.

  4. The Review party approve the application and send an EHF Payment Requst to their accounting system (Payment Party).

  5. The Payment party receives the electronic message from the Review party and prepare a payment to the applicant.

  6. Finally, the payment party sends payment to the applicant.

Result

  1. The Applicant receives funds from the Norwegian Ministraty of Education and Research’s accounting system (Payment Party).

  2. The Applicant receives the financial support in few days by using electronic processes.

2. Detailed Descriptions

This chapter describes selected parts of the information contents of the EHF Payment Request.

2.1. Parties and Roles

The important parties and roles in Payment Request is described below.

Payment Party

Payment party is the party that organize the payment to the applicant.

Applicant

The applicant is a person, project or organization that seeking financial support.

Review party

Review party is evaluating if the applicant is entitled to financial support.

Party on behalf of applicant

The party on behalf of applicant is an organisation that either supports the applicant or the organizational unit that applicant belongs to.

The following diagram illustrates the parties and roles involved in the Payment Request. Note that payment party is often from same organisation as applicant.

rolediagram
Figure 2. EHF Payment Request rolediagram.

2.2. Payment Means Information

2.2.1. Credit Transfer

If payment is made by credit transfer, the Payment account identifier (BT-84) is mandatory

See Payment Means codelist for all allowed codes. Examples of codes for payment by credit transfer are:

  • 30 - Credit transfer

  • 58 - SEPA credit transfer

UBL example of payment means info when payment is done by credit transfer
<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="Credit transfer">30</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>93274234</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>32423940</cbc:ID>(3)
        <cbc:Name>AccountName</cbc:Name>
        <cac:FinancialInstitutionBranch>
            <cbc:ID>BIC32409</cbc:ID>(4)
        </cac:FinancialInstitutionBranch>
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
1 Mandatory, payment means code for credit transfer
2 Remittance information
3 Mandatory, IBAN (in case of a SEPA payment) or a national account number (BBAN)
4 BIC or a national clearing code

2.3. UBL syntax calculation formulas

The following elements show the legal monetary totals for a payment request

Element Formula

<cbc:LineExtensionAmount>

\$sum("cac:InvoiceLine/cbc:LineExtensionAmount")\$

Appendix A: UBL 2.2

This implementation guide builds on UBL 2.2 Schemas, available from OASIS.

These schemas are used when performing syntax validation.

Please see the homepage for information about the standard or further resources available.

Appendix B: Semantic Datatypes

Semantic data types are used to bridge the gap between the semantic concepts expressed by the information elements and the technical implementation. The semantic data types define the allowed value domain for the content, and any additional information components (attributes) needed in order to ensure its precise interpretation.

B.1. Primitive types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000-5:2014, Annex A.

Primitive type Definition

Binary

A set of finite-length sequences of binary digits.

Date

Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.

Decimal

A subset of the real numbers, which can be represented by decimal numerals.

String

A finite sequence of characters.

B.2. Semantic data types

The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000-5:2014.

When used in an instance document, each data element will contain data. In the below tables this is identified as the “content”. Whenever a business term is used this term shall always have content and therefore the content is always mandatory.

B.2.1. Amount

An amount states a numerical monetary value. The currency of the amount is defined as a separate business term.

Amount is floating up to two fraction digits.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.25

B.2.2. Price Amount

A price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term.

Unit price amount does not set restrictions on number of decimals, as contrast to the Amount type
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

B.2.3. Percentage

Percentages are given as fractions of a hundred (per cent) e.g. the value 34,78 % in percentage terms is given as 34,78.

No restriction on number of decimals for percentages.
Component Use Primitive Type Example

Content

Mandatory

Decimal

34.7812

B.2.4. Quantity

Quantities are used to state a number of units such as for items. The code for the Unit of Measure is defined as a separate business term.

No restriction on number of decimals for quantities.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

B.2.5. Code

Codes are used to specify allowed values in elements as well as for lists of options. Code is different from Identifier in that allowed values have standardized meanings that can be known by the recipient.

Codes shall be entered exactly as shown in the selected code list
Component Use Primitive Type Example

Content

Mandatory

String

Abc123

B.2.6. Identifier

Identifiers (IDs) are keys that are issued by the sender or recipient of a document or by a third party.

The use of the attributes is specified for each information element.
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

Scheme identifier

Conditional

String

0088

Scheme version identifier

Conditional

String

1.0

B.2.7. Date

Dates shall be in accordance to the “Calendar date complete representation” as specified by ISO 8601:2004, format YYYY-MM-DD.

Dates shall not include timezone information.
Table 1. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

2017-12-01

B.2.8. Time

Time shall be in accordance to the “Extended time format” as specified by ISO 8601:2004, format [hh]:[mm]:[ss].

Time shall not include timezone information. Decimal fraction on seconds SHALL not be used.
Table 2. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

09:30:12

B.2.9. Document Reference

Document Reference Types are identifiers that were assigned to a document or document line.

Table 3. Document Reference. Type
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

B.2.10. Text

Text is the actual wording of anything written or printed. Line breaks in the text may be present, and any line breaks should be preserved and respected by the receiver’s system

Component Use Primitive Type Example

Content

Mandatory

String

5% allowance when paid within 30 days

B.2.11. Binary objects

Binary objects can be used to describe files which are transmitted together with the business document. Attachments shall be transmitted together with the business document. The binary object has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the business document.

Component Use Primitive Type Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

B.2.12. Boolean

Boolean indicators are used to specify the two allowed values, true or false. All elements of datatype Boolean, must have either true or false as their value.

Component Use Primitive Type Example

Content

Mandatory

String

true

Appendix C: Standard Business Document Header (SBDH)

Standard Business Document Header (SBDH) provides an envelope which contains key data when exchanging business documents between different systems. SBDH enables integration or transmission of document between:

  • internal application,

  • enterprise applications, and

  • business-to-business infrastructure.

The envelope information will determine the routing (Senders and Receivers EndpointID) and processing of a document based on header information. For example, routing business document (transforming information) from an external originator to receiver.

SBDH is RECOMMENDED to be used in combination with EHF Payment Request.

The use of SBDH follows the specification provided by OpenPEPPOL.

EHF Payment Request 3.0 is different from most transmissions in the PEPPOL Network as both sender party’s identifier and receiver party’s identifier MUST have same identifier.

The following example describes the SBDH implementation, and notice how the key data is implemented.

Example of how to implement SBDH.
<?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns = "http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
  <StandardBusinessDocumentHeader>
    <HeaderVersion>1.0</HeaderVersion>
    <Sender>
      <Identifier Authority="iso6523-actorid-upis">0192:123456785</Identifier> (1)
    </Sender>
    <Receiver>
      <Identifier Authority="iso6523-actorid-upis">0192:123456785</Identifier> (2)
    </Receiver>
    <DocumentIdentification>
      <Standard>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2</Standard>
      <TypeVersion>2.2</TypeVersion>
      <InstanceIdentifier>51ddd910-9a95-4b0f-ab01-b3cc0db59d01</InstanceIdentifier> (3)
      <Type>Invoice</Type>
      <CreationDateAndTime>2019-08-14T13:30:00Z</CreationDateAndTime> (4)
    </DocumentIdentification>
    <BusinessScope>
      <Scope>
        <Type>DOCUMENTID</Type>
        <InstanceIdentifier>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:fdc:difi.no:2017:ehf:spec:payment-request:3.0::2.2</InstanceIdentifier> (5)
      </Scope>
      <Scope>
        <Type>PROCESSID</Type>
        <InstanceIdentifier>urn:fdc:difi.no:2019:ehf:postaward:g3:07:1.0</InstanceIdentifier> (6)
      </Scope>
    </BusinessScope>
  </StandardBusinessDocumentHeader>
  <Invoice xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
           xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
           xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"> (7)

      <!-- Rest of the Payment Request input -->

  </Invoice>
</StandardBusinessDocument>
1 Identification of the sender, where the value MUST be the organization number of the handling organization (0192:[organization number]).
2 Identification of the receiver, where the value MUST be the organization number of the handling organization (0192:[organization number]).
3 Universal Unique Identifier (UUID), recommend version 4 UUID.
4 Date and time for when this envelope was created. Use format: YYYY-MM-DDThh:mm:ssZ, where T indicate a divider and Z indicates UTC.
5 Document type identifier for EHF Payment Request 3.0.
6 Process identifier for EHF Payment Request 3.0.
7 EHF Payment Request 3.0 instance document.