root element
unique reference number identifying a single message. An xml-file my contain more than one message.
original sending, update or cancelation of an existing message
Response detail type qualifier
Location of a branch office.
UN/Locode; e.g. the location of the user's branch office.
If there is no UN/LoCode available for this place, alternatively the name can be set.
Communication data, e. g. the message's creation time or sender, recipient
Up to 11 entries can be sent:
SENDER - mandatory with DAKOSY-code
RECIPIENT - mandatory with DAKOSY-Code. Maximum of nine entries is possible.
EDI_PROVIDER
Date and time of message creation.
Format : 1999-05-31T13:20:00
Use local time. Value will be read "as it is". Please do not send an offset from the UTC.
plain text without validation. Either phone number or e-mail address must be filled if the user-element is transmitted.
Meta information for each message.
Contains information concerning transaction type, communication parties etc.
Specifies the transaction type (GM01, AB01 etc.). Only one transaction per file is allowed. Different types must be sent in separate files.
Name of the application that built the message.
unique reference per physical xml-file
0 - false (default);
1- true; transmission for test purpose
Number of messages (elements) that are collected in the transmitted file.
Code identifying the participant
Alias code. Describes how the participant is identified in a system, e.g. DAK as DAKOSY-code. Other identifiers are not specified yet.
Code identifying the participant
just for informal use
Needs only to be set if required by the specified role.
Desribes the particpant's communication part as the message's sender, it's recipient etc.
Required entries:
RECIPIENT
SENDER
EDI_PROVIDER
name of the party who is responsible for the underlying scheme.
Code defined by the provider for the specified transaction.
Single type which is represented by this file.
A Transaction identified by its code may contain several types identified by their type.
This hierarchy is known from EDIFACT-messages where e. g. the transaction GM01 (code) consists of CUSCAR and APERAK (type).
Version of message definition