SISIS to Alma Data Delivery and Migration Guide

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

SISIS-SunRise is an Integrated Library System, produced by OCLC, Inc. Customers are expected to provide extracts for their inventory, fulfillment, and acquisitions data, and map them into expected SISIS fields using this guide and the SISIS Field Mapping form.

This document serves three purposes:

A description of data elements expected, and how they are mapped using the SISIS Field Mapping Form.
A step-by-step guide to filling out the SISIS Migration Form.
An explanation of general migration rules which do not require any customer input.

Recommendations for Using this Guide

This document is divided into four areas:

Inventory
Fulfillment
Acquisitions
Physical to Electronic

Each area has the following sections:

File Information: Information on files that are expected from SISIS and where incoming fields are mapped in Alma, including functional implications.
Migration Form: Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
Migration Form: Individual Tabs – Instructions for how to fill out individual tabs on the Migration Form. (Examples: Alma Library Tab, User Group Tab).

We recommend that you look at the Questionnaire tab section and the individual tabs in each area to assist in filling in the migration form.

For more information about any of the data input or about the migration in general, see the more detailed explanations in the Further Explanations sections.

Migration Overview

The procedure for migrating from SISIS to Ex Libris’ Alma consists of the following steps:

Indicate which local fields correspond to the expected fields using the SISIS Field Mapping form, prior to data delivery (customer responsibility).
Validate the flat files using Non-Ex Libris to Alma Validation Tool Excel. It is recommended that this step be done against a small sub-set of data to ensure that the header of each of your flat files and the filled in SISIS Field Mapping form match each other.
Extract the relevant data elements from the ILS into flat files (customer responsibility).
Upload the files to Ex Libris’ secure file server (MFT) along with the SISIS Delivered Files form and the executed/validated Non-Ex Libris to Alma Validation Tool (customer responsibility).
Transform the data elements, based on the Field Mapping form, into an intermediate conversion XML format (Ex Libris responsibility).
Load the transformed data into Alma (Ex Libris responsibility).

Deliver the SISIS Field Mapping Form and validated data validation output form to Ex Libris along with the validated SISIS MIgration Form prior to the actual delivery of the data. The lead time depends on your project schedule. Provide the SISIS Delivered Files List form, which lists the file names and the record counts for each file, at the same time that you provide your data extract files.

Provide the data elements in flat files, and place them on an Ex Libris secure file server. Prepare the data files in the exact format as specified in Appendix A – File Delivery and Delivered Files Form with the naming conventions as described there.

Files Requested from SISIS

Ex Libris expects a certain set of files to be exported from SISIS, listed below. As files are extracted, be sure that the extracted file description, such as data elements and lengths, matches the description in Expected File Formats.

The data elements listed are those that Ex Libris expects to use in conversion. Not all data elements that exist in SISIS are necessary to transfer to Alma.

The scope of your specific conversion is agreed upon in your Alma contract.

As you extract data from any area listed below, provide it to Ex Libris via the MFT server. Your Ex Libris project representative will provide informaiton on how to connect to the MFT server. This facilitates the transformation analysis and expedites the conversion process. For filedelivery instructions, see Appendix A – File Delivery and Delivered Files Form.
DO NOT OPEN/UPDATE any delimited file extracts you provide to Ex Libris in Excel. This may ruin the appropriate delimiter formatting and text formatting and may result in corrupted data.

Expected File Formats

All the files listed in the tables below are expected in CSV format with one record per line, and fields delimited by commas and multi-values within fields delimited by semicolons. The following is an example of a record with multiple values for the third field:

“field1”,”field2”,”field3a”;”field3b”,”field4”

The following are the only exceptions to this expected format:

Bibliographic records (which are MARC standard files)
MARC Holdings records

For all files, the maximum file size is 2GB.

Dates can be in any format, but they must be consistent. For example, do not use YYYYMMDD and then MMDDYYYY in the same file.

SISIS Field Mapping Form

Prior to submitting your extracted files, complete the SISIS Field Mapping form. Indicate which data elements (files) you plan to provide in the Overview tab of the spreadsheet. On the subsequent tabs, indicate your local field names and how they map to Alma's expected field names.

On all of the tabs in the SISIS Field Mapping form, there is a ##Foreign Key## column. Customers should not fill out this column – it is for internal use only. In addition, there are various note fields for each data element. Fields that are not expected by Ex Libris (because there is no functional place for the data element in the corresponding Alma data structure) can be placed in a note in the record. Specify the note type that you want the field to go to at the bottom of each tab in the SISIS Field Mapping form.

SISIS Delivered Files Form

At the time you submit the requested data files, submit the completed Excel spreadsheet SISIS Delivered Files form. List the files, record counts, and encoding for each file delivered to the secure MFT file server.

SISIS Migration Form

Fill out the questions in the SISIS Migration form, using this page as a guide. The questions and mapping tabs in the migration form are used for data elements which require user input. Submit the migration form along with your data. The migration form must be validated prior to submitting, using the Migration Form Validation tool.

Using the Migration Form Validation Tool

The SISIS Migration Form is used by the migration programs to convert your data for use in Alma. Therefore, it is important that the data entered by the customer is valid so that the migration can continue on schedule.

Your sandbox contains an online validation tool that helps ensure that your data is valid before you submit the form to Ex Libris. Information about this online validation tool can be found at: Validating the ILS Migration Form.

After you have completed the form, visit the above link in your sandbox to begin the validation process.

Inventory

Bibliographic Records

Bibliographic records are expected in MARC format. Binary MARC is preferred, but Ex Libris also accepts files in MARCXML format as well. The character encoding expected is UTF-8. If your library prefers to export in a different format, inform your Ex Libris project manager. All files should be delivered with the same character encoding.

Each Bibliographic record MUST have:

a single unique source key/identifier in a consistent single source MARC field, for example the 001
a LDR
a 245 (title) field

Records which do not conform will be rejected.

Non-filing characters

The 245 field (title statement) and possibly other fields have non-readable characters which indicate non-filing. For example, using '&' to represent a non-filing character, we may receive this:

&The &Dog Ran Away with the Spoon.

This represents four non-filing characters, which could be moved to the 245 second indicator (=4).

This could also be represented functionally in Alma as:

<<The >>Dog Ran Away with the Spoon.

Customers are encouraged to either replace the non-filing characters with an appropriate second indicator, or change them to the functional << and >> text.

Suppressed Records

Suppressed records are those bibliographic records that you want to have in the database, but not show to the public. Examples of this are:

titles on order
missing or damaged titles where you want to keep the record but not show it to the public
titles that are for internal management only, such as equipment

Provide a text file that contains the source BIB key/ID, one key per line, for bibliographic records that are suppressed.

Boundwiths

Boundwiths are not expected from SISIS libraries. If your institution has boundwith records, where a single item links to multiple bibliographic records, inform your Ex Libris representative.

Linked Bibliographic Records

If you use standard 7XX fields for linking between MARC bibliographic records (or standard linking fields for UNIMARC), they are leveraged during migration and create appropriate bibliographic-level linking in Alma.

No exported files are necessary for this category: use the migration form, Questionnaire tab, to indicate if your bibliographic records contain linking fields.

Electronic Link Resolver Records

If you have SFX MARCIt records, 360MARC records from 360Link, or equivalent electronic records from a different link resolver in SISIS which are also represented by your link resolver system, Ex Libris recomends that they be excluded from the data provided to Ex Libris to avoid unnecessary duplication. If these records are NOT removed, you will likely see a record in Alma migrated from the ILS and the same record migrated from SFX or the .

An exception to this is if the records have active orders or physical inventory that are also being migrated, these records should be kept. If you choose to provide a string to indicate records to be removed/not migrated, the migration programs remove records with no attached orders or inventory and keep records with attached orders and items.

No exported files are necessary for this category: use the Questionnaire tab of the migration form to indicate a string that will be checked in the 035 field. Example: ‘(SFX)’.

Holding Records

Previous SISIS customers who migrated to Alma provided holding record information in Aleph sequential format, because they were part of a consortia which also uses Aleph. Therefore, Aleph sequential is an acceptable format for SISIS holding records.

However, if you are coming from SISIS and are NOT part of an Aleph consortium, and want to provide holding information in a different way, you can provide the following:

MARC holdings
Holding information embedded in bib tags

On migration, Ex Libris removes the contents of the 852 $a in MARC holdings records. If you want to preserve the information in the 852 $a, move it to a separate subfield prior to delivery for migration.

Aleph Sequential Holdings

Aleph sequential holding records are essentially MARC records but in a special format used by Aleph, an Integrated Library system produced by Ex Libris. In order to provide Aleph sequential holding records, the following must be true

There must be a unique holding record key in the 001
There must be a link to the SISIS bib record in the 004
The 852 must contain SISIS-type library ($b) and location ($c) codes. These will be sent through the Alma Location mapping tab in the SISIS Migration Form.

Items from SISIS can link to Aleph sequential holdings as long as the items are linked to the same bib, and the items are in the same location as the holding. Items will attach to holding records using the algorithm described in the question 852_SUBFIELDS_FOR_HOL on the Questionnaire tab of the Migration form.

Note also that the match for the library/location codes is done AFTER the mapping. Therefore, the holding record and the item record could have two different SISIS library/location codes, but if the map to the same thing in Alma, they will still attach.

MARC Holdings

If MARC holdings are provided, each record MUST have a single unique source identifier in a consistent single source MARC field as well as a valid unique bibliographic identifier in the 004 in order to link it to its correct bibliographic record. Records that do not conform are rejected.

Holding Records from a Summary Statement in a Bibliographic Record

If the customer has serial holdings which are only represented by a summary statement such as Vol. 1 (1980) – Vol. 21 (2000), these statements should be included in a tag in the bibliographic record. Use the Holdings tab of the SISIS Field Mapping form to indicate which field and subfield contents to use for generating holdings records from summary statements embedded in the bibliographic record.

Fill in the values of the following fields in the Holdings tab of the SISIS Field Mapping form. If the SUMM_LOC_CODE matches an existing holdings record on the same bibliographic record, even a holdings record that was generated from items attached to the same holdings record, then the summary holdings statement is attached to that holdings record, regardless of call number. In other words, the summary holdings is placed on the holdings record with the same location, even if 852_SUBFIELDS_FOR_HOL contains call number subfields for matching like bchi. If there is no existing holdings record on the bibliographic record with the same location, a new holdings record is generated.

Holding Records from a Summary Statement in a Bibliographic Record
Expected Field Name	Value	Notes
SUMM_TAG		Five characters; tag+2 indicators. May use # as wildcard, for example, 866## or 86#3#. Wildcard allowed for third digit and indicators but not first two digits. To indicate a space character, use b, for example 866b1.
SUMM_SUBFIELDS		Multiple subfields allowed,for example, abz. May use # to indicate all subfields.
SUMM_CALLNO		Textual call number to be used in all newly generated holdings records, if desired.
SUMM_LIB_SUBF		A single subfield code (like 'a') which contains a library code in local ILS format. DO NOT enter a different bib tag: the migration program searches for a subfield within the SUMM_TAG BIB tag.
SUMM_LOC_SUBF		A single subfield code (such as a) that contains a location code in local ILS format. Do NOT enter a different bib tag: the migration program searches for a subfield within the SUMM_TAG BIB tag.
SUMM_LIB_CODE		If SUMM_LIB_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a library code in local ILS format.
SUMM_LOC_CODE		If SUMM_LOC_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a location code in local ILS format.
SUMM_PUBLIC_NOTE_SUBF		Public note, is placed in 852 $z of the generated holding record.
SUMM_NON_PUBLIC_NOTE_SUBF		Non-public note, is placed in 852 $x of the generated holding record.

Item Records

Ex Libris expects item records from SISIS in csv delimited format. CSV delimited format. Items that do not have a BIB key are not migrated.

Suppressed Item Records

All suppressed item records are migrated to Alma as regular items (not suppressed). However, specific locations can be marked as suppressed in Alma so that groups of items can be suppressed from public view.

Holding Record and Item Record Relationship

If your ILS does not store holding information or if not all inventory records have a holding record, for example, if serials records have a MARC holding record but monograph records do not, then Ex Libris generates holdings for the items based on the item information provided.

See the 852_subfields_for_hol question for more information about how to determine how item records are grouped when generating holding records.

Item Record

The following format is used for an item record in CSV format from SISIS. Records should be provide one record per line, with quotes and commas. Provide a header at the top. If something is allowed to be repeatable, provide the repeated information with a semicolon.

Item Record
Expected Field Name	Notes
IZ-Key	ib key; used to link to bib record
Barcode	links to loans, requests, fines. The barcode may be delivered with spaces within the barcode (e.g. 123 45 678). By default, the spaces are removed. If you wish to retain the spaces, meaning that there are spaces on the actual barcode of the item, inform your Ex Libris representative.
CallNo 1	If a holding record is present, then this is used to match an item to a holding record, if $h is included in 852_subfields_for_hol. If a holding record is not present, then this is used when generating a holding record. Further, if only bc is used in 852_subfields_for_hol, then this call number could* be placed in the ITEM_CALL_NUMBER field when multiple items are grouped together into a single holding record. * 'could' because CallNo 2 will be placed in ITEM_CALL_NUMBER if present. If CallNo 2 is NOT present, then CallNo 1 is placed in the ITEM_CALL_NO according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.
CallNo 2	If this is present, then the value will be placed in ITEM_CALL_NUMBER. This value takes precedence over a possible value from CallNo 1, according to the descriptions in "Determining Groups of Holding Records" and "Changing the Holding Record Grouping" sections below.
CallNo1Sort	use in Shelving Scheme tab
CallNo2Sort	use in Shelving Scheme tab
Library_Key	use in Alma Location map
Location_Key	use in Alma Location map
Alma_ItemPolicy_Code	use in Item Type map; this or LoanabilityMark but not both
Alma_TempLib_Code	use in Alma Location map
Alma_TempLoc_Code	use in Alma Location map
MaterialType	use in Material Type map. If empty, migration will generate based on LDR/008
PhysItemDesc	use in ItemType map column 2
LoanabilityMark	use in ItemType mapcolumn 1
InventoryNo
CountLoanSum	To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'. Alma increments the loan count for items currently on loan, so it is recommended that you send (loans - 1) for currently loaned items.
LastReturnDate	To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
NumberofSupplements
Damaged	will be placed in Alma PHYSICAL_CONDITION field. Use in 'Item Physical Condition' map.
Description	like V. 12 No. 1 (January 2020)
ArrivalDate	can be in the past or in the future (expected)
POL_NUMBER	Links to POL_NUMBER in *_OT (monographic) orders only

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. You may place any incoming field in the notes that you wish: you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, make as many copies of the line in the spreadsheet as needed for all note name/local field combinations.


Note Name	Description
PUBLIC_NOTE	Shows to the public
FULFILMENT_NOTE	Pops up at circulation activity.
NON_PUBLIC_NOTE_1	Internal notes
NON_PUBLIC_NOTE_2
NON_PUBLIC_NOTE_3
STAT_NOTE_1	Statistical notes
STAT_NOTE_2
STAT_NOTE_3

Item Statistics Notes (STAT_NOTE_*) can use controlled vocabulary when statistics_note_controlled is set to true. For more information, see Configuring Item Statistics Notes.

Secondary Item File

You may want to provide item descriptive information in a secondary file, because the data coming from SISIS is not separated into the various Enum and Chron fields. For example, you have a description in the format Vol. 12 No. 2 (2015 February), but Alma recommends that enumeration and chronology information are without labels and are in separate fields. You can provide your description in a secondary item file.

With the exception of the item_key and barcode, all other fields will force blank if an empty field is provided. In other words, if you have an item description in Alma, and you provide a blank description in this file, the incoming blank will be 'written' to Alma, meaning the Alma description will be deleted.

We recommend that EnumX and ChronX fields contain only numbers, for example '12' instead of 'Vol. 12' and '2' instead of 'Feb'. However, it is programmatically time-consuming to distinguish between an invalid use (Vol. 12) and a valid use (12A), so in the interest of processing quickly, we allow any string in EnumX and ChronX fields. Do not provide a full date in a single field. Split any dates into three, for example 4 Feburary 2020 is ChronI=2020, ChronJ=2, ChronK=4.

Even though it is not recommended, if for any reason you need to provide a full date in a single field, put a tick (') before the date in the Excel cell so that it is treated like text (instead of the Excel date format).

Provide the secondary item file in Excel format (xls or xlsx) format, with the following fields:

Expected Field Name	Notes
item_key	Provide either item_key or barcode, but not both. If both are provided, item_key is preferred Always provide both fields, even when one is empty. For example:
barcode
description	Provide in a format such as: Vol. 12, No. 6 (February 2015)
enumA	For example, “12”.
enumB	For example, "6".
enumC
enumD
enumE
enumF
enumG
enumH
chronI	For example, "2015"
chronJ	For example, "2".
chronK
chronL
chronM

E-Resources Indication (P2E)

Provide a list of bibliographic system numbers that represent electronic resources and an indication if these electronic resources are portfolios, packages, or database resources. Prepare the list as a comma separated text file containing lines that represent each e-resource. Structure each line as follows:

For example:

b000000001,Portfolio

b000000002,DB

b000000003,Package

Note that the words portfolio, package, and db are not case-sensitive, therefore both portfolio and Portfolio are acceptable.

Item Call Number Sequences

Some libraries use a sequence for a prefix in their item call numbers. Since these sequences must start at a specific number after go-live in Alma, customers may provide their sequence prefix and the next number in line.

Records should be provided in CSV format, quotes and commas. There should be one record per line with a header at the top. Provide the sequences in the following format:

Note Name	Description
prefix	Mandatory
name	Not mandatory. If empty, the name will be filled with the prefix.
library	Provide this as an Alma library code (not SISIS). Not mandatory.
location	Provide this as an Alma location code (not SISIS). Not mandatory.
nextNumber	The next sequence number in line. Mandatory

Customer Input - Inventory

The following questions and tabs are in the Migration Form, and relate to Inventory.

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 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). These are mandatory and must be filled in.

Default: N/A

Time Zone: Select your time zone from the drop-down list. If your time zone is not listed, contact your Ex Libris project manager.

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 former system number field (bibliographic system number) to the 035 $a field:

(MOC)<bibliographic record id>-<customer code>

<(moc)> is the MARC Organization code specified here. <customer code> is the customer code specified in the CUSTOMER_CODE question above.

For example: (AbC)u12345-01abc_inst

Usually the former system number can be in the 001 field of the bibliographic record. Customers should specify where the former system number is in the Bibs & P2E tab of the Generic Field Mapping form.

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. Multiple strings are allowed, use a semicolon to separate: (SFX);WaSeSS;EBC

Further Information: If your catalog contains records imported from SFX or another electronic resources management system and you are also migrating bibliographic records directly from SFX or the other management system, this may 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 into 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 your incoming records 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.

Do you use internal system numbers in Linked Entry fields?

Indicate if you use internal system numbers in linking fields. Internal system numbers from your legacy system are not continued in Alma, and therefore should be changed to MMSID (the Alma internal system number).

MARC fields: $w subfield for tags 76x-78x, 80x, 81x, and/or 83x

Unimarc fields: $1 subfield with prefix 001 for fields 423, 461, 462, 463, 464 [example: bib key 99999 in tag 461 = 461 $100199999]

Code: LINKED_ENTRY_W

Default: No

Options: If you answered Yes to this question, the internal system numbers in the subfield $w or $1001 of the specified tags are converted from the former system number to the Alma system number.

Internal record designation for Linked Entry fields $w

Code: LINKED_ENTRY_PREFIX

Default: Blank

Options: If you answered Yes to the previous question and the internal system numbers have a prefix, enter the value to be matched to identify the local system number. If the system numbers in $w or $1001 do not have a prefix, or if you answered No to the previous question, leave this question 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, your previous ILS may store the information in bibliographic fields 76x-78x, 80x, 81x, and 83x $w for MARC, and 423, 461, 462, 463, 464 for Unicode. If the number in the $w or $1001 of the linking tags is the internal legacy ILS 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 instead 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 linking field 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. For more information on configuring related records, see Configuring Related Records for Physical Inventory.

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 and location only, select bc here. If you have many items in the same bibliographic record in the same llibrary/ocation 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: 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.

Further Information: See Determining Groups of Holding Records and Changing the Holding Record Grouping.

Do you want to use a call number in the generated holdings records?

Code: CALL_NO_IN_HOL

Default: Yes

Options: Yes or No

Further Information: You may choose to generate holding records without any call number, so that the 852 contains only $b (library) and $c (location) by selecting 'No' here. When 'No', values in the incoming Item Call Number field are placed in the Alma Item Call Number. Further, when 'No', customers should only use ‘bc’ for the 852_CALL_NO_FOR_HOL question.

Be aware that some Alma notices, such as request notification, use the call number from the holding. Test your workflow thoroughly with no call number in holdings.

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 is 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 in Fulfillment

Move 001/003 to 035 or 935

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

Ex Libris marks the moved 035 or 935 with $9 ExL to indicate that the migration programs generated this field.

Further information: If an 035 exists in the record already with the identifier that was in the 001, then a second (duplicate) tag is NOT made. Also, when checking if the identifier already exists, the migration programs compare to the $a only. Meaning, if an existing tag contains

001 12345

003 OCoLC

035 $a(OCoLC)12345 $z (OCoLC)54321

then the existing 035 $a is considered a duplicate and a second tag is not created.

Add institution suffix to Bib ID

Code: BIBID_INST_SUFFIX

Default: No

Options: When moving the legacy bibliographic identifier to the 035 or 935, you can choose to add the institution code to the end of the string, like 12345-34ABC where 12345 is the legacy bib ID and 34ABC is the institution code. This may be used in conjunction with other bib identifier options, such as BIB_KEY_PREFIX and MARC_OC.

Yes = include suffix

No = do not include suffix

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#

The wildcard works only for the third digit of the tag and the indicators. Examples:

CORRECT: 95###

INCORRECT: 9####

Also, 900-949 cannot be used here, as described in the Migration Considerations for Consortia guide

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: !@#$%^&*()+=/?><.,\|]}[{`~ and 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. This must be unique. For example, you cannot have two libraries with code LIBA and LIBB and have them both called 'Library'. They must have different names.

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 Alma library is the higher level of location. The Location or sometimes Physical Location is the lower level of location. Your ILS may or may not have an existing higher level of location. If you have a higher level of location already, you may likely simply copy those libraries to this tab here. If you only have one level of location, you can list new libraries here and then map existing locations to a library/location combination using the Alma Location tab.

Use the Alma Libraries tab in the Generic Migration Form to indicate your list of Alma libraries. The actual mapping from the legacy library to the Alma library is done in conjunction with the Physical Location in the Alma Location tab.

If you use an error library (for example “EMPTY”) in the ALMAME_VALUE_NOT_FOUND line of the Alma Location Map 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 legacy libraries and locations to libraries and locations in Alma. Filling in this tab is mandatory. If your legacy ILS has only one level of location, put the values for that location into the ‘Second Level Location’ column (Column B - Location), and leave Column A blank. If your legacy ILS has two levels of location, use both Column A and Column B.

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.

Library_key: First level of location - Value from the Library field in the SISIS item extract or the 852$b in the MARC holdings extract. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed. Incoming locations cannot have special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.

Location_key: Second level of location - Value from the location field in the SISIS item extract or the 852 $c in the MARC holdings extract. Incoming locations cannot have special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.

Alma Library Code: The library that contains this library/location combination in Alma. You can use the same library codes that you used in SISIS, 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 your legacy ILS, but this is not required. You may also use this form to collapse locations if desired, for example refa and refb 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.

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 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 want to stop using a location code after migration, map the incoming code to an easily identifiable code such as XXX or unused just in case any stray items are still in SISIS. 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.


Incoming Library code	Incoming Location Code	Alma Library Code	Alma Location Code	Alma Location Desc	Alma External Loc Desc	Suppress from Externalization
ALMAME_ VALUE_NOT _FOUND	ALMAME_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:


Alma 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:


Alma 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 your legacy ILS 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 incoming code to an easily identifiable code such as XXX if any stray items are still in your library database.

If you collapse location codes, you may have lines in the table such as the following:


Incoming 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 three values in bold italic above (ReserveElec as the External Location name, and Yes for Suppress from Externalization and 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 incoming Item Type 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.

This mapping table has two optional inputs, mapping to a single Alma output.

Incoming Loanability Mark, or Item Type: The value in either the Loanability Mark field or the Item Type field from SISIS. The item type is usually used to differentiate between items when determining how items circulate.

Description: The description of the incoming loanability mark or item type, for information only. This column is not used during the mapping process.

Incoming PhysicalItemType: The value in the PhysicalItemType field from SISIS.

Description: The description of the incoming loanability mark or 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.

Either input column can use an asterisk (*) to indicate 'any value'. If you want to indicate 'no value' (i.e. empty), then leave the column blank.

Acceptable input for this tab:

Loanability Mark	PhysicalItemType	Notes/explanation
A	y
A	*	will catch every value for PhysicalItemType except y
A	t	this line will not be used because the line above with the asterisk will have caught A,t
	m	this will only catch fields with no Loanability Mark and 'm' in PhysicalItemType
B	m
*	m

Item Material Tab

Use this tab to migrate any incoming Material type to the Alma Material type. The material type is not mandatory; if no material type is indicated for an item, one will be generated based on information from the bib fixed fields.

If you want *some* incoming items to be assigned a material type here, and the rest to be assigned the material type from the bib fixed fields, then be sure to not include the ALMAME_VAL_NOT_FOUND line. If this line is included, then all incoming items will be assigned a value from this table.

Incoming Material Type: The value in the material type field of the incoming item.

Material type Description: The description of the material type, for information only. This column is not used during the mapping process.

Alma Material Type: The Alma value for the material type. Material types in Alma are fixed. You cannot add any new types to the list. Select the appropriate material type from the drop-down list.

If this field is not provided in the extract, Alma migration assigns the item material type based on the fixed fields in the bib as described in section Material Type from Bib Fixed Fields below.

Shelving Scheme Tab

Alma will generate a first indicator for the 852 - in the newly created holding record - based on the Shelving Scheme tab.

CallNo1Sort or CallNo2Sort: The values in the CallNo1Sort or CallNo2Sort fields as delivered in the extract from SISIS. This field indicates what kind of call number is being used for this item/holding, such as Library of Congress or Dewey.

852 1st Indicator: List the value that should be used in the 852 first indicator field when generating a holding record from the item. For a list of possible values and their description, see http://www.loc.gov/marc/holdings/hd852.html. Note that 7 is not supported on migration. Mandatory.

Description: A description or note for this shelving scheme value, if you need to make a note while deciding the first indicator value. This column is not used in migration.

Further Information: Do not use an ALMAME_VAL_NOT_FOUND line here, because if an item has a shelving scheme that is not listed or does not have a shelving scheme value, the shelving scheme is taken from the Call Number Type column on the Alma Location tab.

Item Physical Condition Tab

Alma will map an incoming value to the Alma Item Physical condition field. In addition, you can generate the code table for the Alma values using columns C and D.

Incoming Physical Condition ("Damaged" field): The values in the incoming Physical Condition field, also called 'Damaged', from SISIS.

Description: A description or note for the incoming value. This column is not used in migration.

Alma Physical Condition Code: The code for the physical condition in Alma. Customers can add their own list of conditions, in addition to the predefined conditions: Damaged, Deteriorating, Fragile, Brittle.

Alma Physical Condition Description: The description for the physical condition, used along with the code to generate a code table in Alma.

Further Information: You may use an ALMAME_VAL_NOT_FOUND line here if you wish. This value will only be used if there is an incoming value and it was not found in column A the table. If you do not want an incoming value to be shown/used in Alma, leave column C blank.

If there is no incoming value, then no value is migrated to Alma.

Further Explanation – Inventory

Bibliographic Records

Bibliographic records are migrated as is and each bibliographic record can 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) is marked for OCLC publish, if relevant.
The LDR position 9 (character coding scheme) is set to a indicating Unicode.

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 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 may decide which 852 subfields are used to determine what makes items belong to the same group. The 852 subfields as mapped, described in the Library, Location and Call Number sections above, are: $b Library $c Location $h 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 holding 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 .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 Generic Migration Form, “Indicate which 852 subfields to use to determine unique holding records”.

Attaching Items to Existing Holding Records

The algorithm described above to determine groups of items for generating new holdings records is also used to determine if an item should be attached to an existing MARC holdings record. The question Indicate which 852 subfields to use to determine unique holding records from the Questionnaire tab of the Generic Migration Form is used here as well.

For example, consider the following incoming records:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

Holding record B: $b PER $c CURRENT $h Shelved by title

item 1: PER,MFORM PN 567 .M4

item 2: PER,MFORM PN 567 .M4 2010

item 3: PER,MFORM PN 567 .M4 2011

item 4: PER,CURRENT PN 567 .M457 2012

When only location (852 $b $c) is used to determine unique holding records, the following is the resulting structure in Alma:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

item 1 (ItemCallNo is empty because the call number matches)

item 2 (with PN 567 .M4 2010 in ItemCallNo)

item 3 (with PN 567 .M4 2011 in ItemCallNo)

Holding record B: $b PER $c CURRENT $h Shelved by title

item 4 (with PN 567 .M457 2012 in ItemCallNo)

When the entire call number (852 $b $c $h $i $k) is used to determine unique holding records, multiple additional holding records are created in Alma:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

item 1

*Holding record B: $b PER $c MFORM $h PN 567 $i .M4 2010

item 2

*Holding record C: $b PER $c MFORM $h PN 567 $i .M4 2011

item 3

Holding record D: $b PER $c CURRENT $h Shelved by title

*Holding record E: $b PER $c MFORM $h PN 567 $i .M4 2012

item 4

The holdings records with the asterisk (B, C, and E) are created new because the entire call number string of the item did not match the entire call number string of any of the existing holdings records.

Item Barcodes

While many legacy ILS systems allow item barcodes to be duplicated, Alma does not. The item barcode must be unique in Alma, although it may be left blank. Blank is not a unique check: very many of the barcodes can be left blank.

The item barcode is migrated according to the following rules:

If the barcode is empty, leave as empty in Alma.
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>

Because it is possible to use the barcode as the link between item and loan, request, fine, or order, if one of those is linked to an item with a duplicated barcode, it will be linked to the item with the unsuffixed barcode.

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.

All customers may provide a material type in a subfield of the item record, and use the Material Type tab to map them to valid Alma material types (see the explanation for Material Type tab, above). 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 header 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

This section describes the files expected and a description of individual fields, if necessary.

Patrons

Ex Libris expects patron records in CSV delimited format. Patron records without a record key identifier are skipped, since this is the minimum required patron information. The record key identifier is used to link the patron to other records such as loans and fines.

The following fields are expected. Indicate the local field names for the expected fields in the Patrons tab of the SISIS FIeld Mapping form.

Patrons
Field Name	Notes
PatronID	use to link to loans, fines, requests
FirstName
LastName
Gender	W=Female, M=Male, else = blank
UserTitle
Birthdate
UserGroupKey	use in User Group map
AdressType
Street
City
AdressCode
CampusCodeKey	use in Campus Code map
ExpiryDate	may be left blank
Email1
Email2
Phone1
MobilePhone
AdressExt
Country
LastActivityDate
UserLang
AdressType2ndAddress
Street2
AddressCode2
City2
AddressExt2
Phone2
Country2
SISIS provides a separate block flie because there can be multiple blocks for a single patron.
PatronID	links to patron record
BLOCKType1Nr	use in User Block map
BLOCKType1
BLOCKCreate1

User Identifiers

There can be a number of fields in the patron record that are user identifiers. The types of identifiers that are available for migration into Alma are listed in the left column. Enter fields from your institution’s patron extract that include identifiers. The values in the left column cannot be changed. Use the values in the left column to select the appropriate primary identifier in the Questionnaire tab of the SISIS Migration Form.

All patron primary identifiers MUST be unique across all users, as required by Alma. If they are not, the migration program disambiguates them.

User Identifiers
Alma Identifier Type	Migration Form Value
UNIV_ID	UNIV_ID
BAR	BAR
ADDL_ID_1	ADDL_ID_1
ADDL_ID_2	ADDL_ID_2
ADDL_ID_3	ADDL_ID_3
ADDL_ID_4	ADDL_ID_4

User Statistical Categories

There may be a number of fields in the patron record that function as a statistical category only, for example, a student’s department or major. The way the student borrows can be determined by the User Group, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. You may map up to ten SISIS fields to the USER_STAT_CATEGORY.

User Statistical Categories
User Statistical Category	Local Field Name	Field Label
USER_STAT_CATEGORY		SCHOOL:
USER_STAT_CATEGORY		DEPT:
USER_STAT_CATEGORY

Up to 10 incoming fields can be mapped. To map the values, use the UserStatCategories map in the SISIS Migration Form. If a value is not found in the map, it is migrated as is.

You may use a label if you wish; the label can help to distinguish between the same value in two different fields, for example if there is a department of LAW and a major of LAW and you want to be able to distinguish them in the map. If you use a label, the userStatCategory map tries to map the field including the label. The first column in the userStatCategory map would be: LABEL: value, for example: SCHOOL: Law. The migration program does not provide a colon; if you want a colon for easier management, put one in the label as above. The migration program does provide a space between the label and the value.

If you use this prefix, be sure to use the prefix again in the Migration Form Mapping tab for User Stat Categories, in column A (incoming data). In the Field Mapping form, provide labels to the right of the field:

Then, in the migration form, use that label as a prefix to the values in the field. Be sure to put a space between the label and the code:

In the case above, you can see that if there were no prefix to the fields, it would not be possible to distinguish between 'UN' from PC1 and 'UN' in PC2.

Notes

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column. The fields listed in the Default Local Field column are those that are expected by Ex Libris. If you use other field names or have fields that you want to include in the migration but are not expected by Ex Libris, you can rearrange, add, or subtract fields on the right, as necessary. If you want to include multiple local fields in the same Alma note, make as many copies of the line in the spreadsheet as needed for all note name/local field combinations.

Notes
Note Name	Information
LIBRARY_NOTE
BARCODE_NOTE
ADDRESS_NOTE
OTHER_NOTE	OTHER_NOTE is set as userViewable by the migration programs. This is the only note which migration marks as user viewable.
CIRC_NOTE	The 'CIRC_NOTE' is marked by the migration programs as a popup note. This is the only user note which migration marks as a popup note.

Loans/Circ Transactions

Extract only current circulation transactions.

Provide the loan files in comma delimited format. The following fields are expected. Use the Loans tab of the SISIS Field Mapping form to indicate local field names for the expected fields.

Loans/Circ Transactions
Field Name	Repeatable?	Notes
DATE_HOUR_OUT	N
DATE_HOUR_DUE	N
ITEM_BARCODE	N	links to item file; also links to fines
USER_ID	N	links to patron file
ORIGINAL_DUE_DATE	N
RENEWAL_DATE	N
PROCESS_STATUS:Renew	N
LOST_DATE	N	only checks for existence for 'lost' status; to keep date also put in notes


Note Name	Default Local Field
NON_PUBLIC_NOTE

Requests/Holds

Extract only those hold requests where the item is waiting on the hold shelf for pickup.

Provide the request files in comma delimited format. The following fields are expected. Indicate the local field names for the expected fields on the Requests tab of the SISIS Field Mapping form.


Field Name	Notes
ITEM_BARCODE	links to item file
USER_ID	links to patron file
PICKUP_LIBRARY	send through location map to get library
REQUEST_DATE
HOLD_DATE	FYI, the HOLD_DATE is ONLY used to calculate the expiration date. The date that the item is placed on the hold shelf is always set to the migration date. This is due to data constraints in the Request Workflow in Alma.
constant: expiration days	type a number, such as 30, to be added to HOLD_DATE to determine hold shelf expiration date.


Note Name	Default Local Field
NON_PUBLIC_NOTE	(none)

Fines/Fees

Fine and fees information is not mandatory, but when it is provided, Ex Libris expects active fine and fee information in csv format. Only active (outstanding) fine and fee information is migrated, and only the outstanding balance of each individual fine/fee; partial payment information is not preserved.

Potential Fines (Mahnverfahren or Dunning)

SISIS has a type of Fine/Fee record which is for potential fines, or Dunning (Mahnverfahren). These potential fines are physical records on the patron account in SISIS which indicate the fine which would be assessed if the item is returned today.

These potential fines should not be migrated to Alma. The only fines which should be migrated to Alma are those where the item has already been returned.

In Alma, when an item is overdue, customers can send overdue notices to remind the patron to return the item. Also, customers can set configuration rules so that patrons are blocked if they have too many overdue loans.

Potential fines are displayed on the Loan list in Alma, but the potential fine is not written to the database. The potential fine is calculated on the fly for display purposes only.

If the potential fines from SISIS ARE migrated to Alma for overdue loans, then when the loan is actually returned, Alma will create a fine record and then there would be two fines: the migrated potential fine and the actual fine.

Fields expected

The following fields are expected. Indicate the local field names for the expected fields in the Fines/Fees tab of the SISIS Field Mapping form.


Field Name	Notes
PatronID	matches patron ID in patron file
Reason	use in Fine Fee map
ItemId	matches item ID in item file; also loan file for linking fine to loan
Fees	current amount owed
Overdue Fines
Fee Update Date


Note Name	Default Local Field
NON_PUBLIC_NOTE

Customer Input - Fulfillment

The following questions and mapping tables are in the Migration form and relate to Fulfillment.

Questionnaire Tab

Complete the following in the 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 as the patron's Primary Identifier?

Code: PATRON_PRIMARYID

Default: UNIV ID

Options: Using the Generic Field Mapping Form, map the identifiers exported from Generic 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.

See also: Identification Numbers, Internal? Question on the User Group tab

How should we handle duplicate identifiers in the same patron?

Code: DUP_ID_SAME_PATRON

Default: DISCARD

Options: Alma does not allow duplicate identifiers anywhere, even in the same patron. If the patron has the same number in two or more different identifier types, we can either not migrate the second one, or disambiguate it with -1, -2 etc.

DISCARD: do not migrate the second and subsequent identifiers
ADD_SUFFIX: add -1, -2, etc

Default: DISCARD

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 patron campus 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 your patron records 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.

Request Default Destination Library

Code: REQUEST_LIBRARY

Default: None

Options: If the requests file does not contain a destination library/location, the library you enter for this question is used as the default for where patrons will usually pick up requests from the hold shelf.

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.

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.

UserGroupKey: The incoming values for the patron group, from SISIS.

Description: A description of the incoming patron group 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 your previous system, or you can use different codes. You can also collapse groups if desired, for example, having Freshman and Sophomore from SISIS 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 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. 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 user groups. 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?

See also the section on internal/external patrons.

User Stat Categories Tab

This tab is used to migrate the statistical categories in your patron records to Alma. It is possible to migrate up to ten different fields which will be placed in the USER_STAT_CATEGORY field in Alma.

Before filling in this tab, specify in the Patrons tab of the Generic to Alma Field Mapping form which fields from your legacy ILS 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 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.

The migration engine adds a space between the label you specified in the Field Mapping form and the value. So if you included a label 'CAT:' in the field mapping, then use 'CAT: a' here (if 'a' is an incoming value).

Incoming patron 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 listed three different three fields that have a patron category in the field mapping form, then list all of the values from all three of those fields here. 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 single Statistical Categories field in the patron record that can be used to retrieve statistics on groups of patrons.

User Block Tab

User Blocks are indicators that a patron may be prohibited from borrowing temporarily, for example because they need to update their address. Provide the list of available blocks from SISIS and their description, along with the block code as it should be in Alma. Alma does generate blocks based on configurable factors, such as for the number of overdue books or the amount of money owed. Migrated blocks should be blocks that are placed and removed by library staff - in other words, not the configurable blocks.

This mapping table is not mandatory.

BlockType: The patron block code as found in the patron extract from SISIS.

Do not include statuses that indicate the patron is not blocked, such as OK.

Description: A description of the patron block code, 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: A space for noted; not used in the migration.

Campus Code Tab

Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the patron campus to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.

CampusCodeKey: The value of the patron campus as found in the patron extract from SISIS.

Description: A description of the patron campus field, for informational purposes only. This column is not used in the mapping.

Alma Campus Code: The Alma campusCode desired. You may map the codes 1-to-1, or you may use this map to collapse codes if desired.

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. If your library maintains the such a field for a similar purpose, map the value to the Alma Campus Code value with this map.

Unlike other mapping tabs, the campus code and description are not loaded as a code table to Alma. Customers should set up campuses in Alma.

Fines and Fees Tab

The Fine Fee Type indicates why a patron has to pay a fine. Some common examples are: Overdue material, Lost material, Registration fee.

Incoming Fine Fee Type (Reason): List all of the values from the Reason field in the fine/fee extract from SISIS.

Description: A description of the fine fee 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 the legacy ILS 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.

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 SISIS 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 for the patron. You may map multiple identifiers from your previous ILS. You may also consider mapping email address, a common matchpoint in authentication systems, to an additional ID field.

The following is a typical assignment of SISIS fields to Identifier types in Alma. This map is in the SISIS Field Mapping Form, Patron tab.

Field Name	Mapped field from SISIS
UNIV_ID	UnivNumber
ADDL_ID_1	StudentNumber
ADDL_ID_2	PersonalNumber
ADDL_ID_3	LibraryNumberILL
ADDL_ID_4	AlternativeNumber
BARCODE	PatronBarcode

So, for example, if you want the PersonalNumber to be used for the primary ID for your users in Alma, select ‘ADDL_ID_2’ for the primary ID question on the Questionnaire tab of the SISIS 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.

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.

Identifiers may not be duplicated, even within the same patron record. See the questionnaire question DUP_ID_SAME_PATRON for options.

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 SISIS Migration Form.

Acquisitions

Acquisitions is migrated only if it is part of your contract with Ex Libris.

When acquisitions is not included in the migration, there is still some acquisitions related information that the migration programs need to know in order to set up an empty acquisitions environment in Alma for use on day 1. These questions are listed under “Customer Input for Empty Acquisitions Environment” below.

When Acquisitions is included in the migration – meaning that the customer has contracted for migration of acquisitions data elements, a few questions are necessary. These questions are listed under Customer Input – Acquisitions Data Migration.

Customer Input for Empty Acquisitions Environment

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.

Default currency for Ledgers and 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

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 beginning/end of the fiscal period. 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.
Select a year from the dropdown box.

For example if the date of conversion is June 15, 2017, and your fiscal year ends on June 30, 2017, then selecting ‘determine by date of conversion’ will place the active fiscal year as 2016-2017. If you wish to start fresh on July 1 with the new fiscal year, then select the year from the drop-down that corresponds to the 2017-2018 fiscal period.

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.

Yes-duplicate funds can only be used if the customer has contracted for Acquisitions migration.

Files Expected for Acquisitions Data Migration

If you are migrating Acquisitions, then provide the following files, and also answer additional questions regarding Acquisitions, listed after the files.

Order Records

Provide order records. If you are also providing invoices, you can provide closed orders in previous fiscal years, because invoices link to inventory through the order. Orders in previous (closed) fiscal years cannot be open, so they are not linked to funds. Open orders are only allowed in active fiscal years (the current fiscal year and possibly the next fiscal year if the library uses Accrual Accounting).

The fields in the following table are expected. Indicate the local field names in the SISIS Field Mapping form.

Field Name	Notes
PO_NUMBER
POL_NUMBER
POL_CREATE_DATE
POL_VEND_REF_NUM
POL_NOTE_TO_VENDOR
POL_ITEM_QUANTITY
VENDOR_CODE	matches vendor code in vendor file
VENDOR_ACCOUNT	matches vendor account code in vendor file, if present
POL_BIB_ID	links to bib 001
POL_UPDATE_DATE
POL_ACQ_METHOD	PURCHASE, APPROVAL, GIFT, VENDOR_SYSTEM, DEPOSITORY, EXCHANGE, TECHNICAL, LEGAL_DEPOSIT
POL_EXP_REC_DATE
POL_CURRENCY	three characters, e.g. EUR
POL_RUSH
POL_SUBS_END
POL_ENTRY_POINT	NEW, SENT, WAITING_FOR_INVOICE, CLOSED, CANCELLED
PO_SEND_DATE	date order was sent to vendor (for non-NEW orders)
POL_INV_STATUS	Provide two options: INVOICE or FULLY_INVOICED: either string is accepted here, but they operate the exact same way. In this case, migration will determine if the final result is PARTIALLY_INVOICED or FULLY_INVOICED based on the type of order (continuous or monographic). In other words, if you provide FULLY_INVOICED for a continuous order, migration will change it to PARTIALLY_INVOICED since open continuous orders cannot be fully invoiced in Alma. or NO_INVOICE
POL_Line Type	PRINTED_BOOK_OT, PRINTED_JOURNAL_CO, PRINTED_BOOK_SO, PRINT_OT, PRINT_CO, PRINT_SO, PRINT_SO_NONMON, OTHER_SERVICES_OT, OTHER_SERVICES_CO
POL_TOTAL_SUM	this is the foreign sum for a single item. This amount will be multiplied by the quantity to get the final total sum for the line. Sum can 0 for POL_ACQ_METHOD: GIFT, DEPOSITORY, EXCHANGE, or TECHNICAL Price (SUM) is not mandatory for LEGAL_DEPOSIT. See Working with Legal Deposits.
POL_SUM_LOCAL
POL_LIBRARY_ID	Order unit for library; also used to determine related inventory for SO and CO (continuous) orders
POL_NOTE
POL_FUND	matches fund code in fund file
POL_ADDL_NUM
POL_CREATED_BY
POL_RECEIVING_NOTE
POL_ASSOCIATED_POL	currently only one related PO allowed
POL_INV_LOC	intended inventory location, used to determine related inventory for SO and CO (continuous) orders
POL_INV_LOC_MONO	type a default SISIS location code for OT (one-time; monographic) orders, if not provided indivudually in POL_INV_LOC
POL_INV_LOC_SER	type a default SISIS location code for CO/SO (continuous or standing order) orders, if not provided indivudually in extract POL_INV_LOC
POL_ITEM_BARCODE	optional; use if you can link directly to item record for monographic orders (OT). The POL-Item Link for OT (monographic orders) can also be provided in the item record, POL_NUMBER field.
POL_REP_CODE	Use the PO Reporting Code maps to map values to the Alma Reporting Code field. The values in columns C and D are used to make the 1st Reporting Codes code table. No prefix is necessary here since the PO Reporting Code map allows only one incoming value per map.
POL_REP_CODE_2	Use the PO Reporting Code 2 map to map values to the Alma Reporting Code 2 field. The values in columns C and D are used to make the 2nd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code maps allow only one incoming value per map.
POL_REP_CODE_3	Use the PO Reporting Code 3 map to map values to the Alma Reporting Code 3 field. The values in columns C and D are used to make the 3rd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code maps allow only one incoming value per map.
POL_REP_CODE_4	Use the PO Reporting Code 4 map to map values to the Alma Reporting Code 4 field. The values in columns C and D are used to make the 4th Reporting Codes code table. No prefix is necessary here since the PO Reporting Code maps allow only one incoming value per map.
POL_REP_CODE_5	Use the PO Reporting Code 5 map to map values to the Alma Reporting Code 5 field. The values in columns C and D are used to make the 5th Reporting Codes code table. No prefix is necessary here since the PO Reporting Code maps allow only one incoming value per map.
POL_NO_CHARGE	Y or N. Set to Y when the POL_TOTAL_SUM = 0 and the POL_ACQ_METHOD is one of the following: PURCHASE VENDOR_SYSTEM APPROVAL In this case, there is no link to fund (transaction) generated.

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column.

Note Name	Default Local Field
POL_VEND_REF_NO	This line cannot be duplicated; place only one local field name here.
POL_ADDL_NO	This line cannot be duplicated; place only one local field name here.
POL_RECEIVING_NOTE	This line cannot be duplicated; place only one local field name here.
PO_NOTE	This line can be repeated as many times as necessary; multiple local fields can be placed in this note.
POL_NOTE	This line can be repeated as many times as necessary; multiple local fields can be placed in this note.

Inventory related to Orders: Items, Holdings

After the correct bibliographic record has been identified, orders can further be linked directly to an item or a holding. First, an attempt is made to use direct links specified in the order or item record, and second, an attempt is made to find a related inventory using intended inventory location.

Monographic orders can be linked directly to item records if such a link is present in SISIS. SISIS provides this link in the item record's POL_NUMBER field, but it could also be provided in the order's POL_ITEM_BARCODE field.

Continuous orders can be linked at the holding level. There is no method to provide a direct link to holding records, so the holding link is found using the intended inventory location (POL_LIBRARY_ID and POL_INV_LOC) from the order record only. First, we look for an existing holding record with the exact intended inventory library and location. If that fails, we look for an existing holding record with the intended inventory library only, ignoring the intended inventory location.

In both cases, monographic and continuous, if no item or holding is found to generate a link to inventory, then a receiving note is created with the intended inventory. This provides the receiving librarian some information to start with when they receive the inventory.

Finally, if you do not have an intended inventory location specified in SISIS, you can provide a default SISIS location code for the intended inventory for mographs or serials, on the SISIS field mapping form, using POL_INV_LOC_MONO or POL_INV_LOC_SER. These locations are used for ALL monographis and ALL serials, along with the POL_LIBRARY_ID, to make an attempt to find related inventory.

Generally speaking, non-monographic orders are linked to a holding record, and monographic (one time) orders are linked to an item record. Here is a specific chart for Items vs Holdings, and how they link to orders, below:

POL_ LINE_TYPE	Link to Holdings	Link to Items
PRINTED_JOURNAL_CO PRINT_CO PRINT_SO_NONMON	Y	N
PRINTED_BOOK_OT PRINT_OT PRINTED_BOOK_SO PRINT_SO	N	Y
OTHER_SERVICES_*	N	N

* Other Services orders are intended to be used for services not related to inventory and are therefore used very rarely. OTHER_SERVICES orders do not link to inventory at all.

Continuous Purchase Orders That Were Invoiced in the Current Fiscal Year

This situation is seen primarily at the end of a fiscal year, just prior to fiscal year rollover. When there is a continuous purchase order in the current fiscal year that has been received and invoiced, there is a potential for double posting of funding amounts.

since the order is considered open/SENT, there is an encumbrance created for this order
since there is a completed invoice for this order, there is an expenditure created for this invoice

The encumbrance and the expenditure are on the same fund in the same fiscal year. In SISIS, the invoice and the order are linked and the encumbrance is suppressed from the active amounts. Be aware that this may make the encumbrance amount for certain funds appear higher in Alma than they are in SISIS. This issue is resolved after the encumbrances roll over to the next fiscal year. Until then, customers may want to increase the allowed over-encumbrance percentage for affected funds.

This situation will happen throughout the fiscal year, but is more pronounced at the end of the fiscal year after many continuous orders have been received and invoiced. At the beginning of the fiscal year, this situation is not as pronounced, because not very many continuous orders will have been invoiced. If you are migrating around the end/beginning of a fiscal year, you may want to consider rolling over in SISIS prior to migration in order to lessen the effects of this situation.

Orders, Invoices, and Fund Balances

During the migration process, fund transactions are generated for the following:

Open Orders in the current fiscal year (encumbrances)
Invoices in all fiscal years (expenditures)

Notice that encumbrances are not generated for orders in any previous (non-active) fiscal years. Therefore, fund balances in previous (non-active) fiscal years will only reflect invoice transactions (expenditures).

Encumbrances

Transactions from active purchase orders are created as encumbrances in Alma when the orders fund reference is valid and exists. 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.

Encumbrances are not generated for orders in previous (inactive) fiscal years. The fund code is preserved in the PO Note for reference.

Transactions of Amount 0.00

SISIS allows for transactions to be of value 0.00 for all purchase orders (encumbrances). In Alma, encumbrances or open orders of amount 0.00 are changed to 1.00. The following types of orders (Acq method) can be open with amount 0 on the order, but with with no transaction: GIFT, DEPOSITORY, EXCHANGE, TECHNICAL, and orders with the 'no charge' flag set to Y.

PO Entry Point (Status)

The PO Entry point indicates where the order sits in the workflow. SISIS libraries provide the Alma-ready statuses in the exported files.

NEW = order has not yet been sent. Likely it is waiting for funding. Fund codes are not required for NEW orders.
SENT = order has been funded and sent to the vendor. Fund codes are required. Continuous orders (*SO or *CO line type) remain in SENT status indefinitely. A continuous order can be received but still in SENT status because the order is expected to be received again the next year.
CLOSED = order is received and invoiced
CANCELLED = order canceled

Default: SENT

PO Line Type

The Alma line type value. SISIS provides Alma-ready line types in the SISIS exported files.

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.
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.
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 orderswithout inventory. For electronic resources, see the ‘Line Types and electronic orders’ section below.
OTHER_SERVICES_CO: Other Services Subscription. This should only be applied to orders without inventory. For electronic resources, see the ‘Line Types and electronic orders’ section below.

Further Information: 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 (SENT) indefinitely.Alma does have other PO Line types but they are not available for use in migration

PO Acq Method

AcqMethod is mandatory in Alma. If you are not sure which to use, then use PURCHASE.

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

Orders in Review Status or Waiting for Renewal

Alma migration programs move orders to Alma with statuses that are as close to the original Symphony status as possible. For example if an order is open (SENT) or closed, what type of order it is (monographic, continuous), if it is purchase or gift, etc.

However, Alma has further statuses that are set after an order is loaded to Alma. Two examples of this are In Review and Waiting for Renewal. Migration does not set the 'In Review' status, but rather the 'In Review' status is set by a series of rules using the elements above and possibly other elements. These rules are not controlled by the customer; instead, they are controlled by Alma Development.

In particular, when an order is NEW, the status is set as:

OT (one time) orders: In Review
SO and CO (continuous) orders: Waiting for Renewal

Information about orders that are In Review can be found here: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/020Acquisitions/110Configuring_Acquisitions/030Configuring_Purchasing_Review_Rules

Information about the renewal workflow can be found here: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/020Acquisitions/040Renewals/010Renewal_Workflow

Invoices

Provide the invoices in CSV format.

Fields Expected

The fields in the following table are expected. Indicate the local field names using the SISIS Field Mapping form.

There may be fields in the extract that are not listed below. The migration programs do not need the data in the missing fields.

Field Name	Notes
Invoices.csv: invoice header file
VENDOR_CODE	matches vendor code in vendor file
VENDOR_ACCOUNT	matches vendor account code in vendor file, if present
INVOICE_NUMBER	used as the Invoice Number in Alma
INVOICE_NUM_FOR_MATCH	used to match against invoice line file
INVOICE_DATE
INV_CREATE_DATE
APPROVE-DATE
CURRENCY	three characters, e.g. EUR
INV_ENTRY_POINT	NEW, WAITING_APPROVAL, WAITING_SEND, WAITING_PAYMENT, CLOSED, CANCELLED
invoiceLine: repeatable group, fields below
INVL_FUND	matches fund code in fund file
INVL_PO_LINE	matches POL_REFERENCE in purchase order file
INVOICE_NUM_FOR_MATCH	matches INVOICE_NUM_FOR_MATCH in invoice header file (above)
INVL_NUM
INVL_CREATE_DATE
INVL_CURRENCY	three characters, e.g. EUR
INVL_TOTAL_LINE_FOREIGN
INVL_LINE_PRICE_LOCAL
INVL_FISCAL_PERIOD	YYYY
INVL_REP_CODE	Use the PO Reporting Code map to map values to the Alma Reporting Code field for invoices. Invoices and POL use the same map for the first reporting code.
INVL_REP_CODE_2	Use the PO Reporting Code 2 map to map values to the Alma Reporting Code 2 field for invoices. Invoices and POL use the same map for the second reporting code.
INVL_REP_CODE_3	Use the PO Reporting Code 3 map to map values to the Alma Reporting Code 3 field for invoices. Invoices and POL use the same map for the third reporting code.
INVL_REP_CODE_4	Expected October 2021 Use the PO Reporting Code 4 map to map values to the Alma Reporting Code 4 field for invoices. Invoices and POL use the same map for the fourth reporting code.
INVL_REP_CODE_5	Expected October 2021 Use the PO Reporting Code 5 map to map values to the Alma Reporting Code 5 field for invoices. Invoices and POL use the same map for the fifth reporting code.

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column.

Note Name	Default Local Field
INV_NOTE

Vendors

Provide the vendor file in csv format.

The fields in the following table are expected. Indicate the local field names using the SISIS FIeld Mapping Form.

Field Name	Notes
VENDOR_CODE
ACCOUNT_CODE	see 'Vendor Accounts' below
ERP_CODE
Account_ERP
VENDOR_NAME
ACCOUNT_DESC
VENDOR_LANG	two characters, e.g. 'de' or 'en'
VENDOR_ADDRESS_LINE1
VENDOR_ADDRESS_LINE2
VENDOR_ADDRESS_COUNTRY
VENDOR_ADDRESS_POSTAL_CODE
VENDOR_ADDRESS_CITY
VENDOR_ADDRESS_LINE3
VENDOR_ADDRESS_LINE4
VENDOR_PHONE
VENDOR_EMAIL
VENDOR_EMAIL_CLAIM
VENDOR_URL
VENDOR_ADDITIONAL_CODE
VENDOR_ADDRESS_NOTE
ACCOUNT_EXP_REC_INT
ACCOUNT_EXP_ACT_INT
ACCOUNT_CLAIM_INT
LIABLE_FOR_VAT	type a value, Y or N. Setting this to Y sets the tick box to ticked on the vendor record, 'Liable for VAT'.
ACCOUNT_RECLAIM_INT
ACCOUNT_SUB_GRACE

Vendor Notes

Any additional fields not listed above may be put into notes. The possible note fields in Alma items are listed in the following chart in the Note Name column.

Note Name	Default Local Field
VENDOR_NOTE
USER_NOTE
ADDRESS_NOTE
DETAILS_NOTE

Vendor Accounts

It is possible to provide a vendor record with multiple vendor accounts. In order to accomplish this, provide two (or more) separate vendor records with the same vendor code but different vendor account, in the same delivered vendor file.

In the case of multiple vendor accounts, both/all of the vendors must have an account: it is not possible to provide the first vendor with no account and then a second vendor with an account.

Further, make a special request to your Ex Libris representative to have the vendors merged when loaded.

When vendor merge is specified, the first vendor found is loaded as is, and the second vendor with the same vendor code is matched and the vendor account is added to the first vendor. The only thing added during the match process is the account - the main section of the second vendor is discarded.

In order to match POs and/or invoices to the specific vendor account, provide the vendor code and the vendor account code in the relevant PO or invoice.

At least one vendor account is mandatory in Alma, but if your library does not use accounts at all, you can leave all vendor accounts blank and the migration programs will create a vendor account based on the vendor code.

Funds

Fund records are not exported from SISIS. Rather, they are entered into an Excel migration form, then exported to CSV and delivered to Ex Libris for loading into Alma. All funds must be listed on a single tab (the first tab on the spreadsheet) before exporting to CSV. You can submit separate CSV files, but they must be physically separate files and not multiple tabs on the same sheet. Each csv file must contain a header line with the field names, as described below.

In the fund file, LEDGER CODE, LEDGER NAME, FUND CODE, and FUND NAME are mandatory. Ledgers are mandatory and if your institution does not have ledgers in the current ILS, define one general ledger for use in Alma.

Note that fund and ledger codes are unique across the entire fiscal period, not just within specific hierarchies. Therefore, there should be no fund or ledger code duplication in the spreadsheet submitted. This uniqueness restriction applies across ledger codes, summary fund codes, and fund codes.

For SISIS migrations which migrate only orders, all of the funds go into a single active fiscal period, so the codes have to be unique among themselves. However, when a SISIS customer is migrating invoices, the customer makes multiple entries for each fund code, one for each fiscal years. In this case, the funds must still have different codes. Since in Alma the fund code is maintained as it rolls over to the next fiscal period, the recommendation is that the fund codes be structured like:

current fiscal year: CODE

previous fiscal years: CODE-2020, CODE-2019,CODE-2018, etc.

Ledger codes should be disambiguated in the same way when invoices for multiple fiscal years are being migrated.

The invoice and order files must contain the FUND CODE in order to provide a link to funds.

Funds are grouped under summary funds, and summary funds/funds are grouped under ledgers. Only one level of summary fund is allowed in the extract; however, it is a simple task in Alma to create a new summary fund after migration and drag other summary funds underneath it.

Field Name	Notes
LEDGER CODE	May be repeated across lines to group funds under a single ledger
LEDGER NAME	May be repeated across lines to group funds under a single ledger
SUMMARY FUND CODE	Not mandatory, may be repeated across lines
SUMMARY FUND NAME	Not mandatory, may be repeated across lines
FUND CODE	Alphanumeric, not repeatable. Must be unique, even across ledgers.
FUND NAME	Alphanumeric, repeatable
LIBRARY	Library code, in the SISIS form of the code. There can be multiple libraries here, separated by a semicolon. This field can be left empty, which means that all libraries in the institution can use the fund. If the central order library is used in the migration form, this field is ignored and all funds are set to the institution level, meaning that all libraries in the institution can use the fund.
EXT ID	External ID for linking to an external source, if one exists.
ALLOCATION	Allocation, in base (local) currency, of the current fiscal year’s funds.
FY	Fiscal year, if customer is providing previous year funds for invoices.
NOTE	Will be placed on Note tab of funds screen

Customer Input – Acquisitions Data Migration

Use these questions only if you have contracted with Ex Libris to migrate your acquisitions information.

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 Order Location field specifies the order location for orders in the previous system. The migration attempts to map the location field to the corresponding Alma Library. If you want to override this 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 order location field to determine the order library, leave the Central Order Library question 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 order location 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).

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 SISIS prior to conversion.

Accrual Accounting

Code: ACCRUAL_ACC_FY

Default: No, do not make an additional fiscal year

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 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.

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 Tabs

Use this tab if you wish to map values from the SISIS reporting code field to the Alma Reporting Code field. These tabs are 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.

SISIS Reporting Code: The value of the reporting code in order record, found in the POL_REP_CODE_* fields in the order extract.

Description: A description of the SISIS reporting 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 incoming 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.

Physical to Electronic (P2E) Processing

This section describes the process of correctly categorizing resources as electronic in Alma. In most legacy ILS systems, 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. It is up to you to provide a list of records that are identified as electronic, in the following format:

123475,portfolio

12346,db

The words portfolio and db are not case-sensitive; therefore, both portfolio and Portfolio are acceptable.

During the P2E process, all resources must either be categorized as a portfolio or a database (DB). It is not possible to generate packages during P2E processing, since packages require at least one portfolio. A database is essentially a zero-title package. Post migration, when you add portfolios to the db, you can change them to type 'package'.

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 - P2E

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 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 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 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 Generic Migration Form.

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 – Delivering Files and 'Delivered Files' Form

Place any data files that you provide to Ex Libris in the formats indicated in Expected File Formats on the MFT server which has been specified to you by your Ex Libris project manager.

The following is the default naming convention:

CustomerName+DataType+sequence+date+[.<file_extension>].</file_extension>

For example: centralu_bib_01_20120420.mrc, centralu_bib_02_20120420.mrc, centralu_bib_03_20120420.mrc

Ex Libris recommends a maximum of 200,000 records per MARC file, and 400,000 for other types of records (items, orders, etc).

All records in a single file must be homogenous – all of the lines in the file must have the same number of fields, and those fields must contain the same type of data. Additionally, all of the records must be delimited in the same manner. For example, do not delimit with quotes and commas for some records and pipes for others within the same file.

Provide the SISIS Field Mapping form, the SISIS Delivered Files list, and the SISIS Migration Form along with the submitted files.

Recommendations for Using this Guide

Related Documentation

Migration Overview

Files Requested from SISIS

Expected File Formats

SISIS Field Mapping Form

SISIS Delivered Files Form

SISIS Migration Form

Using the Migration Form Validation Tool

Inventory

Bibliographic Records

Non-filing characters

Suppressed Records

Boundwiths

Linked Bibliographic Records

Electronic Link Resolver Records

Holding Records

Aleph Sequential Holdings

MARC Holdings

Holding Records from a Summary Statement in a Bibliographic Record

Item Records

Suppressed Item Records

Holding Record and Item Record Relationship

Item Record

Secondary Item File

E-Resources Indication (P2E)

Item Call Number Sequences

Customer Input - Inventory

Questionnaire Tab

Institution Code, Customer Code, Institution Name, Customer Name, Time Zone

MARC Organizational Code

List Prefix for bibs from SFX or other management system

Do you use internal system numbers in Linked Entry fields?

Internal record designation for Linked Entry fields $w

Indicate which 852 subfields to use to determine unique holding records

Do you want to use a call number in the generated holdings records?

Limit exported records by location

Bib Key Prefix

Move 001/003 to 035 or 935

Add institution suffix to Bib ID

Use subfield indicators in item call number (AltCallNo)

Add $9 LOCAL to specified tags

Alma Library Tab

Alma Location Tab

Alma Location Name and Alma External Location Name

Collapsing Locations

Item Type Tab

Item Material Tab

Shelving Scheme Tab

Item Physical Condition Tab

Further Explanation – Inventory

Bibliographic Records

Determining Groups of Holding Records

Changing the Holding Record Grouping

Attaching Items to Existing Holding Records

Item Barcodes

Material Type from Bib Fixed Fields

Fulfillment

Patrons

User Identifiers

User Statistical Categories

Notes

Loans/Circ Transactions

Requests/Holds

Fines/Fees

Potential Fines (Mahnverfahren or Dunning)

Fields expected

Customer Input - Fulfillment

Questionnaire Tab

Enter a two-letter code for the default conversational language for your users

Which identifier should be as the patron's Primary Identifier?

How should we handle duplicate identifiers in the same patron?

Currency for patron fines

Use a map for the patron campus to campus code migration?

Request Default Destination Library

Merge Patron Prefix

User Group Tab

User Stat Categories Tab

User Block Tab

Campus Code Tab