TABLE OF CONTENTS 1. NEW VALUES FOR DEPENDENT-PATERNITY-STATUS FIELD (OCSE REF #202) 1.1 Summary of Changes 1.2 Background 1.3 Description of Changes 1.4 Impact on States 1.5 Pilot Testing 1.6 Resource Materials 2. CREATE NEW TRANSACTION TO SUPPORT FEDERAL TAX OFFSET TRANSMISSION NOTIFICATION (OCSE REF #296) 2.1 Summary of Changes 2.2 Background 2.3 Description of Changes 2.4 Impact on States 2.5 Pilot Testing 2.6 Resource Materials 3. CREATE NEW TRANSACTION TO SUPPORT CHANGE OF PAYEE (OCSE REF #298) 3.1 Summary of Changes 3.2 Background 3.3 Description of Changes 3.4 Impact on States 3.5 Pilot Testing 3.6 Resource Materials 4. CREATE NEW TRANSACTION TO SUPPORT REQUEST PATERNITY AND ESTABLISHMENT (OCSE REF #300) 4.1 Summary of Changes 4.2 Background 4.3 Description of Changes 4.4 Impact on States 4.5 Pilot Testing 4.6 Resource Materials 5. STATES CONVERSION TO CONNECT:Direct AT THE NCC (OCSE REF #308) 5.1 Summary of Changes 5.2 Background 5.3 Description of Changes 5.4 Impact on States 5.5 Migration and Deployment Process 5.6 Resource Materials APPENDICES CSENET DATA BLOCK RECORD LAYOUT – EXCERPT A.1 Transaction Structure A.2 CSENet 2000 Required Data Blocks and Data Elements A.3 Rules Governing the Editing of CSENet Transactions CONNECT:DIRECT PROCEDURES - EXCERPT

1. NEW VALUES FOR DEPENDENT-PATERNITY-STATUS FIELD (OCSE REF #202)

The Child Support Enforcement Network (CSENet) application is being modified to add new values for the Dependent-Paternity-Status field in the Order data block.

1.1 Summary of Changes

The valid values for the Dependent-Paternity-Status field are being expanded to identify the method by which paternity was established. This change will support the Uniform Interstate Family Support Act (UIFSA) standard forms.

1.2 Background

The Continuous Service Improvement (CSI) team identified gaps and proposed changes that were shared with State representatives during Interstate Communications Teleconferences on January 19, 2007 and March 15, 2007. Feedback was obtained, suggestions considered and proposed changes developed.

During the April 5, 2007 conference call with State representatives, a long list of CSENet enhancements compiled over several years was discussed, along with a shorter list of items identified by States as a priority. States were asked about their willingness and ability to make the changes. Some States expressed concern about limited programming resources and other priorities. Therefore, the group recommended reducing the number of changes to minimize State impact. As a result, several enhancements including new transactions and values were presented to State representatives on May 3, 2007. Four of these were subsequently approved by OCSE as high-priority items for inclusion in Release 08-02, based on several factors: requests by States, changes in requirements in the Code of Federal Regulations, enhancement of electronic communications, and electronic support of paper-based UIFSA forms.

1.3 Description of Changes

The valid values for the Dependent-Paternity-Status field are being expanded to identify whether paternity has been established and specifically the method by which paternity was established. The modification will allow for additional values other than the current value of Y indicating "Paternity status determined".

• Existing Values:
• N (or blank) - Paternity status not determined
• Y- Paternity status determined
• New Values:
1. Born in Wedlock
2. Paternity established through genetic testing
3. Paternity not an issue (adoption)
4. Paternity established judicially (order)
5. Paternity established through acknowledgement
6. Other

The following current error code remains in effect:

• E567, "Invalid Dependent Paternity Status".

All current requirements for the Dependent-Paternity-Status field remain in effect.

Although the Information data block is not required, it is recommended that the Information data block be included in the transaction when the value '6' is chosen for the Dependent-Paternity-Status field, to provide information about how paternity was established.

1.4 Impact on States

If States make all the changes necessary to comply with the expanded valid values for the Dependent-Paternity-Status field, there should be no impact. However, States that do not program the new valid paternity values may experience an impact with incoming new values and how they are processed. States that do not program for the new values may have existing edits that reject the values. If this is the case, the data may not be received and stored.

The software is being implemented on October 3, 2008 in time for the afternoon cycle.

1.5 Pilot Testing

States may elect to participate in pilot testing from September 15 to September 26, 2008 to verify system programming. Pilot testing provides States an opportunity to exchange transactions via test data sets with:

• the CSENet Application using FIPS code 9100000,
• other States participating in pilot testing, or
• their own system through "loopback" testing.

States may also elect to test receiving transactions from the CSENet Testdeck application.

CSENet technical representatives will be available to provide analysis and feedback concerning test transactions during the September 15 to September 26, 2008 timeframe. State representatives should contact their CSENet technical representative or the CSENet Service Desk at:

Call 800.258.2736 or CSENet.2000@lmco.com to participate.

1.6 Resource Materials

Appendix A, "CSENET Data Block Record Layout - Excerpt", contains detailed descriptions of the changes resulting from Release 08-02.

The CSENet 2000 Interface Guidance Document (IGD) can be viewed on the OCSE Website at: http://www.acf.hhs.gov/programs/cse/newhire/csenet/library/csenet2000/csenet2000.htm. The Data Block Record Layout (Version 7.0) is Appendix C, and the Transaction Error Codes and Messages (Version 7.0) is Appendix E of the IGD. These appendices will be updated in the future to reflect the changes from this release.

Table of Contents

2. CREATE NEW TRANSACTION TO SUPPORT FEDERAL TAX OFFSET TRANSMISSION NOTIFICATION (OCSE REF #296)

2.1 Summary of Changes

The COL P CISUB is being added to the CSENet application to provide States the ability to send and receive a notification that an interstate case has been submitted for Federal tax offset. This activity is not currently supported in CSENet with a unique transaction, and it corresponds directly to the requirements in Code of Federal Regulations 45CFR 303.72(d) (1).

This new transaction facilitates the ability to electronically generate a required notification.

2.2 Background

Identified gaps and proposed changes were shared and discussed with State representatives during Interstate Communications Teleconferences on January 19, 2007 and March 15, 2007. Feedback was obtained, suggestions considered, and proposed changes developed.

During the April 5, 2007 conference call with State representatives, a long list of CSENet enhancements compiled over several years was discussed, along with a shorter list of items identified by States as a priority. States were asked about their willingness and ability to make the changes. Some States expressed concern about limited programming resources and other priorities. Therefore, the group recommended reducing the number of changes to minimize State impact. As a result, several enhancements including new transactions and new values were presented to State representatives on May 3, 2007. Four of these were subsequently approved by OCSE as high-priority items for inclusion in Release 08-02, based on several factors: requests by States, changes in requirements in the CFR, enhancement of electronic communications, and electronic support of paper-based UIFSA forms.

2.3 Description of Changes

This enhancement adds a new transaction, COL P CISUB, to support the Code of Federal Regulations (CFR) 45CFR 303.72(d)(1):

"Notification of changes in case status. (1) The State referring past-due support for offset must, in interstate situations, notify any other State involved in enforcing the support order when it submits an interstate case for offset."

This new COL P transaction requires Header, Case, and NCP_ID data blocks. Because of the nature of this transaction, the Collection data block is not required. The transaction has the following requirements:

• The Header data block should be formatted according to current requirements and must contain CISUB in the Action-Reason field.

All current requirements remain in effect for all data blocks included in this transaction, with the addition of the new requirement.

2.4 Impact on States

To send this new transaction, States need to add CISUB as a Reason code for the COL P to their CSE systems. States should also be prepared to receive transactions with this code. To exchange this transaction, States must have open exchange agreements for the COL Function code with their partners. To enable or expand exchange agreements, State representatives should contact their CSENet 2000 technical representative or the CSENet Service Desk.

States using the COL P CISUB transaction will be in compliance with AT-04-08 (November 5, 2004) from OCSE requiring that the State referring past-due support for offset must, in interstate situations, notify any other State involved in enforcing the support order when it submits an interstate case for offset.

The software is being implemented on October 3, 2008, in time for the afternoon cycle.

2.5 Pilot Testing

States may elect to participate in pilot testing from September 15 to September 26, 2008 to verify system programming. Pilot testing provides States an opportunity to exchange transactions via test data sets with:

• the CSENet application using FIPS code 9100000,
• other States participating in pilot testing, or
• their own system through "loopback" testing.

States may also elect to test receiving transactions from the CSENet Testdeck application.

CSENet technical representatives will be available to provide analysis and feedback concerning test transactions during the September 15 to September 26, 2008 timeframe. State representatives should contact their CSENet technical representative or the CSENet Service Desk at: 800.258.2736 or CSENet.2000@lmco.com to participate.

2.6 Resource Materials

For more detailed information on the Header record and Information data block, see Appendix A, "CSENET Data Block Record Layout - Excerpt". This appendix contains changes resulting from Release 08-02.

The CSENet 2000 Interface Guidance Document (IGD) can be viewed on the OCSE Website at: http://www.acf.hhs.gov/programs/cse/newhire/csenet/library/csenet2000/csenet2000.htm. The Data Block Record Layout (Version 7.0) is Appendix C, and the Transaction Error Codes and Messages (Version 7.0) is Appendix E of the IGD. These appendices are to be updated in the future to reflect the changes from this release.

Table of Contents

3. CREATE NEW TRANSACTION TO SUPPORT CHANGE OF PAYEE (OCSE REF #298)

The Child Support Enforcement Network (CSENet) 2000 application is being modified to support a new request (R) transaction for the Managing State Cases (MSC) Function code for a change of payee.

3.1 Summary of Changes

The MSC R GRPAY transaction is being added to the CSENet Application to provide States the ability to send and receive a request for a change of payee. This activity, which is not currently supported in CSENet with a unique request transaction, corresponds directly to an action found in Transmittal #1 - Initial Request and Transmittal #2 - Subsequent Actions of the Intergovernmental (UIFSA) forms.

This new transaction promotes electronic, standardized interstate communications.

3.2 Background

Identified gaps and proposed changes were shared and discussed with State representatives during Interstate Communications Teleconferences on January 19, 2007 and March 15, 2007. Feedback was obtained, suggestions considered, and proposed changes developed.

During the April 5, 2007, conference call with State representatives, a long list of CSENet enhancements compiled over several years was discussed along with a shorter list of items identified by States as a priority. States were asked about their willingness and ability to make the changes. Some States expressed concern about limited programming resources and other priorities. Therefore the group recommended reducing the number of changes to minimize State impact. As a result, several enhancements including new transactions and values were presented to State representatives on May 3, 2007. Four of these were subsequently approved by OCSE as high-priority items for inclusion in Release 08-02, based on several factors: requests by States, changes in requirements in the CFR, enhancement of electronic communications, and electronic support of paper-based UIFSA forms.

3.3 Description of Changes

This enhancement adds a new transaction, MSC R GRPAY, to support the electronic communication of the current interstate business conveyed by the UIFSA forms.

This new MSC R transaction requires Header, Case, NCP_ID, and at least two Participant data blocks, with the following requirements:

• The Header data block should be formatted according to current requirements and must contain GRPAY in the Action-Reason field.
• The Case data block requires the Payment-Mail-Address-Line-1 field to be filled.
• One Participant data block requires a 'C' indicating custodial party in the Relationship field.
• The second Participant data block requires a 'D' indicating dependent in the Relationship field.

All current requirements remain in effect for all data blocks included in this transaction, in addition to the new requirements.

No new error codes and messages will be generated as a result of using this new transaction.

3.4 Impact on States

To send this new transaction, States need to add GRPAY as a Reason code for the MSC R to their CSE systems. States should also be prepared to receive transactions with this code. To exchange this transaction, States must have open exchange agreements for the MSC Function code with their partners. To enable or expand exchange agreements, State representatives should contact their CSENet 2000 technical representative or the CSENet Service Desk.

Using the MSC R GRPAY transaction supports the electronic communication of the current interstate business conveyed by the UIFSA forms.

The software is being implemented on October 3, 2008, in time for the afternoon cycle.

3.5 Pilot Testing

States may elect to participate in pilot testing from September 15 to September 26, 2008, to verify system programming. Pilot testing provides States an opportunity to exchange transactions via test data sets with:

• the CSENet application using FIPS code 9100000,
• other States participating in pilot testing, or
• their own system through "loopback" testing.

States may also elect to test receiving transactions from the CSENet Testdeck application.

CSENet technical representatives will be available to provide analysis and feedback concerning test transactions during the September 15 to September 26, 2008 timeframe. State representatives should contact their CSENet technical representative or the CSENet Service Desk at: 800.258.2736 or CSENet.2000@lmco.com to participate.

3.6 Resource Materials

For more detailed information on this transaction, see Appendix A of this document. This appendix is an excerpt of the CSENet Data Block Record Layout that contains changes resulting from Release 08-02.

The CSENet 2000 Interface Guidance Document (IGD) can be viewed on the OCSE Website at: http://www.acf.hhs.gov/programs/cse/newhire/csenet/library/csenet2000/csenet2000.htm. The Data Block Record Layout (Version 7.0) is Appendix C, and the Transaction Error Codes and Messages (Version 7.0) is Appendix E of the IGD. These appendices are to be updated in the future to reflect the changes from this release.

Table of Contents

4. CREATE NEW TRANSACTION TO SUPPORT REQUEST PATERNITY AND ESTABLISHMENT (OCSE REF #300)

The Child Support Enforcement Network (CSENet) 2000 application is being modified to support a new request (R) transaction for the Establishment (EST) Function code to request both paternity establishment and order establishment simultaneously.

4.1 Summary of Changes

The EST R SRPAT is being added to the CSENet application to provide States the ability to send and receive a single transaction to request the establishment of both paternity and support. This is the most frequently requested combination of multiple actions. Currently CSENet supports two separate transactions, one to request the establishment of paternity and the other to request the establishment of a support order.

This new transaction better meets the interstate business needs and promotes electronic, standardized interstate communications.

4.2 Background

Identified gaps and proposed changes were shared and discussed with State representatives during Interstate Communications Teleconferences on January 19, 2007 and March 15, 2007. Feedback was obtained, suggestions considered, and proposed changes developed.

During the April 5, 2007 conference call with State representatives, a long list of CSENet enhancements compiled over several years was discussed, along with a shorter list of items identified by States as a priority. States were asked about their willingness and ability to make the changes. Some States expressed concern about limited programming resources and other priorities. Therefore the group recommended reducing the number of changes to minimize State impact. As a result, several enhancements including new transactions and values were presented to State representatives on May 3, 2007. Four of these were subsequently approved by OCSE as high-priority items for inclusion in Release 08-02, based on several factors: requests by States, changes in requirements in the CFR, enhancement of electronic communications, and electronic support of paper-based UIFSA forms.

4.3 Description of Changes

This enhancement adds a new transaction, EST R SRPAT, to provide States the ability to send and receive a single request transaction requesting the establishment of both paternity and support.

This new EST R transaction requires Header, Case, NCP-ID, NCP-Locate, and at least two Participant data blocks, with the following requirements:

• The Header data block should be formatted according to current requirements and must contain SRPAT in the Action-Reason field.
• One Participant data block requires a 'C' indicating custodial party in the Relationship field.
• The second Participant data block requires a 'D' indicating dependent in the Relationship field.

All current requirements remain in effect for all data blocks included in this transaction, in addition to the new requirements.

No new error codes and messages will be generated as a result of using this new transaction.

4.4 Impact on States

To send this new transaction, States need to add SRPAT as a Reason code for the EST R to their CSE systems. States should also be prepared to receive transactions with this code. To exchange this transaction, States must have open exchange agreements for the EST Function code with their partners. To enable or expand exchange agreements, State representatives should contact their CSENet 2000 technical representative or the CSENet Service Desk.

Using the EST R SRPAT transaction supports the electronic communication of the current interstate business conveyed by the UIFSA forms.

The software is being implemented on October 3, 2008, in time for the afternoon cycle.

4.5 Pilot Testing

States may elect to participate in pilot testing from September 15 to September 26, 2008, to verify system programming. Pilot testing provides States an opportunity to exchange transactions via test data sets with:

• the CSENet application using FIPS code 9100000,
• other States participating in pilot testing, or
• their own system through "loopback" testing.

States may also elect to test receiving transactions from the CSENet Testdeck application.

CSENet technical representatives will be available to provide analysis and feedback concerning test transactions during the September 15 to September 26, 2008 timeframe. State representatives should contact their CSENet technical representative or the CSENet Service Desk at: 800.258.2736 or CSENet.2000@lmco.com to participate.

4.6 Resource Materials

For more detailed information, see Appendix A of this document. This appendix is an excerpt of the CSENet Data Block Record Layout that contains changes resulting from Release 08-02.

The CSENet 2000 Interface Guidance Document (IGD) can be viewed on the OCSE Website at: http://www.acf.hhs.gov/programs/cse/newhire/csenet/library/csenet2000/csenet2000.htm. The Data Block Record Layout (Version 7.0) is Appendix C, and the Transaction Error Codes and Messages (Version 7.0) is Appendix E of the IGD. These appendices will be updated in the future to reflect the changes from this release.

Table of Contents

5. STATES CONVERSION TO CONNECT:Direct AT THE NCC (OCSE REF #308)

The Child Support Enforcement (CSENet 2000) application is now being hosted at the Social Security Administration's National Computing Center (NCC) in Woodlawn, MD, along with most of the other federal applications, such as the Federal Case Registry (FCR) and the National Directory of New Hires (NDNH). OCSE is now prepared to have States begin exchanging CSENet files directly with the NCC using CONNECT:Direct with Secure+ (C:D). This project supports States' conversion from CSENet file transfers across the OCSE Network to C:D with the NCC.

5.1 Summary of Changes

The transmission method of transferring CSENet transaction data to and from the States will be changed. The current method of transmission is across the OCSE Network. The new method of transmission will be by C:D directly with the NCC.

This new transaction better meets the interstate business needs and promotes electronic, standardized interstate communications.

5.2 Background

Since 1999, State Child Support Enforcement agencies (CSE) have been using the CSENet application to exchange interstate case data and the OCSE Network to exchange those data files.

As part of OCSE's on-going effort to improve its child support services and infrastructure, a decision was made to consolidate Federal applications and supporting communication methods to the NCC. As of January 2008 the CSENet application is hosted at the NCC and was moved into production in March 2008. The application now processes all CSENet files from the NCC.

OCSE is beginning the conversion process wherein States will send CSENet files across C:D to the NCC and cease using the OCSE Network. All States will be migrated to C:D within the next two years.

5.3 Description of Changes

Currently States transmit CSENet transactions across the private OCSE Network.

Each State will be required to change its transmission procedures for CSENet transactions to mirror the processing executed for FCR data transfers directly with the NCC.

Each State currently has a direct connection with the NCC where FCR and NDNH transmissions are executed utilizing C:D.

CSENet data files, picked up from the States, will be stored in EBCDIC format at the NCC regardless of the source format at the State. States will submit a C:D request process for C:D to pick up CSENet transaction data files. To be picked up, the CSENet transaction data files will continue to be in their current format (both layout and structure). Unique C:D processes will be created for each State for each file type the State sends.

CSENet data files, sent from the NCC to the States, will be sent in the format required for storage at the State (EBCDIC or ASCII as requested by the State). CSENet data files will be sent to the State upon completion of processing at the NCC and not necessarily specifically at the 4:00 AM and 4:00 PM timeframe as is current. State's current participation in AM and PM groupings will be maintained and efforts will be made to deliver files by the 4:00 AM and 4:00 PM timeframe. However, if data files are ready earlier, they will be delivered at that time. CSENet data files, sent from the NCC to the States, will be formatted with their current logical record length (LRECL) file type.

5.4 Impact on States

The State will be responsible for any procedural changes necessary to move the CSENet transmission files from their current location to the location where the C:D connection with the NCC resides.

The State will be responsible for the development of the C:D processes necessary to request pick-up and to receive the CSENet data files at their location.

There are no changes to the content or format of the CSENet transmission files, only the method and location of their transfer. There are no changes to the functionality of the CSENet application necessary to support this communication conversion.

5.5 Migration and Deployment Process

Each State must develop and test a new process, or modify an existing process, to move the CSENet transaction files to and from the existing C:D communication point with the NCC.

The content of the CSENet transaction files is not changing; only the file transmission method is changing. Therefore, the same number of files will be exchanged as with the current method. The only difference in the number of files exchanged is that States that do not currently participate in State-to-State testing are encouraged to code for the handling of this function. The content and format of data files will not change. Instructions for interaction with the C:D team at the NCC are included in Appendix A.

During the migration process, States are expected to:

1. Identify key staff to coordinate this process and resources within the State to accomplish the conversion;
2. Set up a process to move files from the current CSENet location to the C:D transmission site;
3. Create automated, repeatable and scheduled file pick-up request and retrieval processes similar to what is used for FCR file transmissions;
4. Work with the NCC C:D team to test the transmission process with the NCC for connectivity and C:D configuration;
5. Coordinate efforts with the OCSE/FPLS team to test the transmission process through the CSENet application for compatibility; and
6. Perform the final cutover to C:D

Initially five States began the conversion of CSENet files to the C:D transmission method in March 2008. This pilot effort is targeted for completion by June 2008. A schedule is being developed for the conversion of all States and will be available by mid-Summer 2008.

For further information or other questions, contact your CSENet technical representative or the Service Desk at 800.258.2736. E-mails may be directed to: CSENet.2000@lmco.com to participate.

5.6 Resource Materials

For more detailed information, see Appendix B, "CONNECT:Direct Procedures - Excerpt", procedures authored by the CONNECT:Direct Team for the SSA at the NCC in Woodlawn, MD.

Table of Contents

---

APPENDICES

A. CSENET DATA BLOCK RECORD LAYOUT - EXCERPT

This appendix provides data layouts, field definitions and requirements necessary for the establishment of CSENet 2000 functionality on State CSE systems.

Each layout contains the following information:

Rules

Denotes the rules that govern the editing of each field

Field Name

Identifies the name of the data element

Location

Identifies the position within the data block that the element is located

Length

Identifies, in bytes, the size of the element

A/N

Designates the type of format that applies to the element

Comments

Provides a description of the data element, requirements associated with the element as well as the values that are relevant to the field

The material that is highlighted in turquoise indicates a change to existing information.

For further assistance during the programming of CSENet 2000 on the State CSE system, refer to the CSENet IGD, Appendix A, "Data Dictionary", and Appendix B, "Valid Transactions Table".

For additional information regarding the structure of CSENet transactions, refer to the CSENet IGD, Part 5, "CSENet Transaction Structure".

Table of Contents

A.1 Transaction Structure

Every transaction is a single string of data terminated with a new line character. When a transaction is sent, the actual location (position) of each data field after the transaction header differs depending on the number of data blocks transmitted.

When transmitting CSENet 2000 transactions, the first data block must contain the Transaction Header. The header provides information about the source and destination of the transaction, the case IDs to which the transaction refers and indicators showing the number of data blocks. Data blocks containing case data transmitted from one State to another may follow the header. Although not every data block will appear in every transaction, the data blocks must appear in the order depicted in to the CSENet IGD, Chart C-1.

The minimum number of data blocks that must be transmitted depends on the type of transaction being sent to the CSENet IGD. Chart C-2 identifies the required data blocks for each CSENet 2000 transaction. The combination of Functional Type and Action codes determines the data blocks that are required for a CSENet 2000 transaction to the CSENet IGD. Chart C-1 describes the data blocks and shows the maximum number that can be attached to a single transaction.

CHART A-1: DATA BLOCK RECORD LAYOUTS ACCEPTED BY CSENET 2000

Data Block Name	Maximum Number of Data Blocks	Data Block Purpose
Transaction Header	1 - (Sent to the CSENet 2000 server) 1 - (Sent from the CSENet 2000 server)	Provides information regarding the source, destination, and content of a CSENet 2000 transaction
Case	1	General case information, contact, and payment address
Noncustodial Parent Identification (NCP-ID)	1	Physical description of noncustodial parent or alleged father
Noncustodial Parent (NCP) Locate	1	Location and employer information about the noncustodial parent or alleged father
Participant	9	Information about other people involved in the case. Relationship field indicates the relationship of each person in the case (custodial party, dependent, etc.).
Order	9	Support or paternity order information
Collection	9	Information about money collected
Information	1	General text information

Table of Contents

A.2 CSENet 2000 Required Data Blocks and Data Elements

The Header data block is always required and must be the first data block in each transaction. Additional data block requirements are determined by the combination of Functional Type, Action, and Action-Reason codes (located in the Header).

The Comments section of the data block layout indicates whether an element is required or conditionally required for a particular data block. Where the information is required or conditionally required, the State Child Support Enforcement (CSE) system must provide the appropriate information. If the field is not identified as required in the Comments section of the data block layout, the particular element is optional. If the optional information is provided by the CSE system, then the appropriate edits and rules for that field type will be enforced by the CSENet 2000 application. Also provided in the Comments section are the valid values (if any) for each data element, an explanation of the field and its relationship to other fields within the data block or record.

The CSENet IGD, Chart C-2 illustrates the data block requirements for CSENet 2000 transactions with Action codes of 'R', 'U' and 'P'.

Note: Transactions with Action codes of 'A', 'C' or 'M' require only the Header data block unless any of the data block indicators are set to one or greater, or if the Attachments Indicator is 'Y'. For definitions of Action codes, refer to the CSENet IGD, Appendix B, "Valid Transactions Table".

CHART A-2: CSENET 2000 REQUIRED DATA BLOCKS

Data Block Name	Requests and Updates, Action Codes R and U						Responses, Action Code P
	LO1	CSI	EST	ENF	PAT	MSC	LO1	CSI	EST	ENF	PAT	MSC	COL
Transaction Header	R	R	R	R	R	R	R	R	R	R	R	R	R
Case	R		R	R	R	I	R	A	R	R	R	D	R
Non-Custodial Parent Identification (NCP-ID)	R		R	R	R	I	R		R	R	R		G
NCP Locate			R	R	R		A
Participant			B	B	B	H		A
Order				R
Collection													F
Information	C	C	C	C	C	C	C	C	C	C	C	E	C

KEY

R	The data block is always required.
Blank	Non-required data block
A	These data blocks are required if the response is successful, i.e., the second character of the Action-Reason code is 'S'.
B	The CSENet 2000 application requires at least two participant data blocks on these transactions: one with the Relationship field containing a code of 'C', indicating a custodial party, and at least one with a Relationship code of 'D', indicating a dependent.
C	If the Attachments Indicator in the Transaction Header is Y, the CSENet 2000 application requires an Information data block. This is used to list the attachments being sent. This rule applies to every transaction (including those with Action codes of 'A', 'C' and 'M').
D	Required, except for MSC P REJCT
E	Required for the MSC P REJCT and MSC GSCAS
F	Required, except for COL P CISUB
G	Date of Tax Offset Submission is not numeric
H	Required for MSC R GRPAY. The CSENet 2000 application requires at least two Participant data blocks on these transactions: one with the Relationship field containing a code of 'C', indicating a custodial party, and at least one with a Relationship code of 'D', indicating a dependent.
I	Required for MSC R GRPAY.

Table of Contents

A.3 Rules Governing the Editing of CSENet Transactions

The rules listed below are applicable to all CSENet 2000 transactions. The rules are located in the first column of each data block layout.

Data transmitted to CSENet 2000 application must comply with the following requirements:

1. All data must be in ASCII format.
2. All alphanumeric data must be in upper case.
3. All alphanumeric data must be left justified.
4. All unused fields must be left blank (blank-filled).
5. For numeric data:
• All dates must be in the Year 2000-compliant format of CCYYMMDD. Acceptable date ranges are 1900-2099.
• Dollar amounts are in the format +99999999.99. If used, the amount must be right justified and zero filled to the left. If unused, the field must be blank-filled. If negative, the minus (-) character must appear in the first position of the field. If positive, the plus (+) character (or blank fill) must be in the first position ¹ of the field. Zero may be an acceptable amount (where noted in the comments section of the record layout).
• Fields such as weight, telephone numbers, and Zip1 and Zip2, if used, must be filled with valid numbers between 0 9 inclusive. (The fields noted above must be filled with legitimate data.) If unused, the field must be blank-filled. Note: Zip1 field(s), if used must not be repetitive unless the value is 22222, 44444, or 55555.

Note: The following abbreviations are used in the A/N (Field Type) column:

• 'N' denotes the element is Numeric.
• 'A/N' denotes the element is Alphanumeric.

---

¹ If blank-filled in the first position of the field, the State CSE System should read as positive. For zero amounts, the following will pass the edits: +00000000.00, space, 00000000.00, and –00000000.00.

---

CHART A-3: CSENet 2000 DATA BLOCK TRANSACTION HEADER RECORD FOR TRANSACTIONS SENT TO THE OCSE SERVER

Rules	Field Name	Location	Length	A/N	Comments
1	Local-FIPS-State	1-2	2	N	Required The Local-FIPS-State must contain valid FIPS codes based on the jurisdiction table downloaded from the IRG. This always refers to the first two digits of your FIPS code. The CSENet 2000 application will convert the Local-FIPS-State and Other-FIPS-State on incoming transactions to keep the appropriate point of reference. You must have communications enabled for the specific Functional-Type-Code with the state with which you are communicating. The exchange of information agreement must be established in the FIPS Communication Matrix in the CSENet 2000 application.
1	Local-FIPS-County	3-5	3	N	Required The Local-FIPS-County must contain valid FIPS codes based on the jurisdiction table downloaded from the IRG. This always refers to the 3rd, 4th, and 5th digits of the state with which you are communicating. The CSENet 2000 application will convert the Local-FIPS-County and Other-FIPS-County on incoming transactions to keep the appropriate point of reference. You must have communications enabled for the specific Functional-Type-Code with the state with which you are communicating. The exchange of information agreement must be established in the FIPS Communication Matrix in the CSENet 2000 application.
1,2,3,4	Local-FIPS-Sub	6-7	2	A/N	The value of the Local-FIPS-Sub portion of the FIPS code will not be edited.
1	Other-FIPS-State	8-9	2	N	Required The Other-FIPS-State must contain valid FIPS codes based on the jurisdiction table downloaded from the IRG. This always refers to the first two digits of the state with which you are communicating. The CSENet 2000 application will convert the Local-FIPS-State and Other-FIPS-State on incoming transactions to keep the appropriate point of reference. You must have communications enabled for the specific Functional-Type-Code with the state with which you are communicating. The exchange of information agreement must be established in the FIPS Communication Matrix in the CSENet 2000 application.
1	Other-FIPS-County	10-12	3	N	Required The Other-FIPS-County must contain valid FIPS codes based on the jurisdiction table downloaded from the IRG. This always refers to the 3rd, 4th, and 5th digits of the state with which you are communicating. The CSENet 2000 application will convert the Local-FIPS-County and Other-FIPS-County on incoming transactions to keep the appropriate point of reference. You must have communications enabled for the specific Functional-Type-Code with the state with which you are communicating. The exchange of information agreement must be established in the FIPS Communication Matrix in the CSENet 2000 application.
1,2,3,4	Other-FIPS-Sub	13-14	2	A/N	The value of the Local-FIPS-Sub portion of the FIPS code will not be edited.
1	CSENet 2000-Version-Number	15-17	3	N	Required Valid value for this field is: 003 States must fill with the CSENet 2000 version number '003'.
1	Transaction-Serial-Number	18-29	12	N	Required Valid values for this field are: '1' or greater The value must be right justified and zero filled to the left. This is a unique sequential number assigned to each transaction and it must be generated by the state CSE system. Can be used to prevent the sending and/or processing of duplicate transactions.
1,4	Error-Reason-Code	30-31	2	A/N	This field is reserved for a future version. For the current version, this field must be blank-filled.
1,4	Transaction-Type	32-33	2	A/N	This field is reserved for a future version. For the current version, this field must be blank-filled.
1,2,3	Action-Code	34	1	A/N	Required Must contain a valid Action code. Describes the action requested by the other state. Valid values for this field are: R - Request (an initiating transaction) A - Acknowledgment (Acknowledgment of receipt of request) P - Provision (Provision of information) M - Reminder (Used when a response is overdue) U - Update (Update of previously transmitted request) C - Cancel (Cancellation of previous request)
1,2	Functional-Type-Code	35-37	3	A/N	Required Must contain a valid Functional Type code. Indicates the child support business function. Valid values for this field are: LO1 - Quick Locate CSI - Case Status Information ENF - Enforcement MSC - Managing State Cases (formerly Miscellaneous) PAT- Paternity Establishment EST- Order Establishment COL - Collection
1,5a	Transaction-Date	38-45	8	N	Required The date the transaction was generated. Date must not be greater than the current date.
1,2,3,4	Case-ID	46-60	15	A/N	Required The Case ID used by your jurisdiction. Required for all transactions except LO1 Responses and L01 Acknowledgments. The CSENet 2000 application will convert the Case-ID and the Other-Case-ID on incoming transactions to keep the appropriate point of reference. The following criteria apply to this field: First position must not be a space. Must not contain all zeros. Must not contain an asterisk (*) or backslash (\) in any position. Must not contain a combination of spaces and zeros.
1,2,3,4	Other-Case-ID	61-75	15	A/N	Required The Case ID used by the sending jurisdiction with which you are communicating. Required for Responses, Acknowledgments and CSI transactions except for CSI P RINIT and CSI P RRESP. The CSENet 2000 application will convert the Case-ID and the Other-Case-ID on incoming transactions to keep the appropriate point of reference. The following criteria apply to this field: First position must not be a space. Must not contain all zeros. Must not contain an asterisk (*) or backslash (\) in any position. Must not contain a combination of spaces and zeros.
1,2,3,4	Action-Reason	76-80	5	A/N	Required Required for CSI transactions. If used, must be in conjunction with Action and Functional Type codes pursuant to the Valid Transactions document.
1,4,5a	Action-Resolution-Date	81-88	8	N	This field should be used in conjunction with certain Action-Reason codes to indicate the date on which an event occurs.
1,2	Attachments-Ind.	89	1	A/N	Required Indicates whether attachments will accompany this transaction. Valid values for this field are: Y - Yes N - No If this is set to 'Y', then an Information data block must be included. The Information data block should list the attachments being sent.
1	Case-Data-Ind.	90	1	N	Required Indicates whether a Case data block is included in this transaction. Valid values for this field are: 0 - Case data block is not included in this transaction 1 - Case data block is included in this transaction This indicator can be '0' or '1' for all transactions with an Action code equal to 'A', 'C', or 'M', MSC Request, MSC Updates, CSI Request and MSC P REJCT. For CSI Responses, this indicator must be '1' if the second character of the Action-Reason code is 'S'. This indicator must '1' for MSC R GRPAY This indicator must be filled with '1' for all other transaction.
1	NCP-Identification-Ind.	91	1	N	Required Indicates whether an NCP Identification data block is included in this transaction. Valid values for this field are: 0 - NCP Identification data block is not included in this transaction 1 - NCP Identification data block is included in this transaction This indicator can be '0' or '1' for all transactions with an Action code equal to 'A', 'C', or 'M' and COL, MSC and CSI transactions. This indicator must be '1' for MSC R GRPAY and COL P CISUB. This indicator must be '1' for all other transactions.
1	NCP-Locate-Data-Ind.	92	1	N	Required Indicates whether an NCP Locate data block is included in this transaction. Valid values for this field are: 0 - NCP Locate data block is not included in this transaction 1- NCP Locate data block is included in this transaction This indicator must be set to '1' for PAT, EST, ENF Requests and Updates. This indicator must be set to '1' for LO1 Responses if the second character of the Action-Reason code is S. This indicator can be '0' or '1' for COL, MSC, CSI transactions. Note: This indicator can be '0' or '1' for PAT, EST and ENF Responses.
1	Participant-Data-Ind.	93	1	N	Required Indicates the number of Participant data blocks included in this transaction. Valid values for this field are: 0 - Participant data block is not included in this transaction 1 - One Participant data block is included in this transaction 2 - Two Participant data blocks are included in this transaction 3 - Three Participant data blocks are included in this transaction 4 - Four Participant data blocks are included in this transaction 5 - Five Participant data blocks are included in this transaction 6 - Six Participant data blocks are included in this transaction 7 - Seven Participant data blocks are included in this transaction 8 - Eight Participant data blocks are included in this transaction 9 - Nine Participant data blocks are included in this transaction This indicator must be set to '2' or greater for PAT, EST, ENF Requests and Updates and MSC R GRPAY. These transactions require a minimum of two Participant data blocks: one containing the custodial party's information, and at least one additional Participant data block containing dependent information. This indicator must be at least '1', and may be '2-'9' for CSI Responses if the 2nd character of the Action-Reason Code is 'S'.
1	Order-Data-Ind.	94	1	N	Required Indicates the number of Order data blocks included in this transaction. Valid values for this field are: 0 - Order data block is not included in this transaction 1 - One Order data block is included in this transaction 2 - Two Order data blocks are included in this transaction 3 - Three Order data blocks are included in this transaction 4 - Four Order data blocks are included in this transaction 5 - Five Order data blocks are included in this transaction 6 - Six Order data blocks are included in this transaction 7 - Seven Order data blocks are included in this transaction 8 - Eight Order data blocks are included in this transaction 9 - Nine Order data blocks are included in this transaction This indicator must be '1' or greater for ENF Requests or Updates.
1	Collection-Data-Ind.	95	1	N	Required Indicates the number of Collection data blocks included in this transaction. Valid values for this field are: 0 - Collection data block is not included in this transaction 1 -One Collection data block is included in this transaction 2 - Two Collection data blocks are included in this transaction 3 - Three Collection data blocks are included in this transaction 4 - Four Collection data blocks are included in this transaction 5 - Five Collection data blocks are included in this transaction 6 - Six Collection data blocks are included in this transaction 7 - Seven Collection data blocks are included in this transaction 8 - Eight Collection data blocks are included in this transaction 9 - Nine Collection data blocks are included in this transaction Note: This indicator must be '1' or greater for COL Responses except for COL P CISUB.
1	Information-Ind.	96	1	N	Required Indicates whether an Information data block is included in this transaction. Valid values for this transaction are: 0 - Information data block is not included in this transaction 1 - One Information data block is included in this transaction If the Attachments-Ind. is 'Y', this field must be set to '1'. For MSC P REJCT and MSC P GSCAS this field must be set to 1.
1,4,5a	Sent-Date	97-104	8	N	This field may be filled by the State CSE system with the date the transaction was generated or sent.
1,4,5a	Sent-Date	105-110	6	N	This field may be filled by the State CSE system, with the time the transaction was generated or sent. If used, the time must be in the military format of HHMMSS.
1,,4	Due-Date	111-118	8	N	This field is reserved for a future version. For the current version, this field must be blank-filled.
1,4	Response-Date	119-126	8	N	This field is reserved for a future version. For the current version, this field must be blank-filled.
1	Overdue-Ind	127	1	N	Required This field is used to indicate that a response is overdue. This field must be filled with 0.

Table of Contents

CHART A-4: CSENet 2000 CASE DATA BLOCK RECORD

Rules	Field Name	Location	Length	A/N	Comments
1,2	Case-Type	1	1	A/N	Required Type of case in your state. Valid values for this field are: A - TANF N - Non-TANF * Obsolete F - Foster Care R - TANF Arrears Only * Obsolete C - Foster Care Arrears Only * Obsolete V - Non IV-D M - Medical Care S - Former Assistance T - Never Assistance *These case types are considered obsolete pursuant to modifications identified in the FPLS Release 01-01 Manifest Minor in support of changes in the Uniform Interstate Family Support Act (UIFSA) forms and implemented in November 2001.
1,2	Case-Status	2	1	A/N	Required Indicates whether a case is open in your state. Valid values for this field are: O - Open C - Closed
1,2,3,4	Payment-Mail-Address-Line 1	3-27	25	A/N	Required Address to which payments are mailed. Required for EST, ENF Requests and Update transactions. It is also required for MSC R GRPAY.
1,2,3,4	Payment-Mail-Address-Line 2	28-52	25	A/N	Address to which payments are mailed.
1,2,3,4	Payment-City	53-70	18	A/N	City for payment address.
1,2,3,4	Payment-State	71-72	2	A/N	State for payment address. Must be a valid two-character State abbreviation. (See Appendix A for listing.)
1,4,5c	Payment-Zip-1	73-77	5	N	Five-digit Zip code for payment address.
1,4,5c	Payment-Zip-2	78-81	4	N	Four-digit Zip code for payment address.
1,2,3,4	Contact-Name-Last	82-102	21	A/N	The last name of person who should be contacted about the case.
1,2,3,4	Contact-Name-First	103-118	16	A/N	Contact's First Name.
1,2,3,4	Contact-Name-Middle	119-134	16	A/N	Contact's Middle Name.
1,2,3,4	Contact-Name-Suffix	135-137	3	A/N	Contact's Suffix e.g., III, Jr., etc.
1,2,3,4	Contact-Address-Line 1	138-162	25	A/N	Contact's Street Address.
1,2,3,4	Contact-Address-Line 2	163-187	25	A/N	Contact's Street Address.
1,2,3,4	Contact-City	188-205	18	A/N	Contact's City.
1,2,3,4	Contact-State	206-207	2	A/N	Contact's State Address. Must be a valid two-character abbreviation. (See Appendix A for listing.)
1,4,5c	Contact-Zip-1	208-212	5	N	Contact's five-digit zip code.
1,4,5c	Contact-Zip-2	213-216	4	N	Contact's four-digit zip code.
1,4,5c	Contact-Phone-Num.	217-226	10	N	Contact's phone number.
1,2,3,4	Phone-Extension	227-232	6	A/N	Contact's phone extension.
1,2,3,4	Responding-Docket-Num.	233-249	17	A/N	Responding State's docket number.
1,4,5c	Fax	250-259	10	N	Contact's fax number.
1,2,3,4	Internet-Address	260-294	35	A/N	Contact's Internet address.
1,2,3,4	Initiating-Docket-Num.	295-311	17	A/N	Initiating State docket number.
1,4,5c	Send-Payments-Bank-Account	312-331	20	N	Bank account number for transfer of payments via Electronic Funds Transfer (EFT).
1,4,5c	Send-Payments-Routing-Code	332-341	10	N	Routing code for transfer of payments via Electronic Funds Transfer (EFT).
1,2,3,4	State-With-CEJ	342-343	2	A/N	State with Continuing Exclusive Jurisdiction (CEJ). Must be a valid two-character State abbreviation. (See Appendix A for listing.).
1,4	Payment-FIPS-State	344-345	2	N	The Payment-FIPS-State must contain valid FIPS codes based on the jurisdiction table downloaded from the IRG. This always refers to the first two digits of your FIPS code. FIPS code used for the Payment Mailing Address
1,4	Payment-FIPS-County	346-348	3	N	The Payment-FIPS-County must contain valid FIPS Code numbers based on the jurisdiction table downloaded from the IRG. This always refers to the 3rd, 4th, and 5th digits of your FIPS code. FIPS code used for the Payment Mailing Address.
1,2,3,4	Payment-FIPS-Sub	349-350	2	A/N	The value of the "sub" portion of the FIPS code will not be edited.
1,2,3,4	Nondisclosure-Finding	351	1	A/N	Identifies if case is to be handled confidentially. Valid Values for this field are: Y - Nondisclosure attachment on its way, treat case as confidential. N or blank-filled - No nondisclosure attachment.

Table of Contents

CHART A-5: CSENet 2000 PARTICIPANT DATA BLOCK RECORD

Rules	Field Name	Location	Length	A/N	Comments
1,2,3,4	Name-Last	1-21	21	A/N	Required Last name of the participant. Required for PAT, EST, and CSI Requests, Updates and CSI Responses. For ENF Requests and Updates, the Participant Name is required if the relationship code is 'D'.
1,2,3,4	Name-First	22-37	16	A/N	Required First name of the participant. Required for PAT, EST, and CSI Requests, Updates and CSI Responses. For ENF Requests and Updates, the Participant Name is required, if the Relationship code is 'D'.
1,2,3,4	Name-Middle	38-53	16	A/N	Middle name of the participant.
1,2,3,4	Name-Suffix	54-56	3	A/N	Suffix for participants name e.g., III, Jr., etc.
1,4,5a	Date-Of-Birth	57-64	8	N	Required Participant's Date of birth. Must be a valid date and prior to the current date. Required for PAT Requests and Updates. Required for EST Requests and Updates ENF Requests and Updates if the Relationship code is 'D'.
1,4,5c	SSN	65-73	9	N	Participant's Social Security Number.
1,2,4	Gender	74	1	A/N	Participant's gender. Valid values for this field are: F - Female M - Male O - Other (i.e., unborn, unknown)
1,2,4	Race	75	1	A/N	Participant's race. Valid values for this field are: A - Asian or Pacific Islander B - Black I - American Indian, Eskimo or Aleutian S - Hispanic W - White X - Other
1,2,4	Relationship	76	1	A/N	Required This field indicates the role of this particular Participant to the case. Required if a participant name is entered for LO1, PAT, EST, or ENF Request, Update or Response transactions. Valid values for this field are: A - Non-Custodial Parent C - Custodial Party D - Dependent P - Putative S - Second Adult (Caretaker if not parent)
1,2,4	Participant-Status	77	1	A/N	Required Indicates whether the participant is an active member in this case. Required if a participant name is entered. Valid values for this field are: C - Closed (Inactive) O - Open (Active)
1,2,4	Dependent-Relation-CP	78	1	A/N	Required This field is used if the Participant is a dependent. It describes the relationship of the dependent to the custodial party in the case. Required for PAT Requests or Updates if the Relationship Code is 'D'. Valid values for this field are: A - Adopted Child C - Natural Child F - Foster Child G - Grandchild E - Niece/Nephew N - No Relation O - Other Relationship S - Sibling U - Cousin W - Ward
1,2,3,4	Participant-Address-Line-1	79-103	25	A/N	Required Line 1 of participant's address. Required for PAT Requests or Updates if the payment address is not on the Case data block and the Relationship field is C for the custodial party.
1,2,3,4	Participant Address-Line-2	104-128	25	A/N	Line 2 of participant's address
1,2,3,4	Participant-City	129-146	18	A/N	Participant's City.
1,2,3,4	Participant-State	147-148	2	A/N	Participant's State. Must be a valid two-character state abbreviation. (See Appendix A for listing.)
1,4,5c	Participant-Zip-1	149-153	5	N	Participant's five-digit zip code.
1,4,5c	Participant-Zip-2	154-157	4	N	Participant's four-digit zip code.
1,2,3,4	Participant-Employer-Info.-Emp.-Name	158-197	40	A/N	Participant's employer name.
1,2,3,4	Participant-Employer-Info.-Emp.-Street-Line-1	198-222	25	A/N	Line 1 of the participant's employer's address.
1,2,3,4	Participant-Employer-Info.-Emp.-Street-Line-2	223-247	25	A/N	Line 2 of the participant's employer's address.
1,2,3,4	Participant-Employer-Info.-Emp.-City	248-265	18	A/N	Participant's employer's City.
1,2,3,4	Participant-Employer- Info.-Emp.-State	266-267	2	A/N	Participant's employer's State. Must be a valid two-character State abbreviation. (See Appendix A for listing.)
1,4,5c	Participant-Employer-Info.-Emp.-Zip-1	268-272	5	N	Participant's employer's Zip1 code.
1,4,5c	Participant-Employer-Info.-Emp.-Zip-2	273-276	4	N	Participant's employer's Zip2 code.
1,4,5c	Emp-EIN	277-285	9	N	Participant's Employer's Federal Employer Identification Number (EIN).
1,2,4	Address-Confirmed	286	1	A/N	Indicates if address is valid. Valid values for this field are: Y- Confirmed. N or Blank filled - Not Confirmed
1,4,5a	Date-Address-Confirmed	287-294	8	N	Date address confirmed.
1,2,4	Employer-Confirmed	295	1	A/N	Indicator if employer listed has been confirmed. Valid values for this field are: Y- Confirmed. N or Blank - Not Confirmed
1,4,5a	Date-Employer-Confirmed	296-303	8	N	Date employer confirmed.
1,4,5c	Work-Phone	304-313	10	N	Participant's work phone number.
1,2,3,4	Place-Of-Birth	314-338	25	A/N	Participant's place of birth.
1,2,3,4	Dependent-Child-State-Of-Residence	339-340	2	A/N	This field is used if the participant is a dependent. Must be a valid two-character State abbreviation. (See Appendix A for listing.)
1,2,4	Dependent-Paternity-Status	341	1	A/N	For dependents only (Relationship =' D'). Valid values for this field are: Y - Paternity status determined N or blank - Paternity status not determined (not disproved) 1 - Born in wedlock 2 - Paternity established through genetic testing 3 - Paternity not an issue (adoption) 4 - Paternity established judicially (order) 5 - Paternity established through Acknowledgment 6 - Other It is recommended that the Information data block be included if the value '6' was chosen to provide information concerning how paternity was established.

Table of Contents

CHART A-6: CSENet 2000 COLLECTION DATA BLOCK RECORD

Rules	Field Name	Location	Length	A/N	Comments
1,4,5a	Date-Of-Collection	1-8	8	N	Required The date of this particular collection. Required for all Collection transactions except COL P CISUB.
1,4,5a	Date-Of-Posting	9-16	8	N	Required Indicates the date the payment posted. Required for all Collection transactions except COL P CISUB. This field must be equal to or greater than the Date-Of-Collection if both have been entered.
1,4,5b	Payment-Amount	17-28	12	N	Required The total amount of the collected payment. Required for all Collection transactions except COL P CISUB
1,2,4	Payment-Source	29	1	A/N	Required Indicates the source of payment. Required for all Collection transactions except COL P CISUB Valid values for this field are: A - Wage Assignment G - Garnishment I - IRS Tax Intercept S - State Tax Intercept U - UIB Intercept N - Normal O - Other W - Worker's Compensation Offset All of the above codes are valid, but the IRS and State tax intercept codes are the only two recommended uses of the COL transaction.
1,2,4	Interstate-Payment-Method	30	1	A/N	Required Required for all Collection transactions except COL PCISUB. Valid values for this transaction are: E - Electronic Funds Transfer M - Manual O - Other Note: If IRS Tax Offset money, the O code is recommended because money will not be sent to the other State.
1,2,3,4	RDFI-ID	31-50	20	A/N	Reserved for Electronic Funds Transfer use.
1,2,3,4	RDFI-Account-Num.	51-70	20	A/N	Reserved for Electronic Funds Transfer use.

Table of Contents

Chart A-7: CSENet 2000 INFORMATION DATA BLOCK RECORD

Rules	Field Name	Location	Length	A/N	Comments
1,2,4	Status-Change-Code	1	1	A/N	Required This field is used to indicate whether the case status has changed. Required for all transactions except for MSC P REJCT. Valid values for this field are: O – Open C – Closed
1,2,3,4	New-Case-ID	2-16	15	A/N	Required This field will be used to transmit a new, changed, or corrected IV-D case ID to another State. Required for MSC P GSCAS The following criteria apply to this field: First position must not be a space. Must not contain all zeros. Must not contain an asterisk (*) or backslash (\) in any position Must not contain a combination of spaces and zeros.
1,2,3,4 1,2,3,4 1,2,3,4 1,2,3,4 1,2,3,4	Information-Text -Line-1 -Line-2 -Line-3 -Line-4 -Line-5	17-96 97-176 177-256 257-336 337-416	80 80 80 80 80	A/N A/N A/N A/N A/N	Required All 5 lines contain free form text. A value, other than a space, in line 1, 2, or 3 is required if the Attachment Indicator = 'Y'. For MSC P REJCT, the first 24 positions of the Information-Text-Line-1 field must not be all spaces. Data from the rejected transaction must be entered in the following order in the Information-Text-Line-1: Transaction-Serial-Number, Action-Code, Functional-Type-Code, Transaction-Date, and Action-Reason (if applicable).

Table of Contents

B. CONNECT:DIRECT PROCEDURES - EXCERPT

States currently exchange CSENet transactions through the OCSE Network. CSENet exchanges are being converted from the OCSE Network to the existing C:D connection with OCSE/SSA at the National Computing Center (NCC) that Federal Case Registry (FCR) uses.

The following steps should be performed by the State to accomplish this conversion:

1. Identify the State C:D location where data file transfers currently occur for the Federal Case Registry (FCR).
2. Identify the State technical contact(s) responsible for the above.
3. Identify the location of the current State CSENet network connection in relationship to the State's C:D location identified in Step 1.
• If current CSENet data file transfers occur at the same location (co-located) as the C:D location, then go to Step 4.
• If current CSENet data file transfers occur at a different location (not co-located) than the C:D location follow the steps below.
• Develop and implement procedures to transfer CSENet data files from/to the C:D location. Use the procedures for transferring FCR files as a guide.
• When CSENet data files can be transferred successfully from/to the C:D location, go to Step 4.
4. Provide the NCC C:D team the State data file names for the two files which may be picked-up from the State. These have been identified/described as:
• CSENet Transactions for Production; and
• CSENet Transactions for State-to-State testing.

Note: States who do not currently participate in State-to-State testing are encouraged to code for the handling of this function.

5. Provide the State data file names for the potentially seven files the States may receive from the NCC to the NCC C:D team:
• The first four files are identified/described as production files with types:
• Valid CSENet Transactions;
• Transaction Error File;
• Transaction Validation Report; and
• IRG Refresh File
• The second three files are identified/described as State-to-State testing files with types:
• Valid CSENet Transactions;
• Transaction Error File; and
• Transaction Validation Report

Note: Not all States currently process all nine file types.

6. Because these transmissions are daily, the State file naming convention must include a method for uniqueness such as date and time stamp, GDG processing or file append processes. OCSE recommends the following data file name convention:
• CSENet transactions picked up by C:D: ##IP.Thhmmss.Ryymmdd
• CSENet State-to-State testing transactions picked up by C:D: ##IT. Thhmmss.Ryymmdd
• CSENet transactions returned to the State: ##OP. Thhmmss.Ryymmdd
• CSENet State-to-State testing transactions returned to the State: ##OT. Thhmmss.Ryymmdd
• CSENet Error report returned to the State: ##EP. Thhmmss.Ryymmdd
• CSENet State-to-State testing Error report returned to the State: ##ET. Thhmmss.Ryymmdd
• CSENet Validation report returned to the State: ##VP. Thhmmss.Ryymmdd
• CSENet State-to-State testing Validation report returned to the State: ##VT. Thhmmss.Ryymmdd
• CSENet IRG file returned to the State: IRGP. Thhmmss.Ryymmdd
  Where:
  ## = State FIPS Code
  hhmmss = Hours, Minutes, Seconds
  yymmdd = Year, Month, Day

Note: States that choose a method of file management other than file appends and emptying are responsible for ensuring files are not duplicated, processed more than once or overlaid.

7. The State security staff will coordinate with the NCC C:D team to define security for the possibly nine data files to be transferred by C:D for the CSENet application. The security userid to be used will likely be the same one used for the current C:D data transfers for FCR.
8. Coordinate with the NCC C:D team to create the C:D procedures to transfer CSENet data files. These may be copied from the current State procedures used to exchange FCR files with the NCC. Procedures need to include transferring:
• Two CSENet data files to the NCC
• Seven CSENet data files from the NCC
9. When ready, provide the filenames to Abe.Klugman@acf.hhs.gov 410.965.5635 or to Dominic.Perry@acf.hhs.gov 410.966.4737. These contacts are available for any questions or suggestions and to schedule and conduct the testing of the data transfer of the nine possible files in both directions.