Hi Cate,

we use postal addresses when sending snail mail and they will be necessery for written
"notices" - the last ones. Our libraries want their individual postal addresses be printed on
snail-mail and written in e-mails.

Yours,
  Carsten

Am 26 Sep 2018 um 15:18 hat Cate Boerema geschrieben:

> 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=3Xi6lXgoLFKHcb4ll8CMPgCoNUd
> > JG 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=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