# Technical response

Through the start to end flow of a message exchange; from the creation of an electronic message, down the transport line that goes through one or more transport networks to the designated receiver and all way through the eventual processing of the message content, there may be needed to give responses to the relevant parties up-line about the status or results of the actions that the message goes through.

sequenceDiagram

    participant c1 as ERP system
    participant ms1 as Messaging system
    participant c2 as VAN/Accesspoint
    participant c3 as VAN/Accesspoint
    participant ms2 as Messaging system
    participant c4 as ERP system

    Note over c1: Corner 1
    Note over c2: Corner 2
    c1->>c4: Business document
    Note over c3: Corner 3
    c3-->>c2: Transport acknowledgement
    c2-->>c1: Clearance notification
    ms2-->>ms1: Message level response
    Note over c4: Corner 4
    c4-->>c1: Business level response

These responses are of different nature but can be divided into the following main groups.

These are messages that are exchanged within the transport network(s) to inform about the process of carrying a message down the transport line. These responses may inform someone up-line that the delivery to a given point was successful or not and may contain details about issues that are relevant such as why a delivery was not successful.

The key nature of these responses is that they do not in any way act on result of validation or processing of the content of the payload that is being transported.

These response messages are commonly called "ACK/NACK" or technical receipts.

The use of the clearance notification message type is applicable in clearance and CTC markets where documents needs to be cleared or reported to the government or another assigned authority.

It will inform the issuer of a document of the clearance/reporting status (i.e. rejected or accepted) but can also contain clearance artefacts such as QR codes or a signed cleared document.

When a message has reached a given point in the transport line its content may be validated according to agreed specifications that may be both syntactical and semantic. The outcome of these validations may be reported to a relevant party up-line, informing him whether the validation was successful or not as well as giving some details.

An example could be that an order message that is received is rejected because it is missing a closing tag (syntax error) or because its amounts don’t add up according to what is specified in the relevant syntax specification.

A key nature of these messages is that they report on the message content on the basis of the technical specifications that apply.

A message that has been received and accepted for processing may call for an action on the receiver’s behalf. That receiver’s action may need to be reported back up-line to a relevant party. An example is that a technically correct order may be received but the receiver decides to reject the order for any business reason such as out-of-stock situation, expired contract etc.

The key nature of these responses is that they report a business decision that is made on the message instance received.

Technical response documents, mainly message- and business level response, are intrinsically connected to the application response document type.

For more information, please see the application response section.