confirming the focus group position on section …...single touch payroll draft version 2.2...

Single Touch Payroll

Draft Version 2.2 Unclassified

Confirming the Focus Group position on Section 1.4.1 “End-

State Validation Processing Rules” in readiness for the DWG on

the 27th of July

Whilst there are other minor updates remaining in the paper resulting from Micro and Focus groups this particular

section was approved on the 5th of July Focus group. Therefore, the following excerpt from section 1.4.1 End-State

Validation Processing Rules has been provided to progress consideration and approval by the DWG on the 27th of

July. (Note: The paper in its entirety still requires Focus Group validation.)

Design principle: To maximise the number of child forms processed

IF the parent passes channel validation

THEN

IF at least 1 child passes channel validation

THEN

IF the parent passes backend validation

Then

Post parent and all children that passed channel validation

AND

Return Message for any child that failed channel validation

ELSE

Return Message with complete file rejection

ELSE


ELSE


Note: Where the entire file is rejected, then the employer has not met their STP obligations (Noting during the transition to STP the ATO will work with

employers and their DSPs to address the causes of file rejections)



Version Date Author Summary of Changes

0.1 14/06/2017 Hasan Huseyin First draft

0.2 20/06/2017 Maree Ascher (on

behalf of micro

group)

Deletions where no longer required and

wording description updates

0.3 21/06/2017 Hasan Huseyin Additional Context added from minutes

from 15.6.17 Micro Group

0.4 23/06/2017 Hasan Huseyin Updated as per feedback from Deanne

0.5 28/06/2017 Hasan Huseyin Updated as per outcomes from 26.06.17

Micro Group

1.0 3/07/2017 Hasan Huseyin Updated as per feedback from Deanne.

Version 1.0 Endorsed by Michael Karavas

on behalf of STP Micro Group

2.0 14/07/2017 Hasan Huseyin Updated as per feedback from STP Focus

Group and Deanne.

Version 2.0 Awaiting final approval

2.1 21/07/2017 Hasan Huseyin Updated return messaging wording based

on internal feedback.

Replacement of embedded spreadsheets

with live links

Cross referenced to current (July 20th

2017) SBR Pay Event artefact

Minor updates from 19.07.17 Micro Group

discussions

2.2 24/07/2017 Hasan Huseyin Added Temporary Header Page for 27th

July DWG Positioning on End-State

Validation Rules

Minor updates as part of Micro Group

review



STP Return Messaging

Table of Contents

1 Purpose of this Document ........................................................................................................................................ 4

1.1 Review of Current Technical Design Principles ................................................................................................. 4

1.2 Current Return Messaging Logic: ...................................................................................................................... 4

1.3 Outcomes from 26.6.17 Micro Group ............................................................................................................... 5

1.4 Proposed Design Principles ............................................................................................................................... 5

Envisaged End-State Return Messaging Action: ....................................................................................................... 6

1.4.1 End-State Validation Processing Rules: ..................................................................................................... 7

1.4.2 Context on Timing and Transmission of Return Messaging...................................................................... 7

1.4.3 Table 1 – Return Messaging ...................................................................................................................... 8

1.5 Appendix 1 – Prior Micro Groups .................................................................................................................... 11

1.5.1 15.6.17 Discussion Points: ....................................................................................................................... 11

1.5.2 Outcomes from 15.6.17 Micro Group ..................................................................................................... 11

1.5.3 Discussion points: .................................................................................................................................... 11

1.5.4 Assumptions: ........................................................................................................................................... 11

1.5.5 Additions/Removals for Table 1 Return Messaging as per outcomes from 26.06.17 Micro Group: ...... 13



1 Purpose of this Document The purpose of this document is to present the current Payroll Reporting return messaging design with a view to

identify and address any points of concern. Specifically, to ensure the design effectively defines when errors occur,

whether the nature of information is sufficient to achieve the right balance of processing efficiency from both a DSP

and ATO perspective.

1.1 Review of Current Technical Design Principles According to the current technical design (as of June 2017) all scenarios in table 1 below result in a rejection

of the whole file. The second entry - channel validation of the child records - present the most significant

impact whereby potentially one field in one child can result in the complete file being rejected.

Issue first rose on 25.5.17 as part of the TA210 Error Handling Options for STP Payroll Events and subsequent

discussions at the TWG (8.6.17) have noted this is not ideal for SWDs.

Parent Level validation is key – that is, if the parent file passes the necessary checks then, as long as all of the

child record fields are valid, then the complete file will be processed.

o An example that can test the parameters of this position is where the parent file for a full file

replacement has a unique submission id and passes all channel validation. All children also pass

channel validation. Even if all children have complete identical information to the last payroll event,

ATO systems will still process them as valid.

1.2 Current Return Messaging Logic: If the complete file (parent and all children) pass Channel Validation

AND

The parent does not encounter any errors identified below,

THEN

The parent and all children will be processed

ELSE

Return Message with complete file rejected



1.3 Outcomes from 26.6.17 Micro Group

1.4 Proposed Design Principles The field validations defined in the Payroll Event and Update Event Data Definitions are expected to be delivered in STP-enabled payroll solutions but will be similarly

validated by ATO in the channel.

It is anticipated, therefore, that there will be minimal incidents of channel validation failures. DSPs are expected to address any issues of failure to validate to ensure

non-occurrence of rejected files.

If parent data fails the channel validation, the whole file will be rejected.

If parent data passes the channel validation, the child data will be accepted that also passes the channel validation, but each child record that fails the channel

validation will be rejected, unless a critical mass of (to be determined)child record failures is reached. At such a point, the entire file will be rejected.

Where the entire file is rejected, then the employer has not met their STP obligations. (During the transition to STP the ATO will work with employers and their DSPs

to address the causes of file rejections)

If child records are rejected due to channel validation failure, only the child records will be rejected, not the parent record. Steps will have to be performed to ensure

alignment and accuracy of reported data (refer to section “Fix” of the Business Rules1.)

Each field that fails validation will be identified in the return message, to ensure that all aspects of validation failure may be addressed before resending the data.

1. To be updated as a “Business Implementation Guide” which provide additional contextual information as well as include Business Rules and Scenarios)



Envisaged End-State Return Messaging Action:

(Further context is provided in “Section 3 Fix” of the Business Rules)

http://softwaredevelopers.ato.gov.au/Businessrulespayrollreporting



1.4.1 End-State Validation Processing Rules:

Design principle: To maximise the number of child forms processed

IF the parent passes channel validation

THEN

IF at least 1 child passes channel validation

THEN

IF the parent passes backend validation

Then

Post parent and all children that passed channel validation

AND

Return Message for any child that failed channel validation

ELSE


ELSE


ELSE


Note: Where the entire file is rejected, then the employer has not met their STP obligations (see above “Proposed Design Principles”).

1.4.2 Context on Timing and Transmission of Return Messaging

Overall there is an expectation that Payroll, Full File Replacements and Update events transmitted by software

providers will be completely processed with any necessary receipt and return messages provided back within 72hrs.

This should avoid (in the vast majority of cases) the accumulation or overlapping of unconfirmed/partially processed

payroll runs. Details around transmissions times/responses for receipts, sequencing and processing will be

progressed through the appropriate technical forums and is outside the intent of this position paper.



1.4.3 Table 1 – Return Messaging

This table describes the context (eg pay event/update event), scenario (description/example) and message wording for instances where return messages are expected1.

That is, where the appropriate condition outlined in section 1.4.1 above is met. The “User Action” column provides the opportunity for the appropriate direction to be

captured in the STP Business Implementation Guide. For a technical reference of the payroll event return messages refer to “PAYEVNT.0002 (2017)” software developer’s

artefact on SBR under Employer Obligations. (An Update Event technical reference is scheduled to be published in early August 2017).

1. The ”Return Message” column provides the final text to be released and may not be identical to current developer artefacts on SBR

Service PAYEVNT.0002 (2017) Message Repository ID

Error Type Description/example Return Message User Action

Payroll Event Parent

N/A Channel Validation Error

Where fields do not pass validation at the channel (eg ABN does not meet algorithm check)

Specific to invalid field (see software developer’s Employer Obligations artefact

on SBR )

Payroll Event Child

N/A Channel Validation Error

Where fields do not pass validation at the channel (eg TFN does not meet algorithm check)

Specific to invalid field (see software developer’s Employer Obligations artefact

on SBR)

Payroll Event 92172 Duplicate (submission id)

A parent record with the same submission id already exists

We were unable to process your submission because we already have a submission with this submission ID.

If intended to be a full file replacement then ensure the Full File Replacement Indicator has been selected. If duplicate, do not resend.

Payroll Event 92166 Cannot Identify Branch

Where the branch id provided cannot be used to determine the specific branch. Eg: the branch given does not match ATO records.

The file you provided could not be processed because the branch code you provided is incorrect.

Check your branch code and resubmit.

Full File Replacement

41469 Record not found

Cannot identify Submission id to be replaced. Eg: The full file replacement box has been ticked, the ATO do not have a record of the original file and therefore can’t replace it.

We were unable to process your submission because we could not locate the submission that you have requested to be replaced.

If not intended as a full file replacement remove the Full File Replacement

http://www.sbr.gov.au/software-developers/developer-tools/ato/employer-obligations-eo2







Indicator. Otherwise please verify the Submission Id and resubmit


41432 Records already cancelled

The pay event has already been cancelled for the particular parent record.

We were unable to process your submission because the file you wanted to replace has already been replaced.

If not intended as a full file replacement remove the Full File Replacement Indicator. Otherwise please call the ATO


41551 Cannot Identify Account/ BMS ID

Cannot determine which file to replace as IDs do not match. Same ABN , mismatched Branch and BMS ID

We were unable to process your submission because your submission had an incorrect BMS ID. Please check you have used the correct identifier for the submission.

If not intended as a full file replacement remove the Full File Replacement Indicator. Otherwise verify Branch and/or BMSID and resubmit


1. Does Not Exist Change to

Individuals records from original

New Error message required for Full file replacement, where there is a change to the Individuals record from the original. This will cater for large entities, running payroll frequently.

**Does not Exist** Future Rule that ATO systems will need to handle. Action: Cannot perform a full file replacement as one or more child records in the original submission has been included in a later pay/update event. Note: This is an area





of vulnerability for ATO systems as they are currently unable to enforce this rule. DSPs are requested to ensure this validation occurs in their solutions.

Update Event 92169 Over 5 years in past

Where the update relates to records over 5 years in the past, this should be addressed outside of Single Touch Payroll, using current processes.

We were unable to process your submission because the submission you are attempting to update is more than 5 years old and cannot be processed.

Future Rule that will point the user to the necessary instructions on the ATO website. Needs to be available by 2022

Update Event 92166 Cannot Identify Branch

Where the branch id provided cannot be used to determine which branch to post to, ie the identifiers don’t match up.

We were unable to process your submission because the branch code you provided is incorrect.

Check your branch code and resubmit.

Update Event 92168 STP enabled; No STP reports lodged in financial year

The update is referring to a previous year where STP reporting did not occur

We were unable to process your submission because you have not reported using Single Touch Payroll for that financial year.

You cannot lodge for pre-STP. Refer to the ATO website for the pre-STP process

Update Event 92172 Duplicate (submission id)

Identical record already exists We were unable to process your submission because we already have a submission with this submission ID.

If intended to be a full file replacement then ensure the full File Replacement Indicator has been selected. If duplicate, do not resend.



1.5 Appendix 1 – Prior Micro Groups

1.5.1 15.6.17 Discussion Points:

Reaffirm principle of non-contentious/sensitive information being returned as part of messaging; however

there is enough to clarify reason for rejection.

Agreement on logic/principles behind the treatment of each error type

Address question of rejecting the whole file if channel validation fails for any particular child record

Consider intermediaries whose message structure may be composed of many and multiple employers. If one

child in one employer “batch” within the greater message does not pass validation then, is the whole file

with all employers rejected?

1.5.2 Outcomes from 15.6.17 Micro Group

Michael’s whiteboard drawing: Process flow - STP full or partial file rejection due to a technical error and who needs to action it.

1.5.3 Discussion points:

Error message will include record ID + reason + field

Require a limit rule for when a file should be a full or partial rejection (refer action item 1506-02).

Michael K raised potential risk if data is being corrupted intentionally and we let some data through

Deanne W raised that the ATO whitelisting could potentially be a cause of the DSP problems

1.5.4 Assumptions:

Errors will reduce over time – It is assumed that once the data is fixed and error realised, the DSP’s will fix for

the future reducing the errors over time

The employer won’t need to touch technical validation errors, unless they have to fix their data

The future design items below were identified throughout discussions and should be considered for a future release.

Future

design:

1506-01

Detail:

Digitise TFN declaration in

existing process and the

compliance program

Next steps: Require an ATO appropriate

compliance message that an STP

enabled DSP can absorb and

generate into a file

Future

design:

Detail:

Provide an online service to

Next steps: Maree to identify any existing



1506-02

identify if STP enabled by ABN

look-up

ABR improvement projects to

take and further scope the

idea

Future

design:

1506-03

Detail:

Implement true 2 way messaging;

where a child record is

unmatched and it is not a TFN

declaration, the employer is

not notified, the future design

should cater to send a message

back to the employer

Next steps:

Requires a completely

different set of

authentications and

authorisations to send

employee data back out



1.5.5 Additions/Removals for Table 1 Return Messaging as per outcomes from 26.06.17 Micro Group:

The Table was updated as per discussions at the 15.6.17 Micro Group. Notably the removal of the following

messages as these scenarios were determined to not be able to occur:

CMN.ATO.PAYEVNT.EM92170 Payroll Event Message “Cannot Process for a Prior Financial Year”

CMN.ATO.PAYEVNT.EM92171 Full File Replacement “This form cannot be cancelled for a prior financial year”

CMN.ATO.PAYEVNT.EM14160 Full File Replacement - Unique record not found – “More than one form was

identified to be cancelled/replaced”

Also the addition of a Full File Replacement message “Change to Individuals records from original“ Additional context

added to a number of errors for “Description/Example”.

confirming the focus group position on section …...single touch payroll draft version 2.2...

Documents