380 likes | 390 Views
Understand and compare data migration reports for efficient data transfer. Ensure accuracy with system checks and error resolutions provided in the report.
E N D
Data Review: Understanding the Data TestLoad Migration Statistics Report Shared Library Services Platform Project Maggie McGee
Data Testload Migration Report from ExLibris • Understanding the spreadsheet • Tabs • Bib_inventory • Vendor • Fund • Fund_tx • P_order • Invoice • Parton • Loan • Request • P2E
Data Testload Migration Report from ExLibris • Understanding the spreadsheet continued • Counts • The number of counts based on each tab: • Are from the time of each institution’s data pull • Will not match current numbers in Aleph if major changes have been made • Some reports can be run by an institution before the final data extract before go-live for more accuracy for comparing statistics* • Code/ID • Bib_inventory tab code/id = Aleph BIB Sys No. • P_order tab code/id = Aleph ADM Sys No. • Invoice tab code/id = Vendor code and invoice number • Reason for reject • Explains why the record(s) were rejected
Data Testload Migration Report: Bib_Inventory Tab • Do the counts match in Aleph and Alma? • Number of Bibs* • Number of Hols • Aleph GUI Report by Collection Code • Number of Items* • Aleph Reports: I am waiting for OLIS to confirm if they will be able to extract reports for the total number of bib, holdings, and item records for each institution before the next data extract before go-live. • GUI reports in Aleph either failed when extracting the report due to size or very time consuming
Data Testload Migration Report: Bib_Inventory Tab • Does the Link Resolver countseem correct? • Number of portfolios comes from the Link Resolver or 360 form • Checking the Link Resolver Portfolios in Alma is a way to check is the count number is correct*
Data Testload Migration Report: Bib_Inventory Tab • Do the counts match the P2E form? • Number of portfolios from the ILS • Number comes from the P2E form • Check the counts number against the number of Portofolios on the P2E form • Number of Packages/DB from the ILS • Number comes from the P2E form • Check the counts number against the number of Packages/DB on the P2E form • Note: Oneonta’s number of Portfolios is off by 1. We didn’t migrate any DB this migration.
Data Testload Migration Report: Bib_Inventory Tab • Do the counts match the Link Resolver form and in Alma? • Number of Packages/DBs from Link Resolver • Check the number of Packages/DBs on the Link Resolver or 360 form against the count number
Data Testload Migration Report: Bib_Inventory Errors • Code/ID: Bib_inventory tab code/id = Aleph BIB Sys No. • Error: An ADM record without a BIB record has items • There are item records attached to an ADM record without a bib record. • The records will not migrate to Alma • Use the Aleph Bib Sys No. to find the records in Aleph
Data Testload Migration Report: Bib_Inventory Errors • Possible Solutions: • The item records need to be deleted or attached to a bib record in Aleph OR • Delete the ADM #s in Aleph
Data Testload Migration Report: Bib_Inventory Errors • Error: Cannot generate mmsid. Missing bib-library sequence mapping in alephe_taburm_bib_libs_seq_mmsid • The BIB library that the ADM is connected to is a holding library and not a BIB library • The records will not migrate to Alma • Use the Bib Sys No. to find the records in Aleph • Possible Solution: Connect the ADM record to the BIB record*
Data Testload Migration Report: Bib_Inventory Errors • Error: An invalid XML character (Unicode: 0xe) was found in the value of attribute "tag" and element is "datafield". SAXParse. • There is a character in the record that cannot be processed with the Oracle SAX parser • The record is not exported from Aleph to Alma • Use the Bib Sys No. to find the records in Aleph
Data Testload Migration Report: Bib_Inventory Errors • A Unicode character in the bib record is not being recognized and has been rejected by Alma during the migration process • Possible Solution: Recatalog in OCLC and overlay the record in Aleph
Data Testload Migration Report: Vendors Tab • Did the correct number of vendor records migrate?* • The counts are the number at the time of the institution’s data pull • Run a report in Aleph to check that the number of vendors match in Aleph and Alma
Data Testload Migration Report: Vendors Tab • Print a list of vendors from Aleph • Search by All, Not Active, orActive • Scroll through the results list from A-Z • Press Function key F11 • Print
Data Testload Migration Report: Vendors Tab • Verify the number of All vendors in Alma matched the testload migration report • Using the persistent search box, search Vendors>Names>[Leave blank] and click the magnifying glass or hit enter • If the Vendor Status does not default to All, change the Vendor Status to All • The total of vendors will display
Data Testload Migration Report: Fund Tab • Lists all the funds & ledgers migrated from Aleph to Alma • Compare the budget codes in Aleph to funds & ledgers in Alma • The counts are the numbers at the time of the institution’s data pull • View Funds in Aleph acquisitions to compare numbers in Alma • Oneonta noticed we had a lot more active funds than expected • Solution: Oneonta closed the funds in Aleph to non-active
Data Testload Migration Report: Fund_tx Tab • Do the numbers in Aleph and Alma match? • These counts are the numbers at the time of the institution’s data pull • Run reports in Aleph by transaction type to verify counts • Disencumbrance = Invoice transaction type in Aleph • The number may not match because transaction types may have changed since your institution’s data pull date.
Data Testload Migration Report: Fund_tx Tab • Aleph reports by transaction type: Acquisitions>Services>Retrieve and Print Acquisitions Records>General Retrieval Form (acq-02-01) • Aleph report: Acquisitions>Services> Retrieve and Print Acquisitions Records >Print Acquisitions Records (Acq-03)
Data Testload Migration Report: P_order Tab • Do the count numbers by order types in Aleph and Alma match? • These counts are the numbers at the time of the institution’s data pull • The By Order Types are the order types each institution defined on the Order Type tab of the migration form • Run reports in Aleph by order type and material format
Data Testload Migration Report: P_order Tab • Aleph report by transaction type: Acquisitions> Services>Retrieve and Print Acquisitions Records General Retrieval Form (acq-02-01) • Order Type (M, O, S) • Material Format (BK, SE, DA, etc.) • Aleph report: Acquisitions>Services> Retrieve and Print Acquisitions Records> Print Acquisitions Records (Acq-03) • Note: Oneonta’s numbers in Aleph did not match with the count number
Data Testload Migration Report: P_order Tab Errors • Code/ID = Adm Sys No. Use the first 9 digits • Error: Subscription related to a deleted adm/bib. Subscription ignored. • Use the Aleph Adm Sys No. to find the records in Aleph • Possible Solution: Do nothing because the order record will not migrate
Data Testload Migration Report: P_order Tab Errors • Error: PO vendor_code is empty.Vendor code origin: Z68-VENDOR-CODE. PO ignored. • Use the Aleph Adm Sys No. to find the records in Aleph • Vendor is empty in the order record • Possible Solutions: • Input vendor in Aleph OR • Delete the order record • Note: if the vendor does not exist in Alma, add the vendor in Alma after you have input it into Alma. Vendors will not migrate at cut-over.
Data Testload Migration Report: P_order Tab Errors • Error: PO related to a deleted adm/bib. PO ignored. • The ADM and/or BIB records for an order record have been deleted • Use the Aleph Adm Sys No. to find the records in Aleph • Possible Solutions: • Do nothing because the order record will not migrate OR • Delete the order record and ADM
Data Testload Migration Report: Invoice Tab • Do the count numbers in Aleph and Alma match? • These counts are the numbers at the time of the institution’s data pull • Run a report in Aleph acquisitions by order status and order type • Use the Aleph vendor code and invoice number to find the record in Aleph • Note: Oneonta’s closed invoices totals in Aleph do not match what is in Alma. We opened a Salesforce case.
Data Testload Migration Report: Invoice Tab • Aleph report: Acquisitions>Retrieve and Print Acquisitions Records>General Retrieval Form (acq-02-01)
Data Testload Migration Report: Invoice Tab • Aleph report: Acquisitions>Retrieve and Print Acquisitions Records>Print Acquisitions Records (acq-03)
Data Testload Migration Report: Invoice Tab Errors • Error: Invoice without lines. ADA 509142. Invoice ignored. • No line items in Aleph • Invoices were not created in Alma • Use the Aleph vendor code and invoice number to find the record in Aleph • First 9 numbers of the Code/ID on the Testload Migration Statistics spreadsheet • Possible Solutions: • Add line items if you have that information OR • Do not do anything and the invoice will not be migrated into Alma
Data Testload Migration Report: Invoice Tab Errors • Error: Invoice header with empty status and date. Invoice-line rejected: UPS 0000826240105 00001. • Use the Aleph vendor code and invoice number to find the record in Aleph • Possible Solution: Add status and date
Data Testload Migration Report: Invoice Tab Invoice/Invoice line Migration Rules : Alma Structure • In Alma invoices are described by invoice_details (mandatory) and invoice_lines (not mandatory). • The invoice structure in Aleph is based on Z77 records (Invoice header or general invoice) and Z75 records (invoice payment or line item). • There may be Z77 records without related Z75 records, but a Z75 record must have an associated Z77 record. Connection between Z77 and Z75 records is a match between VENDOR-CODE and INVOICE-NUMBER fields available in both record types. • Based on this structure, the migration creates:One Alma Invoice for each Aleph invoice header (Z77) : Aleph invoice headers without attached invoice line item should not be migrated • One Alma Invoice Line for each Aleph invoice line item (Z75) matching an invoice header (Z77). • Invoice migration ensures the total invoice amounts are correct, not necessarily the net breakdowns.
Data Testload Migration Report: Invoice Tab Mapping Rules and Assumptions • Invoice lines may be linked for payment to particular orders • Aleph invoice headers with empty Z77-P-STATUS and Z77-I-DATE equals to 0 are not migrated to Alma • Aleph Z77 records and Z75 records with Z77-CREDIT-DEBIT and Z75-CREDIT-DEBIT equal to ‘C’ (credit invoices) are migrated with negative prices • In Alma, Payment Status and Invoice Status elements of the Invoice Details are populated based on various conditions set on Aleph invoice payment status, dates (invoice date, invoice payment date), approval department and notes. The total price of both the invoice as a whole and each line are the price details passed from Aleph to Alma. • Migrated invoice statuses in Alma include New/In Review, Sent for payment and Closed/Paid • Subscription details - starting and ending date of the subscription coverage period (Z75-I-DATE-FROM, Z75-I-DATE-TO. • Z77-I-TYPE is mapped to the Alma Payment Method field. Mapping Z77-I-TYPE to the payment method is provided by the customer when filling in the Aleph to Alma migration form (INV-PAY-METHOD parameter). If the Z77-I-TYPE of the invoice is not mapped, the field is set to ACCOUNTINGDEPARTMENT by default. The following values are valid for this field:VAT is included in the total invoice amount. VAT details are mapped to Alma invoice and invoice lines notes (Z77_VAT_CODE, Z77_VAT_AMOUNT, 77_VAT_RECEIVER, Z75_VAT_CODE, and Z75_VAT_AMOUNT). • If your generally did not include the payment status of the invoice in Aleph, it is highly recommended that you update the relevant payment statuses for all invoices before migration. Invoices with a payment status other than Paid migrate to Alma with InReview status. Having large amounts of invoices with this status makes it difficult to manage the workflow of invoices in Alma.
Data Testload Migration Report: Patron Tab • Are the number of patrons correct in Alma? • These are the numbers at the time of the institution’s data pull • Great way to check if the numbers are correct is to do a patron purge in accordance with the SLC’s recommended patron purge instructions: https://slcny.libanswers.com/faq/240645 OR • Run a report in Aleph acquisitions by patron status
Data Testload Migration Report: Patron Tab • Aleph report: Circulation>Services>Reports>Patron List (circ-05) • Run a report for each internal and external user by patron status in order not to break Aleph when trying to print the results • Change the Privileges Expires Before date
Data Testload Migration Report: Loan Tab • Do the counts match in Aleph and Alma? • This is the number at the time of the institution’s data pull • Aleph report: Circulation>Services>Report>Loan Report (circ-04)
Data Testload Migration Report: Request Tab • Do the counts match in Aleph and Alma? • This is the number at the time of the institution’s data pull • Aleph report: Circulation>Services>Reports>Hold Shelf Report (circ-06)
Data Testload Migration Report: P2E Tab • Do the counts match your P2E form? • This is the number of Portfolios and DB on the P2E form • Compare the number of Portfolios and DB from the P2E form and the counts number • Note: Oneonta had one more number on our P2E file
THANK YOU A special thank you to all who were instrumental in the creation and execution of the Data Review Training Sessions. These sessions could not have happened without all of you! • Logan Rath – helped guide me in creating a clear outline and objectives for the Data Review Training Sessions • Data Migration Review & Discussion Group – provided helpful feedback, thoughtful discussion, and invaluable input for the Data Review Training Sessions • Carol Franck, Gail Pawlowski, Jason Parker, Ken Wierzbowski, Kristy Lee*, Lauren Jackson-Beck, Marian Stern, Maureen Zajkowski, Sandy Card, Shafeek Fazal, and Wendy West • Session Guides – spent hours preparing for and presenting the Data Review Training Sessions • Shannon Pritting • Sarah Maximiex • Rebecca Hyams • Joe Riggie • Heidi Webb • Erin Rushton