Recall/Hold Load – Reported Data Migration Problems

 

04/09/2002 – Will ‘Items Available for Pickup’ window contain appropriate information after circ batch job?

Many of the recall/hold items that were migrated are actually available; that is, there is an outstanding recall against the material, even though it has a status of 'Not charged'.  These items are not listed in the patron's 'Items Available for Pickup' window.  Will they appear in the 'available' window once we've run the circulation batch jobs?

Endeavor Response 04/08/2002:

Please also run the circ jobs in the very near future. Thanks, Adriana

 

Charges Load – Reported Data Migration Problems

 

04/05/2002  Archival Charges file is Missing Patron ID

Our Archival Charge transactions are missing a very key piece of information - none of them have an associated Patron Id.  Patron Id and Item Id are the two of the key pieces in re-creating a historical transaction (along with due date and discharge date).

Endeavor Response 04/08/2002:

After doing some digging, I discovered the reason for the missing Patron Information.  The load program, as a default, enters only the Patron Group of the associated patron record; it does not load the Patron ID for reasons of patron privacy.

**Archival Charges re-loaded on 04/09/2002 – fix to Charge ID verified.

 

04/05/2002  Is Item Overdue Status produced by the circulation batch job?

Overdue transactions have a status of 'Charged' instead of 'Overdue+'.  See attatched print screen of two records.  The first Charged Item Index screen was generated yesterday in the Charges load to 'yaledb'.  The first three titles on the screen have been overdue for several months, and have received multiple overdue notices, yet the status associated with the item is simply 'Charged'.

 

04/05/2002  Will Renew Date and Renew Time Load?

According to the Charges SIF (see attached 'ChrgTrans.SIF' doc), two of the fields that are migrated are the Renew Date and the Renew Time.  Neither of these fields seems to have loaded.  If you pull up the 'Charged to' window in the Item record, the Renewal Date / Renewal Due Date box is empty (see attached 'renew example.doc').  There are also no transactions in the renew_transactions table.  Do these values get loaded?  And if so, where?

 

Fine/Fee Load – Reported Data Migration Problems

 

4/03/2002Can the Posting Reason, Barcode, Due Date, and Billed Date be loaded to their respective fields?

Fine/Fee Posting Reason, Barcode, Due Date, and Billed date are not loaded to their respective fields.  All fields are loaded to the description field.  Can these fields be parsed to their appropriate places?

Endeavor Response 04/04/2002:

Several fields are taken from the NOTIS records and placed into the Fine/Fee note field, including the item Barcode.  These notes are not parsed by the loader, so the associated item will be available through the note, not the item field.  The exception to your questions is the Fine/Fee Type, which did load into the records in the corresponding Voyager field.  You can change the descriptions of the Fine/Fee Type codes in Sys Admin.  The loaded codes were: IL,MS,OV,RF,RE,RP,RR.  Currently, the names for all of these codes are "Added by Fee load".

 

4/03/2002 – Can we include Summary Comments in the Fine Note field?

Is the extract supposed to include the Comments (notes) from the Notis Patron Accounting records?  I haven't been able to find one of these that is associated with a fine/fee that migrated.  (I have a couple examples from fine/fees that didn't make it in do to a lack of a matching barcode).  Specific fields include:

PAIDCMTS - bytes 112 – 141

PAIZCMTS - bytes 121 – 229

Endeavor Response 04/05/2002:

No, the fine/fee extract uses the output file from LPA810J.  I took a look at the output file from

LPA810J and I didn't see any data from PAIZCMTS.

 

 

4/03/2002 –Are all Miscellaneous charges being migrated?

Question: Miscellaneous charge fines were not migrated in one record.  All other fines and fees associated with this patron are migrating correctly, and I have found other records where the misc. charges migrated.  This patron only has 1 barcode in Orbis, so this is not the result of a dropped patron barcode, etc.  Any ideas?

 

Patron Barcode = 0442890711; $150 worth of Miscellaneous Charges are dropped.

 

Orbis Fines and Fees

----------------------------

 Essays           (Montaigne, Michel de) CC YL TL/FAC       7.50

 Nyelv es lelek     (Kosztolanyi, Dezso) SC YL TL/FAC      20.00

 Magyar irodalom modern iranyai (Bori, ) SC YL TL/FAC      20.00

 Magyar Muzsa; kolteszeti antolog (UNAV) SC YL TL/FAC      20.00

 Magyar Muzsa; kolteszeti antolog (UNAV) SC YL TL/FAC      20.00

 Korkep.                   (UNAVAILABLE) SC YL TL/FAC      70.00

            [...intervening lines deleted...]

 MISCELLANEOUS CHARGE BILLED 11/01/1995  SC                50.00

 MISCELLANEOUS CHARGE BILLED 11/01/1995  SC                50.00

 MISCELLANEOUS CHARGE BILLED 11/01/1995  SC                50.00

 

Total:  $597.50

 

Voyager Fines and Fees

-------------------------------

Last fine = $20.

Miscellaneous charges do not appear.

 

Total:  $447.50

Endeavor Response 04/03/2002:

I found the missing $150...  It is recorded on the log file (voyage1fineslog.yl).  They were rejected because they didn't contain patron charge IDs.  There were 375 fines without patron charge ID.

** Yale response: Please build the patron charge id by extracting the Social Security number and adding a final digit of  '1'.

 

 

4/03/2002 – Can we use a barcode mapping file to load Fine/Fees associated with dropped patron IDs?

The Patron conversion programs will only load one Charge ID per patron category.  As a result, many of our Charge Ids that had associated Fines & Fees were dropped in the patron load.  Would you be willing to use a mapping file to load these Fines & Fees to the patron ID that was migrated to Voyager?

Endeavor Response 04/03/2002:

I could certainly map the patron barcodes for this file as I'm doing for the

charges load.  It would be best if we used the same mapping file, if that's acceptable to you.

** Yale confirmation 04/03/2002 – we will provide a single mapping file for the production Fine/Fee and Charges Load

 

4/03/2002 –Fine/Fees associated with duplicate barcodes are rejected

Fines & Fees associated with patrons that have duplicate barcodes are rejected by the loader.  We have many patrons, for example, with a ‘Faculty’ id and a ‘Staff’ id that use the same Charge ID.  In order to remedy this situation, YUL will add a suffix of EXP to the expired charge id associated with the patron.  This will not clear up all Fine/Fee loading problems, but should take care of the majority.

 

Patron Load - Reported Data Migration Problems

3/22/2002 - Can we load 'Hold mail' flag?

In Orbis, the patron's permanent address is the address that is used to send out notices. The hierarchy in Notis is 1) e-mail 2) designated 3) secondary. Both designated (loads as 'permanent') and secondary (loads as 'temporary') addresses are active in Orbis. Voyager, of course, puts the temporary address above the permanent address in its notice hierarchy: 1) email 2) temporary 3) permanent. It looks like our print notices will get sent out to the wrong address. Is there a way to load the 'Hold mail' flag for the temporary address?

Endeavor Response 3/26/2002:

 Yes, the ‘Hold mail’ flag can be set to ‘H’ to indicate that notices should not be sent to this address.

 

Order Load - Reported Data Migration Problems

3/20/2002 - Pending vs. Approved?

What are the ramifications of loading our Order records as Pending or as Approved?

Endeavor Response 3/20/2002:

If Orders are loaded as Pending, then you can still go back an clean up any data that is out of sync due to the migration. Amounts for pending orders show up as 'pending commitments' in the fund record, but do not affect the Fund Total. If orders are loaded as 'Approved', no changes can be made to Order records after the load. Sites normally load their orders as pending.

** Yale decided to load orders as pending.

 

3/19/2002 - Multi-division Orders not migrating correctly

All divisions of multi-division order records are not migrating correctly. Only the first division is migrating. According to #17 of Appendix B-3 in our Contract, all divisions of a multi-division Order should be migrated. (This is indicated in the Open Order section of our DMQ).

Example: PO Number : 1FPC5565.

In Orbis this PO has two divisions with two different location codes and two different fund codes:
Div 001 - location = ccl, fund code = CCLANON02.
Div 002 - location = sml,phi, fund code = PHILMON02

 

3/19/2002 - Acq Client closes with run-time error 40002 when looking at Subscription Patterns

Client closes with Run-time error 40002 "Invalid Index Value" when clicking on 'Subscription Pattern' button Line Item display 'Type' tab. This is true for every serial I have tried. Is there an index that needs to be re-linked to the client ID after the order load?

Example: PO Number: 1ADF8110.

View 'Type' tab in Line Item Details. Click on 'Subscription Pattern'.

Endeavor Response 3/20/2002:

This is a known bug with a work-around in the Sysadmin security setup.

 

3/19/2002 - Please change order of notes loaded to Line Item Note field

Occasionally staff have entered notes in the Orbis order record in such a way that the full note actually ran on between two different note fields. For example, the NO field would say something like "Last two volumes shelved in the Reading" and the Source field would say " Room on the left". Run together they make one big note. Because the notes are not extracted and loaded into Voyager in the order they appear in Orbis, the sense of the note gets lost. Would it be possible to load the notes in the following order:

1. L1 (field ORDLIB1)

2. VA (field B51F)

3. NV (field B52F)

4. NO (field B53F)

5. Source (field B54F)

6. Reference (field B55F)

7. Division Note (field B60F)

8. 'N' Statements

 

3/19/2002 - Currency conversion question

What will the production migration of currency codes look like (since we're coming up in version 2001)? If we're paying for material in British Pounds, will the currency code migrate as British Pounds? Will the pay amount still be converted to US dollars?

 

Vendor Load - Reported Data Migration Problems

3/06/2002 - Please Change source for Vendor Name

The Vendor Name field is currently coming from the first address attached to the Notis Vendor record. As a result, several of our Vendors are being given the Name associated with the Pay address, which is usually the name of a bank, not the name of the publisher/vendor. Would it be possible to take the Vendor Name from the address that is flagged as the Order Address?

Example: Orbis Vendor Record 6MANU1101 - Vendor Name should be Juan Manuel de Castro, not Banco Popular de Puerto Rico

Endeavor Response 3/08/2002:

The Vendor Name will come freom the 'order' address in the re-load on Monday.

**Vendor Name source verified in reload 3/11/2002.

 

 

MARC Load - Reported Data Migration Problems

3/08/2002 - Please Suppress Bibliographic records associated with unlinked items

Unlinked items currently do not display to the public in Orbis. Due to the nature of the information they contain, we would like to load the bibliographic records associated with these items as 'Suppressed'.

 

2/22/2002 – 99,999 Suppressed records - coincidence?

I've got a question for you about the extract and load of bib records marked for Suppression. I ran a quick report and discovered that there are 99,999 suppressed bib records in 'yaledb'. This could be a coincidence, but it could also be that we've run up against a max for the number of suppressed records that can either be extracted or loaded (since 99,999 is a common max in MARC-land). Do you guys know if there's a max on either end?

Endeavor Response 3/03/2002:

I did a count of all suppressed bib. records in the last extract files and the total count is 100,040. I think this is just a coincidence.

 

2/22/2002 –"UM=" notes migrating to staff notes, not public notes

Most "um=" notes are being converted to |x staff notes instead of |z public notes. However, some notes appear to have migrated correctly. (BTW - I checked the bad record examples in yaledb on epreservation; these all loaded correctly in the first test load).

BAD:
Orbis: DBR5595, HoldID: 1814935;
Orbis: ABY9698, HoldID: 467613
GOOD:
Orbis: AAB1412, HoldID: 19432;
Orbis: FFS7894, HoldID: 2999990

Endeavor Response 3/11/2002:

Extract program for copy holdings notes has been fixed. Holdings re-extracted and loaded to the 'yaledb' dress rehearsal migration database.

** Fix to notes reviewed and holdings migration specs signed off 3/12/2002.

 

2/22/2002 – Unlinked items not present in database

All of the following unlinked item records are not present in the dress rehearsal database. They are all present in the 'yaledb' on epreservation, created during our December extract and load.

See Science (item 39002012181534) and Nature (item 39002012181385).

Endeavor Response 2/25/2002:

Thank you for pointing out this omission. In the "pre-test" extract & load, there were files called unlkbib.yl1 and unlkmfhd.yl1, which contained these Unlinked records.

**Unlinked items verified in reload 3/11/2002.

 

2/22/2002 – 006e display problem

We have found display problems with the 006e (Printed Map) and 006f (Manuscript Map) fields. I strongly suspect this may be a display issue on the client side, not a data migration issue. In both of the sample records described below, the 006 looks fine in the main bib record view, but the values aren't carried into the pop-up label view when you click on the '006' button.

See Orbis record: FNW2417YL, Bib ID: 4685377.

 

 

 

Reported Data Migration Problems - Correction Test Load

1/17/2002 –Change terminology of 852$2 to 'localyale'

Our catalogers have requested a change in the terminology we're using to signify the 'oldyale' call numbers in 852$2. Many of the Class 'T' call numbers are local yale call numbers, but are not, strictly speaking, Old Yale. Would it be possible to change the phrase in 852$2 to 'localyale' instead?

Endeavor Response 2/05/2002:

852$2 has been changed from 'oldyale' to 'localyale'.

**Verified in extract 2/05/2002

 

1/17/2002 –Please strip 940 from provisional records before converting to USMARC

The routine that converts provisional record tags to USMARC tags (i.e. 924 -> 245) is converting our 940 fields to 500 note fields. The 940 is one of the fields that we'd like stripped from our records. Would it be possible to strip the 940 before running the provisional records through the tag conversion program?

Examples:

Orbis Key: PMD9717, Endeavor Bib ID: 109051

Orbis Key: PMD9803, Endeavor Bib ID: 109134

Endeavor Response 2/05/2002:

The 940 tag is now stripped from provisional records during the extract.

**Verified in extract 2/05/2002

 

1/17/2002 –Withdrawn status display confusing

Items with Status 'W' correctly migrated with the status 'Withdrawn'. However, because the items already contain the Status 'Not Charged', this is the status that displays in the Hierarchy view. Is there any way to make 'Withdrawn' the first, or dominant, status associated with the item record?

Endeavor Response 2/15/2002:

The order of the status display is not something we can change

1/15/2002 – Replacement string for "see k=" searches not done correctly

"um=" public note string replacement for "see k=" notes not done quite correctly. The string prior to the Orbis key has been replaced

correctly. However, according to the specs the string 'YL' should be appended to the Orbis Key. (This important so that patrons can correctly search for the right record).

See Orbis Key: FFT6693, MFHD ID: 21903.

"For circulation information, do a Keyword search for ACA8750" should be

"For circulation information, do a Keyword search for ACA8750YL."

Endeavor Response 1/15/2002:

I'll send Mei the information about issue #1. This one should be pretty straightforward.

**Verified in Extract 02/05/02

 

1/15/2002 – Suppressed MFHDs not sorting after Unsuppressed MFHDs

Suppressed MFHDs are not sorting after unsuppressed MFHDs in the Hierarchy view or the Get Holdings view. MFHDs appear to be sorting in straight alphabetic order, instead.

See Orbis Key: AGG5238, Bib ID:12.

Endeavor Response 2/06//2002:

Endeavor is unable to display the suppressed holdings last in the record because the client software automatically resorts the display, despite the fact that the suppressed records are in fact stored last in the system.

**Kalee Response 02/06/2002 - go ahead and sort these within each call number.

 

1/15/2002 – $k 'Suppressed' Stamp not displaying in Hierarchy view when no call number

The 852$k stamp of 'Suppressed' is not displaying for Suppressed MFHDs

that do not have call numbers in the Hierarchy View.

See Orbis Key: AGG5238, Bib ID: 12

Endeavor Response 2/06//2002:

This is how the software works. The $k stamp will display if you put in an empty 852$h, but that is the only way to get it to display.

**Kalee replied 03/1/2002 - please add an empty 852 $h to suppressed holdings with no call numbers

 

Reported Data Migration Problems - MARC Load Test 1

 

12/17/2001 - Catalog Status 'd' migration in Voyager

In Notis a Catalog Status of 'd' generates the OPAC message "Search under individual Author/Title for items in this series." The OPAC message also suppresses display of any other holdings information from the Copy Holdings record. This message is lost in the current migration.

For example see:

Orbis ID: ACF2289

Voyager ID: 529597

Title: Journal for the study of the Old Testament. Supplement series.

**Reported to Endeavor 12/17/2001.

Endeavor response 12/20/2001:

We will try to add an 852 |z public note of "Search under individual Author/Title for items in this series" for Cat Stat ‘d’ holdings.

12/17/2001 - Drop Additional 9xx fields?

The following fields are currently migrating to Voyager: 905, 909, 929, 936. Should these be added to the list of 9xx fields we will drop?

**Yes, per Joan Swanekamp - Reported to Endeavor 12/21/2001.

12/17/2001 - Class 'Z' statements not inheriting appropriate call number

Class 'Z' copy statements with no call numbers in Orbis are being populated with incorrect information, not due to a flaw in the program, but because the call number is being copied from the previous 'Z' suppressed copy, whose location may or may not use the same classification scheme. Migrated Class ‘Z’ statements that do not have call numbers in Orbis should not inherit a call number during the extract.

For Example: AGG5238

1st copy statement is "1Z CN |a law |b SSB |c Sa49;1992"

2nd copy statement is "1L CN |a ssl,p2 |b HB171.5 |c +S26;1992;(LC)"

3rd copy statement is "1Z CN |a ccl |b SSB |c Sa49;199"

** Reported to Endeavor 12/17/2001.

 

12/17/2001 - 'Suppressed' holdings not identified in Hierarchy View

Class Code 'Z' copy statements migrate as suppressed holdings records in Voyager. Unfortunately, it is impossible to tell from the Voyager Hierarchy View which holdings are suppressed.

For Example see AGG5238YL, "Hierarchy View".

Endeavor response 12/07/2001:

We will add a subfield $k ‘Suppressed’ in the next test load.

12/17/2001 - Oversize '+' LC Call Numbers Not Sorting Correctly

Yale oversize call numbers are not sorting properly in the LC index. Yale Call oversize materials contain a '+' sign before the call number cutter to indicate shelf location. In the NOTIS LC index, call numbers like PJ2 A46 and PJ2 +A46 sort together. In Voyager, however, all the '+' cutter numbers sort A-Z first, followed by all the non-'+' cutters.

**Reported to Endeavor 12/14/2001

Endeavor response 1/04/2002:

The '+' is non-standard and therefore is not accommodated in the LC sorting routines. Options are:

  1. Move the plus sign to the end of the call number;
  2. Move the plus sign to a prefix (subfield k);
  3. Move the plus sign to a suffix (subfield m);
  4. Add the plus sign to the location code, and Yale can create new locations;
  5. Other options that the customer may suggest

12/13/2001 - Items with Status 'W' not loaded with Status 'Withdrawn'

The 'Special Programming in Extract document' specified that extracted items with a status of 'W' (for Withdrawn) be loaded with a status of 'Withdrawn' in Voyager. Looks like this didn't happened. Example:

Orbis barcode: 39002033390353

Voyager item no: 2788296

Item Status: Not Charged

Other examples: 39002010044379, 39002010044387

**Reported to Endeavor 12/13/2001

Endeavor response 12/20/2001:

Items with Status ‘W’ will load appropriately in next test load.

 

 

12/13/2001 - Left and Right brackets in Call number Not Displaying Correctly

Orbis Key: DAR3176

Voyager Holdings: 1725242

Original call number is: |b Film |c B974;reel;6,;no.;[29b]

Voyager call number is: |h Film |i B974 reel 6, no. 29b) -- I think this is a superscript right paren

SQL Blob view is: |h Film |i B974 reel6, no.29bM -- obviously translated to 'M' in the Access display

**Reported to Endeavor 12/13/2001

Endeavor response 12/20/2001:

This problem is under investigation.

 

12/03/2001 -NOTIS Class Code -> 852 1st indicator conversion?

Orbis FHM7763

Voyager Holdings: 3661645

Title: ABC pol sci on disc

The original Copy Holdings Statement had a Class Code of 'L' for LC, yet this copy statement migrated to an 852 field with first indicator of '8', for Other. Do migration programs check for the LC call number algorithm during the migration (this call number doesn't exactly follow LC convention)?

Endeavor response 12/07/2001:

Yes indeed, our load programs check the structure of the call numbers. If the incoming call number isn't REALLY an LC number, it will be changed to the type 'Other.'

11/30/2001 - 007 Field Not Displaying Correctly

The architecture of Jefferson country [computer file].

Orbis FPA6522

Voyager 4558441

007: a number of fields did not seem to convert correctly

Orbis: COLOR: c / Voyager: Color g (gray scale)

Orbis: DIM: g /Voyager: Dim: a

Orbis: Sound: a /Voyager: No attempt to code

Endeavor response 12/06/2001:

In the Voyager folder on your PC, go into the ‘bmarcfix.cfg’ file under MARC, OCLC, RLIN, and the additional bmarcfix.cfg file that is not under one of the preciously noted directories and make the following changes:

[007_ComputerFile]

Specific Material Designation, 007ComputerMaterial, 1, 1, a

Original vs. Reproduction Aspect (OBSOLETE), 007ComputerReproduction, 2, 1, _

Color, 007ComputerColor, 3, 1, a

Dimension, 007ComputerDimensions, 4, 1, a

Sound on Medium, 007ComputerSound, 5, 1, _

Image Bit Depth, 007ComputerImageBitDepth, 6, 3, ---

File Format, 007ComputerFileFormats, 9, 1, a

Quality Assurance Target(s), 007ComputerQATarget, 10, 1, a

Antecedent/Source, 007ComputerAntecedent, 11, 1, a

Level of Compression, 007ComputerCompression, 12, 1, a

Reformatting Quality, 007ComputerReformattingQuality, 13, 1, a

 

 

11/30/2001 - Suppressed Copy Holdings Statements Not Sorting Correctly

Surprised by sin PAG1117

Location order: On Voyager the order from top to bottom is:

ccl, ccl, ccl, sml

According to the customization specs it should be sml, ccl, ccl, ccl since all the ccl's are suppressed.

** Reported to Endeavor on 12/03/2001

Endeavor response 12/20/2001:

This problem is under investigation.

 

11/28/2001 - Oracle Vendor Code Loaded in Vendor Name Field

Vendor Code: 69HAR15003

Voyager uses the Oracle Vendor Number (an 8-digit non-mnemonic code) as the Vendor Name. There is a field in the Voyager vendor record called Institutional Id. That's where the Oracle Vendor Number should be loaded. Right now, there is nothing there.

** Reported to Endeavor 11/30/2001

Endeavor response 12/20/2001:

This problem is under investigation.

 

11/28/2001 - Copy Holdings Statement Note conversion problems

ORBIS FFS3312

VOYAGER HLD 3175946

ORBIS a cispr; a um=(Section X-9)

VOYAGERz Current issues in SML Periodical Room.;z (Section X-9)on X-9)-9)

Messed up |z -- "on X-9)-9)"

ORBISDBK4839

VOYAGER HLD 1831804

Very bad note conversion.

More examples found: DBJ8670, dbj8932, dbk0215

** Reported to Endeavor on 11/30/2001

Endeavor response 12/20/2001:

This problem is still under investigation.

11/28/2001 - Degree symbol in Call Number not migrated correctly

ORBIS FHX2118.

VOYAGER HLD 3767873.

NOTIS holdings record has a space in the primary location bac ,rb which I

fixed. How this happened is a mystery. BUT degree symbol in call number did

not transfer as degree symbol to Voyager. Looks like ae.

 

11/28/2001 - Bad Character in Call Number dropped

ORBIS FMQ5893

VOYAGER HLD4739176

Bad character in call number dropped. This is probably good - but it's the

first time I found a dropped char in the call number.

11/27/2001 - Do we want Title level notes from Holdings records?

Audrey Novak: I noticed that the NOTIS title level notes (A11 from the holdings) are

being mapped to the 948. Do we want these there, too? Do we want them at

all?

 

11/26/2001 - Can Switch M-date for A-date in 852$d?

Suzanna Lengyel: I am unhappy (mildly unhappy) about the fact that of the TWO dates in each

Receipt Statement (the M-date and the A-date) the M-date DOES NOT GET

CONVERTED, but the A-date DOES. For example, see OPR 001FJT3548.

In other words, the M-date (Machine-date or Mod-date), the date when the

item was actually received, is lost in the conversion. A long-ago expired

Action Date is converted.

11/20/2001 - 949 note field dropped

Endeavor Response 11/27/2001:

We will map 949 to 948 note field in next load.