Interview - Group 6 Screens
DSHS Home Page

ACES

Search     for:
DSHS HomeACES ManualEAZ ManualSocial Services ManualWork First Manual

Interview - Group 6 Screens


Revised October 15, 2009



Purpose:

(SANC) - Client Sanctions (SHEL) - Shelter Expenses
(SSNA) - Additional SSNs and Names (STAT) - Assistance Status
(STRT) - Street Names List - (Invalid after 10/19/2009)

(SANC) – Client Sanctions Screen

The (SANC) screen is used to record information about penalty income, temporary absences not reported, and Intentional Program Violation Disqualifications.
  • (SANC) follows (UNER) in the regular screen flow. 

  • (SANC) is a client level screen.

  1. Penalty Income field

    1. Penalty income is income that is attributed to a food assistance AU and budgeted as unearned income when a client, who is the member of a Basic Food AU is sanctioned from a means-tested public assistance program for failure to cooperate with a program requirement.

      The most common of these is sanction for non-cooperation with a WorkFirst or Division of Child Support requirement.  See WAC 388-422-0010 and WAC 388-310-1600. See also the WorkFirst Implementation Handbook.

    2. Z displays on the (FSFI) in the Penalty Income field but not on the (SANC).

    3. After the data has been committed to the database the penalty income displays in the Penalty Income field on (SANC).

    4. It is very important to review the (FSFI) to ensure the penalty income is used in the Basic Food computation before confirming the benefit computation.

  2. Sanction Reason field

    1. Policy states that for TANF / SFA a caretaker relative must report within 5 days when they learn that the temporary absence of a child will exceed ninety days.  See Disqualified / Sanctioned Assistance Unit / Individual - Temporary Absence of Child Becomes Permanent, Not Reported  and WAC 388-418-0005 .

    2. Failure to report this timely results in a sanction of 1 month and counting the income of the absent person as available to the remaining assistance unit members.

    3. If the temporary absence of child becomes permanent and is not reported timely then the client must be sanctioned.

    4. The change must be processed following current effective date rules. To implement the sanction, enter reason code [100] in the Sanction Reason field on the (SANC).

    5. ACES then sets the effective start date and end date based on the benefit month being processed and taking into account that 10 days advance notice can be given.

  3. At the end of the sanction period, ACES will add the client back to the AU.


Client level information on the (STAT) / (ELIG) is:

  • Finl Resp field = RN
  • Stat T field = A
  • RSN field = 259

IPV (Intentional Program Violation) Section

  1. Information entered in the IPV section of the (SANC) is used to disqualify an applicant or recipient found guilty of an Intentional Program Violation on the Basic Food Program.

  2. Enter information about the IPV as follows:

    1. Ind field = Type of disqualification per valid values. See <F1> Help.

    2. Ctr field = Enter [1 for the first, 2 for the second, or 3 for the third disqualification].

    3. Dec / Off Dt field = Enter [the date of the IPV Hearing decision]. The penalty end date is calculated with month 1 being the first month after allowing for 10-day advance notice.

    4. Start Dt field = Enter the [date the disqualification is to begin] allowing for 10 days advance notice. The date entered here must be greater than the date entered in the Dec / Off Dt field.

    5. Pnlty End Dt field = This field fills automatically based on the number of the offense and the disqualification decision date.

    6. Override Dt field = Use this date to override the system set penalty end date. If for some reason, based on policy, the end date is not correct enter the correct penalty end date in this field. The system will display the date entered here in the Pnlty End Dt field and in the Penalty Date field on the (STAT) / (ELIG).

  3. To enter IPV information for a client not know to ACES use the DRS process on the (LMEN) submenu.  See Disqualified – Disqualified Recipient System (DRS).


(SHEL) – Shelter Expenses Screen

The SHEL screen is used to record the AU’s shelter expenses such as rent and utilities.
  • SHEL follows WORK in the regular screen flow

  • The SHEL is a client level screen.

  • Only the SHEL for the head of household (client pointer 01) automatically displays in the regular screen flow.

  • If a household member other than the head of household incurs shelter expenses additional SHEL screens can be called by entering [SHEL and the appropriate client pointer] in the screen short name field.

  • The income standard for some cases is based on whether or not a household has a rental obligation or is receiving supplied shelter.

  • This is true for most cash cases and some medical cases.

  • Categorically and medically needy medical cases in the F and S track such as F04, CN TANF-Related and S02, SSI-Related CN Medical use the information on the SHEL  to determine the appropriate income standard.

  • For cases that use the Federal Poverty Level (FPL) as the income standard a rental obligation makes no difference in which standard is used to determine income eligibility.


EXAMPLE

  • F06 - Children’s Medical;
  • F07 - Children’s Health Insurance;
  • S03 - QMB; and
  • S05 - SLMB.


  • To calculate expenses, ACES adds all of the rent / mortgage amounts entered on all SHEL screens together to determine the amount of the housing expense.

  • It is not necessary to enter a separate shelter cost on a child’s SHEL for the system to use the correct standard in the benefit calculation.

  • If a cash AU contains an adult with a financial responsibility code of anything but NM, and a child, ACES will correctly allow the owning, buying, renting standard when appropriate.

  • In these situations the shelter costs should all be entered on the screen of the person that has the shelter obligation, which in most situations is the head of household.

  • If the household contains an ineligible AU member with income, such as an alien, the shelter costs should be coded on that household member’s SHEL screen. This will correctly prorate the shelter expenses.

  1. Util Std (Utility Standard) field

    • If the household is receiving Basic Food, the utility information needs to be coded on the SHEL of the client that is the head of household for the Basic Food AU except in the following situation:

      • If the Basic Food household contains an ineligible member (ND) with income (such as ineligible aliens, clients who refuse to provide a social security number, etc.), the SUA utility standard needs to be coded on the ND (Ineligible member) SHEL screen. After determining the correct SUA based upon the number of members in the AU, the SUA may be prorated as a part of the AU's shelter expenses.  See WAC 388-450-0140 and WAC 388-450-0195 Income - E.- Effecct on Eligibility and Benefit Level.

    • Only one utility standard can be entered per Basic Food AU. If more than one is entered the user will see Edit Message 1858 – Utility Standard Entered On Multiple Clients - when trying to commit the data.

    • Beginning with benefit month November 2000 the SUA is based on household size and is not prorated using the Other Sharing Utilities field.  See Basic Food Program – SUA.

  2. Public Housing or Rent Subsidy field

    1. Policy states that a client living in subsidized housing who is not paying rent because they are receiving a subsidy must be responsible for a separate utility cost in order to receive the renting standard.

    2. In order for the system to use the owning, buying or renting standard in the eligibility determination, a [Y] must be entered in the Public Housing or Rent Subsidy field.  See WAC 388-478-0010.

  3. Others Sharing Utilities field

    1. For benefit months prior to November 2000:

      1. When there are other people living in a household, not receiving Basic Food benefits but the FA assistance unit is sharing utilities with these other people, enter the number of other persons sharing utilities with the client who are not members of the AU.

      2. Do not include person’s in the FA AU regardless of that person’s financial responsibility code.

    2. The field is not used for benefit months from November 2000.


(SSNA) - Additional SSNs and Names Screen

When information is entered in the Alternate Names and/or Additonal  SSNs field(s) on the (MEMB) during Screening a Y is pre-filled in the Alt Name and/or More SSNs field on the (DEM1) and the (SSNA) screen displays in the screen flow.
  • The (SSNA) is a conditional screen that will not appear in the regular screen flow unless there is data entered on it or a [Y] is entered in the Alt Name and/or More SSNs field(s) on the (DEM1).

  • The (SSNA) is a client level screen.

  • The names and/or SSNs displayed on this screen cannot be changed.

  • New names and/or SSNs can be added.

  • When information is entered on the (SSNA) the new demographic information for that client is compared to existing demographic information on the database and the (NMCL) displays.

  • It is very important at this point that the new client information is matched to the correct existing client information so that the client ID remains the same.  See Screening - Name Clearance.


(STAT) – Assistance Status Screen

The (STAT) screen displays information entered during Screening such as program code, type code, medical coverage group, application date, and is used to collect information regarding the financial responsibility of the head of household to each other member of the household.
  • (STAT) follows (ADDR) in the regular screen flow. 

  • The (STAT) is an AU level screen.

  • One (STAT) displays for each AU in the case.

  • The enterable fields on this screen are:

  • AU Status Reasons - AU level status reason code

  • Penalty TypeAU level penalty type code

  • Penalty End DateAU level penalty end date

  • Stat Rsn - Client level status reason code

  • Rel – Relationship code

  • V - Relationship verification

  • Finl Resp - Financial responsibility code.  See Financial Responsibility.

  • Rsn– Client level reason code

  • Penalty T – Client level penalty type code

  • Penalty Date – Client level penalty end date.

  1. Penalty Type field:  AU level penalty type-code – If the assistance unit has been disqualified or is in penalty status the type code indicating the reason for the disqualification displays here.

  2. Penalty End Date field:  AU level penalty end date – The date in this field reflects the end date of the assistance unit’s penalty period.

  3. Stat T / Date / RSN field

    1. Assistance Status Type - The field next to the Finl Resp field indicates each client’s status in the AU, date that status became effective.

    2. The status code is for that month only.

    3. Status code A - Active, does not mean that the listed individual receives benefits.

    4. Persons with income allocated or deemed to the assistance unit have a status code of active.

    5. The code in the RSN field indicates the client is not receiving benefits or is receiving only a certain type of benefit such as a medical only when a TANF client is sanctioned due to conviction for a drug related felony.

    6. Enter a [500 level reason code] in this field to deny or close an individual client.

  4. Stat Date field

    1. Assistance Status Date - The date in this field is the date the action was taken to place the client in that status.

    2. The relationship, relationship verification and financial responsibility fields are mandatory and may result in the case being denied if not completed.

    3. All other fields on this screen are pre-filled by ACES based on client data entered in other part of the system.

  5. Penalty T field:  Client level penalty type-code - If the client has been disqualified or is in penalty status the type code indicating the reason for the disqualification displays here.

  6. Penalty Date field:  Client level penalty end date - The date in this field reflects the end date of the assistance unit’s penalty period.

(STAT)  Function Keys

When the user presses This happens:
F16 - eftm (EFTM)- use this screen to access the EFT registration screen in update or inquiry mode.
F19 - jmen Inquire about a warrant, FCA, or DMC issuance.
F22 - alau (arch) View alerts for an archived case.
F23 - alau (curr) The (ALAU) and AU alerts are displayed.

(STRT) - Street Names List

The STRT screen is invalid after 10/19/2009. See ADST - Address Standardization.

There are three conditional screens that are used to assist in standardizing an address:

(NAME)  or (ADDR) is followed by:

If:
(STRT) - (Invalid after 10/19/2009) Street does not match the city and zip.
(CITY) - (Invalid after 10/19/2009) City and zip code do not match
(RANG) - (Invalid after 10/19/2009) Address number does not match the street, city and zip
  1. Once the City and Zip code are correct, Finalist tries to validate the street in relation to the city and zip code. If the street listed on (ADDR) or (NAME) does not match the city, the (STRT) screen displays.

  2. The address information as entered on the (ADDR) or (NAME) displays at the top of the screen.

  3. Below that address are listed possible Street Names that are correct based on the rest of the address. Enter [Y] in the Sel field for the correct street and press enter.

  4. The selected entry displays with the rest of the address information at the top of the screen and the Confirm field displays a red question mark.

  5. If the address displays correctly, enter [Y] in the Confirm field and press enter.

  6. This address is transferred to the appropriate address fields on the (ADDR) or (NAME).

  7. If N is entered in the Confirm field the previously entered information reappears in the address fields so the user can make the correct selection.

  8. If the address cannot be confirmed here press <F3> to go back to the (ADDR) or (NAME) screen.

Back to top

Modification Date: October 15, 2009
Have comments on the manual? Please e-mail us. You can also use this link to report broken links or content problems.