PLS micro-group meeting summary

/ UNclassifiedExternal
File ref:28072017
Title: / ATO error messaging and business processes during a major incident – meeting #1
Issue date: / 1 August 2017 /
Venue: / Teleconference /
Event date: / 28 July 2017 / Start:1:00pm / Finish:2:00pm
Chair: / Joe Maxymenko / Facilitator: / Sharna Maltman /
Contact / Sharna Maltman / Contact phone: / (07) 3149 5913 /
Attendees:
names/section / Jack Wee (Catsoft), Mike Behling (MYOB), Michael Wright (Sage), Joe Maxymenko (ATO), Craig Woodburn (ATO), Mick Ferris (ATO), Gary Warne (ATO), Nicole Moutia (ATO), Anne Soe (ATO), Andrew Mohr (ATO), Sharna Maltman (ATO).
Apologies:
name/section / Andrew Watson (ATO).
Next meeting / TBC /
Agenda item: 1 – Changing the error message when a software product sends a transmission for a service it is not whitelisted for
The purpose of the meeting outlined as scoping the work to be addressed which will then be refined by the ATO and a follow-up meeting scheduled. The ATO’s commitment to investigating how the issue can be addressed in the short and longer term was noted and the ATO informed DSPs that a few friendly Tax Agents will be engaged to understand what will work for them as well.
Error messaging:
  • Sage (Michael Wright):
  • There are different scenarios based on the two types of mechanisms being used i.e. cloud and desktop.
  • As a predominately a desktop solution Sage has no control over when and where Agents are lodging.
  • Cloud providers are able to stockpile lodgments (i.e. hold them back from being transmitted) for the IITR17 during the issues on Monday however, desktop solutions don’t have a mechanism to do this.
  • Conversations on Monday moved from bringing down the whole IITR17 to bringing down the whitelisting for Sage and Handy Tax’s product IDs but the issue here is the error code that would need to be used to reject clients i.e. software not registered which is an incorrect solution for Sage’s product.
  • The ideal short-term fix is to adjust the wording in the error codes to better reflect the situation which would have a quick impact (noting, would still be further improvements required to the ATO’s business processes during issues etc.).
  • If we can change the working of the error codes in relation to this issue perhaps we can also better improve the wording of the ‘auth 007’ error.
  • A review of the ATO’s business processes during issues requires a deep-dive longer-term solution that also needs to happen – in parallel with the quick fix.
  • MYOB (Mike Behling):
  • MYOB also impacted when the ATO doesn’t close services as we have a few hundred desktop solutions.
  • There is merit in re-wording the error messages but there are some concerns for particular scenarios. For example, there could be services that someone is not registered for but are attempting to use – how would a user realise they are trying to use something if we change the wording to this level?
  • Anne Soe highlighted that the ATO cannot currently differentiate whether DSPs are registered / whitelisted (due to the way the whitelist works). It was also noted that to fix this, an extra layer of checking would be required.
  • During planned outages the ATO shuts down connections – can this type of approach be used for isolating a service and preventing access to what could potentially be a harmful service (whether it was a cloud or desktop solution)?
  • Mick Ferris advised that this type of service is in the backlog but there are other issues to be considered with this solution e.g. there are currently no other message to come through if the ATO Gateway is taken down which led to the whitelisting conversations discussed with Sage on Monday.
  • In short term, we need an action that puts up an appropriate message as the ‘software not registered’ message is not good.
  • The ATO is looking at a deferred lodgment capability which will help with the second part of the issue but we need to look the way we are dealing with any sets of those messages.

Action item:
1 / Due date:
Wednesday 2 August 2017 / Responsibility:
Mick Ferris
Describe scenarios and look at how we handle the information better.
  • Simplest solution is to change the descriptionbut this won’t cover all scenarios i.e. the ATO can look at more appropriate wording in the message but this is a Band-Aid for a bigger issue that needs to be worked through. De-whitelisting is a drastic step and it would be preferable to treat the problem and not the symptom.
  • Andrew Mohr noted that on Monday the issue was only with the IITR17 so de-whitelisting everybody would not have been an ideal outcome.
  • Sageprefers not to be de-whitelisted to solve the issue. Instead of bringing down the whole service it would be better if the ATO targeted Sage and its service / product ID only (although again, not ideal).
  • Given the likelihood of the incident occurring again, Sage highlighted the need for a quick fix now (i.e. changing the wording of the messages that aren’t right) and also looking at a longer-term plan for handling the process into the future.
  • As the messages are generic and the whitelisting process is across the board, it will affect different companies in different ways.
  • The ATO highlights a commitment to deferred lodgments June service message i.e. PLS will be like the ELS channel with lodgments stored on eCommerce layer which solves part of the problem.
  • Catsoft (Jack Wee):
  • Agree with above and added that after the outage that saw de-whitelisting across the board, some pre-lodge services were not re-whitelisted for Catsoft (lodge and submit were working but validate was not).
  • Our clients use BURP a lot and have option to push the message through and download the response at a later point so we didn’t experience the same time-out issues.
  • Agree with changing the wording of the message but our concern would be the extent to which the de-whitelisting of other DSPs was done and if it has to be done, need to change the wording to soften it and to be something that explains the ATO is experiencing technical issues etc.

Summary:

  • It was agreed that the best way forward is to update the message wording in the short term while also, in parallel,starting to look at addressing the longer term process measures.

Agenda item: 2 – ATO business processes during an incident
  • ATO needs to consider the thresholds for shutting down the channel e.g. if 80-90% of all people are impacted it be better to shut it down and some decision processes need to be explored with relation to this – Mondays issue is an example of a time when the channel should have been shut down (MYOB).
  • Catsoft does not agree with the above view point and instead, believe de-whitelisting should be the absolute last resort (note, this information was provided by Catsoft out of session as part of the minutes review process).
  • The ATO also needs to understand (and be clear about) the choices for shutting the channel down or de-whitelisting and importantly, once a decision has been made for the process the ATO needs to act fast with communications – our clients need to get the messaging as soon as possible. We would also be linking back to it (MYOB).
  • Mick Ferris confirmed that last week the payloads were going through however, it was the response times that were not coming back and causing the issue as there was a problem with the queue and transactions were timing out i.e. responses to lodgments were stuck.
  • Additionally, Mick Ferris confirmed that more accurate messaging coming back is being looked at and that PIR will bring out how we enforce this side of the issue.
  • Craig Woodburn questioned whether the ATO can turn an IP address off entirely?
  • The group agreed that correcting the text is only one part of the issue – need to be clear about how and when it is used. Need to consider what factors are involved for the ATO when making decisions to de-whitelist and what consultation would be needed with DSPs.
  • If the ATO de-whitelisted us, our cloud clients would get a rejected message and would then have to re-complete the form, the setup and lodgment and they wouldn’t know when the system was back up and running again which means this could need to be done a number of times so there is a lot of work in this scenario (MYOB).
  • We are in a similar but different situation – if the ATO has de-whitelisted, our clients can try again later and there is not as much overhear as they can re-tag and transmit later when they are ready (Sage).
  • Best practise going forward would be to directly contact to each DSP and also make a secondary contact (Sage).
  • DSPs agreed they needed better communications on the exact nature issues.
  • DSPs were informedthat if they wanted to be de-whitelisted they should let their Account Manager know – this will then trigger a 3-way conversation with the DSP, Account Managers and someone from Craig Woodburn’s area.
  • DSPs highlighted that they hear about incidents straight away via their service support area but the main issue is when their support area is offline (i.e. on weekends or overnight) and that during this time, the ATO should be calling DSPs directly with information on the issue.
  • We have a similar situation to Sage in that our clients have a choice and can (because of re-tagging) try to lodge again at a later time (Catsoft).

Action item:
2 / Due date:
Friday 11 August 2017 / Responsibility:
Joe Maxymenko, Sharna Maltman
Given the number of different DSP experiences already identified, the ATO will explore impacts on others in one-on-one conversations and test what we are proposing with others before proceeding.
Action item:
3 / Due date:
Friday 11 August 2017 / Responsibility:
Craig Woodburn
Craig to clarify if during a production deployment the ATO de-whitelists all involved and then re-installs them or not.

UNclassified External1