7.IRS237 Advise Sanction.pdf

IN-CONFIDENCE

IRS237 Advise Sanction

As a system I want to inform SWIFTT of an Obligation Failure for  Status
Final
a client so that benefit sanction can be applied and record the
response from SWIFTT.
Date
03/11/15
Customisation:  N/A
Version
1.4
Impacted Systems: OBMAN, SWIFTT
Author
Out of scope

OBMAN will advise SWIFTT of benefit sanctions.

SWIFTT wil  receive sanction information from OBMAN, process
the sanctions, advise OBMAN of the sanctions that were
successful and those that were unsuccessful.
(Note: SC846 wil  be used by OBMAN and SWIFTT to send and
receive information.)
1  Overview
Currently OBMAN informs SOLO of obligation failures. SOLO associates all failures sent on the same
day for a single client to a single “Failure”. If there is no change to the status of the Failure 5 working
days after it was created, then SWIFTT is notified to apply a sanction to the client’s benefit (which may
be a 50% reduction or a complete suspension or a cancellation). SWIFTT sends a response to SOLO
advising which of the requested sanctions were successful and the ones those were not.
It is envisaged that once SOLO is retired, OBMAN wil  advise SWIFTT to apply benefit sanctions for
clients who failed to meet their obligations. SWIFTT wil  send a response to OBMAN advising which of
the requested sanctions were successful and the ones that were not.
2  Traceability
Dependency - IRS236 Generate Obligation Fail Letter Request
Dependency - IRS262 Configure Obligation Notice Period
Dependency - IRS239 Lift Sanction
Dependency – IRS202 – Resolve Exceptions
3  Acceptance Criteria
3.1  Request SWIFTT for sanction of benefit
The system should request SWIFTT to sanction a client if the client has an obligation failure (X+1)
working days after the creation date of the failure.
Note: X is parameter driven. A privileged user (e.g. System Administrator) should be able to change
the value of the parameter. Refer to IRS262 Configure Obligation Notice Period for details.
Page 1 of 27

IN-CONFIDENCE

•  OFJR - Job Refusal obligation failure (Re-compliance Activity Outcome – RAO – not
started)

4.1.1.2 BR Determine Traffic Light Status
System determines the Traffic Light Status for a client as:
•  GREEN: No active obligation failure or recomplied obligation failure
•  ORANGE: Failed obligation, no sanction applied yet (within dispute period).
•  RED: Obligation failure, sanction applied.

4.1.1.3 BR Start Timer
System starts the timer for al  clients except YP/YPP clients as:
a.   Start date = Date when Failure Letter is generated
b.  End date = X +1 working days from Start date
For YP/YPP clients the system shall start timer as:
a.  Start date = Failure creation date
b.  End date = X+1 working days from Start date

Note: X is parameter driven. A privileged user (e.g. System Administrator) should be able to
change the value of the parameter. Please refer to IRS262 Configure Obligation Notice
Period for details.
Please refer IRS236 Generate Obligation Fail Letter Request for “Date when Failure Letter is
generated”. Example:
Assuming x is 7 working days, so x + 1 = 8,
If Failure is created on Monday 17/08/15 then sanction date should be Thursday 27/08/15.
If Failure is created on Friday 21/08/15 then then the sanction date should be Wednesday
02/09/15.
4.1.1.4 BR Stop timer
If system determines the status of the Failure for the client is changed to any of the following
values before (X+1) working days elapse then system wil  stop the timer immediately and will not
inform SWIFTT:
•  Deactivated
•  Failed in error
•  Superseded
•  Re-complied
•  Overturned
•  Benefit cancelled
Page 3 of 27

IN-CONFIDENCE

4.1.1.5 BR Advise SWIFTT to apply sanction
1.  If system determines the timer stops after (X+1) working days elapse from the start date of

the failure event then system wil  inform SWIFTT that client’s benefit should be sanctioned
for not meeting obligations.
2.  The system will pass on the following details to SWIFTT while advising to apply benefit
sanction:
a)  Client Number
b)  Effective date - The date when sanction should be applied
c)  Reason why sanction is being applied which is one of the fol owing:
•  OF1- Grade 1 obligation failure
•  OF2- Grade 2 obligation failure
•  OF3- Grade 3 obligation failure
•  OFJR - Job Refusal obligation failure
3.  The system should send an immediate notification to SWIFTT to apply sanction for clients
who fail the 6 weeks Re-compliance Activity i.e. Failure for the client is changed to Resulted
(RAO – Failed). The details passed on are:
a)  Client Number
b)  Effective date - The date when sanction (benefit cancellation in this case) should be
applied
c)  FAILRAO - Failed 6 weeks Re-compliance Activity Outcome (RAO)
4.  The system wil  receive an acknowledgment from SWIFTT that it has received the request.
Please refer to the Business Rules for Apply and Lift Sanction table in the Appendix (section 9.2) for a
tabulated view of the rules.
4.1.1.6 BR Definition of “working day”
Working day means a day of the week other than-
a.  a Saturday, a Sunday, Waitangi Day, Good Friday, Easter Monday, Anzac Day, the Sovereign's
birthday, and Labour Day; and
b.  if Waitangi Day or Anzac Day falls on a Saturday or a Sunday, the following Monday; and
c.  a day in the period commencing on 25 December in any year and ending with 15 January in
the following year.
4.1.1.7 BR Update Event History
The system should log al  transactions between OBMAN and SWIFTT for a client with details of
“Action” and “Description” in the Event History as normal process.
Note: Event History is current (existing) system feature.
1.  Where benefit has been successful y sanctioned, the system should update the Event History
with:
a.  Sanction details (i.e. if benefit was reduced by 50% or suspended or cancel ed)
Page 4 of 27

IN-CONFIDENCE

b.  Manual action (if any) required (e.g. backdated review)
2.  Where benefit could not be successful y sanctioned, the system should update the Failure

screen as follows:
a.  Error message (yet to be mapped noted as Exception 3)
Please refer to section 5 of this doc for indicative to-be views of the screen shots.
4.1.1.8 BR Update Failure screen
The system should update the Failure screen with the Sanction Applied date (this is the
OBMAN generated date when OBMAN requests SWIFTT to sanction client’s benefit)
Please refer to section 5 of this doc for indicative to-be views of the screen shots.
4.1.1.9 BR Sanction Effective Date for RAO
1.  The “Effective Date” for the sanction notification to SWIFTT when a client fails a 6 weeks Re-
compliance Activity is whichever of the fol owing dates occur last:
a.  The date that the client started the 6 weeks Re-compliance Activity, or
b.  (X+1) working days from the Failure Creation Date.
Examples:
a.  If a client starts and fails RAO before the end of (X+1) working days from the Failure
Creation Date, a sanction message shall be sent at the end of (X+1) working days from
the Failure Creation Date to SWIFTT to apply a sanction.
b.  If a client starts RAO before the end of the (X+1) working days from the Failure Creation
Date, then fails RAO after the end of the (X+1) working days from the Failure Creation
Date, a sanction message shall be immediately sent to SWIFTT to apply a sanction with
an effective date of the end of the (X+1) working days from the Failure Creation Date.
c.  If the end of the (X+1) working days from the Failure Creation Date passes without the
client starting RAO, a sanction message shall be sent on the date of the end of the (X+1)
working days from the Failure Creation Date to SWIFTT to apply a sanction.
a.  If the client starts RAO after the end of the (X+1) working days from the Failure
Creation Date, the benefit of the client will be reinstated.
d.  If the client starts RAO after the end of the (X+1) working days from the Failure Creation
Date then subsequently fails RAO within 13 weeks from the Failure Creation Date, a
sanction message shal  be immediately sent to SWIFTT to apply a sanction with an
effective date of the date that the client started the 6 weeks Re-compliance Activity.

Page 5 of 27

IN-CONFIDENCE

5  Presentation / Screens

5.1  Indicative to-be view for OBMAN Failure Screen Shot:

“Sanction Applied” field should display the OBMAN generated date when applying of sanction was
requested.
5.2  Indicative to-be view for OBMAN Event History Screen Shot:
Page 10 of 27

IN-CONFIDENCE

•  Where benefit has been successful y sanctioned, the screen should display the following:
a.  under “Event”:
•  Sanction details (i.e. if benefit was reduced by 50% or suspended or cancel ed)
•  Manual action (if any) required (e.g. backdated review)
b.  under “Date/Time”:
• Date/Time of SWIFTT response to OBMAN
c.  under “Created by”:
• System
•  Where benefit could not be successful y sanctioned, the screen should display the following:
a.  under “Event”:
•  Error message (returned by SWIFTT) (Please see Exception 3)
b.  under “Date/Time”:
• Date/Time of SWIFTT response to OBMAN
c.  under “Created by”:
• System

Page 11 of 27

IN-CONFIDENCE

This has happened in the case of other SWIFTT services, where
new (undocumented) error codes were returned.
To avoid this, either 1) OBMAN uses the exact error values (codes

& messages) returned by the SWIFTT service, which means that
the 2 systems are decoupled or 2) if mapping is preferred, then
an additional “catch all” mapping should exist in OBMAN.
Update (16/04): OBMAN database will store the exact error
codes and error messages as responded by SWIFTT.
Update: (08/05) – Noted as Exception 3.
3
TBC with Out of scope  the exact mechanism used and the role
Out of
Closed
SOLO database plays (if at all) for the report generation.
scope
Update:
As per the current business process the “Tranzit Exception
report” is generated by a standalone SOLO Database report
script scheduled via Control^M and is managed by the DBA team
(as confirmed byOut of scope , an Oracle DBA).
It has been confirmed by Out of scope
and his team that the
“Tranzit Exception report” is not generated by IAP.
4
TBC with Out of scope  - The current mechanism used to email the  Out of
Closed
generated “Tranzit Exception report” to the following shared
scope
email ids:
Data [email address]
MSD [email address]
If this is done through a Control^M job then it has to be ensured
that in future the same continues.
Update:  The current mechanism used to email the generated
“Tranzit Exception report” is through a Control^M job.
5
Event History would need to be updated if SWIFTT does not

Out of
Closed
return a date in case of an unsuccessful sanction.
has
scope
Out of
emailed the outstanding question to the business, wait
scope ing for
their response.
Update: Response received from Out of  is as follows-
scope
In the To-be world is the requirement to display both
(OBMAN requested and SWIFTT applied) dates for
Sanction applied?
a.  If yes, what should the labels read for each date?
•  Obligation Failure Date:          A
•  Sanction Applied:                    B
•  SWIFTT Effective Date:         C
•  C should display as ‘Not Applicable’ until a date is
returned. When c does not equal B, this should
display in the exception screen to be looked at
and resolved.

Page 13 of 27

IN-CONFIDENCE

748
SOLO-003 Apply similar functionality added for Warrants to Arrest (WTA), i.e.
to automatically apply the 50% sanction where there are too many payees and
debt offsets for the client.  When the payment extract runs the payee

redirections are ignored.
Note: This is currently reported in TRANZIT SOLO Exceptions report as error
code #47 and actioned manual y. Non-Functional Requirements.
HP order of magnitude $50k - $100k 6 - 10 weeks effort.
770
The Tranzit Exception report contains Work Test Failure (WTF) errors ( Error
Code #47) and other exception/error information some of which is related to
ISLINK errors. Currently the Tranzit Exception report is generated by a sequel
script that collects relevant data from the SOLO database. The generation of
the report and its delivery to [email address] and
[email address] is scheduled through a control M job. The process is
managed by Oracle DBAs.
It has been confirmed that IAP does not generate the report.
The report wil  cease to exist once SOLO is decommissioned.
A decision is required on the solution for presenting exceptions/errors (e.g.
WTF#47) to the business through a report once SOLO is gone.
771
Currently there are 5 ISLINK reports generated by SWIFTT. The reports are
available on Reports Online and are used by Data Integrity Unit. SWIFTT will
not generate these reports once the ISLINK is decommissioned. Fol owing is
the list of current ISLINK reports and an indication if going forward the
business needs the information reported on daily for doing their job:
1. NZES Enrolment Details Received – Not Required
2. NZES Error Messages Received - Not Required
3. Re-compliance/Clean Slate/ Appeal Received – Is Required
4. PA01 Sanction Received – Is Required – This will have two error message –
• Back dated review required
• Sanction Received Client has 50% payment protection
5. Sanction not applied – client has 50% payment protection - Not Required as
information is duplicated in PA01
A decision is needed for a solution for presenting the information required by
the business through a daily report(s) once the ISLINK is gone.
923
It is a business requirement to translate messages returned by SWIFTT to
OBMAN succinctly so that they contain the message, cause and the remedial
action. Out of  suggested discussion with Out of scope  should be held about what
would be inv
scope olved in changing the messages in SWIFTT.
1353
For YP/YPP clients OBMAN will request SWIFTT for sanction once notice period

(X) elapses from failure date. This will be aligned with the current process in
SOLO.
a. Sanction date (YP/YPP clients) = Failure date + X + 1
Note: X is parameter driven. It will default to 7 working days at
implementation.
The consequence of the VR not being approved for go-live is OBMAN will not
request SWIFTT to sanction any youth client (i.e. YP/YPP clients) for failing
their obligations. As advised by Out of   there is no manual method of
sanctioning YP/YPP clients directly in
scope  SWIFTT for failing obligations. So the
implication is no youth client will be sanctioned for obligation failures.
Page 16 of 27

IN-CONFIDENCE

Jira reference for VR1353 - http://jira.ssi.govt.nz/jira/i#browse/RSOLO-514

9  Appendix
The fol owing is an excerpt from MAP on how the 5 working day notice period is counted currently:
(Note: 5 working day notice period wil  be a configurable parameter in OBMAN (IRS262 Configure
Obligation Notice Period has more details on it)).
The five working day notice period is counted from the date after the obligations failure letter has been
sent to the client, to al ow for posting and delivery of the letter.
The five working day notice period excludes weekends, public holidays, or the period 25 December to
15 January each year.
The fol owing table (illustrated in MAP) provides an example of how to count the notice period.
Day 0
Tuesday
Automatic failure in CMS occurs overnight
Day 0
Wednesday  An obligations failure letter is sent
Day 1
Thursday
Five working day notice period begins
Day 2
Friday

Weekend
Saturday-Sunday
Day 3
Monday
Five working day notice period continues
Day 4
Tuesday
Day 5
Wednesday
Day 6
Thursday
Benefit sanction occurs in SWIFTT
9.1  Legislation
•  Procedure for imposing sanctions section 113 Social Security Act 1964
•  Interpretation of a working day (definition) section 3(1) Social Security Act 1964

Page 17 of 27

IN-CONFIDENCE

process is currently normal business as usual. This process of restarting RAO will cease to exist in
the future as the business has agreed to have the “Restart RAO” function removed from
OBMAN.

*** As per the current system functionality, the Traffic Light System does not take into account the
RAO status for a client. Therefore, the client’s TLS status will not reflect the client’s real state.

Page 22 of 27

IN-CONFIDENCE

stopped and wiped out . The count continues as for
Re-complied. (Subject to Interim solution – manual)
Sup erseded
A Failure that has been removed by a Job Refusal
ORANGE:
N
failure on the same day.   It may be reinstated if the
If no
JR is successful y disputed.
sanction
RED: If
sanction
applied
Resulted
A re-compliance for a 3rd or 4th Failure is still an active  GREEN***  N
failure until the re-compliance activity outcome
indicator is set to (F)ailed or (C)ompleted.   It is
resulted when RAO = F or C i.e. the 6-week activity
has been completed or failed.
Benefit
This state for an Obligation Failure was implemented
GREEN
N
Cancelled
by CAPE-139.
Prior to the existence of the “Benefit Cancelled” state,
when a client’s benefit was cancelled in SWIFTT,
OBMAN was not informed of the cancellation. If the
client had any active obligation failure before their
benefit was cancelled, the failures stayed active even
when the client was no longer on any benefit, and the
client’s failure grade also remained unchanged.
As a result of implementing the “Benefit Cancelled”
state, when a client’s benefit is cancelled in SWIFTT,
their failure grade in OBMAN is reset, so that if they
go back onto a new benefit, their failure grade will
start from zero. SOLO is notified of the failure
deactivation with a new Obligation Failure status of
“Benefit Cancelled”. SOLO does not send any letters
to ECS nor notify SWIFTT of the deactivation for this
reason code.
Legend: *** As per the current system functionality, the Traffic Light System does not take into
account the RAO status for a client. Therefore, the client’s TLS status wil  not reflect the client’s
real state.

9.4  Glossary
OBMAN
Obligation Failures Management application
OBMAN Failure
The overall failure which may consist of several SubFailures; known to the
business as a Failure. Held in SOLO as Work Test Event.
SubFailure
Known to the business and on OBMAN screens as Failure Reason. Held in
SOLO as Work Test Reason but referred to as ‘Failure Item’.
Page 24 of 27

IN-CONFIDENCE

Failure grade
An obligations failure will be graded at 1, 2 or 3 sequentially according to
how many the client has failed and resolved. Failure Grade 4 denotes a Job
Refusal failure and can happen at any time.  Different failure grades impose

different sanctions.
Active/Inactive
A Failure is active if not yet resolved.   When its status is changed to be, for
example, re-complied, it is inactive.
Job Refusal
A work-testable client has refused a job offer as recorded in RecruitMe. The
Failure Grade is set to 4 and the sanctions are the same as those for a grade
3 failure.
Dispute type
What used to be known in SOLO as Dispute, and on the database as Appeal,
is held as two types: Dispute – which used to be the SOLO Case Manager
Review - and Review – which used to be the SOLO Review of Decision.
RAO
Re-compliance Activity Outcome
RAO is only displayed for a 3rd or 4th failure with a status of Re-complied.
Re-compliance Activity indicator is set once the 6 week re-compliance
activity is started. The user may update the RAO indicator to ‘Failed’ or
‘Started’ on a failure reason with status of ‘Re-complied’ and a Failure grade
of 3 or 4. RAO indicator ‘Completed’ is only set by the batch job. Failure
Status is changed to “Resulted” when RAO indicator is set to “Failed” or
“Completed”.
RAO indicator ‘Completed’ may only be updated less than 42 calendar days
after the Re-compliance date.

TLS
Traffic Light System
The Traffic Light System is a visual indicator to immediately display client’s
compliance with their work and/or social obligations.
•  GREEN: No active failed obligations, or has recomplied an obligation
failure
•  ORANGE: Has an active obligation failure, and is within the 5-day
working day dispute period
•  RED: Has an active obligation failure, and as a result, has had a
sanction imposed
•  NOT APPLICABLE: Client is not subject to the Traffic Light System

Page 25 of 27

IN-CONFIDENCE

9.5 As-is view of OBMAN Failure Screen Shot:

9.6 As-is view of Event History Screen Shot:

Page 26 of 27