camt.038.001.04
Scope The CaseStatusReportRequest message is sent by a case creator or case assigner to a case assignee. This message is used to request the status of a case. Usage The CaseStatusReportRequest message must be answered with a CaseStatusReport message. It can be used to request the status of a:
- request to cancel payment case;
- request to modify payment case;
- unable to apply case;
- claim non receipt case. The CaseStatusReportRequest message covers one and only one case at a time. If a case creator or case assigner needs the status of several cases, then multiple CaseStatusReportRequest messages must be sent. The CaseStatusReportRequest message may be forwarded to subsequent case assignee(s) in the case processing chain. The processing of a case generates NotificationOfCaseAssignment and/or ResolutionOfInvestigation messages to the case creator/case assigner. They alone should provide collaborating parties sufficient information about the progress of the investigation. The CaseStatusReportRequest must therefore only be used when no information has been received from the case assignee within the expected time frame. An agent may suspend an investigation by classifying it as overdue if, this agent, after sending the request for the status of the investigation, does not receive any response after a long time. Agents may set their individual threshold wait-time.
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
%% CaseStatusReportRequestV04 recursion level 0 with max 0
CaseStatusReportRequestV04 *-- "1..1" ReportHeader5 : RequestHeader
CaseStatusReportRequestV04 *-- "1..1" Case5 : Case
CaseStatusReportRequestV04 *-- "0..1" SupplementaryData1 : SupplementaryData
Now, we will zero-in one-by-one on each of these building blocks.
RequestHeader building block
Identifies the party requesting the status, the requested party, the identification and the date of the status. Specifies generic information about an investigation report. For comparison, see the ISO20022 official specification
classDiagram
direction tb
%% ReportHeader5 recursion level 0 with max 1
class ReportHeader5{
Identification IsoMax35Text
CreationDateTime IsoISODateTime
}
ReportHeader5 *-- "1..1" IParty40Choice : From
ReportHeader5 *-- "1..1" IParty40Choice : To
%% IParty40Choice recursion level 1 with max 1
%% IParty40Choice recursion level 1 with max 1
ReportHeader5 members
| Member name | Description | Data Type / Multiplicity |
|---|---|---|
| Identification | Point to point reference as assigned by the case assigner to unambiguously identify the case status report. | IsoMax35Text - Required 1..1 |
| From | Party reporting the status of the investigation case. | IParty40Choice - Required 1..1 |
| To | Party to which the status of the case is reported. | IParty40Choice - Required 1..1 |
| CreationDateTime | Date and time at which the message was created. | IsoISODateTime - Required 1..1 |
Case building block
Identifies the investigation case. Provides further details to identify an investigation case. For comparison, see the ISO20022 official specification
classDiagram
direction tb
%% Case5 recursion level 0 with max 1
class Case5{
Identification IsoMax35Text
ReopenCaseIndication IsoYesNoIndicator
}
Case5 *-- "1..1" IParty40Choice : Creator
%% IParty40Choice recursion level 1 with max 1
Case5 members
| Member name | Description | Data Type / Multiplicity |
|---|---|---|
| Identification | Uniquely identifies the case. | IsoMax35Text - Required 1..1 |
| Creator | Party that created the investigation case. | IParty40Choice - Required 1..1 |
| ReopenCaseIndication | Indicates whether or not the case was previously closed and is now re-opened. | IsoYesNoIndicator - Optional 0..1 |
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
| Member name | Description | Data Type / Multiplicity |
|---|---|---|
| PlaceAndName | Unambiguous reference to the location where the supplementary data must be inserted in the message instance. In the case of XML, this is expressed by a valid XPath. | IsoMax350Text - Optional 0..1 |
| Envelope | Technical element wrapping the supplementary data. | IsoSupplementaryDataEnvelope1 - Required 1..1 |
Extensibility and generalization considerations
To facilitate generalized design patterns in the system, the CaseStatusReportRequestV04 implementation follows a specific implementaiton pattern. First of all, CaseStatusReportRequestV04 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, CaseStatusReportRequestV04Document implements IOuterDocument. Because CaseStatusReportRequestV04 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type CaseStatusReportRequestV04.
classDiagram
class IOuterRecord
CaseStatusReportRequestV04 --|> IOuterRecord : Implements
CaseStatusReportRequestV04Document --|> IOuterDocument~CaseStatusReportRequestV04~ : Implements
class IOuterDocument~CaseStatusReportRequestV04~ {
CaseStatusReportRequestV04 Message
}
Document wrapper for serialization
The only real purpose CaseStatusReportRequestV04Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:camt.038.001.04’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using CaseStatusReportRequestV04.ToDocument() method. The returned CaseStatusReportRequestV04Document value will serialize correctly according to ISO 20022 standards.
classDiagram
CaseStatusReportRequestV04Document *-- CaseStatusReportRequestV04 : 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.038.001.04">
<CaseStsRptReq>
<ReqHdr>
<!-- RequestHeader inner content -->
</ReqHdr>
<Case>
<!-- Case inner content -->
</Case>
<SplmtryData>
<!-- SupplementaryData inner content -->
</SplmtryData>
</CaseStsRptReq>
</Document>
Data from ISO specification
This is the technical data from the specification document.
<messageDefinition
xmi:id="_eYI_NW2PEei3KuUgpx7Xcw"
previousVersion="_sVWbg1kyEeGeoaLUQk__nA_150838018"
name="CaseStatusReportRequestV04"
definition="Scope
The CaseStatusReportRequest message is sent by a case creator or case assigner to a case assignee.
This message is used to request the status of a case.
Usage
The CaseStatusReportRequest message must be answered with a CaseStatusReport message. It can be used to request the status of a:
- request to cancel payment case;
- request to modify payment case;
- unable to apply case;
- claim non receipt case.
The CaseStatusReportRequest message covers one and only one case at a time. If a case creator or case assigner needs the status of several cases, then multiple CaseStatusReportRequest messages must be sent.
The CaseStatusReportRequest message may be forwarded to subsequent case assignee(s) in the case processing chain.
The processing of a case generates NotificationOfCaseAssignment and/or ResolutionOfInvestigation messages to the case creator/case assigner. They alone should provide collaborating parties sufficient information about the progress of the investigation. The CaseStatusReportRequest must therefore only be used when no information has been received from the case assignee within the expected time frame.
An agent may suspend an investigation by classifying it as overdue if, this agent, after sending the request for the status of the investigation, does not receive any response after a long time. Agents may set their individual threshold wait-time."
registrationStatus="Registered"
messageSet="_moz48_2VEeGjgKzdN0DbWA"
xmlTag="CaseStsRptReq"
rootElement="Document"
xmlns:xmi="http://www.omg.org/XMI">
<messageBuildingBlock
xmi:id="_eYI_N22PEei3KuUgpx7Xcw"
previousVersion="_sVWbhFkyEeGeoaLUQk__nA_1398220389"
name="RequestHeader"
definition="Identifies the party requesting the status, the requested party, the identification and the date of the status."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="ReqHdr"
complexType="_Dr8EK249EeiU9cctagi5ow" />
<messageBuildingBlock
xmi:id="_eYI_OW2PEei3KuUgpx7Xcw"
previousVersion="_sVgMgFkyEeGeoaLUQk__nA_514987102"
name="Case"
definition="Identifies the investigation case."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="Case"
complexType="_8BF4W248EeiU9cctagi5ow" />
<messageBuildingBlock
xmi:id="_eYI_O22PEei3KuUgpx7Xcw"
previousVersion="_sVgMgVkyEeGeoaLUQk__nA_-1985293714"
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="038"
flavour="001"
version="04" />
</messageDefinition>
ISO Building Blocks
The following items are used as building blocks to construct this message.