EOCR workflow discussion
In the Shared Bibliographic environment, the process of loading EOCRs and working with the resulting catalog records is exponentially more problematic and labor-intensive than in pre-SB Aleph. An e-book cataloging request that previously might have taken an hour to complete may now take 2 days. For example, to ensure accuracy, 3 locations (Aleph, vendor platform, and OCLC) need to be searched by 3 data elements (title, ISBN and OCLC#). Then, depending on the results, there are essentially 6 possible ways to proceed:
-IF no EOCR loaded, and if no appropriate record exists in Aleph: Import new OCLC record into Aleph
-IF EOCR was attached to an inappropriate record, and if no appropriate record exists in Aleph: Import new OCLC record into Aleph and move FAU50 data from inappropriate record to new record
-IF EOCR was attached to an appropriate record: create FAU HOLs and add URL to existing Aleph record
-If EOCR was attached an inappropriate record and if a good record is found in Aleph: create FAU HOLs and add URL to existing Aleph record and move FAU50 data from inappropriate record to correct record
-IF EOCR created a PROV record, but a good record already existed in Aleph: create FAU HOLs and add URL to existing Aleph record and move FAU50 data from PROV record to correct record; delete PROV record
-IF EOCR created a PROV record, and no other record is found in Aleph: overlay PROV w/OCLC record –
In the Shared Bibliographic environment, the acquisitions process also has become more complex and labor intensive.
Previously, the majority of firm orders were placed via our main monograph vendor YBP’s GOBI database. Subsequently, the EOCR/Electronic Order Confirmation Records were loaded into ALEPH creating new records in the system. This was a simple and relatively uncomplicated process, with the new records easily identified.
In the current Shared Bib environment, there are three types of scenarios resulting from the YBP EOCR/Electronic Order Confirmation Record loads: 1) If there are no existing records in UXU01 (no other SUL has matching holdings), then new provisional records are created (new bib/adm/order/item). 2) If there is an existing “matching” record in the system, then the acquisitions data embedded in the EOCR will merge with the existing record match, creating an order. 3) If there are multiple matching records (containing the same ISBN) being loaded, the record load fails.
When an EOCR load fails, the orders have to be entered manually. Therefore that particular order has been handled twice: in the vendor database and in ALEPH.
Another consideration is that some records contain multiple ISBNs (for print and electronic editions) resulting in incorrect matches and consequently these errors have to be identified and corrected manually.
In conclusion, the Shared Bib environment has resulted in more time spent in error identification, problem resolution, and work flow analysis and development to find more effective procedures to handle the new and more complicated tasks and processes involved in the SUL shared bibliographic catalog.
Unlike other SUS libraries, UF does not rely on the file-90 match and merge routines to handle dup checking for EOCRs. During testing UF identified a serious problem with the match and merge routines causing e-book orders to be attached to print bib records (and vice versa) because ISBNs for both formats are commonly included in the bibs of both formats. UF decided to not implement the match/merge routines and instead rely on our previous workflow for dup checking EOCRs using a Genload profile in “report” (read “test”) mode that finds all ISBN matches. This allows us to avoid the “inappropriate” record situations FAU outlines since all incoming EOCRs create a new provisional record (which we then dup check using Genload, moving orders and deleting our newly created provisional bibs as needed). This also allows us to avoid manually creating order records due to multiple matches from the match/merge routines in file-90.
- Convert EOCR file into ALEPH Sequential (File-01 & File-02)
- Run Resulting Aleph Sequential file through File-08 (specific to UF to correct fund code year extension issue)
- Run resulting file through File-90 (using fix routines, but leaving Match/Merge routines blank or at default)
- Leaving match/merge blank causes all records in file to load
- Use Genload profile “EOCR dup check” to identify all duplicates in Shared-Bib environment
- Only have to review the multiple duplicate errors from log file
- If loading print and duplicate is e-book (or visa versa) skip, leaving both records
- Move order records and delete unnecessary provisional bibs as neccessary
- Only have to review the multiple duplicate errors from log file
Another problem we faced involves EOCR and WCP loading and how item records are created. When FLVC was working with us to setup the EOCR fix routines we had the option of creating item and holding records when we loaded the EOCR records. We had previously never created items or holding records at this point in the process because Genload was not able to overlay the item records during the WCP loads. Once we began loading WCP records we discovered that Genload could not overlay the provisional item records. This resulted in staff having to manually update items and/or holdings for every WCP record. Once the problem was discovered we immediately requested that FLVC turn off item creation for EOCR loads, and print/media staff manually deleted any remaining provisional item records. It would be helpful if Genload could be enhanced to allow item record overlays.
We have four Genload Profiles for WCP loading for Coutts:
- WCP-SB- Matches on ISBN, overlays only provisional records
- WCP-PRLD-SB – Matches on OCLC#, overlays only provisional records
- WCP-RLD-SB- Matches on OCLC#, adds HOL/Item to existing records
- STO-SB – Matches on OCLC#, adds HOL/Item to existing records or creates new records
Approval/Firm Orders loading workflow
- Run file through WCP-SB
- Loads only those records where there is a single ISBN match w/ a provisional record
- Review Log file to correct errors so WCP-PRLD-SB & WCP-RLD-SB can be utilized
- Insert OCLC number in provisional records for problems so that overlay can take place
- Run problem records through either WCP-PRLD-SB or WCP-RLD-SB as appropriate
Standing Orders (C/SEPS & Analytics)
- Run file through STO-SB
- Should have no problem records as every record is either a match (add HOL/ITEM) or new record.