Common Import Errors and Warnings

Owned by Michelle Drewes
Last updated: Jan 06, 2023 by Amanda Folkman
14 min read

Below is a list of the more common warning and 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, provides 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.  Some of the errors may require clean up to be made in Classic prior to extract so it's imperative to do a test import of the inventory data in order to review possible import errors and clean them up in Classic prior to the final production import.  

Acquisitions (EIS_IRN#_ACQ_EXP.TXT)

  • Acquisition Import Error - tag #xxxxxx, row xxxx: Inventory Item Not found for tag #xxxxxx
    • The associated item record is not on file thereby not allowing the associated acquisition record to be imported.  Please review the import log to see if there is an 'inventory item import error' for the related tag #.
  • Acquisition Import Error - tag #xxxxxx, row xxxx: Date '06010019' is not in year range 1753-9999
    • This error indicates the date on the acquisition record is invalid date and the acquisition record will not import.  The acquisition date must be fixed in classic in order for the acquisition to import.  Please create a support ticket to SSDT on how to fix invalid acquisition dates on the acquisition record.

Category Codes (EIS_IRN#_ITMCT_EXP.TXT)

  • CategoryCodeImportImpl:  error: Category Code Import Error - row 2: Index 1 out of bounds for length 1
    • This error usually indicates the extract files does not contain any category code records.  Please review their Classic EISMNT>CATSCN to confirm there are no item category codes on file.  If that's the case, please ignore this error.
    • If there are category codes in Classic (and on the extract file), on the inventory import results file, find the number of 'records loaded'.  Next, review the migrated category codes via Core>Categories to confirm the same number were loaded and compare back to the Classic category codes (EISMNT>CATSCN) to confirm all category codes migrated. 
      • If you can confirm all Classic category codes migrated to Inventory, please ignore this error.  The 'out of bounds' error may be due to a blank where the importer thinks there should have been a code.
      • IF a category code did not import, please add it manually via Core>Category Codes.

Condition Codes (EIS_IRN#_LOCAT_EXP.TXT)

  • ConditionCodeImportImpl:  error: Condition Code Import Error - row 3: Index 5 out of bounds for length 4
  • ConditionCodeImportImpl:  error: Condition Code Import Error - row 4: Index 2 out of bounds for length 2
    • This error may indicate the extract files does not contain any condition code records.  Please review their Classic EISMNT>CNDSCN to confirm there are no condition codes on file in Classic.  If that's the case, please ignore this error. 
    • If there are condition codes in Classic, on the inventory import results file, please review how many condition codes loaded. Next, review the condition codes in Core>Conditions to confirm the same number were loaded and compare back to the Classic condition codes (EISMNT>CNDSCN) to confirm all condition codes migrated. 
      • If you can confirm all Classic condition codes migrated to Inventory, the 'out of bounds' error may be due to a blank where the importer thinks there should be a code.  If all condition codes migrated, please ignore this error.
      • If a condition code did not import, please add it manually via Core>Condition Codes.

Disposition Codes (EIS_IRN#_DSPCD_EXP.TXT)

  • DispositionCodeImportImpl:  error: Disposition Code Import Error - row 2: Index 2 out of bounds for length 1
    • This error may indicate the extract files does not contain any disposition code records.  Please review their Classic EISMNT>DSPSCN to confirm there are no disposition codes on file.  If that's the case, please ignore this error.
    • If there are disposition codes in Classic (and on the extract file), on the inventory import results file, find the number of 'records loaded'.  Next, review the migrated disposition codes via Core>Dispositions to confirm the same number were loaded and compare back to the Classic disposition codes (EISMNT>DSPSCN) to confirm all disposition codes migrated. 
      • If you can confirm all Classic disposition codes migrated to Inventory, please ignore this error.  The 'out of bounds' error may be due to a blank where the importer thinks there should have been a code.
      • If a disposition code did not import, please add it manually via Core>Disposition Codes.

Dispositions (EIS_IRN#_DISP_EXP.TXT)

  • DispositionImportImpl: Warning: Invalid Disposition Code: for Item #: xxxxxx
    • Missing Disposition Method: The disposition transaction will import with the missing or invalid disposition method.  If you want to update the disposition method, you may fix it in Classic prior to extract or wait until the data has been migrated to fix it in Redesign using one of the steps provided below. 
      • Fix in Classic: Please review the tag in EISSCN>DSPTRN and update it by adding a disposition method. 
      • Fix in Redesign
        • Using Transactions>Disposition, edit the disposition correcting the missing/invalid disposition method. 
        • If you have several dispositions with missing disposition methods, using the Transaction>Dispositions grid, extract the desired dispositions into an EXCEL spreadsheet.  Add the correct disposition code and save the spreadsheet in CSV format. Use System>Import's Dispositions Import type ensuring 'update records' is checked and import the updated disposition transactions.  If the disposition code is new and not currently in Core>Dispositions, it will be automatically added when the spreadsheet is imported and the new disposition also noted on the import results report.  
  • DispositionImportImpl:  error: Disposition Import Error - tag #, row 2: Index 1 out of bounds for length 1
    • This error usually indicates the extract files does not contain disposition transactions.  Please review their Classic EISSCN>DSPTRN to confirm there are no disposition transactions on file.  If that's the case, please ignore this error.

Function Codes (EIS_IRN#_FUNC_EXP.TXT)

  • FunctionCodeImportImpl:  error: Function Code Import Error - row xx: Index 3 out of bounds for length 1
    • If there are function codes in Classic (and on the extract file), on the inventory import results file, find the number of 'records loaded'. Next, review the migrated function codes via Core>Functions to confirm the same number were loaded and compare back to the Classic function codes (EISMNT>FNCSCN) to confirm all function codes migrated. 
      • If you can confirm all Classic function codes migrated to Inventory, please ignore this error.  The 'out of bounds' error may be due to a blank where the importer thinks there should have been a code.
      • If a function code did not import, please add it manually via Core>Functions.

Fund Codes (EIS_IRN#_FUND_EXP.TXT)

  • FundImportImpl:  error: Fund Import Error - row x: Index 3 out of bounds for length 1
    • If there are fund codes in Classic (and on the extract file), on the inventory import results file, find the number of 'records loaded'. Next, review the migrated fund codes via Core>Funds to confirm the same number were loaded and compare back to the Classic fund codes (EISMNT>FNDSCN) to confirm all fund codes migrated. 
      • If you can confirm all Classic fund codes migrated to Inventory, please ignore this error.  The 'out of bounds' error may be due to a blank where the importer thinks there should have been a code.
      • If a fund code did not import, please add it manually via Core>Funds

Items (EIS_IRN#_ITEMS_EXP.TXT)

  • 17:29:46.193 ERROR [ main] o.h.engine.jdbc.spi.SqlExceptionHelper   ERROR: duplicate key value violates unique constraint "uk_inventoryitem_tagnumber" Detail: Key (tagnumber)=(11202) already exists.

    17:29:46.195 ERROR [  main] o.h.i.ExceptionMapperStandardImpl        HHH000346: Error during managed flush [org.hibernate.exception.ConstraintViolationException: could not execute statement]

    • Duplicate tag on file: This could be possible if one of the tag numbers includes a blank space as part of the number.   The one with the blank space will import first (the importer drops the space) thus resulting in the duplicate number to not import.
      • Fix in Classic: If it is a true duplicate, the district needs to delete the duplicate tag in EISSCN>ITMSCN.  If it's not a duplicate, they need to change the tag number with the blank space in EISSCN>ITMSCN in order to allow both tags to import.


  • InventoryItemImportImpl: Warning: Capitalized Item #: xxxxxxx has no fund (function or asset class).
    • Regardless of the status (active, etc.) of the item, if the fund, function or asset class is blank on the item record or if the fund, function or asset class is not listed as a valid code in EISMNT in Classic, a warning will be generated.  The item will migrate over but the fund, function or asset class will be blank on the item record.  If you want to update the fund/function/asset class for active items, you may fix it in Classic prior to extract or wait until the data has been migrated to fix it in Redesign using one of the steps provided below
      • Fix in Classic: The offending tag numbers are listed on the import log. 
        • If the fund, function or asset class is blank on an active tag in EISSCN>ITMSCN, create TRNTRNs to assign a valid fund, function and/or asset class. 
        • If the fund, function or asset class is on an active tag in EISSCN>ITMSCN but the code is not listed in EISMNT's FNDSCN (fund), FNCSCN (function) or CLASSCN (asset class), please add the missing codes to its respective program in EISMNT.
      • Fix in Redesign:
        • Using Transactions>Transfers, for active items, create a transfer transaction to change the blank fund, function or asset class to a valid fund, function or asset class.  The associated item's fund, function or asset class will be automatically updated as well to reflect the new value.

        • If you have several active items with an empty fund, function or asset class, you may use the Transaction>Items grid to extract the desired items into an EXCEL spreadsheet. Enter missing fund, function or asset class and save the spreadsheet in CSV format.  Use System>Import's Item Import Type ensuring 'update records' is checked and 'create Transfers' is checked.  The missing fund/function/asset class will be updated on the item record and a transfer transaction will be created with the new value.  Please refer to the System>Import chapter for more information on required fields and formatting of the spreadsheet.

          NOTE: The import option is not currently available to update items blank fund/function/asset class fields to a value. Jira Issue INV-448 is set to address this on an upcoming release.


  • InventoryItemImportImpl: Warning: Item #: xxxxxx has a depreciation method of: Straight_Line with an invalid date: 000000
    • If an item is marked for depreciation, the beginning depreciation date must be in a valid MMYYYY format in Classic's ITMSCN.   If the date is blank or invalid (i.e. 00/2008, 01-APR, etc.), the item will migrate over but the beginning depreciation date will be blank in redesign.  If you want to update the invalid beginning depreciation date, you may fix it in Classic prior to extract or wait until the data has been migrated to fix it in Redesign using one of the steps provided below  
      • Fix in Classic: The offending tag numbers are listed on the import log.  Access the tag in EISSCN>ITMSCN and modify the Beginning Date field under 'Depreciation Information' with the correct MMYYYY format. 
      • Fix in Redesign:
        • Using Transactions>Items, query the specific tag number and click edit to enter a valid beginning depreciation date and save your changes.

        • If you have several active items with an invalid or blank beginning depreciation date, using the Transaction>Items grid, extract the desired items into an EXCEL spreadsheet. Enter valid beginning depreciation dates and save the spreadsheet in CSV format.  Use System>Import's Item Import Type ensuring 'update records' is checked and import the updated beginning depreciation dates for those existing items.  Please refer to the System>Import chapter for more information on required fields and formatting of the spreadsheet.

          Invalid beginning depreciation dates (i.e. 00/2019) may cause balancing issues on the YTD (aka FTD) Depreciation amounts when comparing the EIS104 vs. Schedule of Change in Depreciation and/or EIS305 vs Book Value and/or EIS102 vs Fixed Asset by Function/Class for active items containing a straight-line method that have not been fully depreciated and contain an invalid beginning depreciation date.  The recommended way to fix this is in Classic.  Please refer to the Life-To-Date Depreciation Discrepancies documentation for further details.


  • InventoryItemImportImpl:  error: Inventory Item Import Error - tag #xxxxxx, row xxx: Index 7 out of bounds for length 7
    • This error may indicate it encountered an invalid character in the item extract.  Examples could include accent mark or special character. .  It's likely the import stopped at this line and did not continue importing the remaining items.  You can confirm by comparing the 'records loaded' on the import log to the number of lines on the extract file.  If there are substantially more lines on the extract file, than what was loaded, the items import did not complete.  
      • Fix in Classic: The offending tag numbers are listed on the import log.  Access the tag in EISSCN>ITEMSCN and remove the invalid character.


  • Inventory Item Import Error: ERROR [main] o.h.i.ExceptionMapperStandardImpl HHH000346: Error during managed flush [Validation failed for classes [org.ssdt_ohio.usas.inventory.model.AssetClass] during persist time for groups [javax.validation.groups.Default,]List of constraint violations:[ConstraintViolationImpl{interpolatedMessage='Code must be max 4 characters long.', propertyPath=code, rootBeanClass=class org.ssdt_ohio.usas.inventory.model.AssetClass, messageTemplate='Code must be max 4 characters long.'}
  • InventoryItemImportImpl:  error: Inventory Item Import Error - tag #xxxxxx, row xxx:
    • These type of errors could be due to a wrapping issue on the ITEMS_EXP.TXT extract file caused by a hidden tab/space issue and could involve several tags.  Please review the extract file in NOTEPAD++ to determine if each item is on its own line, lined up at the left margin.  If you see wrapping similar to snippet below (Lines 5-7), it's a very good indication there are hidden spaces/tabs in the data causing the formatting to wrap and resulting in the error messages above.  In the snippet below, tags #000001 and #000002 are lined up corectly.  Starting with line 5, you no longer see tag numbers line up at the left. The next tag #000003 should be listed at the left margin of line 5.  Instead, that tag is near the end of line 4 due to a possible hidden/tab space issue. 

Most of the hidden tabs/space issues have been found on the "User Defined" section of the item record.  To confirm, run an EIS303 report and at the Reporting Portion option, select 7 'User Defined" and hit enter through the rest of the prompts with the exception of the last option... you want to sort by tag number (TN) only. If it encounters hidden tab/spacing issues, the resulting report will display null spaces (snippet below). 

      • Fix in Classic:

        • If the EIS303 has confirmed this, you can use datatrieve to clear out the user defined fields.   However, please note to check with the district to see if they have any important data stored in the User Defined fields in EISSCN>ITMSCN.  If they do not use this section,  perform the following  datatrieve steps in a test set of their classic data to remove the hidden tabs. Re-extract and view the items extract file to see if ALL items now line up at the left margin. If there is no wrapping, perform another test import to see if it cleared up both the item and acquisition errors on the inventory import results file.

          Steps to clear out the user-defined fields (these fields are displayed on Screen 3 of ITMSCN in Classic)

          • set to their SAAS21 dictionary
          • ready items shared modify
          • find a in items (you will receive a return number of all item records they have on file)
          • modify all using user_money=""
          • modify all using user_date=""
          • modify all using user_code_1=""
          • modify all using user_code_2=""
          • modify all using user_code_3=""
          • modify all using user_description=""
          • exit
    •  If the above steps do not fix the wrapping issue, please create a support ticket attaching both the inventory import results file and their EIS_IRN#_ITEMS_EXP.TXT file 
  • InventoryItemImportImpl:  error: Inventory Item Import Error - tag #, row xxx: Index 1 out of bounds for length 1
    • The 'out of bounds' error may be due to a blank where the importer thinks there should have been an item record.  On the inventory import results file, find the number of 'records loaded' and compare against the number of rows on the Items extract file as well as review the number of migrated items to confirm the same number were loaded.  If you can confirm all items migrated to Inventory, please ignore this error.  

Locations (EIS_IRN#_LOCAT_EXP.TXT)

  • LocationCodeImportImpl: Warning: Location Number: CUMC has a blank category.
  • LocationCodeImportImpl: Warning: Location Category: 001 has a blank number.
    • Missing part of the location:  The location code is made up of a location category and a location number.  The partial location will import in Core>Locations and any items containing the partial location will import as is in Transactions>Items. If you want to update the location codes, you may fix it in Classic prior to extract or wait until the data has been migrated to fix it in Redesign using one of the steps provided below
      • Fix in Classic: You may use EISCHG>Mass Change Location Codes to mass change all items that contain the partial location code to a valid, complete location code.  When doing so, all items will be updated with the valid code and if the location is a new code, the location will be automatically added to EISMNT>LOCSCN.   
      • Fix in Redesign:
        • Using Transactions>Items, query the specific tag number and click edit to enter a valid location and save your changes.
        • If you have several items with invalid locations,  using the Transaction>Items grid, extract the desired items with partial locations into an EXCEL spreadsheet.  Add the correct location_category or location_number and save the spreadsheet in CSV format. Use System>Import's Item Import type ensuring 'update records' is checked and import the updated locations.  If the location code is new and not currently in Core>Location, it will be automatically added when the spreadsheet is imported and the new location also noted on the import results report.  
  • 16:10:47.433 ERROR [  main] o.h.engine.jdbc.spi.SqlExceptionHelper   ERROR: duplicate key value violates unique constraint "uk_locationcode_number" Detail: Key (number, category)=(1, 201) already exists.

Error: LocationCodeImportImpl:  error: Location Code Import Error - row 77: could not execute statement; SQL [n/a]; constraint [uk_locationcode_number]; nested exception is org.hibernate.exception.ConstraintViolationException: could not execute statement

    • Duplicate location on file: This could be possible if the location category or location number includes a blank space.   The one with the blank space will import first (the importer drops the space) thus resulting in the duplicate location to not import.
      • Fix in Classic: If it is a true duplicate, the district can delete the duplicate location in EISMNT>LOCSCN.  
  • LocationCodeImportImpl:  error: Location Code Import Error - row 4: Index 2 out of bounds for length 2
    • On the inventory import results file, please review how many location codes loaded. Next, review the location codes via Core>Locations to confirm the same number were loaded and compare back to the Classic location codes to confirm all location codes migrated. 
      • If you can confirm all Classic location codes migrated to Inventory, the 'out of bounds' error may be due to a blank where the importer thinks there should be a location code.  If all location codes migrated, please ignore this error.
      • If you have some location codes that did not import, you may enter them manually via Core>Location Codes.  If you several, you may also create a spreadsheet and import them via System>Import's Location Code import type.  Please refer to the Import documentation for further details as well as a template location code spreadsheet.

Organization Codes (EIS_IRN#_LOCAT_EXP.TXT)

  • OrganizationCodeImportImpl:  error: Organization Code Import Error - row 4: Index 2 out of bounds for length 2
    • This error usually indicates the extract files does not contain any organization code records.  Please review their Classic EISMNT>ORGSCN to confirm there are no organization codes on file in Classic.  If that's the case, please ignore this error. 
    • If there are organization codes in Classic, on the inventory import results file, find the number of 'records loaded'. Next, review the migrated organization codes via Core>Organization to confirm the same number were loaded and compare back to the Classic organization codes (EISMNT>ORGSCN) to confirm all organization codes migrated. 
      • If you can confirm all Classic organization codes migrated to Inventory, please ignore the error.  The 'out of bounds' error may be due to a blank where the importer thinks there should have been a code. 
      • If a organization code did not import, please add it manually via Core>Organization Codes

Transfers (EIS_IRN#_TRANS_EXP.TXT)

  • TransferImportImpl:  error: Transfer Import Error - row 2: Item for tag #Tag could not be found.
    • Ignore Error: Transfer Header Row Column: Row 2 of the Transfer data extract contains header row information.  It's trying to look for Transfer data in Row 2 and generates an error.  Please ignore.
  • Transfer Import Error: tag #xxxx, row xxxx: Item for tag #xxxx could not be found.  
    • The associated item record is not on file thereby not allowing any associated transfer transaction records to be imported.  Please review the import log to see if there is an 'inventory item import error' for the related tag #.