Introduction

When importing data from Classic USAS into USAS-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 USAS-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

...

Below is a list of the more common error 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. Each Error shows the line number associated with the record in the corresponding import file. The line number can be helpful in locating the record.

Vendors

• Invalid vendor data:  Common errors include invalid state abbreviations, postal codes containing a hyphen, missing primary names, etc.  These vendors will import and all YTD amounts will be correct because the transaction data will be associated to the vendor.  However, these vendors will need to be modified and their information updated.  The SSDT Post Import Vendor Report will generate a report of vendors that did not properly import that will aide in the cleanup process.  You can also filter the vendor grid for a primary name of "Template Vendor" to see which vendors did not import properly.
  • Address.address: state field requires the 2 character code for US states - The State field in the vendor address (ex. OH) is longer than two characters. This is common with international addresses where the user has entered the country or providence in the state field. This information can be added to the city line instead.
  • Address.address: invalid postal code - The zip code should be formatted to 5 characters XXXXX or 9 characters with a hyphen XXXXX-XXXX. 
  • Vendor.primaryName: input is required - The Vendor Primary Name field is blank.

Requisitions

• Requisition header and items:  You may see messages that requisition headers and items were not created because the related purchase order was not found.  When requisitions are converted to POs and then the PO is deleted the import will not post the associated requisition.
  
  • Requisition #XXXXXX not created, no related purchase order found.
  • Requisition header not found for XXXXXX

Invoices

• Suspicious Invoices:  We're seeing a lot of partial invoices with invoices dates after full invoices.  This is a problem in the Redesign because it is date driven.  In most cases these invoices will need to be cleaned up so they don't cause problems with carryover encumbrances.

Users

• Users:  You may see a message stating "Unable to find ord.ssdt_ohio.usas.model.user.User with id "some string of characters".  This means that a user record was created during a transaction import (created by user) but when the user import ran that user was not found in the import file.  This user was most likely deleted in Classic but was still referenced via the created by user field on various transactions.