Vendor Data for Migration to Test Global Vendor File in Vanguard

Legend: not started IN PROGRESS STALLED decided

Recommendation

FG recommends that shared vendors be tested in the Vanguard for a variety of functions. Ex Libris has confirmed that the vendor files for both the NZ and IZ are loaded separately (i.e., there is no matching between NZ and IZ during migration). FG recommends that CDL append a suffix on end of vendor code so that if vendor record is distributed it would not would not find a match. The assumption is that there would also be no match with UCLAs 360RM vendor data.

UC Berkeley will load a vendor record whose code will match the CDL EBSCO code (PRVEBS), vendor name (EBSCOhost) and also change 10 orders to use that code. UCLA’s default vendor codes will also match with CDL’s vendor codes where codes are present in both systems. What happens when CDL’s NZ vendors are shared out via the distribution job? This will be tested in the Vanguard environment.

Examine how Alma would map usage to campus cost in an order record which is in the IZ and uses CDL as a vendor. What needs to be done to establish a link between the usage data and the payment?

Reasoning

We would like to assess the value of sharing vendors in the Network Zone. We want to test the implications for tracking payments, cost-per-use data for local and consortial resources, collection development analysis, etc. Will it allow for easy system-wide reporting of spending per vendor? This could help in efforts to negotiate system-wide contracts related to serial and book vendors.

We can also look into how other roles for vendors in Alma are helpful or problematic when shared at the NZ level.

The decision to adjust the vendor data of one institution pre-migration is for the purpose of having vendor data “preset” to facilitate a match from the NZ to the IZ once the distribution of NZ vendor records job is run in the Vanguard environment. (See Le’s post in Basecamp on June 24th). Additional matches can be achieved (involving more institutions and/or more vendors) with updating data directly in the Vanguard.

Background

Vendor Records in the Network Zone

This earlier Decision Page generated by ILS DC launched the discussion around vendor records in the Network Zone and Institution Zones. Some limitations were identified in mapping the vendor codes from the NZ to the IZ, but this warrants testing in the Vanguard. Ex Libris documentation indicates that Financial System Code is a field not shared, but subsequent Ex Libris presentations indicated that the IZ could use the subaccount portion of the vendor record to indicate local financial system (see 6/3 FG call with Ex Libris). Other consortial implementations (e.g., CSU) also discussed limitations of deploying shared vendors. The FG discussed how to test this functionality.

Dependencies

We to understand what configuration is necessary for correct migration of current data--do trial institutions need to use the NZ vendor code in their POLs? Do trial institutions need to submit the vendor in a vendor file? ANSWER: No, there is no matching during migration. After the Vanguard stage there may be recommendations for vendor records for the test/production stage to facilitate shared vendors.

Questions to consider

• How do the vendor records in the NZ get created? From what data?

  • At migration to the Vanguard, NZ vendor records will get created from 360RM data. CDL will update the Vendor Codes to have a unique suffix.

• How does the vendor data from the Vanguard institutions get migrated?

  • Vendor data for institutions are migrated separately. There is no matching with the NZ vendor data at point of migration.

• What are the implications for institution-level 360RM vendor data?

  • UCLA 360RM vendor data should be examined after creation of Vanguard environment.

FOR TESTING/VANGUARD

• What clean-up is required after migration?

• What are the benefits/limitations after distributing a vendor from the NZ to the IZ? How are orders in the IZ with that vendor affected? (was “How about linking from IZ to NZ for orders?”)

• What is our policy for different scenarios of records? How are we implementing shared vendors?

• What is effect on usage and cost-per-usage?

• Are there resources to test linking local order records to NZ to take advantage of functionality? What is the cost/benefit of this scenario if possible?

• Any way to do batch linking or batch updating?

• For policy considerations: do we need to recommend naming conventions for Vendor Codes so there is no unintentional overwriting whenever the “distribute vendors from NZ” job is run?

• Can an IZ put a vendor in the NZ? (Does this touch on user permissions for the NZ?)

• Can we use shared vendors in the NZ for more than just the CDL resources? (like cross-system analysis for collection development)? How does that affect Analytics reporting, etc.? Example: Amalivre.

• How do we make use of subaccounts for institutions using the same (NZ-level) vendor record?

Action Log