Skip to end of metadata
  • Created by Former user, last modified by Former user on Jan 16, 2020
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Current »

Introduction

When importing data from classic USPS into USPS-R there are three levels of messages that can be written to the log file.

  1. ERROR
    1. An error level condition indicates that the record in question was not imported into USPS-R. These should be reviewed by the hosting entity (ITC) and the school whose data is being imported. It is up to the discretion of the data owner whether the error warrants correction in the source system and another extract and import to be performed. Many times error conditions may be flagged due to invalid or obsolete data in classic USPS. If this is proved to be the case excluding this data on import is not necessarily
  2. WARNING
    1. A waning level condition indicates that we discovered a piece of data in the extracts that is either suspect or considered invalid. Most of the time the record containing the invalid data will still be imported, but it is possible we replaced a piece of invalid data during the import. The message will indicate if data was replaced or if the record was ignored and the user can decide if further action is warranted. 
  3. INFO
    1. An info level message is simply informational and typically should not require any further action on the part of the user.

Below is a list of the more common error and warning level messages you may see in the import logs. This is not an exhaustive list of all possible messages, but addresses the most common ones, gives an explanation of what they mean and gives the user additional context on how to determine if further action is required.

Errors

No Payroll Item Configuration found for deduction code: XXX for pay check number: XXXXXX

  • This error is being thrown during the import of the DEDHIS.IDX file. It signifies that there is a deduction history record that has a deduction code that no longer exists as a USPSDAT/DEDNAM record in classic. Since we do not have a DEDNAM record to reference here we cannot assign a payroll item configuration when importing into USPS-R. Therefor this deduction history record cannot be imported. It is up to the district's discretion as to whether this is data that they do not want to be lost on the import. To fix it they would have to enter a classic DEDNAM record for the deduction code and you would then re-extract / re-import. 

CheckHistoryImportImpl: headers: No SSN found for payroll payment: paycheck number: XXXXXX, job number: XX, pay date

  • This error indicates that there is a check number in the USPCKHIS.IDX file that identifies itself as either a payroll check, direct deposit or refund of deduction but is not assigned to an employee (the SSN is blank on the record). These records cannot be imported as we can not determine what employee to associate them to. If the district knows what employees these checks pertain to you could update the USPCKHIS.IDX file in classic (using datatrieve) or update the extracts to add the employee id. Keep in mind this is really the employee id in the classic SSN field. It is confusing, but it has to do with the field names not being changed when employee ids were implemented. If the district does not want to make the updates they just will not have the history for the checks in question imported into USPS-R. They may be OK with that depending on the nature of the checks and how old they are, but this would be up to them. 

FuturePayAmountImportImpl: Invalid PAY_COUNTER  for employee number (XXXXXXXXX) with job number (XX), pay_counter (???)

  • This error indicates there were orphaned records with invalid ASCII values in the pay counter field discovered in the classic USPFUTPAY.IDX file. It is unclear what caused classic to leave these orphaned records in the file, but this seems to be a common occurrence. They did not show up in the UPDCAL_FUT UI and were ignored by the classic system. The records can be reviewed in the extract file or using datatrieve, however since they were "invisible" for all intents and purposes in classic we assume they can be excluded from the import without negative repercussions.

PayrollItemConfigImportImpl:payrollitem: Line XX: MED/FICA type not found for deduction code 69X

  • This error may happen if there is a DEDNAM record in Classic for a MEDFICA type deduction code that has no employee records attached to determine whether it is a Medicare or FICA type. If there are no employees currently attached to the deduction then the Payroll Item Configuration record may not be necessary.

Warnings

PayrollItemConfigImportImpl: payrollitem: The vendor number () for the PayrollItemConfiguration being imported (code: XXX, type: ) does not match the Payee PayrollItemConfigurationType ([]) or the 'Pay To' information.  Creating a new Payee for the PayrollItemConfiguration.

  • This is actually a warning/informational message and does not result in any data being excluded from import. Basically, this is a side effect of the fact that we created the concept of a payee in USPS-R where as all the payee information (vendor number, address etc.) was stored directly on DEDNAM. . 

PositionImportImpl: position: Pay Per Period () entered does not equal Pay Per Period calculated based upon contract values () for employee:

  • This is also just a warning message. The district can review these if they choose to. It is telling you that when we calculated what we think the pay per period should be based on the contract values at import does not match what the district has in the pay per period field for the contract. We use whatever the district has entered, so the imported data will match classic. 

PositionImportImpl: position2: Calendar Start Date is after Calendar Stop Date. Calendar Start Date will not be imported

  • Also, a warning. It means pretty much what it says in that you can't have a start date after the stop date. We just ignore the start date and don't import it. You can review the position in question, but it should have no affect on processing.

CheckHistoryImportImpl: headers: Non reconciled or voided type () has a reconciled_voided_date, pay_check_number: XXXXXX.

  • This is a warning that indicates we found a check in USPCKHIS.IDX (check history) that has a reconciled / voided date, but the check status is not R (reconciled) or V (voided). We still imported the history record, but we did not import the reconciled / voided date. We simply left that blank.

DeductionHistoryImportImpl: Direct  Deposit deduction type '17' applied to payroll check 99999 for employee XXXXXXXXX - deduction ignored

  • This message indicates a direct deposit deduction was found for a check history record that identifies itself as a check and has a check transaction associated with it. We cannot assign the direct deposit transaction in this case. In most cases it appears this occurs when the direct deposit records were first configured and processed as pre-notes. In that case the employee was paid on a check, but the direct deposit deduction history records were written with zero amounts. In the case of a historical pre-note excluding these deduction history records on import does not result in any lost data. If the user wishes to verify this they can check that the deduction amount for the historical direct deposit deduction is zero either in the extract or via datatrieve. If the amount is zero then this points to a pre-note scenario. If further verification is needed they can review the pay report from the historical pay in question and the employee should be flagged in the deductions section as PRENOTE.            

Check nnnnnn is not a payroll payment - deduction nnn details were not imported.

  • The payment itself will now be imported, but there is currently no way of storing the payroll item detail that was posted with it. These amounts are handled with Adjustment Journals in redesign.


Info

JobCalendarImportImpl:jobcalendar: Line 2: Job calendar with no type or date found. Calendar not imported.

  • A Job Calendar that no longer exists is referenced on a Job. This is likely referenced an an old Job record that is no longer being utilized. If the Job Calendar has not type or date it is not necessary to bring into Redesign. No action needed.

DirectDepositDistribution.rateValid: Rate must be greater than 0 (Value: 'false')

  • This refers to the Rate field on the Direct Deposit record (Classic Deduction Code starting with 7XX). This happens if the Rate is cleared or changed to 0 to "turn off" the deduction instead of entering a stop date. To locate these records for review, the Line Number of the record in the SSWAT Extract .TXT is included in the Info message. Alternatively, you may pull a SAFARI report of all 700 deduction codes and filter on the Rate column. If the record is not being used it is not necessary to make changes. If clean up is desired, a rate and stop date can be entered to eliminate the Info message.

No payment found for check/transaction number: XXXXXX

  • This message is caused by records that are referencing purged information. Classic check history is imported from 4 files: the check history, account history, deduction history, and pay amount history.  If a record exists in the account, deduction, or pay amount history, but there is not a corresponding record in the check history file this Info message will display since the record will not be imported to Redesign. Generally, these are old records that were intended to have been purged so they would not need to import to Redesign and no action is needed. If it is desired to locate the transaction for review, datatrieve or UDMS can be used to look up the check number.


                                                                                                                                                                                                             



  • No labels