I’m wondering if anyone else has had problems with the vendor records for Vox books including the print ISBNs. This is what’s happening to us:
Somehow extra ISBNs are adding into the Vox records when we download from B&T, and then our POs are attaching to those ISBNs and when we send the PO via EDI, they think we are ordering the regular print because the PO attached to the regular print ISBN, even though they are z’d out, AND even though the Vox records DO NOT have those ISBNs before we download from B&T.
So either a) Polaris is adding those ISBNs when we import the vendor records from B&T, OR b) something at B&T is adding the ISBNs in and causing them to attach to existing records in Polaris, when the existing records in Polaris are not the same format.
Has anyone else had this problem?
So this is coming from a Sierra library, but we’ve been in the habit with B&T of setting MARC profiles in 360 to delete all 020 fields and then add in a new 020 mapping the TS360 Data ISBN field to it specifically to eliminate extraneous numbers that can sneak into some of their records.
That was mostly due to AV items in olden times where they would use internal database numbers in cases where something only had a UPC code in their database, but the practice stuck with us when we copied one of those templates for the newer Vox one and it seems to be doing the trick.
Hi Elaine,
I have received a report of Vox using the OCLC record for the print record instead of deriving a new record in OCLC. These records came from Vox instead of B&T. Librarians at our consortium need to derive new records when this happens. It may be that B&T is taking the records from OCLC before a new record is derived.
Rachel Fischer