Spydus (Civica) to Alma Migration Guide
Spydus is the Integrated Library System produced by Civica Library Solutions.
This document serves two purposes:
- A step-by-step guide to filling out the Spydus Migration Form.
- An explanation of the migration rules for Spydus to Alma that do not require any customer input.
Related Documentation
- This document is intended to complement the Spydus Migration Form - an Excel spreadsheet that is read by the migration programs. It provides further information regarding the migration process and the steps required for migration to Alma.
- Prerequisites: Basic knowledge of Alma and Spydus key concepts and architecture, and the requirements (including the migration-related approach) described in Getting Ready for Alma and Discovery Implementation, as well as in Electronic Resource Handling in Alma Migration.
- The format and structure of the data exported from Spydus is detailed in the corresponding document Spydus to Alma Data Delivery Specification. The data structure is validated with the Excel-based validation tool, also described in this document.
- It is recommended that you view the Introduction to the Alma Configuration Process video session before completing your migration form, as the mapping and migration of libraries and locations have implications for subsequent configurations.
Ex Libris migrates your acquisitions and course data only if this service is purchased by your institution and is stipulated in your contract with Ex Libris.
Recommendations for Using this Guide
This document is divided into four areas:
- Inventory
- Fulfillment
- Acquisitions
- Physical to Electronic
Each area has the following sections:
- Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the migration form.
- Individual Tabs – Instructions for how to fill out individual tabs on the migration form. (Examples: Alma Library tab, User Group tab, PO Line Type tab).
- Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.
We recommend that you look at the Questionnaire tab section and the individual tabs in each area to assist in filling out the migration form. If you have further questions about any of the data input or about the migration in general, see the more detailed explanations in the Further Explanations sections.
Inventory
Alma requires bibliographic, holdings, and item records. Spydus provides bibliographic and item records.
Customer Input
Questionnaire Tab
Institution Code, Customer Code, Institution Name, Customer Name, Time Zone
Codes: INST_CODE, CUST_CODE – these are filled in by Ex Libris
INST_NAME, CUST_NAME – these are mandatory and must be filled in.
Default: N/A
Options: This question is mandatory.
INST_NAME and CUST_NAME: fill these fields in with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium).
List Prefix for bibs from SFX or other management system
Code: SFX_PREFIX
Default: ‘(SFX)’
Options: String. If not indicating a link resolver management system, leave blank.
Further Information: If your Spydus catalog contains records imported from SFX or another electronic resource management system and you are also migrating bibliographic records directly from SFX or the other management system, this can result in duplicate bibliographic records in Alma. You can enter a prefix here so that the migration programs can identify these bibs and not migrate them to Alma, to avoid creating duplicate SFX records in Alma. The migration programs do not make any attempt to physically merge the two records into one.
The default response to this question is ’(SFX)’, but you can enter any prefix that represents bibs that you want to exclude from loading to Alma. The migration programs search for the string in the 035 $a field of the MARC record. If you do not want to exclude any such records, leave this field blank.
If the migration programs identify bib records containing the prefix in the 035 $a, and the records in Spydus are connected to a purchase order line and/or physical items, these bib records are still migrated so that the purchase order and/or items can be migrated, but they are automatically suppressed in Alma to avoid end-user discovery duplication.
MARC Organizational Code
Code: MARC_OC
Default: None; this is not mandatory
Options: Enter your MARC Organizational code, which will be used to construct the former system number in Alma. Only one code is allowed.
Further Information: The migration moves the value in the exported record’s 001 field (Spydus bibliographic system number) to the 035 $a field:
(MOC)-
<(moc)> is the MARC Organization code specified here. is the customer code specified in the CUSTOMER_CODE question above.
For example: (AbC)123456-01abc
Do you use internal system numbers in $w of Linked Entry fields?
Code: LINKED_ENTRY_W
Default: No
Options: If Yes, the internal system numbers are converted from the Spydus system number to the Alma system number.
Internal record designation for Linked Entry fields $w
Code: LINKED_ENTRY_PREFIX
Default: blank
Options: If there are internal system numbers in $w, indicate if they have a prefix that is used to identify these numbers (for example, (abc)12345). If the system numbers in $w do not have a prefix (for example, 12345), leave this question blank. If No for the LINKED_ENTRY_W question, then leave blank.
Further information on LINKED_ENTRY_W and LINKED_ENTRY_PREFIX: When bibliographic records are related to each other, such as a journal title that is superseded by a second journal title, Spydus may store the information in bibliographic fields 76x-78x. If the number in the $w of the linking tags is the internal Spydus system number, these numbers must be changed to the Alma representation of the system number. If your library does not use the internal system number to link and rather relies on more general identifiers such as the ISBN, ISSN, or shared cataloging DB (OCLC or DLC), these numbers are not modified.
In Alma, the system numbers in the $w field (along with $z and $x) are used to link two related bibliographic records together using the related records process. Related records can be found by clicking the More Info link on the Alma Search Results page.
Indicate which 852 subfields to use to determine unique holding records
Code: 852_SUBFIELDS_FOR_HOL
Default: bc (library and location only, not call number)
Options: To group all items on a single bibliographic record by library/location only, indicate bc here. If you have many items on the same bibliographic record in the same library/location but different call numbers WITHIN that library/location and you want each of them to have their own distinct holding record, specify additional call number subfields. Acceptable subfields are: bchijklmp.
The library and location codes are matched after the Alma Location Mapping has been performed, meaning the match is done on the Alma version of the library/location codes.
See section: Changing the Holding Record Grouping
Limit exported records by location
Code: LIMIT_BY_LOCATIONS
Default: No
Options: If your export contains all of the data from a shared database, and you wish to only migrate a part of that export to Alma, then the migration programs can filter the data according to locations listed on the Location Tab. In this case, the ALMAME_VALUE_NOT_FOUND line on the location tab is not used. Inventory and Acquisitions are filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab. Use this option only if agreed upon with your Ex Libris project manager.
Bib Key Prefix
Code: BIB_KEY_PREFIX
Default: empty
Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former system numbers in Alma after migration. For example, the different systems likely had completely different bibs for system number 12345 and you want to be able to search for the specific bib from your own institution after go-live. The prefix does not include a hyphen so if you want a hypen in the number (e.g. PQ-12345), then include it in the string. If you are not merging institutions, leave this question blank.
See also MERGE_PATRON_PREFIX and FUND_PREFIX
Move 001/003 to 035 or 035
Code: 001_035_935
Default: 035
Options: If your incoming bibliographic records have a number in the 001, then the migration programs move it elsewhere as (<003>)<001>. For example: (OCoLC)12345. To move to the 035, which is the default, then select 035 in the dropdown. If you are part of a consortium and are using OCLC numbers to determine matching records when linking to the NZ, you may wish to move this number to the 935 so that the moved number does not interfere with another matching key you may be using. If you are not linking to the NZ, then this question is likely not useful. Default: 035
Use subfield indicators in item call number (AltCallNo)
Code: ITEM_CALLNO_SUBFIELD
Default: Yes
Options: When generating an Item Call Number field (also known as AltCallNo), you can decide if the string contains subfield indicators. Default = Yes
Yes = $h PZ3.A93 Pr16 $i A975
No = PZ3.A93 Pr16 A975
For more information on when an Item Call Number is generated, see the section Changing the Holding Record Grouping, which depends on the question 852_SUBFIELDS_FOR_HOL.
Add $9 LOCAL to specified tags
Code: NZ_LOCAL_TAGS
Default: empty
Options: Add $9 LOCAL to specified bib tags, for use in consortia where an IZ environment links to an NZ. Tags marked as Local will be kept in the IZ, and not moved to the NZ.
Format for this input: tag + indicator. Use # for any/wildcard, and b for the space character. Separate with semicolon.
Example: 59###; 69###;960##;970##;090b#
Alma Library Tab
Use this tab to create a list of libraries in Alma. At least one library is mandatory.
Alma Library Code: Maximum 10 characters. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
The Alma Library Code may not be the same as the Alma Customer Code nor the Alma Institution Code .
Alma Library name: Maximum 255 characters. This is visible to the public.
Address lines: Alma allows you to specify address, phone, and e-mail information about each library. It is mandatory for a library to have a shipping/billing address in order to place orders in Alma. The migration process sets the designated address provided with all possible types in Alma (shipping, billing, claiming, etc.). At least one address line is mandatory.
Email: At least one email address is mandatory.
Default language: Indicate the language of patrons and/or staff members if it differs for each library. Use two-letter codes as defined in ISO 639-1. Consult the codes at https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
Further Explanation: The Spydus location, which is the higher level of location is comparable to the Alma library. Use the Alma Libraries tab in the Spydus Migration Form to indicate your list of Alma libraries. The actual mapping from the Spydus location to the Alma library is done in conjunction with the Spydus collection in the Alma Location tab.
If you use an error library (for example “EMPTY”) in the ALMAME_VALUE_NOT_FOUND line of the Location Mapping tab, be sure to list that library here on the Library Tab. It is not mandatory to use an error library; you can also use one of your regular libraries plus a lower-level error location for the items that encounter errors during the mapping process.
Alma Location Tab
Use this tab to map your Spydus locations and collections to libraries and locations in Alma. Filling in this tab is mandatory.
Include ALL locations (collections) of ALL types, including electronic types that may ultimately be deleted in Alma. They still need to be provided in the location tab mapping.
Spydus Location (LOC): Value from the field in the item extract. This is the higher level of location. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.
Spydus Collection (COL): Value from the field in the item extract. This is the lower level of location. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.
Spydus Location Description: A description of the location, for assistance in filling out this form. This column is not used in the mapping routine.
Alma Library Code: The library that contains this library/location combination in Alma. You can use the same library codes that you used in Spydus, but it is not required. This code must be present on the Alma Library Tab, column A. The match is case-sensitive.
Alma Location Code: The new location code for this library/location combination in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in Spydus, but this is not required. You may also use this form to collapse locations if desired, for example General_A and General_B in Spydus both map to General in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.
Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicator. (http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item record itself, we use this as a default for all items in the location.
Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples in the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.
Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.
Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See the Physical to Electronic (P2E) Processing section for more information.
Suppress from Externalization? (Yes or No): Indicate if the location should be suppressed from being visible to the public. The items are not marked as suppressed, but no holdings or items with this location code are exported to Primo.
Further Information: Do not leave the Alma location and library code fields blank. If you wish to stop using a location code after migration, map the Spydus code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Spydus database.
ALMAME_VALUE_NOT_FOUND
The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think you do not have any items left in a certain collection, so you leave it off the location map. However, there may be one or two items left, or a stray holding record, etc.
By default, the location code for the ALMAME_VALUE_NOT_FOUND line is UNASSIGNED, which is the default catch-all in Alma in production mode. Ex Libris recommends that you select your primary/largest library as the library code for the line, for example MAIN as in the example line below. In this case, the items inherit the configurations for the MAIN library.
| Location Code | Loan Desc | Alma Library | Alma Location Code | Alma Location Desc | Alma External Loc Desc | Suppress from Externalization |
|---|---|---|---|---|---|---|
| ALMA_ME_ VALUE_NOT _FOUND | MAIN | UNASSIGNED | Problem location from Migration | Problem: See Library Staff | Yes |
Post-migration, search for items in the “UNASSIGNED” location and correct the records appropriately.
Alma Location Name and Alma External Location Name
The Alma Location Name column contains the names of the location codes that are displayed in the staff interface. The names cannot be repeated in the Location Name column when the location codes both belong to the same library, but you can use the same name for two different locations, if these locations belong to different libraries. The Alma External Location Name column contains the names of the location codes that are displayed to library patrons. These names can be repeated within the column without regard for libraries. For example:
The following is acceptable:
| Library | Alma Location Code | Alma Location Name | Alma External Location Name |
|---|---|---|---|
| Library A | stacks | Main Stacks | Main Stacks |
| Library B | stacks | Main Stacks | Main Stacks |
| Library A | archa | Archives A | Archives |
| Library B | archa | Archives B | Archives |
| Library A | archstk | Archives Stacks | Archives |
| Library A | archref | Archives Reference | Archives |
The following is not acceptable:
| Library | Alma Location Code | Alma Location Name | Alma External Location Name |
|---|---|---|---|
| Library A | archstk | Archives | Archives |
| Library A | archref | Archives | Archives |
The Alma library and Alma location are put in the following places in the migrated or newly created MARC holdings record:
- The Alma library is placed in the 852‡b field.
- The Alma location is placed in the 852‡c field.
Item Base Status Tab
Use this tab to map your item statuses to Alma. This tab is not mandatory if you do not want to migrate your item statuses to Alma.
Spydus Status: The value in the status field from the Spydus item extract. The status typically indicates what is happening to the item, such as in binding, in repair, lost, etc.
Description: The description of the Status code. The text in this column is written to the internal note 1 in the item in Alma. Maximum 255 characters.
baseStatus: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, At Library Counter is on the shelf (1), but Being Repaired is not (0).
Further Information: Alma has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is sent to the bindery, etc.), but the process type is dependent on the corresponding Alma workflow. For migration, all item statuses that are indicated as not on the shelf (0) from Spydus are given the process type of TECHNICAL. Further, the item status description field is written to internal note 1 for all items where there was a status, regardless of the shelf/not on shelf designation.
Include any status that may indicate no status, for example Available, but leave column B blank. This migrates the item to Alma with no status at all, which is how Alma indicates that an item has no status. If any status is in your data but is NOT included in column A, it is given a note of Unknown status.
Post migration, you can search for and re-route items with values in the internal note 1 to the appropriate handling or department in Alma. This process can also be used as a configurable criterion for suppressing items from display in the Get It services screens from discovery systems. See Appendix A - Post-Migration Process Statuses for more information.
Item Type Tab
Use this tab to migrate the Spydus Item Type to the Alma Item Type. Not mandatory. The item type in Alma is not required, so if you leave this tab blank, no item policies in Alma are created.
Spydus Item Type: The value in the item type field of the Spydus item. The item type is used to differentiate between items when determining how something circulates.
Spydus Description: The description of the Spydus item type, for information only. This column is not used during the mapping process.
Alma itemPolicy: The Alma value for the item type. This sheet can be used to collapse item types if desired.
Alma Description: This description is loaded into Alma as the display text for the item types. These values can be changed after migration. Maximum 255 characters.
You can optionally include an ALMAME_VAL_NOT_FOUND line at the top of the map. If this line is included, any value not found or any blank value is assigned the value in the ALMAME_VAL_NOT_FOUND line. If the ALMAME_VAL_NOT_FOUND line is not included, any value not found, including blanks, is left as blank in Alma.
Further Explanation – Inventory
Bibliographic Records
Bibliographic records are migrated as is and each bibliographic record may be marked with Alma management tags in the following way during migration:
- Australian customers have ALL Bibs marked for Libraries of Australia Publish, if relevant.
- OCLC records (records with an 035 |a with an OCLC-official prefix) are marked for OCLC publish, if relevant.
- The LDR position 9 (character coding scheme) is set to a indicating Unicode.
Determining Groups of Holding Records
Spydus extracts provide Bibs and items, but not holdings. Holdings are mandatory in Alma, and, therefore are created based on the item data. The permanent location and call number in Alma is only stored in the holding record. All items attached to the generated holding record have the same permanent location and call number. On migration, the call numbers for any new holding record created are generated from the first item found in the group of equivalent items. By default, a group of equivalent items is determined by the location of each item attached to the same bibliographic record. For example, if a bibliographic record has five items:
- Item 1, 2 in Location A
- Item 3, 4 in Location B
- Item 5 in Location C
The migration program generates three different MARC holdings records, one for each location A, B, or C. The items for each location are then attached to the newly created holding record. If there are any call numbers that differ from the holding record’s call number, the differing call number is stored in the item’s Item Call Number field.
Changing the Holding Record Grouping
You can decide which 852 subfields are used to determine what makes items belong to the same group. The 852 subfields as mapped from Spydus, described in the Library, Location and Call Number sections above, are: $b Location $c Collection $h Call Number. By default, the migration programs compare $b and $c, but you can decide to change this based on how you have cataloged items in your collection.
When the holding record group is based only on $b (library) and $c (location), some item call number informationis not reflected in the holdings record call number if the call numbers differ from each other in the same library/location. However, the differing call number is stored in the item’s Item Call Number field, so the call number is not permanently lost.
For example, if there are four items on the same bibliographic record with the following call numbers, all in location main:
item 1 $b main $c stacks $h PN 567 .M4
item 2 $b main $c stacks $h PN 567 .M457
item 3 $b main $c stacks $h PN 567 .M457
item 4 $b bio $c flr1 $h PN 567 $i .M457
When only $b and $c are used to determine a holding record group, two holding records for the above items are created:
Holding record $b main $c stacks $h PN 567 $i .M4
item 1
item 2 (with PN 567 .M457 stored in ItemCallNo)
item 3 (with PN 567 .M457 stored in ItemCallNo)
Holding record $b bio $c flr1 $h PN 567 $i .M457
item 4
When the holding record group is based on more subfields, for example $b $c $h, three holding records are created:
Holding record $b main $c stacks $h PN 567 .M4
item 1
Holding record $b main $c stacks $h PN 567 $i .M457
item 2
item 3
Holding record $b bio $c flr1 $h PN 567 $i .M457
item 4
Decide which 852 subfields will be used to determine holding record groups by answering the question in the Questionnaire tab of the Spydus Migration Form, “Indicate which 852 subfields to use to determine unique holding records”.
Suppressing Bibliographic Records in the OPAC
In Alma, bibliographic records can be set to be suppressed in the OPAC. Provide a file of suppressed records in a separate file as described in the Spydus to Alma Data Delivery Specification document.
Item Barcodes
The item barcode must be unique in Alma, but it may be left blank.
The item barcode is migrated according to the following rules:
- If the incoming barcode is empty, the barcode is left as empty.
- If the barcode exists but is not unique:
- First item barcode encountered – migrate as is.
- Second and subsequent item barcodes encountered – migrate as <item barcode>-<item id> .
Material Type
The material type in Alma is a description of the type of material the item is such as book, map, issue, DVD, compact disc, etc. It is controlled by a fixed list of physical resource material types in Alma. Each item in Alma must have a material type specified.
If not provided in the extract, the migration automatically assigns a material type based on bibliographic record LDR and 007 fields. There is no customer input required for this part of the migration as the Alma types are fixed. The material type in migration is derived from the resource type which is constructed by Alma based on the bib header information. To see a description of how the resource type is determined, see the Resource Type Field description.
Fulfillment
Patron records are required if loans, requests, or fines are being migrated. Patron records can be updated post-migration with Alma’s patron update routines.
Customer Input
Questionnaire Tab
Which identifier should be used as the patron's Primary Identifier?
Code: PATRON_PRIMARYID
Default: UNIV ID
Options: Using the Spydus Field Mapping Form, map the identifiers exported from Spydus into the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select here the identifier to be used as primary for allpatrons.
Further Information: The identifier selected here is used as the match point for externally managed patron records to match up with an external authentication system such as LDAP or Shibboleth. Additionally, this identifier is the primary identifier for internally managed patrons. It is highly recommended to use the Primary Identifier as the identifier for authentication. Note that Primary Identifier is not case-sensitive, as opposed to all other identifiers, which are case-sensitive.
See also: Identification Numbers, Internal? question on the User Group tab
Enter a two-letter code for the default conversational language for your users (for example en or fr)
Code: PATRON_LANG
Default: en
Options: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes. Additionally, the language code zh-tw (Taiwanese Mandarin) is acceptable.
Currency for patron fines
Code: CURRENCY
Default: USD
Options: Use the three-letter code for the currency used for patron fines. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217.
Use a map for the CAMPUS_CODE to campus code migration?
Code: CAMPUS_CODE_MAP
Default: No
Options: Select Yes for this option only when you maintain and use different values in the Spydus CAMPUS_CODE field to distinguish between different user groups for resource sharing activities like ILL borrowing. When Yes, fill in the mapping from the HOME_LIBR to the Alma CampusCode field on the Campus Code tab. When No, all users are simply considered part of the same group for resource sharing activities.
See also: Campus Code Tab
Merge Patron Prefix
Code: MERGE_PATRON_PREFIX
Default: No
Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the incoming patron record original IDs. This prefix is only added to the internal patron identifier, it is not added to barcodes or usernames or UNIV_ID. If you are not merging institutions, leave this question blank.
See also: BIB_KEY_PREFIX and FUND_PREFIX
User Group Tab
The user group is used to distinguish groups of patrons from each other in determining different levels of circulation policies. Typical user groups are faculty, staff, undergrad, etc.
If patrons are being migrated, then this mapping table is mandatory.
Spydus Category: The Spydus patron type code, found in the CATEGORY field of the patron extract.
Spydus Description: A description of the Spydus patron type code, here for information only. This column is not used in the mapping to Alma user group.
Alma userGroup Code: The mapped group code in Alma. You can choose to use the same codes that you used in Spydus, or you can choose to use different codes. You can also choose to collapse groups if desired, for example, having Freshman and Sophomore both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.
Alma userGroup Description: The description of the Alma userGroup. This description is loaded into the Alma code table as the description seen in the user interface. This description can be changed easily after migration.
Internal? Y or N: Alma categorizes users as either external or internal. External patrons are managed and authenticated by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons are minority cases where community borrowers or alumni use library services. When Y, all of the patrons in the Alma userGroup are categorized as internal. When N, all of the patrons in the Alma userGroup are categorized as external.
External users are fully external (except patron notes), including all user identifiers and authentication and address information.
See also the following question on the Questionnaire tab, regarding Internal or External users:
- Which identifier should be used as the patron's Primary Identifier?
User Block Tab
A user block is assigned to patrons that have a temporary suspension of borrowing privileges. Spydus stores patron blocks in the BLOCK_CODE field in the patron record.
This mapping table is not mandatory.
When a patron has no blocks in Spydus, the BLOCK_CODE field might have a value, for example 'None'. Do not include such Codes in the User Block tab – list only codes that describe actual Blocks.
Spydus BLOCK: The Spydus patron block code as found in the patron extract.
Spydus BLOCK Description: A description of the Spydus patron block code, for information only. This column is not used in the mapping.
Alma userBlock code: The block code desired in Alma.
Alma userBlock description: The description of the block code in Alma. The value in this column is loaded to the server in the userBlock code table. This description can be easily updated after migration.
Campus Code Tab
Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the CAMPUS_CODE to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.
The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing. If your library maintains the HOME_LIBR field in Spydus for a similar purpose, map the HOME_LIBR value to the Alma Campus Code value with this map.
Spydus USER_LIBRARY: The value of the patron home library as found in the HOME_LIBR field of the patron extract.
Spydus USER_LIBRARY Description: A description of the HOME_LIBR field, for information only. This column is not used in the mapping.
Alma campusCode: The Alma campusCode desired. You may map the codes 1-to-1, or you may use this map to collapse codes, if desired.
Alma campusCode Description: A description of the Alma campusCode, for informational purposes only. This field is not loaded into Alma.
User Stat Categories Tab
Use this tab if you use statistical categories in your patron records and you want them to migrate to Alma. In Spydus, it is possible to have multiple fields that contain statistical codes.
Before filling out this tab, use the Spydus Field Mapping form, Patrons tab, to specify which fields from Spydus are migrated to statistical categories in Alma. There, you can include a label before each category to distinguish between categories in different fields. For example, you can have LAW in DEPT and LAW in SCHOOL. Use a prefix to distinguish between the two, for example, DEPT: LAW and SCHOOL: LAW.
Spydus Statistical Category: List all of the values from all of the fields you chose to put into the statistical category mapping. For example, if you used all three fields HOME_INST, DEPT, and SCHOOL, list all values from all three fields in Spydus. Include the label applied if it is important to distinguish between values in different fields.
Statistical Category Description: A description of the individual categories, for information only. This field is not used in the mapping to Alma.
userStatCategory Code: The Alma Statistical Category code desired. This code is used to retrieve groups of patron records with various reporting tools.
userStatCategory Description: The description of the Alma Statistical Category Code. This value is loaded into the code table for userStatCategories. This description can be easily updated after migration.
Further Explanation
Patrons
Explanations about patron migration processes that do not require your input.
Identification Numbers
The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. One of these identifier types should be selected as the primary ID – the primary unique identifier that the patron uses to authenticate via Primo. Internal patrons authenticate with the primary ID and a password via the Alma authentication service, and external patrons use the primary ID as the match point with an external authentication system.
When selecting the primary ID, the first identifier found in the field is used as the primary ID, and all subsequent identifiers are kept in the userIdentifier section. The primary ID must be unique, so if there are duplicates, the first ID found is migrated as is, and the IDs for the second and subsequent patrons with the same ID are given a suffix of -1, -2, etc. The original identifier is stored in the non-unique userIdentifier field so that the patron can still be retrieved using that identifier.
The identifier selected as the primary ID is not also written to the patron identifier section in the Alma patron record. The identifiers that are NOT selected as the primary ID are written to the patron identifier section in Alma.
When an identifier is written to the identifier section and there are multiple instances, the first one found for each type is active and the subsequent ones are inactive. Identifiers that are not used as the primary ID do not need to be unique and are not deduplicated.
If the identifier selected for the primary ID is not present, the migration program creates an identifier for the patron based on the patron original ID, prefixed with ID. The migration programs do not fill in the primary ID with a non-selected identifier.
Select an identifer type from the dropdown list.
Loans
Active loan transactions are migrated from Spydus to Alma. Completed loan transactions are not included in the migration to Alma.
Acquisitions
Customer Input
Questionnaire Tab
ACQ mode
Code: ACQ_MODE
Options: Select Yes or No depending on whether or not you have contracted with Ex Libris to migrate any Acquisitions data.
Central Order Library
Code: CENTRAL_ORDER_LIB
Default: None
Default Order Library
Code: DEFAULT_ORDER_LIB
Default: First library found on the Alma Library list
Options for Central and Default Order Library: The migration attempts to map the Library in the Purchase Order extract to the corresponding Alma Library. If you wish to assign a single owning library to all orders migrated, then fill in a value for the Central Order Library question. Otherwise, leave the Central Order Library blank and fill in a value in the Default Order Library question. In this case the migration will use the Default Order Library if a library is not specified or a mapping is not found.
What is your currency?
Code: ACQ_CURRENCY
Default: USD
Options: List the currency used for all of your funds. Orders can have other currencies and be translated to the default currency, but funds must have a single base currency.
The currency should be a three-letter code, as listed in http://en.wikipedia.org/wiki/ISO_4217
Fiscal Period Cycle Pattern
Code: FISCAL_PERIOD
Default: 01-07-1 (fiscal period starts on July 1 (01-07) and lasts for one year (-1).
Options: To have functioning ledgers, fiscal periods are required. Specify your fiscal period as DD-MM-C (Day-Month-Cycle). For example, a one year fiscal period starting on January 1 is indicated by: 01-01-1. A one year fiscal period starting on July 1 is indicated by: 01-07-1.
Alma currently supports one-year fiscal period cycles.
Accrual Accounting
Code: ACCRUAL_ACC_FY
Default: No, do not make an additional fiscal year
Options: If your library uses accrual accounting, you can instruct Ex Libris to make an additional fiscal year. When an additional fiscal year is created, it will be after the current fiscal year. For example, if the current active fiscal year is 2016, then the additional year, also active, will be 2017. The options are the following:
- No – do not make an additional fiscal year.
- Yes-No Funds – make an additional fiscal year but leave it empty. The library will then need to create funds for this fiscal year after go-live.
- Yes-duplicate funds – make an additional fiscal year and also fill it with funds that are the same codes as the funds in the current fiscal year. No allocations are made.
Default Claiming Period
Code: ORDER_CLAIM
Default: 90
Options: Default claim used for vendors and orders (if applicable), in days
Renewal Date for Serials Subscriptions
Code: RENEWAL_DATE
Default: none
Options: Default renewal date for subscriptions. If your subscriptions are generally ordered on the same cycle and you do not provide that renewal date in the order data itself, place that date here. The first choice of populating this mandatory field for ongoing orders is based on explicit renewal date information in the order. The second one is to populate based on the answer to this question (if populated). The default is renewal date = migration + 1 Year. The fallback is used only if no renewal date is provided in the orders and no answer is provided in the migration form questionnaire.
Fund Prefix
Code: FUND_PREFIX
Default: none/blank
Options: If you are combining data from two or more separate databases into a single combined institution in Alma, indicate a prefix here that will be used to distinguish the former fund codes in Alma after migration.Provide a string to be used to prefix all fund codes in the database. A hyphen is NOT provided. For example, if your fund code is SCIENCE-MONO and you put UWS- here, the final fund code is UWS-SCIENCE-MONO. Leave this question blank to leave the fund code as is.
See also BIB_KEY_PREFIX and MERGE_PATRON_PREFIX
PO Reporting Code Tab
Use this tab if you wish to map values from the <ORD><FLD><MATCDE> field to the Alma Reporting Code field. This tab is not required.
When an encumbrance transaction is created in Alma, the acquisitions staff can classify the transaction with a reporting code. Later, reports can be used to retrieve transactions with the same reporting code. Reporting codes are often (but not always) used to classify a purchase as serial, monograph, or electronic, for state or nation-wide reporting purposes.
Spydus Material Code: The value of the Spydus order format, found in the <<ORD><FLD><MATCDE> field in the order extract.
Form Description: A description of the Material Code field, for information only. This field is not used in the mapping.
Alma Reporting Code: The desired code value for the reporting code in Alma. You may choose to collapse Material Code values if desired.
Alma Reporting Code Description: The name for the reporting codes in Alma. This field is used to create a code table that is loaded into Alma. This value can be easily changed after migration.
PO Entry Point Tab
The entry point value is used to determine where PO falls in the workflow in Alma. The PO entry point is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any <PST><FLD><STATUS> values that may not have been found in the map. Additionally, since all possible values for the <PST><FLD><STATUS> field in Spydus cannot be accommodated, every original <PST><FLD><STATUS> value is placed in the note field for each individual migrated order for reference after migration.
Spydus status code: The possible values for the order status in Spydus, found in the <PST><FLD><STATUS> field in your order extract.
Description: The description of the <PST><FLD><STATUS> field, for information only. This field is not used in the mapping to Alma.
poEntryPoint: The desired order status in Alma. Select from one of the values in the dropdown box. The following options are available:
- NEW – The order has been created but not sent to the vendor yet. Orders can have status NEW for years while librarians are reviewing what to order, or they can be NEW for just a short while if the acquisitions staff created the order to send to the vendor immediately.
- SENT – The order has been sent to the vendor and funds have been encumbered/committed. The item has not been received yet for one-item orders, or the item has been received for continuous orders. Continuous orders that continue to be invoiced/received remain with SENT status (which can be considered as a sub-status of waiting for renewal within Alma) until they are closed.
- WAITING_FOR_INVOICE – Use only for one-time orders. The item has been received, but not the invoice. Invoice status must not be FULLY_INVOICED.
- CLOSED – The order has been received and invoiced. Nothing else will be received on this order. (Do not use for open continuous orders that you are still receiving.)
- CANCELLED – Cancelled order.
PO Line Type Tab
Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times, and may remain open indefinitely.
This tab is mandatory if you are migrating orders. Include a line for ALMAME_VAL_NOT_FOUND since this field is mandatory in Alma.
Spydus Order Category: Value of the order type field in Spydus, found in the <ORD><FLD><ORCAT> field in your order extract.
Order Category Description: A description of the <ORD><FLD><ORCAT> field, for information only. This field is not used in the mapping to Alma.
poLineType: The Alma line type value. Select one of the following line types from the drop-down list:
- PRINT_OT – printed book one time. This is used for one time or infrequent orders of specific items, for example, a printed book, E book, or a musical score, that is not published repetitively. The order is at the item level. If the only physical items that you order are books, this type is essentially the same as Print Book - One Time.
- PRINTED_BOOK_OT: Print Book One Time
- PRINT_CO – journal/continuation. This is used for orders that are repeated on a regular basis. An example is monthly subscriptions to physical or electronic material such as journals. The order is at the holding level, and items in the holding record are received periodically.
- PRINTED_JOURNAL_CO: Print Journal - Subscription
- PRINT_SO – standing order monograph. This is used for orders that are not repeated on a frequent or regular basis. For example, this type of PO line is used for purchasing all the printed books by a particular author when they are published, or where a series of books are being published, but not necessarily on a regular basis. The receipt of new material involves a new bibliographic, holdings, and item record. If the only physical items that you order are books, this type is essentially the same as Print Book - Standing Order.
- PRINTED_BOOK_SO: Print Book - Standing Order
- PRINT_SO_NONMON - Standing Order Non-Monograph – Similar to continuous orders.
- OTHER_SERVICES_OT: Other Services One Time – Various non-inventory orders for services purchased from a vendor. Both one-time behavior and repetitive behavior are available. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
- OTHER_SERVICES_CO: Other Services Subscription – This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
Further Information: Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times and may remain open indefinitely.
Alma does have other PO Line types, but they are not available for use in migration.
Line Types and Electronic Orders
The above line types are all descriptions based on a print order. All orders are stored in Spydus as print, and so are migrated to Alma initially as print using the above line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO, is attached to a bibliographic record you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process.
PO Acq Method Tab
Use this tab to determine the Acquisition Method of an order in Alma. The acquisition method is an indication of how the order is acquired. Possible values for the acquisition method are PURCHASE, APPROVAL, GIFT, VENDOR_SYSTEM, DEPOSITORY, EXCHANGE, TECHNICAL, and LEGAL_DEPOSIT.
The PO Acq Method is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any values that may not have been found in the map. Also, since all possible values for the <ORD><FLD><TYPE> field in Spydus cannot be accommodated, every <ORD><FLD><TYPE> value is placed in the note field for each individual migrated order.
Spydus Acq Type: The value of the <ORD><FLD><TYPE> field in Spydus, found in your order extract.
Spydus Acq Type Description: A description of the Acq Type in Spydus, for information purposes only. This field is not used in the mapping to Alma.
poLineAcqMethod: The Acquisition method in Alma. Select one of the following values from the drop-down list:
- PURCHASE – normal workflow
- GIFT – not sent to vendor and no invoicing or payment
- EXCHANGE – not sent to vendor and no invoicing or payment
- APPROVAL – pre-established delivery plan - normal workflow except not sent to vendor
- VENDOR_SYSTEM – the order is placed at the vendor site so that sending it to the vendor is not required. The normal workflow is followed except that the order is not sent to the vendor.
- DEPOSITORY – usually from the government. The order is not sent to vendor and there is no invoicing or payment.
- TECHNICAL – no fund or amount required
- LEGAL_DEPOSIT – does not require fund or price, and uses a special version of the PO Line order letter
Further Information
Funds
Encumbrances
Transactions from active purchase orders are created as encumbrances in Alma. An active purchase order is defined as one in which the mapped PO entry point is NEW, SENT, or WAITING_FOR_INVOICE and is in the current fiscal year.
Transactions of Amount 0.00
In Alma, fund transactions can be of amount 0.00 only when it is an encumbrance and when the associated PO is of type GIFT, DEPOSITORY, EXCHANGE, or TECHNICAL.
All other encumbrances of amount 0.00 are changed to 1.00.
Purchase Orders
The Alma Purchase Order consists of a PO header, which includes one or more PO lines attached to it. The PO lines represent the items ordered.
All orders from Spydus are migrated to Alma, but only the active orders (NEW, SENT, and WAITING_FOR_INVOICE) in the current fiscal year and with a valid fund reference will be linkedthe fund via an encumbrance transaction.
Additionally, Spydus payment/invoice information is added as a referenceble note for each of its related orders.
PO Invoice Status
In The Alma Purchase Order has a field to indicate the invoice status of the order. The invoice status can be NO_INVOICE, PARTIALLY_INVOICED, or FULLY_INVOICED. Continuous orders must not be FULLY_INVOICED.
If the Invoice input file doesn’t conatain a invoice record for the purchase order, then the invoice status of that order is NO_INVOICE.
If the Invoice input file contains an invoice record and po_line_type = PRINTED_BOOK_OT, then the invoice status is FULLY_INVOICED.
If the invoice input file contains an invoice record and po_line_type = PRINTED_BOOK_SO or po_line_type = PRINTED_BOOK_CO, the invoice status is PARTIALLY_INVOICED.
Physical to Electronic (P2E) Processing
This section describes the process of correctly categorizing resources as electronic in Alma. In Spydus, all resources are stored as physical in the database even if the record represents an electronic item. During migration, all records are initially converted to Alma as physical. A second process converts records that you identify as electronic to the electronic format. You have to provide a list of records that are identified as electronic, in the following format:
123475,portfolio
12345,package
12346,db
The words portfolio, package, and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.
If you provide a bibliographic record in the P2E file, the migration programs will generate an electronic resource for the bib, even if there is no valid URL. An example of an invalid URL might be an 856 tag with an indicator which does not match the specific indicator in the question P2E_LINK, below. For example, if you say that we use 85641u for the P2E_LINK, and you provide a bib record *without* a 85641u but that bib record is in the p2e file, then we will generate a local e-resource without any link at all (an empty resource). Be careful which bibs are placed in the bib file.
Further, the P2E process attempts to identify an order related to the identified inventory for conversion to electronic. Similarly to items and holdings, orders are initially migrated as print and are transformed to electronic through the p2e process. See the guide https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides/Electronic_System_Migrations/Electronic_Resource_Handling_in_Alma_Migration for more information.
Customer Input
Questionnaire Tab
For each of the following three questions (P2E_LINK, P2E_NOTE, and P2E_PROVIDER), you can use indicators in the following manner:
- Specific indicators: 85641u – only tags with 41 as the indicator is used.
- No indicator (# is used for a blank character, for example: 8564#u) – only tags with 4<blank> as an indicator are used.
- All possible indicators: 8564*u – tags with 4 as the first indicator are used. The second indicator is not taken into account.
The space character operates the same way as an asterisk (*), for example: 8564 u is the same as 8564*u.
Special Request: If you need to specify multiple specific indicators, for example 85641 and 85642, it cannot be coded in the migration form but your ExL representative can make a special request to the migration team.
Which Holding or Bib field stores electronic link information
Code: P2E_LINK
Options: Provide a three digit Marc field code + subfield: 856u. Only one field/subfield is allowed.
Recommendation: 856 u
Default: If this is left empty, no tag is used.
Which Holding or Bib field stores electronic link public note
Code: P2E_NOTE
Recommendation: Provide a three digit Marc field code + subfield: 856z. Only one field/subfield is allowed.
Default: 856 z
Default: If this is left empty, no tag is used.
Which Holding or Bib field stores electronic provider name information
Code: P2E_PROVIDER
Options: Provide a three digit Marc field code + subfield: 856m. Only one field/subfield is allowed.
Recommendation: 856 m
Default: If this is left empty, no tag is used.
For the questions on the Questionnaire tab, only one field/subfield is allowed per question.
Alma Location Tab
Electronic Location Column
Identify which locations indicate an electronic holding or item record. A single bibliographic record can contain holdings for multiple locations, but only the holdings/items for electronic locations need to be identified. Identify the locations in the in the Electronic Location? column in the Alma Location tab of the Spydus Migration Form.
PO Line Type Tab
Line Types and Electronic Orders
The PO line types are all descriptions based on a print order. All orders are stored in Spydus as print, and so are migrated to Alma initially as print using the above line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO is attached to a bibliographic record that you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process.
Further Explanation – P2E
If you have multiple 856 links in a single bibliographic record identified as electronic, a different inventory link for that bibliographic record is created for each URL found in the record. In addition, if you have two item records with different electronic locations attached to the same bibliographic record, a different inventory link is created for each location, as well.
For more information on the electronic migration approach to Alma, see Electronic Resource Handling in Alma Migration.
Appendix A – Post-Migration Process Statuses
The process statuses (codes) from Spydus are mapped to the indexed internal note 3 field of the Alma item. These items are considered not available after migration when process = Technical – Migration.
These fields are currently indexed in the item keyword and advanced searches.
When searching for physical items, a staff user can search by item process status code with the general keyword search and then by facet if before searching, Process type = Technical – Migration and with the advanced search filter when Process type = Technical – Migration.
In order to give items real Alma statuses or remove the Technical – Migration status, scan the barcode of the item to various configured departments (via receiving, for example), request a move to various departments/temp locations, or just scan the item for return, which removes the status from the item. You may also use the Scan In API. For more informatin, see the Developer's Network.
Additionally, it is also possible to configure the GetIt (Primo) services to display or not display items with this process status in the GetIt Item list.