MCGILL UNIVERSITY LIBRARIES
ACQUISITIONS CONVERSION REPORT FOR EX LIBRIS – JAN. 12, 2000
Outstanding issues:
1. INVOICES
1.2 Merged invoices. We have identified 3 situations where more than 1 NOTIS invoice record has been merged into 1 ALEPH invoice record:
1)Very long vendor invoices – NOTIS has a maximum of 72 lines per invoice. Some serial invoices have 300+ lines. In this case we make the necessary nos. of NOTIS invoice records for the invoice and link them together.
2) Non-unique vendor invoice nos. Cases where the vendor does not give us an invoice no. We have used 000 or 0000 for these so even for the same vendor we have used the same invoice no. for different invoices.
3) One vendor invoice split over library funds which reside in different processing units in NOTIS. Separate NOTIS invoices have to be made for each of these so the correct fund can be charged.
In the latest re-load each occurrence of these types have been merged into one or more ALEPH invoices (depending on the number of line items – ALEPH can have up to 150 items on one invoice). A 2-digit date suffix has been added to all of our vendor invoice numbers in order to distinguish the ALEPH invoice records in the case where more than one ALEPH inv. has had to be created for one vendor invoice no.
This has not worked well – the totaling of the lines is not working properly, and in many cases when we go to look at these invoices we get a ‘too many debit items’ message. See ELLIOT 000-98 (non-unique inv. #); or BLACKPER 96593229-98 (long invoice)
McGill’s ALEPH Acquisitions Group prefers a one NOTIS invoice to one ALEPH invoice solution provided that in the case where there are multiple ALEPH invoices to one vendor invoice number , we can search for them, even if it means scanning a list of several invoice numbers under a given vendor.
Phone call to Jerry Jan. 7, 2000. He agrees we should try to go with this latter solution and will try to resolve the searching issue. Jerry - Note that Searching by Order List – Invoice filter brings up the invoices for a particular Vendor.
Jerry’s e-mail of Jan. 11 ‘Converted NOTIS invoice records; record key’ has made one NOTIS equal to one Aleph invoice for 12.3. We will check this when we get access to 12.3.
1.2. BNA and BBS invoices. When we search for invoices under these 2 vendor codes , we get a “too many invoices” message. Also searching by individual invoice nos. brings up a ‘new’ screen not the existing invoice – see BNA 38766K-96 (9 pay statements; pd. Jun.96; NOTIS # 60625R880) . We don’t know if there are other vendor codes which have this problem.
Jan. 12.00 We will check to see if this problem has been resolved in 12.3.
1.3. Totaling problem. There is a large discrepancy between the Gen. Invoice total and the Items total in READMORE A 96082585-98 Perhaps due to credits not being properly converted?
1.4 Empty General Invoice record for BNA 15220A-98. Line item record looks normal, and has expenditure of $413.25 This is the only one we have found like this.
2. ORDER TYPE. The changes made in the latest re-load using the NOTIS ORDUNITS and L1 field has been successful – with one exception. See no. 3.1 following. Whether no. 3.1 is resolved or not please use this method to convert our orders.
Note: We have checked the methodology developed by Iowa (e-mail of Jan 5 with subject”Order Type”) and have concluded that this method will not work for us. The main reason is that we have a substantial number of orders which we treat as serials, but which have Leader, byte 07 Bibliographic Level as m. These would be turned into O Type (standing orders). A secondary reason is that new and cancelled standing orders will be converted to M Type.
3. ACQUISITION METHOD.
3.1Approval orders.
Original request: When L1 has ‘aprv’, would it be possible to have the ‘Acquisitions method’ in ‘Order Form: Order Information’ show A for approval? The chart of Instructions for Conversion of NOTIS Orders to ALEPH Order types –Nov. 2, 1999 update - included this request.
Example:
Aleph Admin Record no.: 30138 NOTIS BHK3071
LN 07-01-00NOT YET FIXED. Admin 30139 (formerly 30138) still has ‘Acquisitions method’ P for purchase.
3.2 Incorrect Acquisition method = A. This is a new conversion issue – we have not seen it before:
Some records have A for Approval but they are not approval records in NOTIS (LI=aprv). We find no links with the DORDs’ L1 or SCOPE fields and have been unable to find an explanation. (see Admin nos. 28751 (BHB9587), 29865 (BHH7228) and 17390 (AES1137).
4. PRICING INFORMATION. The pricing information in the various fields on the order and invoice records is now acceptable with one exception:
The Budget Amount which appears beside the Budget Number at the top of the Budget List (accessed by clicking on Budgets button on the Invoice Line Item screen) should be in CAD as the amount which has been debited from the Budget.
In order to prevent confusion for some of the invoicing information which must be calculated dynamically rather than imported from NOTIS fields, we will input some retrospective currency values. We will deal with other ambiguous areas of converted pricing information through staff training.
Functional issue: When a currency is changed retrospectively, only the ‘Local cost’ on the Budget transaction is protected. The ‘Local cost’ in the invoice record is updated. This may not be much of a problem when we are operational but is rather disconcerting when it happens…
5. NOTES IN ORDER LOG
5.1 Migration of Order notes:
We have not seen these yet but we understand that, with the exception of the NOTIS NV (note to vendor which will go to the same field on the ALEPH order record) the notes, including the L3/L4 field contents, will be migrated to the Order Log, preceded by a prefix based on the NOTIS note names.
5.2 Coding of fields in Order Log, e.g. $$a:
We agree with Jerry that these codes should remain for retrospective reports from the Order Log.
5.3 Iowa’s plans and NOTIS NO. notes: (e-mail of Jan. 5 forwarded to us by Jerry, Subject RE: Point Raised).
We will consider whether or not we want these notes migrated into both the Order Log and the Library note field in ALEPH.
5.4 Iowa’s plans and notes relating to serials (same e-mail as 5.2)
In the 12.2 Dec. re-load the NO: notes on serial records have already been migrated into both the Order Log and the Note field of the Subscription record. We will pass this information on to the Serials Group for their evaluation.
6. ORDER NUMBERING FOR CONVERTED RECORDS. As previously discussed, we would like the converted order numbers to be shorter and suggest the following:
Delete the first 0 and the final 01 of the suffix: e.g. Order no. 0025189-00101 sb 0025189-01 and Order no. 0025189-01301 sb 0025189-13.
Reason: we would never have more than 99 orders attached to a Bib, (first 0) and we never ordered using DIV (the final 01).
7. CUT-OFF DATES FOR MIGRATION OF ORDERS AND INVOICES
7.1. All open orders (DORDs) migrate to ALEPH.
NOTIS activity status = A,B,C,D ALEPH Order status = SV
7.2 We plan to purge closed order records (DORDs) from NOTIS according to the following information. Note that we will send Ex Libris 5 years of closed monograph orders rather than 3 as previously suggested because the different order types in NOTIS cannot be defined in the purge program.
NOTIS activity statusALEPH Order status
V vendor can't supply, canc.VC
W ret'd to vendor, order canc.LC
X cancelledLC
Z completeCLS
7.2.1 For Order Type M (monographs and non-subscription orders for all formats) –
Keep 5 years 95/96; 96/97; 97/98; 98/99; 99/00
McGill will delete all DORDs closed up to June 1, 1995
DORDs closed June 1, 1995+
- migrate to ALEPH including all Order log information
7.2.2For Order Type O (standing orders) and Order Type S (subscriptions) -
Keep 5 years 95/96; 96/97; 97/98; 98/99; 99/00
McGill will delete all DORDs closed up to June 1, 1995
DORD closed June 1, 1995+
- migrate to ALEPH including all Order log information
7.3. Invoices - load all invoices paid on NOTIS June 1, 1995+
8. ORDUNIT CONVERSION TO AUTHORIZATION GROUP CODES in Order no. 3 box on ALEPH record. Please convert as follows:
NOTIS ORDUNIT / ALEPH Authorization Group CodeLW01 / TSACQUISITIONS
LW02 / SUBSCRIPTIONS
LW15 / SUBSCRIPTIONS
MN01 / TSACQUISITIONS
MN02 / HSSERIALS
MN15 / SUBSCRIPTIONS
TS01 / TSACQUISITIONS
TS02 / SUBSCRIPTIONS
TS03 / SUBSCRIPTIONS
TS15 / SUBSCRIPTIONS
If any other codes are found, please convert to SUBSCRIPTIONS.
9. MATERIAL TYPE:
Please set up the following Order Material Types for McGill:
Mat. Type / TextM / Monograph (Print)
ME / Monograph (Electronic: CDROM, remote, etc.)
S / Serial (Print)
SE / Serial (Electronic: CDROM, remote, etc.)
CF / Software, Numeric databases, etc.
MF / Microform (film and fiche)
A / Audio (sound recordings)
V / Visual (videos, slides, DVDs, etc.)
MU / Music score (all formats)
MP / Map, Air photo, Plans (Print)
MD / Map, Air Photo, Plans (Electronic: CDROM, remote, etc.)
L / Looseleaf (Print)
P / Graphic, Picture, Photo, Realia
MS / MSS, Archive (all formats)
For closed orders: Convert NOTIS Class Codes (XC codes) as follows:
NOTIS Class code / ALEPH Order Mat. Type0010 mono / M
0020 SO / M
0030 ser / S
0040 ser / S
0050 newsp / S
0060 mss / MS
0070 map / MP
0080 films, etc. / V
0090 picture / P
0100 sound rec / A
0110 video / V
0120 micro / MF
0122 micro / MF
0130 micro / MF
0132 micro / MF
0140 score / MU
0150 electronic / ME
0152 electronic / SE
0160 general / M
0170 looseleaf / L
0180 govdoc / M
9999 techserv / M
For open orders: Convert from NOTIS bibliographic record format as follows:
NOTIS Bib Format / ALEPH Order Mat. TypeB / M
S / S
D / SE
P / MP
M / MU
U / MS
F / V
We will have staff update the Order Material Type which will not convert correctly according to this chart on open orders as required.
10. NOTE FIELD LENGTHS. There are several of these which should be longer in 12.3. We will check.
Issues we are currently investigating:
1. Claims
1.2 Do we want Batch claim box to be ticked as a default on all open mono orders?
1.3 Max. arrival days for standing Orders – can we have? do we want? default no. of days inserted during conversion (or right after); if not what happens with claims reports?
1.4 Conversion default delivery delays in Vendor record for monograph and serial orders.
2. Migration of NOTIS Budget codes/names to ALEPH codes/names - Do we want changes? How many? JS says we have to pay.
1