Message flow and use of EDIFACT - · PDF fileDocument Title Message flow and use of EDIFACT 2007-03-16 Date Version 2.1 6(20) ... Guide to the development of implementation guidelines

Message flow and use of EDIFACT Corporate eGateway

Table of contents

1 PURPOSE OF THIS GUIDE ....................................................................................................................................... 1

2 INTRODUCTION ......................................................................................................................................................... 1

2.1 THE EDIFACT MESSAGE STRUCTURE ........................................................................................................................ 2 2.2 SEGMENT TABLE NOTATION ........................................................................................................................................ 3

3 IDENTIFICATION AND DESCRIPTION OF SEGMENTS ................................................................................... 3

3.1 IDENTIFICATION OF SEGMENTS .................................................................................................................................... 3 3.2 IDENTIFICATION AND DESCRIPTION OF SEGMENT GROUPS ........................................................................................... 4 3.3 DESCRIPTION OF SEGMENT USAGE............................................................................................................................... 5

4 USAGE INDICATORS ................................................................................................................................................ 6

5 PROCESS FLOW AND VERIFICATION METHODS BY NORDEA’S MESSAGE CENTRE ......................... 7

6 SPECIFIC HANDLING OF MESSAGES IN NORDEA’S MESSAGE CENTRE ............................................... 12

6.1 SPECIFICATION OF THE USE OF THE UN/EDIFACT SYNTAX RULES........................................................................... 12 6.2 CHARACTER SET AND ENCODING............................................................................................................................... 12 6.3 SEPARATORS AND THE USE OF THE UNA SEGMENT ................................................................................................... 12 6.4 SERVICE SEGMENTS USAGE AND STRUCTURE ............................................................................................................ 12

6.4.1 UNA - Service String Advice (R1) ................................................................................................................... 13 6.4.2 UNB - Interchange Header (M1) .................................................................................................................... 14 6.4.3 UNZ - Interchange Trailer (M1) ..................................................................................................................... 15

6.5 MESSAGE ACCEPTANCE ACKNOWLEDGEMENT (MAA) ............................................................................................ 15 6.6 ERROR MESSAGES ..................................................................................................................................................... 15 6.7 SPECIAL FOR THE BANSTA MESSAGE FOR PAYMUL MESSAGES ........................................................................... 15

6.7.1 BANSTA messages for domestic and cross-border (international) payments ................................................. 16 6.8 SPECIAL FOR THE BANSTA MESSAGE FOR DIRDEB MESSAGES .............................................................................. 16 6.9 DUPLICATE DETECTION ............................................................................................................................................ 17

6.9.1 PAYMUL ......................................................................................................................................................... 17 6.9.2 Duplicate Detection for DIRDEB ................................................................................................................... 17 6.9.3 Rejections ........................................................................................................................................................ 18

7 CHANGES WITHIN CORPORATE EGATEWAY ............................................................................................... 19

7.1 DEFINITION OF THE CHANGES .................................................................................................................................... 19

Version change history Version Date Description of the changes Version 2.1 2007-03-16 New structure of the document. Message flow removed from other

documents and included in this version. Use of EDIFACT includes general EDIFACT usage as well as Corporate eGateway specific rules and usage.

Changes due to updated version of the Corporate eGateway agreement

Version 2.2 2014-06-16 6.9.1 Number of days transactions will be stored for duplicate check corrected from 180 to 90.

Document title Message flow and use of EDIFACT

2014-06-16 Date

Version 2.2 1(20) Page

Author Reference

Subject Message flow within the service and implementation guide for EDIFACT users

Department CM Products

Project Corporate eGateway

1 Purpose of this guide

This guide is intended for technical persons when implementing the EDIFACT Message Implementation guides for Corporate eGateway. The intention of this guide is to give a brief introduction to how an EDIFACT message is constructed and how Corporate eGateway is handled in particular areas, ie duplicate control, error messages etc. The guide should primarily be read by technical persons with a good knowledge about creating and programming different formats for ERP systems and/or converter programs. The terms and definitions used in this document are defined in the separate document Glossary for Corporate eGateway, which can be found on Nordea's website: www.nordea.com

2 Introduction

This chapter specifies how the Message Implementation Guides (MIGs) are documented. It specifies the notation, terminology and abbreviations used for describing the Message structure and the segment usage in the Messages. It also gives a short introduction to the EDIFACT message structure. The first part of the MIG gives an overview of the Message it is describing. Then the EDIFACT Message is illustrated by way of a segment table. The segment table shows the segments and segment groups used in the implementation. In the second part of the MIG the segments and segment groups used are described in detail. For basic information on the EDIFACT structure, please see General Introduction to UNSM Descriptions: http://www.unece.org/trade/untdid/texts/d426_d.htm

http://www.nordea.com/

http://www.unece.org/trade/untdid/texts/d426_d.htm

Document Title Message flow and use of EDIFACT 2007-03-16 Date


Reference

2.1 The EDIFACT Message structure

All data transmitted in EDIFACT Messages are organised in segments. A segment is a collection of related data and is identified by a tag. For example: Name and address information is stated in the NAD segment (name and address). Segments in an EDIFACT Message may be organised in segment groups. A segment group is a collection of segments used to convey related data that cannot be achieved by one single segment. A group of segments is identified by a segment group number, which is the sequential number of the segment groups within the EDIFACT Message. Each segment and segment group may occur a certain number of times. The minimum number of occurrences is specified by the status C-conditional (meaning zero occurrences) or the status M-Mandatory (meaning at least one occurrence). See also the next page. For example: Data on document details is given in segment group 17, using the DOC segment to give invoice number or credit note number. In addition to this for example invoice amount and invoice date can be stated in the MOA and DTM segments in the same segment group. ----- Segment group 17 ------------------- C9999 D9999-----+||| DOC Document/message details M1 M1 |||| MOA Monetary amount C5 A1 |||| DTM Date/time/period C5 A1 |||| Each segment is constructed from data elements and composite data elements. One data element contains one piece of data, and it is identified by a four-digit number. For example: Element 2380 contains a date. A composite data element consists of multiple data elements and is identified by a four-character code starting with a C followed a three-digit number. For example: C507 is a composite that identifies a date and its usage. C507 DATE/TIME/PERIOD 2005 Date/time/period qualifier 2380 Date/time/period 2379 Date/time/period format qualifier



Reference

2.2 Segment table notation

The segment table is used to give an overview of the whole EDIFACT Message structure. Only segments and segment groups shown in bold are used. Tag: Segment tag Name: Segment name or segment group number Status: Segment or segment group status according to either EDIFACT (Mandatory or

Conditional) or Nordea usage (for code usage, see chapter 4 Usage indicators) Repeats: The maximum number of occurrences of a segment or a segment group according to

either EDIFACT or Nordea usage Loop: A ”graphical” description of the loop structure – ie the beginning and end of groups. Status/ Status/

repeats repeats Tag Name EDIFACT Nordea Loop ----- Segment group 12 ------------------ C3 D1---------+ FII Financial institution information M1 M1 | CTA Contact information C1 0 | COM Communication contact C5 0---------+

3 Identification and description of segments

3.1 Identification of segments

The segment definition starts with the segment tag and name. The status and repetition of the segment according to the MIG is stated in parentheses. See also chapter 4 Usage indicators. If the segment is included in a segment group, a reference to the segment group number is stated on the right hand side of the heading. Function: Relevant parts of the functional description are defined in the UN/EDIFACT Message definition.



Reference

Use: If stated, this section gives additional information (to the functional description) about how the segment is intended to be used in accordance with the MIG. Semantic notes: If stated, this section gives important information about the use of composites, data elements and code values, along with conditions for their usage. Example: DTM - Date/time/period (R1) Segment group 4 Function: A segment identifying the date at which a payment order has been requested to be

executed.

3.2 Identification and description of segment groups

The segment group definition starts with the segment group number. The status and repetition of the segment group according to the MIG is stated in parentheses. See also chapter 4 Usage indicators. Function: Relevant parts of the functional description are defined in the UN/EDIFACT Message definition. Use: If stated, this section gives additional information of special interest for the Sender or Receiver of the message. Segments included in the segment group: An overview of the segments to be used in the segment group. It is not allowed to use other segments than those stated. Each of the segments listed is described in detail later. The overview shows the segment tag, segment name and usage indicators. Example: Segment group 5 (R1) Function: A group specifying the amount and the currency for the debit side of the payment order

and the currency for all credit transactions pertaining to the payment order.



Reference

3.3 Description of segment usage

Tag: Identification of the composite data element or the data element. Name: Name of the composite data element (in uppercase) or the data element (in lowercase). Status: Status of the composite data element or the data element according to EDIFACT. Repr: The representation of a data element (type and length). an = alphanumeric, n = numeric, a = alphabetic n3 = numeric, 3 positions fixed length an..35 = alphanumeric, variable length with maximum 35 positions Use: The use of a composite data element or a data element in this implementation. See

chapter 4 Usage Indicators. If the value ”N” (not used) is stated for a composite data element, none of the data elements within this composite should be present in a Message exchange (and are therefore not marked separately).

Use of elements in the Message: This column states the EDIFACT code values allowed in accordance with the MIG and

identifications of the data values that the elements should contain. Code values: If the element is a coded element, the allowed codes are stated including the EDIFACT

short description. Eg 203 Execution date Data values: If the element is a non-coded element, the data value is stated in arrow-brackets and in

bold. Eg <Date> Tag: Name: Status: Repr: Use: Use of elements in the message: C507 DATE/TIME/PERIOD M M 2 005 Date/time/period qualifier M an..3 M 203 Execution date 2 380 Date/time/period C an..35 O <Date> 2 379 Date/time/period/format qualifier C an..3 O 102 CCYYMMDD



Reference

4 Usage indicators

A description of the usage indicators used in the MIGs is given below. For a complete explanation see: Guide to the development of implementation guidelines for users of UNSM. Usage indicators following this description are used for segment groups, segments, composite data elements and data elements. M - Mandatory, according to UN/EDIFACT, must therefore be present. R - Required, indicates that the data concerned must be sent as a business requirement. D - Depending, indicates that the data concerned must be sent if a particular defined condition

or set of conditions exist. The associated conditions must be specified in the implementation guideline.

A - Advised, indicates that the receiver of the Message would prefer the data to be present, but does not require it.

O - Optional, indicates that the transmission of this data is at the discretion of the sender, ie it is not required by the receiver.

N - Not used, indicates that the data concerned is not to be sent. A number, together with the usage indicator, indicates the maximum number of times the segment or the segment group is allowed to be repeated in the message. For example: M10 - The segment group or the segment must be present with one occurrence in the

transmission, but is allowed to be repeated up to a maximum of ten times.



Reference

5 Process flow and verification methods by Nordea’s Message Centre

It is important to have full understanding of what and how Nordea’s Message Centre performs validation of all Messages including the AUTACK Message. Scenario 1: Normal Message flow An interchange containing payment orders (PAYMUL), direct debit instructions (DIRDEB) or mandate request form (AUTHOR) may be sent from the Customer to the Message Centre. The

interchange is secured by using one AUTACK Message. If the message orders are received properly at the Message Centre and encrypted signature(s) are verified, a positive CONTRL Message is returned as soon as possible. When the CONTRL Message has reached the Customer it implies that the Message Centre acknowledges receipt of the Message and assumes responsibility for further processing of the transactions (Message Acceptance Acknowledgement). The Message orders will then be processed (converted to domestic formats) by the Message Centre and transmitted to the Ordered Banks for execution.

A BANSTA Message is sent to the customer as soon as possible after receipt of the message, depending on the option chosen by the Customer. This BANSTA Message reflects the status after validation on input day and may contain either rejected instructions or both accepted and rejected instructions. Rejected instructions are not booked or processed. Note 1: Nordea’s Message Centre only creates a +ve CONTRL Message if the whole interchange is correct and no errors are detected. A –ve CONTRL is only created in relation to the business Message, eg the PAYMUL, DIRDEB or AUTHOR Messages, but never for the AUTACK EDIFACT Message on its own, see below. Note 2: If a Message is incomplete or incorrect, Nordea may but is not obliged to inform the customer of the incompleteness or incorrectness and to provide the Customer with information concerning the problem. All of the corrections and changes to the Message must, however, always be carried out by the Customer. See also 6.9 Duplicate detection

Accepted / rejected

on input day

CustomerMessageCentre

Orderedbanks

PAYMUL / AUTACK

+ve CONTRL

Payment orders

+-ve BANSTARejected on

payment day

-ve BANSTABooking of accep-ted payment orders



Reference

Scenario 2: Syntax error

A syntactical error is detected in a Message (PAYMUL, DIRDEB or AUTHOR) when the interchange is received by the Message Centre. A negative CONTRL Message is then returned, rejecting the interchange. A reference to the Message number and the segment in the Message where the error occurred is included in the negative CONTRL Message. The Customer must locate and correct the error and if necessary contact Service Support for help. Then the Customer must send the rejected Message again in a new interchange. Level B (payment order) and level C (credit transactions) will contain the same reference numbers as the originals.

Note: No –ve CONTRL Message is sent for syntactical errors related to the AUTACK Message only. If the Message itself (eg PAYMUL, DIRDEB or AUTHOR) is syntactical correct but any syntax error is detected for the AUTACK Message, the whole interchange will be rejected without a CONTRL Message and the Customer will be contacted by telephone and/or e-mail. Scenario 3: Security violation / security problems

If the interchange fails security verification at the Message Centre, a fax/phone call or e-mail will be returned to the security contact persons specified by the Customer. The following points are defined as security violation: Unsuccessful verification of signature(s) Missing AUTACK

CustomerPAYMUL / AUTACK

Tel. / Fax etc

MessageCentre


PAYMUL / AUTACK

-ve CONTRL

PAYMUL / AUTACK

+ve CONTRL



Reference

Customer

PAYMUL / AUTACK

+ ve CONTRL

+ ve CONTRL

Timeout - No CONTRL

Message

Centre

Customer

PAYMUL / AUTACK

+ ve CONTRL

Time out - No CONTRL

Message

Centre

PAYMUL / AUTACK

Scenario 4: Lost CONTRL, re-transmission of CONTRL

If the Customer does not receive any CONTRL Message for a sent payment order (PAYMUL), within the timeframe specified, the Customer must locate the problem (Service Support etc). The Message Centre will re-send the CONTRL

Message until a communication receipt is received.

Scenario 5: Lost PAYMUL, re-transmission of PAYMUL

If the Customer does not receive a CONTRL Message for a transmitted interchange within the timeframe specified, the Customer must locate the problem (contact Service Support etc) and then re-transmit the interchange. A re-transmission is an exact copy of an original

multiple payment order interchange. This implies that all references within the payment (PAYMUL) file Message including the interchange reference and the Message reference will be exactly the same as in the original payment (PAYMUL) file interchange.



Reference

Returnpayments


OrderedBanks

ReceivingBanks

PAYMUL /

Payments

Debit adviceand/or bankstatement

DEBMULand/or FINSTA

Booking - outgoing

Credit adviceand/or bankstatement

CREMUL and/orFINSTA

Booking -incoming

Payment

BookedPayments

Customer

Booked payments on payment day

Message Centre

Ordered banks

PAYMUL / AUTACK

+ ve CONTRL Payment orders

DEBMUL

Debit advice for booked payments

Scenario 6: Booked payments returned by the beneficiary’s bank The Receiving Bank may reject a payment that is accepted and booked by a Nordea Company. This payment will be reported to the Customer as a debit transaction in the DEBMUL or FINSTA Message.

In the next step the returned payment will be booked to the account and this will be shown as a credit transaction in the CREMUL and/or FINSTA Message sent by the Message Centre to the Customer. The Customer must re-book the payment by sending a new payment order transaction to the Message Centre.

Scenario 7: Debit advice (DEBMUL) Message

An interchange containing a payment order (PAYMUL) is sent from the Customer to the Message Centre. After Nordea and/or the local service provider have processed the payment order, a debit advice (DEBMUL) Message can be provided to the customer from Corporate eGateway, for reconciliation of the customer’s supplier ERP system. Note: Debit advice orders (DEBMUL) can only be received for domestic payments from the Baltic and Nordic countries and for International payments only from Finland, Norway and Sweden.



Reference

Scenario 8: Credit advice and bank statement

Incoming payments with references to invoices will be reported in a CREMUL Message immediately after booking. If one credit transaction on the account represents many outstanding invoices, the references to all the invoices will be reported in a structured form in the CREMUL Message, provided that the information is present in the credit advises.


Orderedbanks

PAYMUL / AUTACK

Credit advices

CREMUL

Booking of accepted payment orders and incoming payments

Bank statements

FINSTA

End of day

Payment orders



Reference

6 Specific handling of messages in Nordea’s Message Centre

6.1 Specification of the use of the UN/EDIFACT syntax rules

Version 3 of the UN/EDIFACT syntax rules must be used for all transmissions between the parties as described below:

6.2 Character set and encoding

The UNOC character set, encoded according to ISO 8859-1, must be used for all messages.

6.3 Separators and the use of the UNA segment

Standard separators according to character set UNOA of UN/EDIFACT - must be used for all messages: ' (apostrophe) segment terminator + (plus sign) data element separator : (colon) composite data element separator ? (question mark) release character . (full stop) decimal notation The UNA segment should always be present in an interchange to indicate which separators are used. Other character sets than UNOA do not support the UNOA separators; therefore the UNA segment must be present to support the UNOA separators.

6.4 Service segments usage and structure

The following service segments are in use and should form part of every interchange between the customer and Corporate eGateway.

Segm ID Segment name Use

UNA Service String Advice R1 UNB Interchange Header M1 Message Group M9999 UNH Message Header M1 User Data according to MIGs UNT Message Trailer M1 UNZ Interchange Trailer M1

The use of the UNH and UNT segments is specified in each Message implementation guide.



Reference

6.4.1 UNA - Service String Advice (R1)

Tag: Name: Status: Repr: Use: Use of elements in the Message: COMPONENT DATA ELEMENT

SEPARATOR M An1 M : (Colon)

DATA ELEMENT SEPARATOR M An1 M + (Plus sign) DECIMAL NOTATION M An1 M . (Full stop)

RELEASE INDICATOR M An1 M ? (Question mark )

Reserved for future use M An1 M Space character

SEGMENT TERMINATOR M An1 M ' (Apostrophe) Layout: UNA:+.? '



Reference

6.4.2 UNB - Interchange Header (M1)

Character ‘/’ is not allowed in the interchange reference field. Tag: Name: Status: Repr: Use: Use of elements in the message: S001 SYNTAX IDENTIFIER M M 0001 Syntax identifier M a4 M UNOC 0002 Syntax version number M n1 M 3 S002 INTERCHANGE SENDER M M 0004 Sender identification M An..35 M <Sender Identification> 0007 Partner identification code qualifier A An..4 O <Sender Qualifier> 0008 Address for reverse routing O an..14 N S003 INTERCHANGE RECIPIENT M M 0010 Recipient identification M An..35 M <Recipient Identification> 0007 Partner identification code qualifier A An..4 O <Recipient Qualifier> 0014 Routing address O an..14 N S004 DATE/TIME OF PREPARATION M M 0017 Date M n6 M Date of interchange 0019 Time M n4 M Senders local time 0020 INTERCHANGE CONTROL

REFERENCE M An..14 M Unique interchange reference

S005 RECIPIENT’S REFERENCE,

PASSWORD C N

0022 Recipient's reference/ password M an..14 N 0025 Recipient's reference/ password

qualifier C an2 N

0026 APPLICATION REFERENCE C an..14 N 0029 PROCESSING PRIORITY CODE C A1 N 0031 ACKNOWLEDGEMENT

REQUEST C n1 O 1 if a CONTRL Message should be

returned, otherwise not used

0032 COMMUNICATIONS

AGREEMENT C an..35 N

0035 TEST INDICATOR C n1 O 1 if the interchange is a test, otherwise

not used Example: UNB+UNOC:3+NORDEATEST:ZZ+333666999+000404:1404+1001’



Reference

6.4.3 UNZ - Interchange Trailer (M1)

Tag: Name: Status: Repr: Use: Use of elements in the Message: 0036 INTERCHANGE CONTROL

COUNT M n..6 M Number of Messages in the interchange

0020 INTERCHANGE CONTROL REFERENCE

M An..14 M Identical to 0020 in UNB

Example: UNZ+1+1001’

6.5 Message Acceptance Acknowledgement (MAA)

All Messages sent to and/or from Nordea’s Message Centre are considered to be received by the receiving party when the transmitting party has received a Message Acceptance Acknowledgement (MAA) regarding the sent message. The transmitter of the Messages is obliged to check that a MAA is received for all sent files. If a MAA is not received, the file containing the Messages must be re-transmitted. A re-transmission from either party must always be confirmed by Corporate eGateway, Service Support. The MAA is implemented using a CONTRL message.

6.6 Error Messages

The following error Messages are possible; - Security error Response by telephone only to customer - Syntax error CONTRL - Validation error on PAYMUL BANSTA from each country - Validation error on DIRDEB BANSTA from Corporate eGateway - Validation error on DIRDEB BANSTA from each country

6.7 Special for the BANSTA Message for PAYMUL Messages

You are able to send one file containing PAYMUL for more than one country, but the BANSTA message will be returned country-wise. You will receive one BANSTA message for domestic payments and one BANSTA message for cross-border payments. A BANSTA message may contain up to 99 payments. If there are more than 99 payments in the PAYMUL, the connected BANSTA message will be split into more BANSTA messages (normal EDIFACT standard).



Reference

6.7.1 BANSTA messages for domestic and cross-border (international) payments

Payments are advised at either B or C level, both accepted and/or rejected. The option used by the customer must be stated when the service is implemented. If the SWIFT communication channel rejects a cross-border payment, it is not possible for the Message Centre to create a BANSTA message. In those cases Corporate eGateway’s Service Support will inform the customer about the rejection, either by e-mail or by telephone. If errors are detected in the AUTACK message, neither a CONTRL message nor a BANSTA message is generated In the following cases a +ve CONTRL message is generated, and a –ve BANSTA message: If the same reference is used for more than one payment in the following segments: SG7, NAD “ZZZ” = B level (use of this segment is optional)

SG11, RFF “CR” = C level (this segment will always be validated)

If any errors are detected, a BANSTA message will be created for each local service and each local country. For references used for duplicate check, please see 6.9.1. If errors are detected in the AUTACK message, neither a CONTRL message nor a BANSTA message is generated

6.8 Special for the BANSTA message for DIRDEB messages

You are able to send one file containing DIRDEB for more than one country, but the BANSTA message will be returned for each local service used country-wise. One BANSTA message may contain up to 99 payments. If there are more than 99 payments in the DIRDEB, the connected BANSTA message will be split into more BANSTA messages (normal EDIFACT standard). BANSTA for DIRDEB instructions: Instructions are advised at either B or C level, only rejected. No option exists. BANSTA for DIRDEB from Corporate eGateway: Nordea’s Message Centre will perform several checks, such as cut-off time, fundamental validations and duplicates. If any errors are detected a BANSTA message will be created for each local service and each local country. For references used for duplicate check, please see 6.9.2. If errors are detected in the AUTACK message, neither a CONTRL message nor a BANSTA message is generated.



Reference

6.9 Duplicate Detection

The customer must avoid sending duplicates; Corporate eGateway will endeavour its best effort to detect such duplicates. The receiver at interchange or application level will, if possible, detect duplicates. Nordea’s Message Centre will, however, perform a duplicate check on the application level, on all PAYMUL and DIRDEB Messages, that are received, but Corporate eGateway will not under any circumstances be liable for processing such duplicates if not detected by Nordea’s Message Centre.

6.9.1 PAYMUL

The application level references are stored two different places in the PAYMUL Messages: Level Segment Qualifier Mandatory/

Optional B NAD “ZZZ” Optional

C RFF CR Mandatory Note that at C level in PAYMUL the Customer’s own reference is used for the duplicate control. If the Customer can deliver no unique reference at C level, the Message Centre will check for duplicates combining both the B-and C-level reference. For each transaction all of the above-mentioned references are stored in Corporate eGateway. If two transactions are received with the same application reference, the last arrived transaction may be rejected if detected by the Message Centre. Transactions will be stored for duplicate control in Corporate eGateway for 90 days.

6.9.2 Duplicate Detection for DIRDEB

In DIRDEB the duplicate references vary per country. No A-level reference from EDIFACT is used, but instead the creditor identification (B level) and the payment reference - OCR no (C level) are used for duplicate control. Sweden AGF B level FII BF C level RFF AFO Norway B level FII BF C level RFF AFO Finland B level NAD HS C level RFF AFO



Reference

Denmark BS B level NAD HS C level RFF AST (debitorgruppenummer) B level OR C level DTM 203 LS B level NAD HS C level RFF AST (debitorgruppenummer) B level OR C level DTM 203 The above-mentioned references uniquely identify the transaction for each country. The references are stored in Corporate eGateway. If two transactions are received with the same application reference, the last arrived transaction may be rejected. Rejected transactions are reported to the Customer in a BANSTA Message. These duplicate transactions may not be processed, however Corporate eGateway is not liable for processing such transactions, if not detected by Nordea’s Message Centre. Other transactions from DIRDEB will be processed as usual. Transactions will be stored for duplicate control in Corporate eGateway for 90 days.

6.9.3 Rejections

When received in Corporate eGateway a Message is split up into different files. For each country there will be a different file, one for domestic, one for international payment and one for each local direct debit service. Each file is processed separately. If duplicates are detected in a PAYMUL Message file the whole file may be rejected and may not be processed further. If duplicates are detected in a DIRDEB Message each individual instruction at C level may be rejected and may not be processed further. Corporate eGateway is however not liable for processing such duplicates if not detected by Nordea’s Message Centre. The files containing the other transactions are processed as usual. Rejected transactions, due to duplicate references in a PAYMUL Message, are reported to the Customer by telephone from Service Support. For DIRDEB a BANSTA Message will be created towards the Customer, specifying the reference for the rejected instruction.



Reference

7 Changes within Corporate eGateway

Nordea continuously upgrades the EDIFACT Messages used in Corporate eGateway. This is done due to legislation requirements in each local country, changes of the Local Services used by Corporate eGateway, and/or due to new services that are incorporated into the Corporate eGateway service in order to facilitate a high functionality and quality towards its Customers.

7.1 Definition of the changes

Upgrades and/or changes performed by Corporate eGateway are divided into two (2) different definitions with corresponding time frames for the production date of needed changes. Definition Production date Major Changes Six (6) months Minor Changes Three (3) months Nordea will inform its Customers of any upgrading and/or changes of Corporate eGateway that require actions to be taken by the Customers or has otherwise significance to the Customers. Minor Changes (as defined below) of Corporate eGateway must be informed by Nordea to the Customer three (3) months before production date and Major Changes (as defined below) six (6) months before production date. The Customer is responsible for upgrading its software used towards Corporate eGateway in accordance with such announcement from Nordea. All amendments or changes of the EDIFACT file format, which are considered major changes by Nordea are stated in the table below. Major changes are defined as changes that require that the Customer must open up the segments/elements within its own enterprise resource planning system in order to be able to handle (process) the Messages received from Corporate eGateway or send messages to Corporate eGateway in a required manner. All amendments or changes of the EDIFACT file format, which are considered minor changes are also stated in the table below. Minor changes are defined as changes where the customer does not need to use or recognise the segments/elements, when processing the message in question within the customer’s own enterprise resource planning system or other changes that do not require major technical changes made by the Customer. General changes of Corporate eGateway Effect Explanation New EDIFACT syntax version Major New/change of cut-off times Minor New local services for Corporate eGateway Minor New services added by Nordea Changes in text and/or explanations Minor Changes of qualifiers Minor Content changes of elements Minor e.g. field lengths etc.



Reference

EDIFACT Messages from the Customer to Corporate eGateway Changes of segments/elements for the Message Status From/To Status Effect New and/or removal - - Optional Minor New and/or removal - - Required Major Change Optional To Required Major Change Required To Optional Minor

EDIFACT Messages from Corporate eGateway to the Customer Changes of segments/elements for the Message Status From/To Status Effect New and/or removal - - Optional Minor New - - Required Minor Removal - Required Major Change Optional To Required Minor Change Required To Optional Major

Documents

Message flow and use of EDIFACT - · PDF fileDocument Title Message flow and use of EDIFACT 2007-03-16 Date Version 2.1 6(20) ... Guide to the development of implementation guidelines