All legacy non-Student Customers, AR balances, and Sponsor related balances that are open in the legacy accounts receivable system as of the conversion date will be extracted from the Legacy system and converted into PS Financials Accounts Receivable as open AR items.

Customer account validation will also take place during this cycle to ensure customers associated with open items have been translated properly into the PS system (ie. Address, short name, etc.).  

*It will be imperative for colleges to bill (fully process) for specific Go Live term(s) Sponsor related open receivables in the Legacy system prior to the colleges' Go Live date in order to extract all the Sponsor related open receivables for conversion into PeopleSoft. Any unbilled AR that does not have accounting distribution in the Legacy system at the time of extraction will be captured on an error log.

The Validation Results and Feedback are due NO LATER THAN on the last  day of the Data Validation Period. It is strongly recommended that issues  are reported EARLY in the validation period and are not held until the  end of the period. Validation Results and Feedback are for reporting  closure of the college's validation activities for the conversion cycle.  To view a list of the validation periods please refer to the timeline topic in the Data Validation Overview - Getting Started Guide.

Questions regarding AR conversion data validation activities can be directed to Sabit Gottipati.   General questions or concerns about the project data validation process can be addressed to the following individuals:

The following are requirements and the general process for extracting data from Legacy:

1. Extract customer account detail for invoices with outstanding charges.
2. Include invoiced and non-invoiced open receivables that have accounting distribution only. Transactions that do not have an associated account structure would not be included in the GL.
3. In the legacy AR system, there are transactions for non-student customers, students, and sponsors.
   1. AR customers are identified as follows:
      1. Students  - Transactions with a CUST-TYP of “S”
      2. Non- students  Transactions with a CUST-TYP of “O”
      3. Sponsors  Transactions with a CUST-TYP of “o” and contain a student id with a suffix of “S” in the CUST-REF field.  
   2. Non-student customer and sponsor open balance transactions will be written to Finance Accounts Receivable. Therefore, transactions will be written to the Pending Item and Pending DST (Distribution) files.
   3. Colleges should review balances in the Legacy system to ensure the data is accurate and should be converted to the AR sub-ledger in PeopleSoft. Files of the extracted data have also been provided on Canvas.
   4. Colleges should have readily available, completed reconciliations for all balances that will be converted by account, to include a report from legacy distinguishing which open receivables are non-student, and/or sponsor balances.
   5. Validation of balances for each Sponsor and non-student customers will need to occur within PS, ensuring that the open item extract detail matches what is shown within PeopleSoft.

The following output files will be generated:

AR_CUSTOMERS  This file has customer data (name, address, contact info, etc.)

QF1712S  Pending Item File  Write a single record to the Pending Item file for each invoice with open charges.

QF1713S  Pending DST File - Write a record to the Pending DST file for invoiced transactions where the AMT-CHRG is greater than zero and the AMT-PYMT is equal to zero.

QF1715S  AR Detail File  This file will be used for research and cross walking.  It contains a record for each AR transaction that will be processed.

Qf1714S  Groupline File  Write a record to the Groupline file for invoiced sponsor transactions that occur during go-live term (these transactions are merged within the files listed above - there is no separate file).

How values are extracted from Legacy:

An extract was created within Legacy to retrieve CUST-ACTV-D records with open charges. The extract filters on DEBT-TYP(OPTIONAL), CUST-TYP NOT equal to “S” and AMT-CHRG not less than zero (unless it’s a credit).  These filters exclude transactions for students which will be converted via the Student Finance conversion.

Notes for Future Reference:

1. All open sponsor and other non-student related charges prior to go-live will convert to the Finance module. Billing must be run with distribution prior to the conversion date in order for the transactions to convert to Finance.
2. Payments made against converted sponsor balance transactions after go-live, will also be made in the Finance Accounts Receivables module until the balance is paid.
3. For the go-live term, new contracts for sponsor transactions will be processed by PeopleSoft Student Financials (on and after the go-live date).
   1. New production begins with processing new transactions with accounting dates after the accounting cutover date.

It is possible that issues may arise in the conversion process that we may not be able to correct before college or agency representatives are asked to validate. While the issues should be minimal if at all, these issues generally involve the difference between the timing of when data is extracted out of legacy and when the last update to crosswalks have been made in PeopleSoft, for example.

In cycle 2, most of the differences related to individual customer balances are due to cross-walking the Legacy Customer ID to the correct PeopleSoft IDs and/or determining if new child records for shared customers should be created as an update to the parent record..

In cycle 3,  we continue to review customer balances and customer accounts for accuracy. In addition, a major focus for this cycle is to also review transactions from a cross-pillar perspective (AR/SF).  Where possible, the goal was to ensure reliability of data and to reduce duplication, if any, that could occur. Careful attention to the type of data within the Legacy extract files for AR is needed to ensure appropriate data is not duplicated in both SF and Finance in PS.

Types of issues found in cycle 3 pertaining to customers - to keep in mind for cycle 4:

1. Fields that have a % sign in the address fields need to be cleaned up within legacy with actual addresses or kept blank, perhaps.  Think about how the address fields should be populated in PS (regardless of whether they are being mailed, emailed, or not). Consistency is key.

2. Are some of these customers emailed and do not need addresses?  If so, please state which customers will be emailed only and ensure that the customer email addresses are included.

3. Customers that do not have an address within the system like NSF students for example, need an address if the intention is to bill those students within the finance module.  If the students will be billed in SF, then those transactions should not come into the finance module.  

In cycle 4, continue to review customer balances to include the chartstrings and customer accounts for accuracy. Ensure the local billing and AR business processes are compatible with how PS converts/processes data. It might also be a good idea to start thinking about when and how new transactions will be recorded before or during the time period that Legacy is taken down and Post Go-Live (after conversion weekend).

*Take a look at your AR_Invoice_Detail report from Legacy. This data was converted into PS.  Are the transactions within the extract file from Legacy Sponsor and non-student related transactions only?  If not, we need to determine how transactions that are not Sponsor or non-student related will be converted else where (SF).

Data Validation SMEs should review their converted records very closely, making sure that customer information (address, bill to information, etc.) and open receivables are reflected accurately within PS. This means that the converted open item receivables data (non-student and Sponsor) in PS should match the open AR balances reflected in Legacy at minimum, by invoice and by customer.

AR Customers

Customers are globally set up (shared  WACTC). At minimum, the college responsibility entails making sure that the customer information (name, address, contact information, open balances, etc.) is accurate.

AR Open Items

An important part of the validation process is to reconcile converted PS balances to the ending AR open item Legacy System balances.

Extract Quality Assurance/Recon  The QA and reconciliation is a College Data Validation SMEs responsibility. Quality checks and reconciliation between the two systems should be performed to ensure completeness, accuracy, and validity of the invoice conversion records.  The following reconciliation checks can be a programmatic edit that is part of the extract process.  However, it must also be done manually by our institution’s accounting staff to ensure quality.

• The sum of the extracted open balance records for an Invoice ID should equal the legacy system’s total Invoice open balance.  (Pending Item 1 tab in PS)
• The sum of all extracted open amounts for a Customer ID should equal the Legacy system’s open customer balance.  
• The sum of all extracted open amounts for all customers should equal the total open AR Balance.  
• The sum of all extracted open amounts should reconcile to the legacy GL AR balance.
• It is recommended that you run a BM1710 AR Aging Report in Legacy for the same time frame as the data snapshot for validation.

If the information above presents a potential challenge that needs to be overcome for the final conversion run of AR open items, please be sure to make that concern known.  Conversion planning discussions will be held during and after the Data Validation Workshops.

For each open item a customer has in a business unit, the interface program creates a pending item with an assigned business unit, customer ID, and item ID (invoice). When the Receivables Update Job processes these pending items, it determines if it can use the customer ID that is established in the TableSet for this business unit. It then creates the customer balance and history information for the customer in the business unit.

As you all know, customers and suppliers in ctcLink are global. We have a real challenge maintaining clean customer and supplier tables. Of course, our biggest challenge is during the conversion cycle when hundreds of customers and suppliers are being added.

In an effort to keep the global lists clean, we will not create duplicate customers or suppliers. If you believe truly you need a separate customer for the same company or agency, please check with Teri Sexton ([email protected]).

We are also asking you to clean up the Legacy customer lists that are added during each cycle. Please do not use abbreviations like “NLNT North C013” as users will be unable to figure out who it is (if it were added).

For cleaner, more consistent customers, see chart below:

Review the excel spreadsheets (extracts) and/or data within Legacy to the data output viewed in PS. You are reviewing the data to determine:

1. Did the Customer Data convert as expected?
2. Did the data upload as expected in terms of values (detail/summarized transactional balance(s)?
3. Is the accounting distribution (chartstring) correct?

*There are files on Canvas that may also prove useful as you complete your validation (see screenshot below as an example of the types of file you would expect to find on your Deployment Group's canvas page).

Data from an AR_Invoice_Detail

Data as converted into PeopleSoft

The word balance is highlighted in blue, which means it is a hyperlink that you can drill into. If you click on balance it will take you to another page.

Each invoice is highlighted in blue, which means it is a hyperlink that you can drill into. If you click on the first invoice (00000001770 - $579.20) it will take you to another page, where you can see the detail for that particular invoice. Notice the 4 lines of detail. 3 lines,  1,3, & 4 total the invoice amount of $579.20. If you drill into each of the 3 invoices, a total of eighteen lines will display (which matches the detail of the AR_Invoice_Detail).

*Notate any discrepancies found, if any in the Validation Results Template discussed below.