Notes from IUG Zoom Forum: Third Party Vendors

General
,
1

Here is a list of vendors/services that we discussed. If I missed any or if you have any follow-up questions or contributions, please comment below.

  • Authorities: one library is looking for a vendor. Most respondents are using Backstage and are happy with the service.
  • Aspen & Polaris: bug in recognizing withdrawn items when using the Leap weeding process.
  • Brodart Bibz: EDI orders populating with wrong mat type.
  • Communico: All checkouts given 1 month lending period. Maybe pulled from mat type table rather than item record?
  • Engaged Patrons and Library Market: API issues following Polaris upgrade. Maybe related to need to specify API version number.
  • Envisionware: Issues with credit card payments after going hosted. Elsewhere an issue with credits.
  • Holds Lockers: is anyone using API rather than SIP2? Vendors seem slow to develop PAPI integration even when they have already done the work with Sierra.
  • Ingram: EDI book orders interpreted as eBooks.
  • OrangeBoy: issue with pulling patron data.
  • OverDrive: trying to set up API for authentication without using catalogue integration.
  • Quipu: Sierra library considering switching to them. Other libraries had no complaints.
  • Self-checks: one library considering removing physical self-check machines/dispensers due to maintenance costs. Another library is using MK Solutions self-check software and own hardware.
  • TBS: lengthy set-up issues and lack of responsiveness.
  • Unique: One library implementing uRenew; other libraries considering switching to them for notices; positive feedback from libraries already using their products.
  • Vega (mobile and interact): frustration with ticket responsiveness and being bumped to 3rd party providers.
4 Likes
2

If this is a Polaris system, it sounds like they might be using a default loan period. I wonder if the Communico app is logging in using a weird/different branch that they don’t have loan rules set up for?

Just to clarify what we’ve seen in this regard, some vendors mistakenly believed they needed to put their product version or the version of the base Polaris system in their PAPI URLs; this was never documented to work that way, but prior to 7.6, the Polaris API accepted any version number. After 7.6, it is only accepting the versions that were specified in the documentation, primarily v1, but for some PAPI calls, v2 is also accepted. You can find out more here: Polaris 7.6+ potentially breaks 3rd party integrations using PAPI