Acq FAQ

Below are questions that were sent to the Acq Task Force directly.  Since odds are that multiple people are wondering these same things, we're posting them here.  Interested in the cross-topic Basecamp Q&A page?  Go here.  For Acquisitions-specific questions, see below.

_{REMINDER:  If you have any questions regarding doing Acq in Alma (implementing GOBI API or other integrations, or setting up funds, how to handle taxes, etc.) PLEASE POST THEM to the Tech Svcs ULMS Listserv.  It benefits the group when we share these things.  And nobody knows it all yet, the Acq Task Force included, so let's tap the group's collective knowledge.}

Acq FAQ

Q: When adding invoice lines (creating an invoice in Alma), do I have to manually add on the sales tax amount to each PO line if the amount is not included on the vendor invoice?  Currently, our Alma PO line does not include sales tax and the invoice line amount on the GOBI invoice shows only the item amount (tax is shown as one total at the bottom of invoice but not per item line). When creating an invoice line, we are manually adding the sales tax amount to each line. Is this the best way?

A: You should look into the "Line Exclusive" VAT type when creating these invoices. The definition of that VAT type is this: "If Line Exclusive is selected, the invoice's total amount includes the VAT (similar to Inclusive), but the invoice line’s prices do not." If your Gobi invoices are like ours, then the line items don't include tax; it is applied separately and shown at the bottom, along with whatever tax percentage you have set up with YBP.

 So in your Invoice Details for the Line Exclusive scenario, you would need to add the VAT%, and select the VAT Type of "Line Exclusive". Now, depending upon how your campus does its tax payments, you may want to also check the "Expended from Fund" box for these invoices IF you want the tax to also be paid from each line item's associated fund. This is how we do it, but local practices may have different requirements. In our case (in the 2nd picture below) with a sample YBP invoice, we have 4 separate fund codes, one per line item.  The 8.5% tax we'll pay (shown at the bottom of the invoice as GST/Tax) will be paid along with each line item, so the individual funds will handle the item + the tax. But the "Line Exclusive/Expended from Fund" scenario is just one option; your local needs may be different.  See below the graphics for links to more info.

 Alma tax options are confusing to be sure. We tried to summarize some of the aspects on this wiki page- Tax Payment & Scenarios in Alma .  And there are more detailed examples in the ExL documentation at VAT Calculation – Example

Q: In the example of a Chancellor's Office "Opt-In" resource, how do you link your local PO Line to an appropriate NZ record?  

A: You can do that via the Change Bib Reference function, which would be available when viewing a PO Line in the IZ.  The basic steps are:

View the PO Line:

You'll see a confirmation that you want to change the bib reference:

That takes you to a search to find the desired bib:

From the results, choose the NZ tab to see your network choices and SELECT:

 An Ex Libris Knowledge Center training video (5 minutes) is available here.

Q: We are working on our YBP technical specifications and are confused about which fields we need to map for the GOBI API, EDI invoicing and WCM. 

A: Many of the CSU's have been confused with this set-up.  Part of the issue is terminology.  Let's clarify a few terms first:

• • The YBP Order Key is also referred to as: YBP Order Number, GOBI Order Key, and GOBI Order Number, depending on who you talk to. This is the unique identifier for each order placed and is integral to EDI invoicing.

  • The YBP Order Key (aka YBP or GOBI Order Key or #) is referred to in OCLC's WCM as the Vendor Order Number, and in Alma as the Vendor Reference Number.

  • The YBP Order Key is a separate element from the YBP/GOBI UID. (a frequent point of confusion for some folks)  
  • The GOBI UID (aka YBP UID, aka GOBI/YBP Title ID) is the unique manifestation-level number assigned to each Gobi title. Meaning, hardback and paperback editions have different GOBI UID numbers. This element is not pertinent to EDI invoicing.

Regarding the mapping, some of it will depend on local preferences, and specific questions would need to be bounced off of your YBP contacts.  However, some general things to consider:

  If implementing the GOBI API, the Alma POL is returned to YBP in the API process for your FIRM orders, and will serve as the link between your GOBI API orders and correlating EDI invoices (if choosing EDI invoicing).

  For non-GOBI API orders such as approvals, EDI invoicing is enabled by mapping that YBP/GOBI Order Key/Number via WCM (where it is called the Vendor Order Number) which then gets mapped via your Alma New Order Import Profile to the Alma Vendor Reference Number field.  

So, to repeat - GOBI Order Key → WCM Vendor Order Number → Alma Vendor Reference Number. 

  YBP outputs the GOBI UID to the 035 $b, specifically mapping it there to avoid confusion between that number and the OCLC #'s in the 035 $a. (Per YBP, this mapping was identified with the knowledge that the ULMS has decided the OCLC # in the 035 is our primary match point.)  If there is an existing 035 (which there should be in most cases) then a separate 035 field will be created.  The YBP/GOBI UID is being provided in the 035 $b as an additional match point if needed.

  The procedure document on the Import Profiles for Loading Brief Order Records and WCP into NZ wiki page helps clarify these mapping aspects (Thank you @Marcus Jun & the Import Profiles Task Force.) 

Q: When we migrate order records, do the vendors in the orders have to match to active vendors in Alma? Or will they also be able to match to vendors marked as inactive? 

A: We (Megan Drake, ExL) have confirmed that vendors do not need to be active in order for the orders to link.  Orders will link to both inactive and active vendors.

Q: With the new GOBI API system, would we be getting full records for Print records with OCLC numbers?  This would eliminate the need for WCP (since we don't use shelf-ready)?

A:   We will get brief bib and order data, no full records with the API.  It can be configured to provide the OCLC # for those brief records (which is what we need to function best in the NZ.)  The GOBI API can still work with other YBP and OCLC services, so it depends what you want locally for your records. Take a look at our wiki page for the GOBI API.  

Q:  For e-books title by title, will those still be brief records with (or without?) OCLC numbers or are those going to be full records as well?  If brief, we would still have to pay for cataloging from YBP if we wanted to continue that service, correct?

A: YBP will be able to provide OCLC #'s for ebooks as well, but there may be some issues related to duplicate OCLC records since that seems to be a current trouble spot in OCLC.  Generally, it should end up working like it does for the print, but may require a little clean-up regarding ebook full records down the line based on the OCLC number chosen by the API.  I’m assured by YBP that duplicate ebook records issue are not something they hear complaints about from GOBI API users.

Q:  The assumption is that the invoice will still come attached as it does in the current system.  Will that still be true?

A: You will need to set up EDI invoicing with YBP, which is how to get those e-invoices into the system.  Alma won't load invoices the same way San Jose does now, for example (we receive invoice data as part of the WCM/WCP MARC records and turn that into e-invoices via a load table in Sierra.)  In Alma, we need to set up the EDI process, and that can be scheduled and more automated between YBP and Alma.  So it might be different depending on how you are doing things, but potentially more automated.  Check out the Acq TF wiki Integrations page and the Ex Libris' EDI document in particular for more info.

Q:  I’m confused about what services we still will need from YBP if we choose to use the GOBI API. Can you explain that?

A:  It helps to keep in mind that the GOBI API service takes the place of and automates only the ordering and brief bib/order record acquisition into the system.  It does not handle full records but can work with those services.  For San Jose, we currently subscribe to the EOCR service to handle that part of the process, but won't need that subscription once using the API. The GOBI API will take its place.

So you'd order in GOBI, and the API would instantly (they call this API "Real-Time Acquisitions") load the brief bib and order data into Alma, and the corresponding Alma order info is in turn added back to the GOBI record.  Click here for a brief demo.

The GOBI API can provide OCLC #'s but not full records.  However, YBP can still integrate its other services (partnering with OCLC for the full records, shelf-ready, or YBP's own cataloging services, etc.)  Which of those services a library chooses is up to them. 

Q: Can we still do shelf-ready with the GOBI API? How do those records work?

A: If a library wants to continue shelf-ready services, then they will need to continue that service subscription with YBP regardless of using the API. The shelf-ready service includes records and sets holdings in OCLC, giving that library options for getting those records into the NZ. They can choose to not load the resulting records and allow the OCLC-NZ nightly sync to do the work since their holdings will be set as part of the shelf-ready service.

Libraries not doing shelf-ready may decide that they don’t need full record services at all. Since there will be the regular (nightly?) OCLC-NZ sync loading full records to the NZ based on records with CSU holdings, you may decide you can do without a full record service (and cost) as long as you establish a process to set your holdings in OCLC for those materials.    If you have many YBP records that would not be loaded into the NZ, you may decide that WCP services are warranted, but I imagine for most campuses, that would not really be the case as most YBP material records should be landing in the NZ. 

Q: I’m not sure of the process to request an API key from ExLibris. Can you point me to the documentation?

A: There are some good instructions on the ExL Developer's Network page -

https://developers.exlibrisgroup.com/blog/Real-time-Acquisitions-setup-for-institutions

This section explains the setup for "Real-time Acquisitions" (which includes the GOBI API) from the institution perspective.  When you log in to the developer's network, you'll be able access/generate you campus's API key.

Q: We are trying to set up the GOBI API and have questions about the 980 & 981 fields.  Do we still use those for invoice information (fund, invoice #, price, etc.)?

A: the OrbisCascade documentation has confused some on this point.  At SJSU, the data in these fields was used to inform the Sierra load tables, which then created our order and brief bibs with the right data and statuses.  We confirmed with Dan Miller at YBP that this data in the 980/981 is no longer necessary in Alma.

Q: Is the CO going to help fund the GOBI API for campuses?

A: It was determined that the CO was not going to be able to centrally fund this service at this time; however, the SDLC is offering to manage the subscription for you for the same opt-in price as if you chose the discount that YBP offered directly.  Contact Terri Joiner at the CO's SDLC, and cc Brandon Dudley if you would like to opt-in to the GOBI API subscription.

Q: Do you happen to have any insights as far has how to dup-check with GOBI API? As far as we can tell, it seems as though there would be more manually dup-checking at the point of ordering. There doesn’t seem to be a more systemic way of doing it as it’s done with EOCR. Is this a correct assumption?

A: It depends what kind of dup checking you do now.  At San Jose, we do an initial search of GOBI selections to check for duplicates already available in our catalog.  We also can see materials already purchased via YBP in the GOBI “library history” notes.  If any dupes still slip through, GOBI alerts us at point of order (assuming it was bought thru YBP.)  After loading, I think it's a currently use of heading reports (for us) that calls out any duplicate loads to clean up. 

My understanding from YBP is that moving to GOBI API from EOCR will not lose us any functionality.  GOBI should still recognize potential duplicate orders.  We'll still need to do our dup pre-check the same, but now we'll be searching the NZ before we order through GOBI. 

Then after that, once you're all set up and you've placed your GOBI orders, the Import Profiles will determine whether your order will be added to a matching record in the NZ, or if it will create a new brief record in the NZ to hang that order on.  (There are other if-then scenarios for importing and matching, but that's the basic idea.)

Q: Have you discussed how to record vendor’s change Tax IDs?  What if a vendor has more than one code?  Do you just add a note for the historical code to that vendor record?

A: First, you may want to take a look (if you haven't already) at the Ex Libris doc on Managing Vendors and a 5 minute training video on Vendors.

Alma vendor functionality allows you to update vendors and maintain a history in a couple of ways. [NOTE: At the campus level there may be local requirements that require some separation of those vendor changes, so you may need to see how vendor changes (including Vendors with new TINs) are handled in your campus CFS to make sure your method in Alma will match theirs.}

In the case of a particular vendor (with change of TIN, for example,) depending on those local CFS supplier rules, the "Additional Code" field in the Vendor Summary Tab could also be used to list an associated TIN, or you could use the Notes Tab to record anything you want about a vendor, including old TINs. These would not be true links where you could use it to click from one vendor record to the other, but could be a way to track those associations.

At SJSU, we will usually update a vendor (rather than create a totally new one and new vendor ID) if the vendor's TIN is the same and it the name or address is just being adjusted.  There are cases where we might create a new one if there are a lot of changes at once, but updating seems to be acceptable for most changes to existing vendors. 

There's the option in Alma vendor records to store multiple addresses (and phone #'s, etc.)  You can mark one address as "preferred" to function as the default. 

If the vendor changes entirely with a new TIN and everything then we would create the new vendor in the system and make the now-defunct vendor "inactive."  We will likely use the "Notes" tab to record a connection between the old and new vendors.

Q: How you are handing the fiscal close?  When will you close III/Sierra and when will you start using ALMA?  Any information and feedback you can provide would be helpful.

A: Some libraries plan on completely closing out the fiscal year early in their soon-to-be-old ILS, and then starting with the new year in Alma sometime after go live, from immediately after to a few months down the road.  Some plan not to pay invoices for a while, which might involve notifying vendors/or arranging to get the invoices early to include them before we close this year, etc.  

At San Jose, we are in the 3rd group to cutover, so our data will be extracted from Sierra around May 21st or so. We know we won't have absolutely all invoices paid by that time, so we will need to track whatever happens after the extract to update in Alma when we go live. (since we are migrating open orders.)  But we are hoping to get as much paid in Sierra as we can, track the rest, and update in Alma as things are received and paid (once we're live.) 

We are planning to run Fiscal Close in Sierra during the tech freeze.  We will be populating our funds in Alma from scratch, so that's not a problem.  Our fund codes are migrating, but no balances. 

The Acq TF group has posted some thoughts on things to consider about this at https://calstate.atlassian.net/wiki/display/ULMST/Closing+out+Fiscal+Year+2016-17

Q: We'd like some examples of how your funds and ledgers are structured.  We currently have separate categories like Approvals, Firm Books, Reserves, Media, Periodicals, Standing Orders, then it's broken down by Fund Code, and so on. Are there other examples of how you organize your funds and ledgers?

A: The Acq Task Force has posted some examples along with links to training and documentation regarding fund structures here on the wiki.  This will need some careful thought for each library to determine the best structure for you and your campus accounting needs.  It could be that your current fund structure isn't ideal, so now's the time to change it.  

Q: Regarding the sending of funds to Alma during migration, can we migrate more than just the appropriation section? We're interested to send over more elements including allocation, expenditure, cash balance, etc.

A: From Megan at ExL, "Expenditures and Encumbrances are tied to POL and Invoices so you cannot bring those over via the fund spreadsheet.  However, if an order migrates with a status of NEW, SENT, or WAITING_FOR_INVOICE, Alma will automatically create an encumbrance for that order, provided that the fund code referenced in the order is the same as the Alma fund code.  If you have orders with multiple funds associated, Alma will create an encumbrance for the total amount on the first fund listed."

More questions are being added, check back soon.