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.v
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. Unicode characters are acceptable. Alma Library name: Maximum 255 characters. This is visible to the public.
The Alma Library Code may not be the same as the Alma Customer Code nor the Alma Institution Code .
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: An email address is mandatory. The migration process sets the email address provided with all possible email address types in Alma.
Phone: The phone number must contain dashes (nnn-nnn-nnnn). A phone number with no dashes is not accepted by the migration program. Not 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 Solars field is the BRCH_CODE in the item record, which is the higher level of location and is comparable to the Alma library. Use the Alma Libraries tab in the Solars Migration Form to indicate your list of Alma libraries. The actual mapping from the Solars library Solars BRCH_CODE to the Alma library is done in conjunction with the LOC_CODE 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 may also choose to 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 Solars BRCH_CODEs and LOC_CODEs to libraries and locations in Alma. Filling in this tab is mandatory.
Include ALL locations of ALL types, including electronic types that may ultimately be deleted in Alma. They still need to be provided in the location tab mapping.
Solars BRCH_CODE: Value from the Library field in the item extract from Solars. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed.
Solars LOC_CODE: Value from the LOC_CODE field in the item extract from Solars.
Alma Library Code: The library that contains this BRCH_CODE/LOC_CODE combination in Alma. You can use the same branch codes that you used in Solars, but it is not required. This code must be present on the Alma Library Tab, column A. The match is case-sensitive. See Libraries and Locations in Orders on page 30 about how this Library Code value may also be used as the ordering library in order migration.
Alma Location Code: The new location code for this library/location combination in Alma. It can be a maximum of 10 characters (Unicode is acceptable). You can use the same location codes in Alma that you used in Solars, but this is not required. You may also use this form to collapse locations, for example refa and refb in Solars both map to ref 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. Unicode is acceptable.
Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicators. (
http://www.loc.gov/marc/holdings/hd852.html). If we cannot determine the call number type from the item or holding 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. 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 want to stop using a location code after migration, map the Solars code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Solars database.
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 that 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.
Solars Branch Code |
Solars Location Code |
Alma Library Code |
Alma Location Code |
Alma External Loc Desc |
Suppress from Externalization |
ALMA_ME_ VALUE_NOT _FOUND |
ALMAME_ VALUE_NOT _FOUND |
MAIN |
UNASSIGNED |
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.
Collapsing Locations
This mapping table can be used to collapse location codes – that is, two or more location codes in Solars can map to a single location code in Alma. The Alma location and library code fields may not be empty. If you want to stop using a location code on migration, map the Solars code to an easily identifiable code, such as XXX if any stray items are still in your Solars database.
If you collapse location codes, you may have lines in the table such as the following:
Solars Location Code |
Alma Library |
Alma Location Code |
Alma Location Name |
Alma External Loc Name |
Suppress from Externalization |
Electronic Location |
reserves
|
MAIN |
RESERVES |
Reserves |
Reserve |
Yes |
No |
reservesElec
|
MAIN |
RESERVES |
Reserves |
ReserveElec |
Yes |
Yes |
reservesShort
|
MAIN |
RESERVES |
Reserves |
Reserve |
Yes |
No |
reservesPerm
|
MAIN |
RESERVES |
Reserves |
Reserve |
Yes |
No |
The two values in bold italic above (ReserveElec as the External Location name, and Yes for Electronic location) are not used in Alma. Since the locations are being collapsed, the first line for the RESERVES Alma location is used, and all subsequent lines below it use the values from the first line.
Item Type Tab
Use this tab to migrate the Solars Item CIRC_STATUS or Serial checkin PROC_STAT to the Alma Item Policy. This tab is optional. The item type in Alma is not required, so if you leave this tab blank, no item policies in Alma are created.
Solars CIRC_STATUS or PROC_STAT: The value in the CIRC_STATUS field from items or the PROC_STAT field from checkins in Solars. The item type is used to differentiate between items when determining how items circulate.
Solars Description: The description of the Solars 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 itemPolicy 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.
Item Base Status Tab
Use this tab to map your item CIRC_STATUS or checkin PROC_STAT, plus the CHKIN_STAT from serials, to an item status in Alma.
Solars CIRC_STATUS or PROC_STAT: The Circ status or Proc status in Solars.
Solars CHKIN_STAT: Optionally, the checkin status, used as a determiner for checkins.
Description: A short description of the status in Solars, if desired, for note purposes while filling out this form. This column is not used for migration.
Base Status: 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, NewBooks is on the shelf (1), but Withdrawn is not (0).
Further Information: 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.
For migration, all item statuses that are indicated as not on the shelf (0) from Solars 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.
Post-migration, you can search for values in Internal Note 1 and then move the items to a specific department, or the list can be used as a configurable criterion for suppressing items from display in the GetIt services screens in discovery systems. See
Appendix A – Post-Migration Process Statuses for more information.
Further Explanation - Inventory
Bibliographic Records
Bibliographic records are migrated as is and each bibliographic record may be modified in the following way during migration:
- Australian customers have ALL bibliographic records 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.
Serials
The migration programs generate item records out of unbound serial checkin records. In order to migrate serial checkins, we must have the ACQ_MST order file (even if Acquisitions is not being migrated) so that we may link the serial checkin to the bib record using the IMID and Q_ID fields.
Items are not generated from the Bound Items file, since they are all present in the main item file.
Determining Groups of Holding Records
The permanent location and call number in Alma is only stored in the holding record. All items attached to the 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 holdings record. If there are any call numbers that differ from the holdings record’s call number, the differing call number is stored in the item’s Item Call Number field.
Changing the Holdings 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 Polaris are: $b Owning Branch $c Assigned Collection-Shelf Location $(khim) Call Number. By default, the migration programs compare $b and $c, but you may decide to change this based on items in your collection.
When the holdings record group is based only on $b (library) and $c (location), some item call number information is 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 $i .M4
item 2 $b main $c stacks $h PN 567 $i .M457
item 3 $b main $c stacks $h PN 567 $i .M457
item 4 $b bio $c flr1 $h PN 567 $i .M457
When only $b and $c are used to determine a holdings record group, two holdings records for the above items are created:
Holdings 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)
Holdings record $b bio $c flr1 $h PN 567 $i .M457
item 4
When the holdings record group is based on more subfields, for example $b $c $h $i, three holdings records are created:
Holdings record $b main $c stacks $h PN 567 $i .M4
item 1
Holdings record $b main $c stacks $h PN 567 $i .M457
item 2
item 3
Holdings record $b bio $c flr1 $h PN 567 $i .M457
item 4
Decide which 852 subfields will be used to determine holdings record groups by answering the question in the Questionnaire tab of the Solars Migration Form, Indicate which 852 subfields to use to determine unique holdings records.
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 barcode is empty, leave it as is.
- 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 from Bib Fixed Fields
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.
Solars customers may provide a material type in a subfield of the item tag (typically 999) of the exported bibliographic records, and use the Material Type tab to map them to valid Alma material types. The material type you indicate determines the item's material type.
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/Patrons
Customer Input
Questionnaire Tab
Enter a two-letter code for the default conversational language for your users
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 accepted.
Which identifier should be used as the patron's Primary Identifier?
Code: PATRON_PRIMARYID
Default: UNIV ID
Options: Using the Poalris Field Mapping Form, map the identifiers exported from Polaris to the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select the identifier to be used as primary for all patrons, both internal and external.
Further information: The identifier selected here is used as the match point for externally managed patron records to match 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. Notice 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.
Currency for patron fines
Code: CURRENCY
Default: USD
Options: Use the three-letter code (for example, USD, EUR, GBP) 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 BRCH_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 BRCH_CODE field to distinguish between different user groups for resource sharing activities like ILL borrowing. If you select Yes, fill in the mapping from the USER LIBRARY to the Alma CampusCode field on the Campus Code tab. If you select No, all users are simply considered part of the same group for resource sharing activities.
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
Currency Code Tab
Use this tab to map the currency code values in Solars (CURR_CODE) to a valid Alma currency code.
Solars CURR_CODE: The Solars currency code, taken from the order file.
Solars Description: A description of the Solars currency code, for reference only. This column is not used in migration.
Alma Currency code: A valid currency code in Alma. For a list of valid codes, consult
http://en.wikipedia.org/wiki/ISO_4217. For inactive currencies such as those replaced by the Euro, use the replacement currency code.
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, and undergrad.
If patrons are being migrated, then this mapping table is mandatory.
Solars PAT_TYPE: The Solars patron type code, found in the PAT_TYPE field of the patron extract.
Solars Description: A description of the Solars patron type code, for informational purposes only. This column is not used in the mapping to Alma user group.
Alma User Group Code: The mapped group code in Alma. You can use the same codes that you used in Polaris, or you can use different codes. You can also collapse groups if desired, for example, having Freshman and Sophomore from Solars both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.
Alma User Group Description: The description of the Alma User Group. This description is loaded into the Alma code table as the description displayed 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 would be minority cases where community borrowers or alumni use library services. If you select Yes, all of the patrons in the Alma userGroup are categorized as internal. If you select No, all of the patrons in the Alma userGroup are categorized as external.
Notes/Comments: Add any notes or comments for the Polaris User Profile. This column is not used during migration.
Further information: See also the following question in the Questionnaire tab, regarding internal and external users:
- Which identifier should be used as the patron's Primary Identifier?
User Stat Categories Tab
This tab is used to migrate the statistical categories in your patron records (if you have them) to Alma. In Solars, it is possible to have multiple fields that contain statistical codes.
Before filling in this tab, specify in the Patrons tab of the Solars to Alma Field Mapping form which fields from Solars are migrated to statistical categories in Alma. You can include a label before each category to distinguish between categories in different fields. For example, you can have the value LAW in USER_CATEGORY1 and also LAW in USER_CATEGORY2. If desired, use a prefix to distinguish between the two, for example, CAT1:LAW and CAT2:LAW.
Solars Stat Category: List all of the values from all of the fields that you want to put into the statistical category mapping. For example, if you use all three fields of STAT_CATEGORY in the list, list all of the values from all three fields in Solars. Include the label applied if it is important to distinguish between values in different fields.
Source Description: A description of the individual categories, for information only. This field is not used in the mapping to Alma.
Alma Stat Category: The Alma Statistical Category code desired. This code is used to retrieve groups of patron records with various reporting tools.
Alma Stat Category Description: The description of the Alma Statistical Category Code. This value is loaded into the code table for userStatCategories. This description can be updated after migration.
Further Information: Alma has a Statistical Categories field in the patron record that can be used to retrieve statistics on groups of patrons.
User Block Tab
Solars stores patron block information in the BLOCK_TYPE and BLOCK_NO fields in the secondary patron block file. Provide the list of available blocks from Solars and their description, along with the block code as it should be in Alma.
This mapping table is not mandatory.
Solars BLOCK_TYPE and BLOCK_NO: The Solars Block type and block number, in the format: ‘block_type 1 and block_no 1’.
Solars block Description: A description of the Solars block codes, for informational purposes only. This column is not used in the mapping.
Alma Block code: The block code desired in Alma.
Alma Block 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 updated after migration.
Comment: Use this field to add any comments about USER_STATUS.
Campus Code Tab
Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the BRCH_CODE to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.
Solars BRCH_CODE: The value of the patron home library as found in the BRCH_CODE field of the patron extract.
Solars BRCH_CODE Description: A description of the BRCH_CODE field, for informational purposes only. This column is not used in the mapping.
Alma Campus Code: The Alma campusCode. You may map the codes 1-to-1, or you may use this map to collapse codes.
Alma Campus Code Description: A description of the Alma campusCode, for informational purposes only. This field is not loaded into Alma.
Further Information: The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing.
Fines and Fees Tab
Solars FINE_TYPE: List all of the values from the FINE_TYPE field in the Solars extract.
Solars Description: A description of the FINE_TYPE, for assistance in filling out this form. This column is not used in the mapping routine.
Alma Fine Types: Possible values in Alma are listed in the drop-down list.
Further Information: Outstanding patron bills from Solars are migrated to Alma Fines and Fees. Only the currently owed amount is migrated. If any partial payments have been made before conversion, they are not reflected on migration to Alma.
Additionally, the patron deposit amount is reflected in Alma, but the deposit amount comes from a field in the patron record.
Further Explanation – Fulfillment
Internal/External Patrons
Alma categorizes users as either external or internal. External patrons are managed 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 community borrowers or alumni. Identify patrons as internal or external by user group on the Solars Migration Form, User Group tab, Internal? Yes or No column. For example: all faculty are EXTERNAL and all community borrowers are INTERNAL.
Identification Numbers
The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. Select one of these identifier types 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.
The following appears in the Solars Field Mapping Form:
User Identifiers: Values in column A are the type of identifiers allowed for migration purposes; values in column B are your local Solars field names - change them as appropriate for your own data. Use the values in column A to make a selection for the Primary identifier selection in the Migration Form, questionnaire tab. ##.
A |
B |
UNIV_ID |
ALT_PID |
BAR |
PID |
ADDL_ID_1 |
EMAIL |
ADDL_ID_2 |
FAX_NO |
ADDL_ID_3 |
|
ADDL_ID_4 |
|
So, if you put ALT_PID in the UNIV_ID field in the Field Mapping form, and you want that to be the user’s primary identifier, choose UNIV_ID for the user identifier question in the Migration Form.
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 unique 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 primary ID that you select 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 de-duplicated.
If the identifier selected for the primary ID is not present, the migration program attempts to fill in with other identifiers, in the following order:
- When ADDL_ID_* is selected and not present, use UNIV_ID, then BARCODE, and then ORIGINAL_ID
- When UNIV_ID is selected, use BARCODE, then ADDL_ID_1, and then ORIGINAL_ID
- When BARCODE is selected, use UNIV_ID, then ADDL_ID_1, and then ORIGINAL_ID
Select BARCODE, UNIV_ID or ADDL ID 1, 2, 3, or 4 as the primary ID type for internal or external patrons in the Questionnaire tab of the Solars Migration Form.
Loans
Active loan transactions are migrated from Solars to Alma. Completed loan transactions are not included in the migration to Alma.
Fines and Deposits
Deposit amounts, stored on the patron’s record in Solars, are migrated as a credit in Alma. Fines and fees, which come from a separate fine/fee file, are migrated as debits.
Acquisitions
Customer Input
Questionnaire Tab
Complete the following in the Questionnaire tab:
Migrate Acquisitions
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
Options: See explanation below in Default Order Library
Default Order Library
Code: DEFAULT_ORDER_LIB
Default: First library found on the Alma Library list
Options for Central and Default Order Library: The BRCH_CODE field specifies the order location for orders in Solars. The migration attempts to map the BRCH_CODE field to the corresponding Alma Library. If you want to override this BRCH_CODE field and instead assign an order library to all orders migrated, fill in a value for the Central Order Library question. Otherwise, if you want to use the BRCH_CODE field to determine the order library, leave the Central Order Library blank and fill in a value in the Default Order Library question. In this case, the migration attempts to determine a library based on the BRCH_CODE field and only when a library is not specified or a mapping is not found does it use the Default Order Library as a second choice.
Default currency for Ledgers/Funds
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
Default language of conversation with vendors
Code: VENDOR_LANG
Default: en
Options: Specify the default vendor language for your vendors. 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.
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.
Which year do you use to name the fiscal year?
Code: FISCAL_PERIOD_NAME
Default: second
Options: Specify if the fiscal period is named with the first year or the second year.
- second – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
- first – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2014.
If your fiscal period runs from January 1 through December 31, this question is not necessary.
Current Fiscal Year
Code: CURRENT_FISCAL_PERIOD
Default: determine by date of conversion
Options: This question is important around the fiscal period close, depending on whether or not you have run fiscal period close in your legacy ILS, or if you will run it in Alma after migration. If you do not know how to answer this, select determine by date of conversion. The options are:
- Determine by date of conversion – The conversion program uses the fiscal period that includes the date of conversion.
- 2013-2014 – Select this option if the date of conversion is later than the fiscal period to which you want your orders to migrate. For example, if the migration date is July 3, 2014, and the previous fiscal period ended on June 30, 2014, select this to put all of your orders in the fiscal period that ended on June 30, 2014. Select this option if you want to run fiscal period close in Alma instead of in your old system.
- 2014-2015 – If the date of conversion is earlier than the start date of the desired fiscal period, select this option. For example, if the migration date is June 15, 2014, and the next fiscal period begins on July 1, 2014, select this option to put all of your orders in the next fiscal period. Select this option if you want to perform the fiscal period rollover in your legacy ILS prior to conversion.
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.
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 an answer to this question (if populated). The default is renewal date = migration + 1 Year. The default is used only if no renewal date is provided in the orders and no answer is provided in the migration form questionnaire.
Date to Indicate which Orders are Open
Code: PO_DATE_OPEN
Default: today (conversion date)
Options: (YYYYMMDD or today)
Further explanation: The migration programs look at the CHECK_DATE of the serial subscription, and compare it to the date you list here. If CHECK_DATE is earlier than this date, the order is closed. If CHECK_DATE is equal to or after this date, the order is open/sent. To use the date of conversion, type today.
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 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.
RECEIPT_TYPE: The value of the RECEIPT_TYPE field in Solars, found in your order extract.
RECEIPT_TYPE description: A description of the Receipt Type in Solars, for information purposes only. This field is not used in the mapping to Alma.
poLineAcqMethod: The Acquisition method in Alma. AcqMethod is mandatory in Alma. If not found, then use PURCHASE. 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.
Comment: Add any comments about Receipt Type for use while filling out this form. This field is not used by the migration programs.
Further explanation: 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.
Reporting Code Tab
This tab is optional if you are migrating orders.
Solars BOOK_FLAG: Value of the Book Flag field in Solars, found in the BOOK_FLAG field in your order extract.
Solars USE_TYPE or DONA_TYPE: Value of the Use Type or Dona Type field in Solars, found in your order extract.
Description: A description of the BOOK_FLAG and USE_TYPE/DONA_TYPE field, for information only. This field is not used in the mapping to Alma.
Further Explanation – Acquisitions
Fund Input File
Fund records are submitted in CSV format and loaded to Alma. They are not extracted directly from Solars. See the Solars to Alma Data Delivery Specification document to see the file format required for funds.
The funds in the input file are only created for the current fiscal year.
Initial allocations for the migrated funds are created from the Allocation field of the Fund Input file.
PO Entry Point
All monographic orders are migrated as CLOSED in Solars. For serial orders, if the CHECK_DATE is later than today, the order is SENT. Otherwise the serial order is CLOSED.
PO Line Type
Monographic orders are migrated as PRINT_OT, and Serial orders are migrated as PRINT_CO. If the order is linked to a bibliographic record that is in the P2E (print to electronic) file, the order is transformed to the corresponding electronic order type (OT or CO) when the P2E process is run. See the P2E section for more information.
Transactions of Amount 0.00
Solars allows for transactions to be of value 0.00 for all purchase orders (encumbrances). 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.
Libraries and Locations in Orders
There are two different locations that are needed for the order:
- ordering location – an acquisition unit
- inventory location – destination of the inventory related to this order
The inventory location is taken from the BRCH_CODE/LOC_CODE of the related item.
The ordering location for Solars is taken from the order’s BRCH_CODE – there is no LOC_CODE for the ordering location. The BRCH_CODE needs to be mapped to an Alma library. The migration process uses the Alma Location Tab (see inventory section above) to map the single value BRCH_CODE to an Alma Library code. Since the map is two-level (BRCH_CODE/LOC_CODE – Library/Location), the migration programs take the first library found for the specified branch code.
For example, in the following table:
BRCH_CODE |
LOC_CODE |
Alma Library |
Alma Location |
01 |
08 |
Main |
Stacks |
01 |
02 |
Main |
Reference |
01 |
04 |
Archives |
Local |
There are two different Alma libraries for the single BRCH_CODE 01, Main and Archives. Since there is no LOC_CODE for the ordering unit in the order, we can only use BRCH_CODE in the map. The first line that matches BRCH_CODE 01 is used, in this case Main.
Orders for Multiple Bibliographic Records
An order may have multiple items and/or multiple bibliographic records associated with it. If an order is associated with multiple bibliographic records, a single order is created and linked to the first bibliographic record found. The order is still linked to the inventory of the other bibliographic records. All of the inventory for all of the bibliographic records are listed in the Ordered Items section of the single PO Line.
Serial Records Spanning Multiple Years
Serial orders are often kept open or renewed over multiple years, with the same order being invoiced and received upon many times. In Solars, multiple copies of the same order are created. In Alma, there is only one copy of the order that is rolled over year after year. When migrating to Alma, the most recent serial order is placed in a SENT status, and the previous orders are placed in a CLOSED status. The most recent order is determined by CHECK_DATE.
Monographic and Serial Orders
In Solars, serial and monographic orders share some but not all of their information. The following is a chart that describes how serials (SER_MST) and monographic (ACQ_MST) orders are processed. Generally, the chart says:
- Only make monographic orders if there is an item found in acq_reg_info file
- Only make monographic orders if there is NOT a related serial order
- Do not make a serial order if there was not a related acq_mst record
- Serial orders can either be linked to item records through acq_reg_info file or to bib records through the q_info file
Physical to Electronic (P2E) Processing
This section describes the process of correctly categorizing resources as electronic in Alma. In Solars, 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 must 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 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 3 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
Options: Provide a 3 digit Marc field code + subfield: 856z. Only one field/subfield is allowed.
Recommendation: 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 3 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 may 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 Solars 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 Millennium 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, then 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, refer to Electronic Resource Handling in Alma Migration.
Appendix A – Post-Migration Process Statuses
The process statuses (codes) from the local system 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, described here:
https://developers.exlibrisgroup.com...le-of-barcodes.
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.