IN-CONFIDENCE
IRS239 Lift Sanction
As a system (OBMAN) I want to inform SWIFTT that a Failure
Status
Final
has had an action performed on it so that sanction imposed on
a client due to an Obligation Failure can be lifted and I want to
Date
03/11/15
record the response from SWIFTT.
Customisation: N/A
Version
1.3
Impacted Systems: OBMAN, SWIFTT
Author
Out of scope
OBMAN will advise SWIFTT of lifting benefit sanctions.
SWIFTT will receive lifting of sanction information from
OBMAN, process the request and advise OBMAN of the
sanction has been lifted.
(Note: SC846 wil be used by OBMAN and SWIFTT to send and
receive information.)
1 Overview
Currently client’s re-compliance to obligation failures is recorded in CMS or directly in OBMAN (for
Social Obligations). Re-compliance information originating in CMS propagates to OBMAN which sends
the information (along with the social obligations re-compliance information) to SOLO which in turn
sends the information to SWIFTT requesting SWIFTT to lift sanctions.
When SOLO is retired it is envisaged OBMAN wil send the re-compliance information to SWIFTT and
receive a response from SWIFTT on whether sanction was lifted successfully.
2 Traceability
Dependency - IRS237 Advise Sanction
Dependency - IRS238 Generate Obligation Fail Removal Letter Request
Dependency – IRS202 Resolve Exceptions
3 Acceptance Criteria
3.1 Request SWIFTT for lift sanction
The system should request SWIFTT to lift a sanction imposed on a client.
3.2 Receive response from SWIFTT
The system should receive a response from SWIFTT whether lifting of the sanction was successful or
not.
Page 1 of 22
IN-CONFIDENCE
b. Effective date (i.e. the date when sanction should be lifted)
c. Change Type (value = “LIFTSANCTION”)
d
. Change Reason – the reason why sanction should be lifted which is one of the following:
i.
Re-complied (value = “RECOMPLY”)
ii.
Overturned (value = “OVERTURN”)
iii.
Deactivation (value = “DEACTIVATE”)
iv. RAO status is set to “Started” (value = “STARTRAO”)
v. RAO status is set to “Completed” (value = “COMPLETERAO”)
(Note: As per the current system functionality a user can reset RAO status to “Started” from an
initial value of “Failed” within 5 working days of original “Failed” and before the batch of 6
weeks. In this case the RAO “Failure” is sent through to SWIFTT but SWIFTT is not informed of
the re-set value of RAO “Started”. The Case Manager may go into SWIFTT to grant a provisional
benefit as normal business as usual. This process should remain unchanged in the future.)
Please refer to the Business Rules for Apply and Lift Sanction table in the Appendix for a tabulated
view of the rules.
4.1.1.3 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 the sanction has been successful y lifted, the system should update the Event History
with:
a. Manual action (if any) required (e.g. backdated review)
b. Where the sanction could not be successfully lifted, the system should update the
Failure screen as follows:
c. Error message (yet to be mapped noted as Exception 3)
Note: IRS202 Resolve Exceptions – addresses business requirements regarding informing users and al owing
users to handle exceptions where (a) sanction is unsuccessful (b) lift is unsuccessful (c) manual action/review is
required.
4.1.1.4 BR Update Failure screen
Where benefit has been successful y sanctioned, the system should update the Failure screen with
Sanction lifted date (i.e. the date when OBMAN requests SWIFTT to lift sanction.)
4.1.1.5 BR RAO not failed by 13 weeks from Sanction Date
1. If the client starts RAO after the Sanction Date and is not failed or completed before or on 13
weeks from the Sanction Date, the Obligation Failure shall be deactivated in the system.
Note: There is no requirement to send a message to SWIFTT in this scenario.
Page 3 of 22
IN-CONFIDENCE
5.2 Indicative to-be view for OBMAN Event History Screen Shot:
1. Where benefit has been successful y lifted, the screen should display the following:
a. under “Event”:
• Sanction lifted
• 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
2. Where benefit could not be successfully lifted, 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 or User Id (depending on who triggered off the event)
5.3 “Restart RAO” function
1. The “Restart RAO” function shall be hidden from all users.
a. Note: The “Restart RAO” function does not currently function due to an existing
production defect. Resolving this production defect is outside the scope of the SOLO
Retirement Project, however to reduce user confusion the business has accepted
the removal of this function.
Page 8 of 22
IN-CONFIDENCE
1
Where the sanction lifted date returned by SWIFTT is different to
Out of
Closed
OBMAN generated “sanction lifted date”, this should display scope
in the exception screen or report to be looked at and
resolved, but not displayed to the user. These need to be
addressed with urgency as MSD is failing to pay the client full
and correct entitlement (FACE).
The outcome of VR#748, #770 and #771 will decide where/how
this business requirement wil be implemented.
Update (08/05) Emailed Nigel asking him where currently this
information is displayed.
Nigel’s response – “The NZESLNKS report gives a line item that
states that a Back Dated Review (BDR) may be required (or
something of that nature). Helen has advised me this means
that either the sanction date, or the sanction lifted date is
out of sync between SWIFTT and SOLO.
We require there to be a notification to cover these same
scenarios (although, hopefully we can make the message(s)
more specific in future) in the function that is replacing this
report.”
Since IAP wil generate the replacement NZESLINK reports so
passed on the requirement to Subbu who is managing the
Reporting project.
2.
A decision is awaited on the mechanism for reporting exceptions Out of
Closed
(e.g. unsuccessful lifting of sanctions). Options being discussed
scope
are:
a. A new OBMAN screen displaying exceptions for all
clients (as opposed to a client in focus)
b. A report generated by the OBMAN database
c. A report generated by IAP using data from the OBMAN
database
This is logged in the Variations/Decisions Register ref #748, #770
and #771.
Update: Decisions are:
#748 – New OBMAN screen wil be built – requirements will be
covered in IRS202 Resend Failed Transactions.
#770 – A separate report (replacement of Tranzit Exception
Report) wil not be required by the business if the new OBMAN
screen (#748) shows all failed transactions for all clients and
users are given a facility to save/print a version of failed
transactions presented on the OBMAN screen. Requirements wil
be covered in IRS202 Resend Failed Transactions.
#771 – The replacement ISLINK reports would be replaced by IAP
reports.
3
Mapping of error codes and error messages returned by SWIFTT Out of
Open
to OBMAN.
scope
Once the SWIFTT team makes the list of error codes and error
Page 11 of 22
IN-CONFIDENCE
Superseded
A Failure that has been removed by a Job
ORANGE:
N
Refusal failure on the same day. It may be
If no
reinstated if the JR is successfully disputed.
sanction
RED: If
sanction
imposed
Resulted
A re-compliance for a 3rd or 4th Failure is still
GREEN*** N
an active 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
RED
N
Cancelled
implemented 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.
9.3 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’.
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.
Page 19 of 22
IN-CONFIDENCE
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.
3. GREEN: No active failed obligations, or has recomplied an obligation
failure
4. ORANGE: Has an active obligation failure, and is within the 5-day
working day dispute period
5. 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 20 of 22
IN-CONFIDENCE
9.4 As-is view of OBMAN Failure Screen Shot:
9.5 As-is view of OBMAN Event History Screen Shot:
Page 21 of 22
