...
| Case# | Issue | Notes | Reported | Status | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 00237034 | IZ record has single OCLC number but doesn't link to the NZ during migration when there is a record in both the NZ and CZ with a matching OCLC number | This is caused by the fact that there are multiple matches in the NZ for this record, so there isn't a way to determine which record the IZ record should link to. As a possible solution: remove electronic records from the OCLC load that also exist in SFX to prevent multiple records with the same OCLC number appearing in the NZ. |
| |||||||
| 00230389 | Extra holding is created without call number information or items attached, but contains LIB HAS statement | This happens during the migration if you are using summary statements from the bib record, and your summary statements do not contain any subfield with the location code that represents the holding. There isn't a way to determine which holding the statement should be attached to, so a new holding is created. CO is working on a fix for bib records that have one holding attached. The best fix for bib records with multiple holdings attached is to include a location subfield in the summary statement. Or, the summary statement can be retained in a local note in the bib record instead of in the holding record. |
|
| ||||||
| Not receiving report confirmation emails or emails sent to a printer | Ensure that all email addresses that you expect to receive mail are included in the General Configuration | Configuration Menu | External Systems | Allowed Emails table. |
No further resolution required | ||||||||
| 00208329 | Items on reserve at the time of migration migrate with the reserves location as the permanent location | Script developed for post-migration fix. Details on how to implement this are available here: Updating item locations for items that were on reserve at the time of migration |
| |||||||
| $9LOCAL protection did not lead to successful migration of local notes. | Some III export tables add a '.' to the end of some of these MARC fields, resulting in '$9LOCAL.' at the end of the MARC field. Because of the additional '.', this field was not treated as a local field in the migration. In order to resolve this issue, submit a ticket with III and ask for all full stops/trailing '.' characters be removed from your export table. |
|