Should all locations have service points? Cate Boerema (26 Sep 2018 07:52 EDT)
Re: Should all locations have service points? Dr. Carsten Schwill (26 Sep 2018 09:15 EDT)
RE: Should all locations have service points? Cate Boerema (26 Sep 2018 11:18 EDT)
RE: Should all locations have service points? David W. Bottorff (26 Sep 2018 11:31 EDT)
Re: Should all locations have service points? Dr. Carsten Schwill (27 Sep 2018 11:03 EDT)
Re: Should all locations have service points? Wendy Wilcox (26 Sep 2018 11:16 EDT)
RE: Should all locations have service points? Cate Boerema (26 Sep 2018 11:22 EDT)
Re: Should all locations have service points? Wendy Wilcox (27 Sep 2018 11:06 EDT)

RE: Should all locations have service points? David W. Bottorff 26 Sep 2018 11:31 EDT

On a fundamental level, I agree that each location needs to be associated with at least one service point. We've certainly run into issues in OLE where an item went in transit to nowhere if it was not associated with a service point.

Especially since we're talking about the option for a location to be associated with multiple service points, I wonder what the most efficient way of doing this would be. There tend to be many more locations than there are service points, so adding multiple locations to a given service point (assuming the ability to select multiple locations at once) would seem faster than adding service points to every single location. One could perhaps have a report or system check that would alert an admin if a location was not associated with a service point at all.

That having been said, ultimately the lion's share of work would be at the outset, whereas ongoing operations generally involve creating one new location at a time, in which case it would actually easier to add service to that location rather than vice versa.

Another related question is how service points will be associated with locations as an acceptable pickup location. Obviously a service point has a value of being a pickup location or not, but we also need to be able to potentially define a given location as being able to be picked up at a given service point but not another. That might be something that is better handled in the request policies, since this might be a combination of user, location, request type, etc. But I did want to raise the issue.

Best,
David

-----Original Message-----
From: folio-ra@ole-lists.openlibraryfoundation.org [mailto:folio-ra@ole-lists.openlibraryfoundation.org] On Behalf Of Cate Boerema
Sent: Wednesday, September 26, 2018 10:19 AM
To: folio-ra@ole-lists.openlibraryfoundation.org
Cc: Sean Thomas <sthomas2@ebsco.com>
Subject: RE: Should all locations have service points?

Thanks, Carsten!  Good food for thought here.  I'm going to focus on the service point to location discussion, since time is of the essence on that one.

>> Service points do need exactly one location if locations are being used to determine opening hours and the postal address. On the other hand every location needs excatly one (main) service point, if locations are being used for the transit logic.

Opening hours are associated with service points, not locations.  You can see this feature in progress in snapshot-stable by going to Settings > Calendar.  We don't yet collect postal addresses in FOLIO.  Can you explain how you think postal addresses will be used and why they would require service points to have at least one location?

Cheers,

Cate

-----Original Message-----
From: folio-ra@ole-lists.openlibraryfoundation.org [mailto:folio-ra@ole-lists.openlibraryfoundation.org] On Behalf Of Dr. Carsten Schwill
Sent: 26 September 2018 03:15 PM
To: 'folio-ra (folio-ra@ole-lists.openlibraryfoundation.org)' <folio-ra@ole-lists.openlibraryfoundation.org>
Cc: Sean Thomas <sthomas2@ebsco.com>
Subject: Re: Should all locations have service points?

CAUTION: External E-mail

Hi Cate and RA SMEs,

this is an interesting question and it got me thinking on how to allow for different loan policies for different loans like "inhouse" or "inter library", which could be processed by separate services points. This distinction could be derived from the patron group ("local student" vs.
"ILL student") or perhaps we need another dimension like "request type" for loan rules. It also might be useful to have some kind of "patron location", which would allow to differentiate "own faculty professors" from "other faculty professors".

About associating fee/fine tables with service points I am not sure. The loan rule mechanism might be a more sophisticated way of hooking them up. I picture it like this:
Loan-policies, fee/fine-policies and request-policies can be determined alike using "loan rules" or better "cirulation rules". Thes rules are based upon the following dimensions:
- location (of item)
- patron group
- loan type
- material type
- collection (later)
- request type?
- patron location?
This approach would allow consistent view of all three aspects of the loan. Also fees/fines would not need to be redefined for each one of several service point in a larger location.

In fact even back-office service points could process all items correctly without additional configuration or manual intervention.

Service points do need exactly one location, if locations are being used to determine opening hours and the postal address. On the other hand every location needs excatly one (main) service point, if locations are being used for the transit logic.

So after all it might be useful and perhaps even elegant to use item-locations for determining policies, service-point-locations for determining opening hours and addresses as well as location-service-points for implementing transit routing:
- every item has one effective item-location (policies)
- every location has one effective location-service-point (transit routing)
- every service point has one service-point-location (address, opening hours)

In the end everything will be fine...  ;-)

Carsten

Am 26 Sep 2018 um 11:52 hat Cate Boerema geschrieben:

> Hello RA SMEs,
>
> The developers are reconsidering the location-to-service point
> architecture and I've got a question for you that will inform their
> thinking.  The question is: should at least one service point be
> required for every location?
>
> Emma and I were discussing this and we realized that, probably, each
> location should have a service point.  After all, if you try to check
> in an item whose location doesn't have a service point, you won't know
> if it's home.  You won't be able to calculate its overdue fees
> (because the fee/fine tables will be associated with the service
> point) and you won't know the shelving lag time.  There probably many
> more impacts I am not thinking of at the moment.
>
> Our original designs (and, in fact, what has been implemented so far)
> support the ability to add locations to a service point.  If we need
> to require at least one service point per location, we are going to
> need to switch that around and ask users to add service points to
> locations instead.
>
> Let me know if you have any quick thoughts on this.  I'll try to get
> 10 minutes on the agenda for tomorrow to discuss further.
>
> Thanks much!
>
> Cate
>
>
> To unsubscribe from this list please go to
> http://www.simplelists.com/confirm.php?u=3Xi6lXgoLFKHcb4ll8CMPgCoNUdJG
> mPx

==
Dr. Carsten Schwill
Leiter Hauptabteilung Fachliche Leitstelle LBS Hamburg
Staats- und Universitätsbibliothek Hamburg Carl von Ossietzky Von-Melle-Park 3, 20146 Hamburg
Tel.: 040-42838-4363
Mail: carsten.schwill@sub.uni-hamburg.de
www.sub.uni-hamburg.de

To unsubscribe from this list please go to http://archives.simplelists.com To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=HlPdNmMDsk02fL31CnSAJArYoxM5Hzwp