format / Audience / Date / Classification
/ File Ref: / [G049]
valid formatand error scenarios for record count
Purpose
This document provides guidance on the use of the RecordCount part property in the following SuperStream messages:
a)Initiate Rollover Request (IRR)
b)Rollover Transaction Request (RTR)
c)Electronic Portability Form (EPF)
d)Unclaimed Superannuation Money Rollover Transaction Request (USMRTR)
e)Section 20C Notice (IRRS20C)
f)Member Registration Request (MRR)
g)Contribution Transaction Request (CTR)
h)Government Contribution Transaction Request (GCTR) and
i)Government Contribution Transaction Amendment Request (GCTAR).
Background
The RecordCount part property is defined in the documents Data and Payment Standards Rollover Message Implementation Guide (MIG) v2.0 and Data and Payment Standards Contributions Message ImplementationGuide(MIG) v2.0.
1)Record Count is defined as mandatory for all the transactions listed above except MRR and CTR for which it remains as optional until the next Contributions B2B version upgrade.
issue
There are no concise rules defined for data validation for this part property. There have been examples in production of RecordCount containing additional punctuation such as “,” and these have caused exceptions in receiving solution processing of the messages.
A specification of validation and formattingrules for RecordCount is given below.
Additional guidance is also included here for other error scenarios that may occur in processing of the RecordCount part property
RECOMMENDED GUIDANCE
Valid format
The intended definition of the RecordCount part property is positive integer without punctuation.To enforce this definition, validation and formatting such as defined below must be applied to the values supplied for RecordCount before a message is sent.
The Canonical representation of xsd:positiveIntegercan be used to describe what format the RecordCount part property should follow (i.e. positive integer containing only digits with no leading + sign, leading zeroes or decimal point).
The RecordCount could also be validated against the regular expression: [1-9][0-9]* to achieve the same result.
2)Sending solutions MUST ensure that RecordCount is present for those transactions where it is defined as mandatory and must also ensure, if present, that it is in a valid format before sending the message.
Error scenarios
The expectation and experience from current messaging processes is that RecordCount will always be present where it is defined as mandatory and, if present, it will be in a valid format.
There is still, of course, the remote possibility that someunexpected system or operational issue might cause a message with a missing, invalidly formatted or mismatched RecordCount to be sent into the network.
The expected behaviour for particular error scenarios with RecordCount is specified below.
- Missing RecordCount mandatory part property
This errorwould be detected bygateways processing a message in most cases though some gateways may simply pass on a message directly to a fund solution.
3)The message must be rejected with error code SUPER.GEN.GEN.23 Mandatory PartProperty {property} not supplied.
4)If this scenario is detected by a receiving gateway, the receiving fund must also be notified of the error in the message composition to assist in payment reconciliation. The receiving gateway should use its standard means of communication with the fund to inform of the error.
- RecordCount invalidformat
This error would be detected by gateways processing a message in most cases though some gateways may simply pass on a message directly to a fund solution.
5)The message must be rejected with error code SUPER.GEN.GEN.24PartProperty {property} is invalidly formatted.
6)If this scenario is detected by a receiving gateway, the receiving fund must also be notified of the error in the message composition to assist in payment reconciliation. The receiving gateway should use its standard means of communication with the fund to inform of the error.
- RecordCount does not match number of records
This scenario will not become apparent until the XBRL payload is processed either by the fund’s XBRL solution provider or the fund itself.
A correct match of the RecordCount property and records received is not essential for processing of the message and must not prevent allocation of rollovers or contributions to member accounts.
7)Receiving solutions MUST NOT reject a message simply because the RecordCount part property does not match the number of records actually included in the business document.
8)An out of band process must be used to notify the message sender of a mismatched RecordCount property.
9)If this scenario is detected by a gateway, the receiving fund must be notified of the error in the message composition.
An out of bandprocess must be used because a warning message at the ebMS level cannot be sent in many processing scenarios so this method cannot be relied upon to communicate the RecordCount mismatch back to the sender.
10)The receiving party MUST attempt to process and allocate rollovers or contributions to the member’s account for all the transactions included in the business document.
11)If there are errors encountered in processing these should be dealt with in the normal way by sending an error message and refund.
Release notesGuidance note / G049– RecordCount validation
Message pattern / Rollover and Contribution transactions:
IRR, RTR, EPF, USMRTR, IRRS20C, MRR,CTR, GCTR and GCTAR.
Relevant Schedules / Rollover Message Implementation Guide v2.0
Contributions Message Implementation Guide v2.0
Due date / 31 August 2017
Sending solutions / The recommendations in this guidance note should be implemented by sending solutions as soon as practicable but no later than the due date.
Receiving solutions / The recommendations in this guidance note should be implemented by receiving solutions as soon as practicable but no later than the due date.
Future action / This guidance will be included in future versions of the Rollovers and Contributions MIGs and User Guides where appropriate.
1