Troubleshooting Guide

Cause: If the statistic group number stored for a transaction does not appear in the Statistical Group Maintenance table, the system displays the number instead of an associated location in reports for transaction locations.

Resolution: Add the statistic group number to the Statistical Group Maintenance table.

Cause: If a statistic group number appears in the Statistical Group Maintenance table but has no associated location code, the system displays the number in reports for transaction locations.

Resolution: Make sure every entry in the Statistical Group Maintenance table includes a location code.

Cause: If a location code appears in the Statistical Group Maintenance table but has no associated location group name, the system displays the location code in reports for transaction locations.

Resolution: Add complete entries to the Statistical Group Maintenance table. Fill in all elements for each entry.

Cause: The location code does not appear in any Locations Served table entry and thus the system cannot look up the associated Branches table name.

Resolution: Add the location code to a Locations Served entry or update the location code to one that is included in a Locations Served entry.

Cause: The first location code in the Locations Served entry, to which the location code taken from the Statistical Group Maintenance table matched, is not the location code that staff expected.

Resolution: Re-sequence the Locations Served table entry such that the location code that should supply the location label for the report is first in the Locations Served entry.

Cause: The code is an "invalid" or "bad" code.

Resolution: Verify that all records contain only valid codes. For more information, see the Fixing Bad Codes FAQ.

Cause: Decision Center data is loaded into the application once every twenty four hours, usually around midnight in the library's location. The current day's transactions will be loaded in the next overnight update. See Overview of the "nightly conversation" for more information.

Resolution: No resolution is required.

Cause: Any change to an IP or a domain name needs to be coordinated with Innovative.

Resolution: Contact Innovative before an IP or domain name change. See Changing IP Address.

Cause: When you limit reports by item type, only transactions that happen on a specific item (for example, checkouts or holds placed on a specific item) are counted. Bib records have no item type, and therefore bib-level transactions (like bib-level holds) have an item type of "Unknown" and will not be included when the report is limited to any other item type.

Resolution: No resolution is required.

Cause: Your library staff backdate check-ins (for example, when clearing a bookdrop). Backdated check-ins are counted as if they were checked in at 4:00 a.m. on the backdate date.

Resolution: No resolution is required.

Cause: The library has just begun a new fiscal year and there is no, or very little, activity on which to report. Though the library might have appropriated monies and encumbered funds for outstanding orders, if no invoices have yet been paid, there is no activity to report.

Resolution: No resolution is required.

Cause: On Innovative systems, deleted records include only the record number and deletion date. Consequently, Decision Center can capture only the record number and deleted date for records deleted before Decision Center installation. Decision Center displays holdings trends from 2005 forward. Since deleted records provide no created date, Decision Center assumes a creation date corresponding to the earliest reporting date, that is, 2005. Since some deleted records were created in the years between 2005 and the time at which Decision Center was installed, the total counts for early years appear inflated. (For example, deleted records created in 2007 did not actually exist in 2005.) The inflated holdings totals normalize as the report approaches the Decision Center installation date, at which point the totals are a precise reflection of system holdings.

Resolution: No resolution is required.

Cause: An inaccurate value was entered during invoicing.

Resolution: Locate the inaccurate payment and create a transaction to correct the payment. For example, if an overpayment of $100,000 was made, manually expend -$100,000 against the affected fund(s) to correct the problem. Add a note to affected order records. Process the invoice again correctly. If you cannot locate the invoice or orders causing the problematic fund totals, contact Innovative for assistance.

Cause: An inaccurate exchange rate was entered during invoicing.

Resolution: Determine what the expenditure should have been with the correct exchange rate in place. Create a transaction to correct the payment as described above.

Cause: You are running a complex, filtered report.

Resolution: The first time you generate a report on any day, run the report without any special filtering first. This caches the report. Then filter the report as you want. Your results will appear much faster than if you generate the report with all filters in place.

Note: If your report has run an unusually long time without generating results (20 or more minutes), stop the report and start it again.

Cause: Decision Center and Web Management Reports use different metrics for evaluating some data. For example:

Web Management Reports transaction counts by codes are static counts that reflect the codes in place at the time of the transaction. For circulation reporting in Decision Center, item code data also reflects the values stored at the time of the transaction. In many other reports, Decision Center displays the codes currently present in patron and item records. For this reason, past transaction activity for records could show a different count for a given code when viewing the same report in Web Management Reports versus Decision Center.

If your library plans to make code updates and you would like to retain a report of past transaction activity displaying the code values as they exist presently, generate and save any desired Decision Center reports before making code changes.

Decision Center assigns backdated check-ins to the backdate date. The Web Management Reports assign backdated check-ins to the date of the transaction. Because Decision Center increments the check-in counts for the dates to which transactions were backdated, check-ins could grow for a given date, such as when staff are backdating check-ins for a snow day or backdating check-ins to the last open day before a holiday. Web Management Reports check-in counts are static, since any backdated check-in is counted on the date the check-in occurs.

Decision Center's tools and reports do not include the current day's data. (See Why doesn't my newest data appear in Decision Center?)

Resolution: No resolution is required. However, if your library plans to make code updates and you would like to retain a report of past transaction activity displaying the code values as they exist presently, generate and save any desired Decision Center reports before making code changes.

Cause: The Collection | Summary | Current Titles by Call Number Range and Material Type report uses bib call numbers. Libraries that have call numbers only in item records see no results for this report.

Resolution: No resolution is required.