Document Versioning Is Described in IT Standard 03

ENDORSEMENT/VERSION CONTROL

VERSION CONTROL

Document versioning is described in IT Standard 03

Table of contents

1Introduction

1.1References

1.2Definitions

1.3Stakeholders

1.4Discussion History

1.5Assumptions

2Error Hanlding Options

2.1Option 1 (Bulk)

2.2Option 2 (Batch in a Bulk)

2.3Comparison of Behaviour

2.4Recommendation

1Introduction

The current STP design has been taken up by a number of SWDs for the implementation and it is currently based on the “BULK” processing pattern when the whole message is rejected if at least one validation error is found in the request message.

The current production statistic for failed BDE payment summary lodgements shows about 5% validation error ratio which means a potential increase in the number of transmission because the data for the failed transmissions needs to be fixed and lodged again. Considering that STP is a very high volume initiative those additional “correction” re-lodgements will increase the overall number of transmissions.

In addition the “correction” process requiring Clients or Tax Agents to update errorred Employee records and resubmit Payroll Event will result in reprocessing of it and in the delay for Employee data to become available via ATO Online.

Based on those main reasons two different options for processing patterns have been considered and presented in this document.

1.1References

N/A

1.2Definitions

1.3Stakeholders

Stakeholders in this document are:

1.4Discussion History

1.5Assumptions

The table below lists the assumptions upon which this document is based.

2Error Hanlding Options

2.1Option 1 (Bulk)

Processing is implemented as per the current design – at the high level the approach used by the SBR solution for this option is “all or nothing” so the whole Payroll Event message is treated as one atomic transaction which can be processed only if the whole message is valid including the parent and all children records (see the diagram below).

The validation in the SBR channel supports two level of validation:

• first one (being the xml schema validation) that ensures that the message is valid in the technical senses, (checks the payload is a well formed XML and it is validated against the schema which incorporates majority of the field level validation rules, e.g. cardinality, acceptable formats and values)
• second one (being the custom validation) is performed at the record level that ensures that message is valid in the business sense and supports check of business rules which can’t be expressed in the xml schema (e.g. cross fields/record checks).

All errors encountered during validation process are combined into the validation report which is made available for the BMS. At this point if there are any errors found then the processing of the request message is stopped and no records are sent to the backend for further processing. Only if the validation passed successfully then all data records from the Payroll Event message are passed to the backend.

After BMS pulls out the validation report the BMS user has to check whether any errors were encountered and if so then fix required data in the BMS. As soon as all issues are fixed the Payroll Event information needs to be resubmit to the SBR and for that BMS needs to generate the Payroll Event message and to include the full set of Employee records in it.

The process continues until the Payroll Event message can be successfully validated. Only then the message will be processed by ATO and customer’s obligation to report the certain Payroll Event is considered fulfilled.

The advantage of this option:

• Easy to retransmit the Payroll Event message as all Employee information need to be retrieved from the payroll system without any filtering.
• It is aligned with the current implementation and doesn’t require any changes by ATO and/or SWDs
• The “all or nothing” approach is the supported bulk processing pattern for all eCommerce channels

The disadvantage of this option:

• In case of re-submit all “good” records need to be sent by BMS and re-validated by ATO
• The reprocessing of all Employee data records multiple times caused by the resubmission of fixed records will lead to the additional delay for Employee data to become available via ATO Online

2.2Option 2 (Batchin a Bulk)

This option is suggested to implement more efficient processing of payroll event transactions. At the high level the Payroll Event message is considered as a set of independent Employee records (transactions) which allows validate and process them independently (as a batch hence the name for the option is “batch in a bulk”).

Similar to the first option when BMS user submits the Payroll Event to the SBR channel, all validation errors are reported in the validation report which is made available to the client via BMS. However the main difference in this option is that the errors encountered in some records would have no impact on other records which have been validated successfully so it would result in ability to accept or reject Employee records individually.

When the message is validated in the SBR channel the validation report will be produced and made available to the end user via BMS similar to the option 1. However records which passed validation would be processed in ATO backend.

As for the option 1 the BMS user has to check all returned errors and fix the data in the BMS. But in this scenario the BMS needs to generate new Payroll Event message with only a subset of Employee records (only those ones which required fixes and have been modified by the user). In addition to this the BMS needs to include Employer details as they were in the initial Payroll Event lodgement to allow ATO to update the data accordingly.

In this case the BMS doesn’t re-send all Employee records to the SBR channel but instead sends only Employee records which failed validation in the initial Payroll Event lodgement.

The advantages of this option:

• Valid Employee data records received and processed on the first submission so clients can see their details without delay or waiting for the re-submission
• Reduced duplicate validation of valid Employee details records
• Employee data can become available via ATO Online quicker because the reprocessing of the same Employee records multiple times doesn’t occur for resubmission of fixed records

The disadvantages of this option:

• Additional logic is required in the BMS to be able recreate a previous Payroll Run details in a Payroll Event message.
• BMS needs to filter out only corrected Employee records to include them into “corrected” message
• Requires additional reconciliation process to ensure that all Employee records are received for every Payroll Event
• Requires changes in the design and implementation of payroll event services by SWDs and ATO which means additional expenses and time delay

2.3Comparison of Behaviour

The table below presents the comparison of behaviour for both options.

2.4Recommendation

Considering the tight timeframe and significant additional efforts required to change the current design and implementation the option 1 (stay with the current BULK processing pattern) is recommended.