Kentucky Automated Support and Enforcement

KENTUCKY AUTOMATED SUPPORT AND ENFORCEMENT

SYSTEM HANDBOOK

KHT. NO 52

INTERSTATE ACTIONS

SECTION 5.00001/23/03

ASEMUD: CSENET OPTIONS MENU – Screen ASEMUD displays a list of CSENet options used to generate interstate requests and responses, and to query and update CSENet screens. The options allow users to initiate requests and respond to other states, to query CSENet inquiry screens, and to update KASES with information received from other states. Screen ASEMUD also allows users to view the CSENet transaction exchange table to determine whether communications are open between Kentucky and a particular state to send and receive CSENet transactions.

When a CSENet transaction request is sent to another state, that state responds with a provide transaction. The worker is notified of the provide transaction by worklist. The worker then accesses the CSENet Update Info segment and either selects or rejects the update information. ( Staff are also able to update KASES with data provided in an enforcement request (ENFR) from another state.) After the information has been selected and confirmed to KASES, workers are denied additional access to the Update Info segment for that transaction. However, all the information in the update segment is moved to the CSENet Inquiry segment on KASES.

NOTE: WORKERS ARE REMINDED TO REVIEW THE CASE AND PARTICIPANT DATA PRIOR TO ACCESSING THE CSENET OPTIONS TO COMPLETE A TRANSACTION. A review of case and participant helps the worker to determine which reason code to select for a responding transaction.

The processing options for this screen are shown below.

ENTER-CONTINUE – Type the appropriate number in the ENTER NUMBER OF SELECTION field, and press ENTER. For the purpose of generating CSENet transactions, select 01-Csenet Functions-Request/Response, and press ENTER. The Generate Interstate Request/Response screen (ASEKCJ) displays. See page 17 for instructions for completing this screen.

To query a CSENet transaction, select 02-CSENet Inquiry, and press ENTER. The CSENet Inquiry screen (ASEKCN) displays. See page 25 for instructions for completing this screen.

To update KASES with CSENet transaction data from another state, select 03-CSENET Update Info, and press ENTER. The Update CSENet Case Information screen (ASEKCB) displays. See page 28 for instructions for completing this screen.

To view the CSENet Exchange Table, select 04-CSENet Exchange Table Maint, and press ENTER. The CSENet Transaction Exchange Table Maintenance screen (ASEKCO) displays. See page 30 for instructions for completing this screen.

PF4-SUB MENU – Press PF4 to return to the Interstate Functions Menu screen (ASEMUA).

PF1-HELP – Press PF1 for online help.

PF3-PREV SCREEN – Press PF3 to return to the previous screen.

PF12-MAIN MENU – Press PF12 to return to the Main Menu screen.

ASEKCJ: GENERATE INTERSTATE REQUEST/RESPONSE – Screen ASEKCJ is used to initiate and respond to CSENet transactions by entering the other state abbreviation, the other state case number if required, and selecting the appropriate FUNCTION and ACTION options. The other state case number is required for CSI and MSC transactions.

Each CSENet transaction is classified into one of seven functional types and six action codes. The following lists the functional types and action codes used for CSENet transactions.

FUNCTIONS

LO1 – QUICK LOCATE

CSI – CASE INFORMATION

PAT – PATERNITY ESTABLISHEMNT

EST – ORDER ESTABLISHMENT

ENF – ENFORCEMENT

COL – COLLECTION

MSC – MANAGING STATES CASES

ACTIONS

R – REQUEST

A – ACKNOWLEDGMENT OF RECEIPT OF REQUEST

P – PROVISION OF INFORMATION

M – REMINDER

U – UPDATE PREVIOUS REQUEST

C – CANCEL PREVIOUS REQUEST

Each transaction is a combination of one functional type and one action code. For example, a transaction may be an Enforcement Request (ENFR) or an Enforcement Update Previous Request (ENFU), in which case the functional type is ENF, and the action codes are R and U respectively. There are only two valid action codes for Case Information (CSI) transactions. They are R (Request) and P (Provision of Information).

Quick Locate (LO1), Case Information (CSI), Enforcement (ENF), and Managing State Cases (MSC) functions are available for processing on KASES at this time.

A CSI transaction is used to request complete case information from another state when the Federal Case Registry (FCR) indicates a successful participant match in a case in another state. Information on the FCR acts as a pointer to the case in another state and provides a means of supplying detailed case information from one state to another upon request.

Based on FCR information received by a state, an initiating state sends a CSIR (request) transaction to the responding state. The responding state receives the request, the workstation sends an automatic acknowledgment to the initiating state, and the responding state begins a search for the matched case on its own system. Once the search is complete, the responding state sends a CSIP (provide) transaction back to the initiating state containing all available case information, or if nothing was found, notifies the initiating state they are unable to locate case information. Upon receiving the response, the initiating state’s responsible worker determines if the information in the CSIP transaction is to be uploaded on the system.

Outgoing CSIP transactions are automated on KASES. When Kentucky receives a CSIR from another state, the system automatically sends a CSIP in response without caseworker intervention. The only instance in which staff will manually complete an outgoing CSIP transaction is if an error is encountered in the automated CSIP build process. If an error is encountered, a CERR worklist with an attached note explaining why the automated CSIP errored off is written to the responsible worker. The responsible worker corrects the error within the case and manually resends the CSIP through the CSENet process on KASES.

The ENF transaction is used by states to request and receive assistance with the registration and enforcement of existing support orders and collection of arrears. An initiating state has an existing support order and identifies the need to begin enforcement actions with an NCP who lives in another state. An enforcement request is initiated on line with supporting documentation sent by mail. There must be an existing support order for the case and the location of the NCP must be known before initiating an enforcement request.

The enforcement request includes the case, participants, and support order details. The responding state receives the request and identifies an existing case or builds a skeleton case on its own system. The responding state may send a CSENet enforcement acknowledgement (ENFA) with reason code AADIN if additional information is required to proceed with the request. The responding state continues to process the case as an interstate case and performs all possible actions that do not require the forthcoming paper documentation. When the documentation is received by the responding state from the initiating state, the worker in the responding states checks the documents for completeness and completes the appropriate action, such as wage withholding or scheduling a hearing or interview with the NCP. The responding state sends details of actions taken by way of the Enforcement Provision of Information and Update transactions.

The MSC transaction, formerly the Miscellaneous transaction type, is now the Managing State Cases transaction type. The MSC transaction is used to inform another state with a common case of any changes to the case. An automated outgoing MSCP will be sent to the other state notifying the state whenever a change to the common case occurs. The other state IV-D case number is required for MSC transactions.

To begin the CSENet transaction process, complete the following instructions.

1. OTHER STATE ABRV – Enter the abbreviation of the state the CSENet transaction is to be sent. There are three two-position fields available. Up to three state abbreviations per case per day can be entered in the fields when sending quick locate transactions. Only one state abbreviation is used when completing other CSENet transactions. The OTHER STATE ABRV is a required field.

1. OS FIPS # - Enter the FIPS Code for the out-of-state IV-D agency that is to receive transactions associated with the case. If unknown, the PF6-AGENCY FILE option is available to path to the Select Employer/Agency screen (ASEEMC) to select and confirm a specific FIPS Code. The system inserts the FIPS Code in the OS FIPS # field after the selection is confirmed. For example, if the Anderson County Tennessee Responding agency was selected from the agency file, the system enters 470015001 in the OS FIPS # field. This field is a ten-(10) position field. This field is optional.

1. OS CASE ID – The out-of-state case number is required for outgoing provision of information, acknowledgments, CSI, and MSC transactions. Out-of-state case number can be obtained from transactions on the HR CSR-04A CSENet Reports on RMDS. They are also available on CSENet Inquiry for incoming CSI, ENF, and MSC transactions. There are fifteen (15) positions available for the OS CASE ID field.

1. FUNCTION SELECTED – Enter the FUNCTIONS number in the FUNCTION SELECTED field to identify the appropriate transaction function. This is a required field.

1. ACTION SELECTED – Enter the ACTIONS number in the ACTION SELECTED field to select the appropriate transaction action. The valid entries for CSI transactions are numbers 1 and 3. This is a required field.

1. ADDITIONAL INFORMATION – Additional information is used to ask a question or compose a message to send to the other state. Any information that seems important but does not fit into any of the other transaction categories can be sent with most transactions* with an information data block. Additional information does not show on this screen for incoming CSENet transactions. Additional information for incoming CSENet transactions is stored in Notes under the KASES event created by the receipt of the incoming transaction. Additional information is shown in the Information (INF) Block on the CSENet Inquiry screen (ASEKCN) and Update CSENet Case Information screen (ASEKCB) on incoming and outgoing transactions. This field is optional.

*Since most states have automated CSI and LO1 transactions, staff do not review those transactions and any additional information entered for those transactions will not be utilized. However, the ADDITIONAL INFORMATION field is a valuable tool for adding information (or a question) for MSC and other type transactions that can are not automated.

The processing options for this screen are shown below.

PF6-AGENCY FILE – To path to the Inquire Employer/Agency File screen (ASEEMA) to select an agency FIPS code, place the cursor in the OS FIPS # field and press PF6. Select the appropriate agency from the Select Employer/Agency screen (ASEEMC) and confirm, and the system returns to screen ASEKCJ and inserts the out-of-state FIPS code in the OS FIPS field.

PF9-CONFIRM - Press PF9 to confirm the transaction. The CSENet Case Information Reason Codes screen (ASEKCL) displays with the appropriate reason code menu for the selected function and action if the transaction requires a reason code. The system bypasses screen ASEKCL if the transaction does not require a reason code. See the following pages for instructions for completing screen ASEKCL.

Staff are to note that PF9 must be pressed when returning from screen ASEKCL in order for the transaction to be generated from KASES.

ASEKCL: CSENET CASE INFORMATION REASON CODES - To clarify the meaning of a transaction, most CSENet transactions require a reason code . For example, an ENFR could be a request to collect arrears, enforce an existing order, or to register a support order. To differentiate between these possibilities, a reason code is added to most transaction. Screen ASEKCL displays the appropriate CSENet reason codes for the transaction in progress. For example, Screen ASEKCL displays as CSENet Case Information Reason Codes for CSI transactions, CSENET ENFORCEMENT REASON CODES for ENF transactions, and CSENET GENERAL REASON CODES for MSC transactions. Not all CSENet transactions require reason codes. For example, LO1R (QUICK LOCATE REQUEST), ENFC (ENFORCEMENT CANCEL), and ENFM (ENFORCEMENT REMINDER) transactions do not require reason codes.

The above example of screen ASEKCL shows outgoing CSIR transaction reason codes for IV-D and non-IV-D cases. However, an edit has been entered to prevent completing transactions for NON-IV-D cases and reason code 02-FRNNF REQ. ALL NON IVD CASE DATA DUE TO FCR NOTIFICATION will be removed from the ASEKCL screen at a later date. If staff attempts to use reason code 02, the transaction will error off and the system will create a CERR worklist with the following message. NON-IVD CASES ARE NOT VALID FOR CSENET TRANSACTIONS.

A CSIR transaction contains the initiating state’s case identification number, the responding state’s case identification number, and the following reason code.

FRINF - REQUEST ALL IVD CASE DATA DUE TO FCR NOTIFICATION

Reason Code FRINF is used to request all IV-D case information.

If a CSIP transaction was being completed, screen ASEKCL would have displayed the reason codes for CSIP transactions. A CSIP contains the initiating state’s case identification number, the responding state’s case identification number, and one of the following reason codes.

FSINF – PROVIDE ALL AVAILABLE CASE INFORMATION

FUINF – NO CASE INFORMATIN FOR CASE NUMBER PROVIDED

Reason Code FSINF is included in the outgoing CSIP transaction when KASES provides case information to the other state. Reason Code FUINF is included in the outgoing CSIP transaction to inform the other state information is not available on KASES for the case in question. For example, FSINF is selected if the NCP’s address and/or employer is available and the family violence code is not in place for any of the participants in the case. FUINF is selected if the NCP’s address and/or employer is not available on KASES, or if the family violence code is in place for any of the participants in the case.

Screen ASEKCL displays reason codes appropriate for a specific transaction. A list of CSENet Reason Codes for transactions that are in production at this time are attached to this section. The codes list will be added to as other CSENet transaction functions are migrated to KASES.

The processing options for the reason codes screen are shown below.

ENTER-CONTINUE – The ENTER-CONTINUE option is used to bypass a reason code selection if a CSENet transaction does not require one. However, if a transaction requires a reason code, the system will not allow the transaction to be completed through the ENTER-CONTINUE option. The following message appears at the bottom of the screen warning the worker the transaction cannot be generated. INVALID FUNCTION, REASON CODE REQUIRED FOR TRANSACTION. The worker then enters a line number to select an appropriate reason code and presses PF9 to confirm.

PF9-CONFIRM - Type the appropriate line number in the ENTER LINE NUMBER FOR SELECTION field and press PF9. KASES returns to the Generate Interstate Request/Response screen (ASEKCJ) with the following message shown at the bottom of the screen. PF9 TO ADD TRANSACTION. When PF9 is pressed, the system displays the following message at the bottom of screen. ASEKCJ: TRANSACTION TRIGGER CREATED. The system creates an event item if the transaction is successful. It also displays the transaction item on the CSENET Inquiry screen. The system writes a CERR worklist item with notes attached to the responsible worker if the transaction errs off for some reason. The reason for the error is contained in the CERR Worklist notes.

ASEKCJ: GENERATE INTERSTATE REQUEST/RESPONSE – KASES returns to screen ASEKCJ after a reason code is selected. The message PF9 TO ADD TRANSACTION is shown in the bottom left corner of screen ASEKCJ to prompt a worker to press PF9 to generate the transaction.

When PF9 is pressed to confirm, KASES generates the transaction and displays the following message in the bottom left corner of screen ASEKCJ: TRANSACTION TRIGGER CREATED. If the transaction was successful, KASES creates an appropriate event item and adds the transaction item to the CSENet Inquiry screen. KASES also creates a 60-day future dated worklist item to remind the worker an incoming provide transaction has not been received for an outgoing request. The worklist is automatically deleted if the provide is received before the 60-day period.

After the transaction is confirmed, staff should check EVENTS to see if an event was created, and the CSENet Inquiry screen to see if the transaction item was added to the screen . If an event and transaction trigger were not created, the transaction was not successful. Instead, a CERR worklist with the reason the transaction errored off, appears on the worker’s worklist.

Error transactions are those that the KASES program has found an error and will not pass to the CSENet Host. An error occurs when an incorrect reason code is entered, a piece of mandatory data is missing on a transaction, etc. For example, a CERR worklist would be written if staff attempted to complete an outgoing ENFR transaction for a case and court order data was not available in KASES. The error message informs the worker that the order data block is missing from the transaction. If order information is available, the worker enters the data on KASES, then again completes the ENFR transaction.