format / Audience / Date / Classification
Applying maximum severity to response messages –G012
Issue
The current rollover induction process has identified that there is an ambiguity relating to the application of the MaximumSeverity code as described in the Schedule 6 document: Error Code Management. This ambiguity stems from the interaction of Section 3.1, (which states that MaximumSeverity must be set to the most severe level of error present in the associated EventItems), with Section 3.5 (which provides greater detail regarding the application of certain MaximumSeverity codes).
One example discovered is in the application of code SUPER.GEN.RLVR.5. This code has a severity of ‘Information’, and a short description of ‘Rollover process unsuccessful’. If communicated unaccompanied by a higher severity code this would imply a MaximumSeverity code of ‘Information’, per Section 3.1. This is ambiguous when contrasted with Section 3.5, which states that MaximumSeverity ‘Information’ shall be interpreted to mean that processing was successful for all components included in the associated request message.
Thisambiguity has led to different implementations by participants in Cohort1 which is impacting on interoperability.
Recommended solution
The following guidance is presented to help Cohort participants resolve the identified ambiguity.
Note: this guidance is presented as a recommendation only.
The SuperStream Technical Architecture Sub-group will monitor the use of MaximumSeverity inthe data standard. As patterns of use become clearer additionalspecification will beconsidered for inclusion in a future version of theSuperannuation Data and Payment StandardLegislative Instrument Schedule documents.
Guidance
If there is any confusion about how to resolve ambiguities between Sections 3.1 and 3.5 in applying MaximumSeverity, Section 3.1 should take precedence.
However, whilst Section 3.1 does indicate the allowable values for MaximumSeverity, it does not clearly articulate the hierarchy for selecting the ‘most severe’ code. Accordingly, the following table outlines the intent behind this section.
1. / Progressive / Used whenever a progressive approach is taken, irrespective of individual EventItem severity.2. / Error / Used for a non-progressive approach where all EventItems have the severity code ‘Error’.
3. / Partial / Used for a non-progressive approach where at least one EventItem has the severity code ‘Error’, and processing for at least one other member was successful.
4. / Warning / Used for a non-progressive approach where no EventItems have the severity code ‘Error’, but at least one EventItem has the severity code ‘Warning’.
5. / Information / Used for a non-progressive approach where all EventItems have the severity code ‘Information’.
Funds should take care to examine and consider all EventItems to ensure that appropriate treatment is applied.
To assist Funds to convey the correct business meaning in resolving the ambiguity experienced when interpreting Section 3.5, an alternative treatment of a small number of error codes is recommended.
The following error codes should be treated as having severity ‘error’ in all cases. This includes for population of the MaximumSeverity code.
- SUPER.GEN.RLVR.5
- SUPER.GEN.RLVR.6
- SUPER.GEN.RLVR.7
- SUPER.GEN.RLVR.9
For example, if a response message is sent in which there is only one EventItem and that has a value of ‘SUPER.GEN.RLVR.5’ for the Error.Code element, then the MaximumSeverity would be set to ‘Error’.
Additionally, the following code must not be used as it implies an interim update and not a final state:
- SUPER.GEN.RLVR.8 (‘Member not registered with Receiving Superannuation entity. Rollover contributions have been placed into a holding account while member is identified and registered.’)