ReceiptV05

camt.025.001.05

Scope The Receipt message is sent by the transaction administrator to a member of the system. It is sent to acknowledge the receipt of one or multiple messages sent previously. The Receipt message is an application receipt acknowledgement and conveys information about the processing of the original message(s). Usage The Receipt message is used when the exchange of messages takes place in an asynchronous manner. This may happen, for instance, when an action is requested from the transaction administrator (a deletion, modification or cancellation). The transaction administrator will first acknowledge the request (with a Receipt message) and then execute it. The message can contain information based on the following elements: reference of the message(s) it acknowledges, the status code (optional) and further explanation:

• reference of the message it acknowledges
• potentially, a status code and an explanation.

Message Construction

Every ISO20022 message has at the highest level what we call ‘building blocks’. Because the message is constructed as immutable records, the association is by composition. Below you can see the relationship between the message and its constituent building blocks: For comparison, see the ISO20022 official specification

classDiagram
     direction LR
%% ReceiptV05 recursion level 0 with max 0
ReceiptV05 *-- "1..1" MessageHeader9 : MessageHeader
ReceiptV05 *-- "1..1" Receipt3 : ReceiptDetails
ReceiptV05 *-- "0..1" SupplementaryData1 : SupplementaryData
  

Now, we will zero-in one-by-one on each of these building blocks.

MessageHeader building block

Common business identification for the message. Set of characteristics, such as the identification or the creation date and time, specific to the message. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% MessageHeader9 recursion level 0 with max 1
class MessageHeader9{
    MessageIdentification IsoMax35Text
    CreationDateTime IsoISODateTime
}
MessageHeader9 *-- "0..1" IRequestType4Choice : RequestType
%% IRequestType4Choice recursion level 1 with max 1
  

MessageHeader9 members

ReceiptDetails building block

Details of the receipt. Provides details on the request. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% Receipt3 recursion level 0 with max 1
Receipt3 *-- "1..1" OriginalMessageAndIssuer1 : OriginalMessageIdentification
Receipt3 *-- "0..1" IPaymentIdentification6Choice : OriginalPaymentIdentification
Receipt3 *-- "0..0" RequestHandling1 : RequestHandling
%% OriginalMessageAndIssuer1 recursion level 1 with max 1
class OriginalMessageAndIssuer1{
    MessageIdentification IsoMax35Text
    MessageNameIdentification IsoMax35Text
    OriginatorName IsoMax70Text
}
%% IPaymentIdentification6Choice recursion level 1 with max 1
%% RequestHandling1 recursion level 1 with max 1
class RequestHandling1{
    StatusCode IsoMax4AlphaNumericText
    Description IsoMax140Text
}
  

Receipt3 members

SupplementaryData building block

Additional information that cannot be captured in the structured elements and/or any other specific block. Additional information that can not be captured in the structured fields and/or any other specific block. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% SupplementaryData1 recursion level 0 with max 1
class SupplementaryData1{
    PlaceAndName IsoMax350Text
}
SupplementaryData1 *-- "1..1" IsoSupplementaryDataEnvelope1 : Envelope
%% IsoSupplementaryDataEnvelope1 recursion level 1 with max 1
  

SupplementaryData1 members

Extensibility and generalization considerations

To facilitate generalized design patterns in the system, the ReceiptV05 implementation follows a specific implementaiton pattern. First of all, ReceiptV05 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, ReceiptV05Document implements IOuterDocument. Because ReceiptV05 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type ReceiptV05.

classDiagram
    class IOuterRecord
    ReceiptV05 --|> IOuterRecord : Implements
    ReceiptV05Document --|> IOuterDocument~ReceiptV05~ : Implements
    class IOuterDocument~ReceiptV05~ {
        ReceiptV05 Message
     }
  

Document wrapper for serialization

The only real purpose ReceiptV05Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:camt.025.001.05’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using ReceiptV05.ToDocument() method. The returned ReceiptV05Document value will serialize correctly according to ISO 20022 standards.

classDiagram
    ReceiptV05Document *-- ReceiptV05 : Document
  

Sample of message format

This is an abbreviated version of what the message should look like.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.025.001.05">
    <Rct>
        <MsgHdr>
            <!-- MessageHeader inner content -->
        </MsgHdr>
        <RctDtls>
            <!-- ReceiptDetails inner content -->
        </RctDtls>
        <SplmtryData>
            <!-- SupplementaryData inner content -->
        </SplmtryData>
    </Rct>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_jwlb8RbvEeiyVv5j1vf1VQ"
  nextVersions="_jx5UwwKxEe2rHs6fbn9-0A"
  name="ReceiptV05"
  definition="Scope&#xD;&#xA;The Receipt message is sent by the transaction administrator to a member of the system. It is sent to acknowledge the receipt of one or multiple messages sent previously.&#xD;&#xA;The Receipt message is an application receipt acknowledgement and conveys information about the processing of the original message(s).&#xD;&#xA;Usage&#xD;&#xA;The Receipt message is used when the exchange of messages takes place in an asynchronous manner.&#xD;&#xA;This may happen, for instance, when an action is requested from the transaction administrator (a deletion, modification or cancellation). The transaction administrator will first acknowledge the request (with a Receipt message) and then execute it.&#xD;&#xA;The message can contain information based on the following elements: reference of the message(s) it acknowledges, the status code (optional) and further explanation:&#xD;&#xA;- reference of the message it acknowledges&#xD;&#xA;- potentially, a status code and an explanation."
  registrationStatus="Registered"
  messageSet="_S0OMdGY1EeuQ__SOdbf47A"
  xmlTag="Rct"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <messageBuildingBlock
    xmi:id="_jwlb8xbvEeiyVv5j1vf1VQ"
    nextVersions="_jx5UywKxEe2rHs6fbn9-0A"
    name="MessageHeader"
    definition="Common business identification for the message."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="MsgHdr"
    complexType="_jAUZkZIhEeect698_YsnIA" />
  <messageBuildingBlock
    xmi:id="_jwlb9RbvEeiyVv5j1vf1VQ"
    nextVersions="_jx5UzQKxEe2rHs6fbn9-0A"
    name="ReceiptDetails"
    definition="Details of the receipt."
    registrationStatus="Provisionally Registered"
    minOccurs="1"
    xmlTag="RctDtls"
    complexType="_IC3ysW4-EeiU9cctagi5ow" />
  <messageBuildingBlock
    xmi:id="_jwlb9xbvEeiyVv5j1vf1VQ"
    nextVersions="_jx5UzwKxEe2rHs6fbn9-0A"
    name="SupplementaryData"
    definition="Additional information that cannot be captured in the structured elements and/or any other specific block."
    registrationStatus="Provisionally Registered"
    minOccurs="0"
    xmlTag="SplmtryData"
    complexType="_Qn0zC9p-Ed-ak6NoX_4Aeg_468227563" />
  <messageDefinitionIdentifier
    businessArea="camt"
    messageFunctionality="025"
    flavour="001"
    version="05" />
</messageDefinition>

ISO Building Blocks

The following items are used as building blocks to construct this message.