Welcome. Region 3B CSENet Training “PARTS OF THE CSENET PUZZLE” May 24, 2005 DeKalb County Public Library. Presented by Dianne Ashe, Policy Specialist, Region 3B. First things first. Please take a minute and make the following corrections to your training manuals: Page 8 Change
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Region 3B CSENet Training
“PARTS OF THE CSENET PUZZLE”
May 24, 2005
DeKalb County Public Library
Presented by Dianne Ashe, Policy Specialist, Region 3B
Please take a minute and make the following corrections to your training manuals:
“While a UIFSA code is not needed when sending an L01 or CSI transaction, it is important for data reliability purposes.”
“While a UIFSA code is not required to send a CSENet transaction, it is important for data reliability purposes.”
Under EST, first bullet under “What actions will the Georgia user or $TARS take”
“a paternity” to “an establishment”
5th bullet, Remove “Cancel”—it is not an option for MSC
Remove “outgoing and” from “Example of MSC P outgoing and incoming transactions on View Assigned Transactions screen.”
To add MSC GIHER to auto transactions when court date is entered to the Court Tracking Screen.
Action Taken $TARS Screen Function/Reason Code
New Court Date Legal-Court CalendarTracking MSC GIHER
Since most of the staff in Region 3B have attended at least one CSENET training class, we aren’t going to focus on every little transaction detail.
Instead, this class is designed to show you how to make the pieces of the interstate caseload and CSENet puzzle fit together.
It is mandatory that all GA OCSE offices use CSENet to communicate case management processes with other states having CSENet agreements.
Information contained in a memorandum from Alfreda Moore dated October 25, 2004 to all Central Registry Managers and CSENET Coordinators:
As part of our ongoing commitment to improve case information sent to other states, Georgia Central Registry will implement the use of CSENET, in order to provide quick and accurate exchange of data between states. To insure successful implementation and to standardize transactions all child support agencies with the capabilities of handling an interstate case by electronically transmitting information, will be expected to communicate in this manner. Please make sure all child support offices within your state receive a copy of this letter. This change will become effective 30 days from the date of this letter.
If you have any questions, comments or concerns, please do not hesitate to contact Alfreda Moore (404) 657-3874 or firstname.lastname@example.org.
FEDERAL TIMEFRAMES – the following was taken from Assessment Procedure 1000:
Within 20 calendar days of locating the NCP in another state or obtaining all information necessary, prepare and submit an appropriate UIFSA packet to the responding state’s central registry.
Respond to the other state within 30 calendar days of receipt of a request.
Upon receipt of new information on a case, notify the responding state of such information within 10 business days.
Within 20 calendar days of receiving a request for review & adjustment (from CP), take appropriate action under UIFSA statutes (Agent Enforcement Manual Procedure 950).
Within 10 business days of receipt of an interstate IV-D case, Georgia’s Central Registry must take appropriate action and acknowledge receipt of the case and forward the case to the appropriate local jurisdiction.
Once the local office receives the case, they are to work under the appropriate federal in-state timeframes for the case. In other words, if the case needs an order established, then the local office has 90 days to complete as per federal in-state guidelines.
If information, documentation, etc, is needed from the initiating state, then Georgia must request this and follow up as needed.
Complaints or unresolved inquiries from other states must be responded to within 5 working days. These will usually come through central registry.
Within 10 business days of receipt of new information, notify the initiating state of that new information. This includes but is not limited to a new address, court date, genetic testing information, court order entered, etc.
Within 2 business daysof receipt of collections, forward any support payments to the initiating state.
The section on “Automatic Updates” beginning on page 40 in your training manual shows what ‘new information’ $TARS will send to assist in meeting the ten-day timeframe.
How the pieces fit together
Uniform Interstate Family Support Act
Laws enacted at the State level to provide mechanisms for establishing and enforcing child support obligations in interstate cases (when a non-custodial parent lives in a different State than his/her child and the custodial party).
EXPLANATION OF CODES
Note: If there is a UIFSA Type code of II or UI then no FIW (Federal Income Withholding Order) will generate.
Enter the correct UIFSA type into $TARS. This code can be entered through either the Case Management/Case Summary/Case Management screen or the Federal Interfaces/CSENet/Case Information Screen.
Federal Information Processing Standard
A unique code that identifies the child support jurisdiction, (i.e., States, counties, central state registries). Codes ending in 0 – 4 represent state disbursement units. Codes ending in 5 – 9 represent local offices and should be used for correspondence. FIPS codes are maintained on a database that is updated routinely with changes, such as name, address, or phone numbers.
The Payee FIPS code on the Support Order screen and the Pay FIPS/Corresponding FIPS codes on the Case Summary/Case Management Screen do not have to match as they are not used for the same purposes.
Each FIPS code represents a child support agency or disbursement unit. When the address of an agency changes, the FIPS code database is updated to include the correct address. This prevents case management information from being sent to an incorrect address.
Physical addresses should only be used when the custodial parent lives in a country for which the US Postal Service requires additional postage. Cases of this nature should have the local office address in the account address fields and should include the notation “Do Not Post” and the custodial parent’s name. These payments are mailed to the appropriate recipient by local accounting staff.
The FIPS code will be one of the following:
The 2-digit state code plus 5 zeros when sending a L01 or an initial EST, ENF or PAT transaction. Example: FIPS code when sending L01 to FL will be 1200000
13 – State code
135 – County code
02 – Local office code
Your first action after viewing this training:
FIPS codes can be found by viewing the Interstate Roster Guide (IRG) or by using the Search FIPS feature on $TARS.
The IRG web address can also be accessed by going to Resources on the GA OCSE website:
To obtain information on FIPS codes sign on as a State User.
User Name is Georgia (case specific) and Password is Peach (case specific)
Click on Login
Click on FIPS/Addresses and select appropriate state
Search by County or City
Information provided will be the 2-digit state code for the State and 3-digit county code. (Georgia uses 7 digits. To identify the complete FIPS code to use in $TARS, use the FIPS Search feature.)
For more information regarding FIPS codes, refer to the information beginning on page 5 in your training manual.
With the exception of L01 and initial Establishment, Paternity or Enforcement requests, the other state’s case number is required to submit and receive transactions. The Federal Case Registry/Interstate Case Reconciliation Case ID Matrix is shown beginning on page 54 in your training manual. The matrix provides examples of Case ID’s used by other states. It is important to enter the correct case number on $TARS.
$TARS should enter the other state’s case number into the appropriate fields on both the Case Management and CSENet Case Information screens when a transaction is received. If it does not, enter the number manually. If an old case number is on the system, $TARS may not overwrite it with the correct one.
It is also important Georgia users provide the other state with our correct case number. If a new case is established due to an APID, CPID correction or for any other reason, notify the other state of the new case number. CSENet is a case-processing tool based on a specific case number. If the case number changes, no auto updates will be sent on the new case and prompts and information will continue to be received on the old, closed case.
FEDERAL CASE REGISRY and FEDERAL PARENT LOCATE SERVICE (FPLS)
The Federal Case Registry (FCR) is a database, which contains basic case and participant data from each of the State Case Registries (SCRs). As part of the Personal Responsibility and Work Opportunity Reconciliation Act (PRWORA) of 1996, each State must implement a State Case Registry (SCR) and establish an interface to the FCR that will automatically transmit and receive child support information for all IV-D cases and non IV-D orders entered or modified after October 1, 1998.
In Georgia the State Case Registry (SCR) is actually $TARS. There is a separate database where Non IV-D information is registered by the FCSU.
The Federal Case Registry (FCR) contains state Child Support Enforcement (IV-D) and non IV-D case data and serves as a pointer system to help locate persons across state lines. FCR involves computers talking to computers. There is no human intervention.
Person data in the FCR are matched daily against employment data in the National Directory of New Hires (NDNH) and sent to states to facilitate case processing and increase collections, especially through automated income withholding. Additionally, matches are sent to states to inform them if a IV-D case participant in their state appears as a participant in a IV-D or non IV-D case in another state.
The FCR also serves as the conduit for matching against the following sources: Social Security Administration (SSA), Department of Veteran Affairs (VA), Department of Defense (DOD), Federal Bureau of Investigation (FBI), and Internal Revenue Service (IRS). Matches made through the Multistate Financial Institution Data Match (MSFIDM) are returned to states through the FCR.
Although the information contained in the FCR is from the states’ SCR, the FCR is not a duplication of all of the data maintained in each State’s child support system.
The FCR provides basic information to facilitate interstate case processing. It also provides proactive matching against the National Directory of New Hire (NDNH). The FCR assists states in locating individuals that reside in different states to establish, modify, and/or enforce child support obligations.
The data elements listed below are found in the FCR:
Note: Data elements for clients with Family Violence Indicators are suppressed.
You will not receive specific information from the FCR concerning case information from another state. You will only receive information that a particular state has information on the participant.
FCR is just an indicator or pointer for workers to know that information is contained in another state’s child support system. When a State sends the FCR information about persons in a new case or child support order, this new information is automatically compared to the existing person’s information in the FCR. If a match is found, the Federal Parent Locate Service (FPLS) notifies all appropriate States of the record match. Thus, a State will know if another State has a case or support order with participants in common with them, and can take appropriate action.
In Georgia, if the case number and SSN provided by FCR matches “Other State’s case #” on the Case Management screen and SSN in CRS, the proactive match will be deleted; therefore, the user will not receive a prompt. If the case number or SSN do not match, information will appear on the FCR Proactive Match Response screen and the user will receive a prompt.
National Interstate Case Reconciliation
Detailed information can be found in the National Interstate Case Reconciliation (ICR) User Guide, Document Version 1.0, MAY 10, 2004 at:
First, the ICR process uses the state code (e.g., 02 = Alaska) and the case ID you have for the other state to try to find an interstate case that corresponds to your interstate case. Then, if the match routine finds a corresponding interstate case in the other state's ICR file, it checks for a match on county code, case status, and SSN or name for each participant on your interstate case.
If the case ID you have for the other state's case cannot identify a corresponding case, then the ICR process looks for a child in common between your case and a case in the other state's ICR file.
The match routine assigns Reason Codes to identify data discrepancies and to indicate the extent to which critical data match between your interstate case and the other state's interstate case. Results are returned for each person submitted on your interstate case.
The national ICR offers an important first step by reconciling interstate cases and, as stated above, by providing correct other state case IDs. As part of the ICR effort, case IDs were analyzed to evaluate what states were using as a case ID in all forms of external communication. This initial analysis, which was a collaborative OCSE/state effort to address case ID inconsistencies, has led the way to standardizing how each state consistently uses its case IDs for interstate and intergovernmental communication. The standardization of case IDs establishes a foundation for better communication to occur among the states, and facilitates ongoing synchronization of interstate cases. Existing methods of electronic interstate communication, such as the FCR, CSENet, and EFT/EDI, are dependent upon states maintaining correct other state case Ids for their interstate cases.
ICR pieces fit?
Current activities undertaken by OCSE with the states include efforts to:
From: Rose Bramlett
To: CSE‑CA; CSE‑CASS; CSERMS
Date: 11/5/04 4:02PM
Subject: ICR Update
PLEASE MAKE SURE ALL EMPLOYEES RECEIVE A COPY OF THIS.
Previously I had sent an email to explain ICR (Interstate Case Reconciliation) and stated that in the next few weeks our system would be processing a match with other states. At that time, the match file was sent to other states but did not include our Agents name and contact information but had given my name for contact. The last match file that was sent just a couple of weeks ago, now has the Agent's name as the contact.
I received a phone call from Ohio today that had called one of our agents who stated they did not know what ICR was. Any case that matches with ALL data in another state, will automatically update the other state case # in $tars. Those that don't match all data will drop into an error report that I will be working to save offices from having to contact the other state, but may need your help with some cases and may contact you.
I just wanted to share the info with you again, and to please ask that all Case Agents have this and the attached information as they may receive calls from other states.
If any questions, or you need any help please email me. Thanks for all you do and all your help
The Child Support Enforcement Network (CSENet) is a nationwide communications network that transfers child support case data between states. Over the Network, States use standard transactions to electronically request or provide:
CSENet is not a database; it is a case-processing tool. This means actions requested or sent are on specific cases. Information returned will come back only to that specific case. If the NCP has multiple cases, information will be returned only to the case number used to initiate an action. Depending on the circumstances, a transaction may need to be generated on each individual NCP case.
To provide quick, accurate, and inexpensive exchange of information between states. It is to support data transfers between state child support systems, standardize transactions, support follow up on FCR matches and is fully automated. CSENet is designed to improve interstate case processing by:
CSENet transactions are processed overnight through the CSENet host, located in Manassas, Virginia. All transactions that pass the edit will be sorted at the host by the Federal Information Processing Standards (FIPS) address code. Those that do not pass edit are generated onto a CSENet Error Report. A designated person in each state reviews the report to determine if user training or system enhancement is needed. Georgia staff will receive an email from the state office if the Report indicates user error.
$TARS sends CSENet updates automatically to other CSENet states which receive MSC transactions. A docgen form is not needed. Example: Send CSEnet transaction (MSC P GSPUD) to NC when notifying them case will be closed in 60 days rather than sending FormINC The Other State’s Corresponding FIPS code and Case Number must be entered on the Case Summary/Case Management Screen for this to work properly. These automatic CSENet updates are done through the Federal Interfaces/CSENET Screen.
At this time all states do not communicate for all functions. To view the states and functions with which Georgia has an agreement, go to our staff only web site pages, under Resources tab select CSENET states. Or refer to the listing of states with which Georgia has an agreement as of January 27, 2005 beginning on page 45 of your training manual. Review the states on the Georgia OCSE website before submitting transactions as states are added and functions changed. The list also provides the first 2 digits of all states as well as the US territories.
A transaction will be rejected at the CSENet hub in Virginia if it is sent to either a state not on this list or is sent to a state on the list but not for that specific function.
The “Documents Attached” feature on State Request and State Response screens refers to Comments.
When adding Comments, enter a check mark in the Documents Attached box. Ensure comments are clear and do not include acronyms that would only be known in Georgia. Your goal is to relate clear, useable information make it clear to whomever reads the case action log what you need from the other state, which state the transaction was sent, and any other item that will be useful at a later date.
Comments entered will document the case action log and can be no more than 240 characters. However, the Case Action Log allows only 150 characters so the last 90 characters will appear separately.
Incoming comments from the transaction can be seen in “Transaction Comments” field. If the comments are received from a MSC function type, they can also be found in the case action log. If they are received from other function types, they only appear in the “Transaction Comments” on the View Assigned Transaction screen. The case action log will always provide function, action and reason codes.
For more information regarding documents attached and comments, refer to the information beginning on page 42 in your training manual.
When a CSENet prompt is received, the information being sent can be determined by:
To respond to an incoming transaction, see State Response information beginning on page 10 in your training manual.
For more information regarding CSENet prompts, refer to the information beginning on page 47 in your training manual.
FUNCTION TYPE CODE
The action being communicated is identified by a combination of codes that specify the Function, Action, and Reason for the CSENet transaction. The codes are also referred to by their field names: Functional-Type-Code, Action-Code, and Action-Reason-Code.
The combination of these 3 codes makes up the Transaction Code. The type of transaction determines the required field codes.
Incoming transactions are noted with an “I” and outgoing transactions are noted with an “O” on the CSENet/View Assigned Transactions screen.
FUNCTION TYPE CODE
Functional-Type-Code refers to the child support action to which the transaction relates. The following slide shows the seven (7) valid Function codes. It is important to always verify Georgia has an agreement both with the specific state and for the specific function before sending a CSENET transaction.
The Quick Locate function is generated when a user believes the NCP may be in another state with which Georgia has an L01 agreement. $TARS allows only three L01’s on a single case per day. If no SSN is on the system, the responding state may return the transaction automatically without performing a search. It is very important to obtain the NCP’s SSN and process client ID corrections as soon as possible if required.
LO1 transactions should be a fully automated process; however, this is dependent on each state. Worker intervention should not be required. When L01 transactions are received, the receiving state’s computer system checks it’s database and sends a response. The Reason codes for LO1 transactions provide very specific information, understanding the response assists the user in quickly identifying if successful or unsuccessful information was returned.
For more information on L01, refer to the information beginning on page 15 in your training manual.
Ensure the other state has an ENF agreement with Georgia.
The ENF Function code supports a variety of enforcement actions for interstate cases.
Once the interstate case has been initiated, the Georgia user may receive a prompt such as “CSENET: Info Rec’d for Case”, “CSENET: Transaction Rec’d with new/info for Case”, “CSENET: MSC info Rec’d for Case” or “CSENET: Request Rec’d for Case”. Go to the View Assigned Transactions screen (information beginning on page 12) to see the information or request.
To provide updates, use the State Response screen. Use MSC R to request updates. Do not use ENF R once acknowledgement has been received to prevent a duplicate case being established. See the View Assigned Transactions section to see more on requesting or sending updates using the Generate Response feature.
For more information regarding the ENF function type, refer to the information beginning on page 18 in your training manual.
Ensure the other state has a PAT agreement with Georgia.
The paternity process is used to request and receive assistance with the establishment of paternity. The function type is Paternity Establishment Required (PAT). This function type is used when paternity establishment only is being requested. An example would be if the NCP is located in prison and all that is needed is establishment of paternity.
When requesting establishment of both paternity and an order, use the Order Establishment Request (EST) function. Because only one function type can be entered, use EST, click Documents Attached and document in the Comments field what is being requested in the actual petition
Example: EST R SRORD (Request Support Establishment all available support types); Comments: Georgia is mailing NC a petition requesting establishment of paternity, support, medical and income deduction on 02/21/05.
For more information regarding the PAT function type, refer to the information beginning on page 20 in your training manual.
Ensure the other state has an EST agreement with Georgia.
The order establishment process is used to request and receive assistance with the establishment of a support order. The process for requesting an establishment of an order is the same as paternity.
Once the interstate case has been initiated, the Establishment or Miscellaneous function can be used to provide updated information. However, use EST R only one time as sending again may cause the other state to create a second case.
For more information regarding the EST function type, refer to the information beginning on page 22 in your training manual.
Ensure the other state has a MSC agreement with Georgia.
The MSC code previously stood for Miscellaneous. It has been changed to Managing State Cases. To coincide with $TARS and for this training, we will refer to it as Miscellaneous Transactions. However, Federal information refers to it as Managing State Cases.
The Miscellaneous (MSC) Function code supports many of the requirements that are not addressed by other Function codes. MSC transactions can be used to communicate a variety of actions including ongoing case activities, status update requests and responses, and notification of hearing dates. A MSC transaction may be generated automatically by the system or manually by a user. These function types are the ones used most often.
For more information regarding the MSC function type, refer to the information beginning on page 24 in your training manual.
The Collection (COL) Function code is used to notify another State that an IRS tax intercept has been received and disbursed. The initiating state’s system must automatically generate a CSENET notice to the responding state when the IRS tax intercept is received. The sole purpose of the COL function code is to notify the other state when a federal tax intercept is credited. No responses are required by the responding state. Once a COL is received, adjust the arrears by posting as a certified payment.
In the summer of 2003 Georgia sent its first automatic Tax Collection information through CSENET and began with Tax Year 2002. The Collection transactions are generated quarterly and obtained from the Payment Summary Screen when Payment Source is F.
If an NCP receives a refund after the tax collection is posted, notify the other state using a MSC function code.
If an outgoing COL transaction is found on the View Assigned Transactions screen for a state with which Georgia does not have a COL agreement, the transaction will fail at the Federal CSENet Hub in Virginia. Georgia user must send manual notice of the tax collection to states that are not on the list of CSENet states accepting COL transactions.
For more information regarding the COL function type, refer to the information beginning on page 26 in your training manual.
Ensure the other state has a CSI agreement with Georgia.
The Case Information Transaction (CSI) Function code was added to allow states to send and receive requests for basic case and participant information when a FCR (Federal Case Registry) Proactive Match is received. If one state shares a client of any type with another state, a FCR Proactive Match is generated. The match does not provide detailed case information; it only acts as a pointer that another state has a case. The CSI function is only used in connection with a FCR Proactive Match. It is not used to generate messages back and forth on an existing interstate case. A CSI request can be generated through the CSENet or FCR screens if the other state has an agreement with Georgia for CSI function codes.
FCR Match Information screen provides the State, matched case identification number, matched client name, social security number (SSN) of matched client, and member type. The county code is sometimes provided. The matched case ID is the case number in the other state.
If the case number and SSN provided by the FCR matches the “Other State’s Case Number” on the Case Management screen, $TARS should delete the proactive match and not send a FCR prompt to a user. If either the case number or the SSN does not match, the user will receive the FCR Proactive Match.
In $TARS the FCR Proactive Match screen shows the name of the client on which the match was received which may not necessarily be the name of the NCP.
Prompt received on John Doe, case #123456789
Go to FCR Proactive Match screen; no John Doe shows on the screen
FCR Proactive Match shows case #123456789 with Client and NCP name as Silly Sally
The match came in on Silly Sally, who may be the CP/CU or child on Georgia’s case
Example of FCR Proactive Match screen showing Client and NCP names. The Case Date is the date the case was sent to the FCR by the other state, not when Georgia user received the prompt or the match.
Example of information received on the match. The response date is the date the match was received.
A CSI request can be submitted either through the FCR Match Information screen or through the CSENet Request screen. Delete the match if no CSI Request is needed.
For more information regarding the CSI function type, refer to the information beginning on page 27 in your training manual.
The Action-code, also required for each transaction, describes the kind of transaction. An example is using R to request information from another state and P to provide information to another state. There are 6 valid Action codes:
R-Request (initial requesting activity)
A-Acknowledgment of receipt of a Request
P-Provision of information/Response to a request
M-Reminder (used when a Response is overdue)
U-Update of a previously transmitted Request
C-Cancellation of a previously transmitted Request
After the other state has established a case on their system, do not use the “R” Action code on future ENF, PAT or EST transactions.
EST R SRORD sent to FL, Acknowledgement received from FL providing case number and requesting additional information. Georgia agent is uncertain what information is needed from FL and wants to ask a question. Do not send another EST R to ask the question; use MSC R instead. Using EST R again may cause FL to create another case.
Additional information concerning Action Codes can be found beginning on page 31 in your training manual.
The Reason code, which is not required for every transaction, provides further definition of the activity that the transaction communicates. CSENet allows only certain combinations of function, action and reason codes and will not allow invalid transactions to be processed. $TARS only provides Reason Code options that match both the Function and Action Codes.
The first two characters of the Reason code assist to quickly identify the nature of the transaction. Example: L as noted in LSADR reason code stands for Locate, S stands for Successful. When seeing the CSENet code in the case action log, you will readily know Successful Locate information is being sent.
Additional information concerning Reason Codes can be found beginning on page 37 in your training manual.
Data Blocks can be found on the VIEW ASSIGNED TRANSACTIONS screen. This is the screen that shows both outgoing and incoming transactions. To see information received, highlight the transaction; scroll to the bottom of the screen to the Data Block drop-down box; Acrobat Reader will open.
Each Data Block contains data elements that convey child support case information. The transaction type determines the required data blocks and elements.
Additional information concerning Data Blocks can be found beginning on page 38 in your training manual.
“ I ”
“ O ”
Incoming and Outgoing transactions on the VIEW ASSIGNED TRANSACTIONS screen - This is the screen that shows both outgoing and incoming transactions.
The screen provides the Functional Type, Action code and Reason Code, the date the information was received, the other state’s case number, other state’s FIPS code, the Reference (or transaction) number, the UIFSA code type and whether it is an Incoming (I) or Outgoing (O) transaction.
An Outgoing transaction will be replaced with an Incoming transaction when a response is received.
Function Codes: L01=Quick Locate; CSI=Case Status Information; ENF=Enforcement; MSC= Managing State Case; PAT=Paternity; EST=Establishment; COL=Collection
Action Codes: R=Request – an initiating transaction; A=Acknowledgement of receipt of request; P=Provision of information; M=Reminder – used when a response is overdue; U=Update of previously transmitted request; C=Cancel of previous request
1st ltr. of Reason Code: G=General; A=Acknowledgement; L=Locate; P=Paternity; S=Support Order; E=Enforcement; C=Collection; F=CSI
2nd ltr. of Reason Code: I=Information Only; R=Request; A=Acknowledgement; S=Successful Response (data for update); U=Unsuccessful (no useful data)
Case Information of each.
STATE REQUEST screen of each.
STATE REQUEST screen - Examples of when a request can be sent are sending UIFSA for the first time and requesting status updates.
This screen is used to send Requests for actions, Cancel previous actions or Remind the other state no response has been received.
State Request Screen Tips: of each.
For more information on the State Request feature, refer to the information beginning on page 9 in your training manual.
STATE RESPONSE screen of each.
STATE RESPONSE screen - The Response screen is used to provide information or to respond to a transaction received. All Functional Types can be used. The Action Code is based on the Functional Type and is limited to provide information (P), acknowledge receipt of a request (A) or update of a previously submitted transaction (U).
State Response Screen Tips: of each.
For more information on the State Response feature, refer to the information beginning on page 10 in your training manual.
CASE INFORMATION screen of each.
CASE INFORMATION screen - The Case Information screen provides basic information that is helpful when quickly reviewing a case. The UIFSA type, other state’s case number and other state’s FIPS code can be entered either on this screen or the Case Management Screen.
It is also a good location to enter the other state’s local office agent, address, phone number and email address. $TARS should automatically move the other state’s case number and worker information onto this screen when it received in a CSENet transaction. The Respond/Initiate, Document Received Indicator and Document Date fields are optional and were brought over from an old program.
VIEW ASSIGNED TRANSACTIONS screen of each.
VIEW ASSIGNED TRANSACTIONS screen - This is the screen that shows both outgoing and incoming transactions. An Outgoing transaction will be replaced with an Incoming transaction when a response is received.
The screen provides the Functional Type, Action code and Reason Code, the date the information was received, the other state’s case number, other state’s FIPS code, the Reference (or transaction) number, the UIFSA code type and whether it is an Incoming (I) or Outgoing (O) transaction. Any comments that are sent with the transaction by the other state’s user appears on this screen in the Transaction Comments field. To see information received, highlight the transaction; scroll to the bottom of the screen to the Data Block drop-down box; Acrobat Reader will open.
The user can also generate a response from the View screen by highlighting the transaction and clicking on the Generate Response button. $TARS will take you to the State Response screen and will pull over the other state’s case number, FIPS code and the CSENET transaction number. Use the appropriate function, action and reason codes. If an error code is received when using the Generate Response feature, remove the Transaction number.
ACROBAT READER of each.
To copy information from Acrobat Reader into $TARS, change the hand tool to Text by clicking on the T icon at the top of the screen. You can then copy and paste information into various $TARS fields. Print any pages as needed. To close out Acrobat Reader, click on the X at the right top of the screen.
Hint: Before copying and pasting new address and employer information, check to see if the same information has been received through a FPLS hit. It is easier to put the information into a sequence on Locate Management or Locate Employer than using the copy and paste feature here.
For more information regarding How To Use Acrobat Reader, refer to the GA OCSE website – staff only pages – manuals.
How do the pieces of the CSENet puzzle fit together?
Happy CSENetting to you all