Hi, On Thu, Feb 28, 2013 at 2:41 PM, Liz Rea <[email protected]> wrote: > I think we do not want to lose any data regarding transfers, no matter > how weird or nonsensical an action might be, a librarian might > legitimately want to do chained transfers, so we should not disallow > that.
I think the idea of chained transfers needs to be unpacked a little. Under what circumstances would one want an item to be transferred from A to B, then, the instant it is checked in at B, have a transit slip print directing it to C? I could see wanting to have an item auto-transfer to C after a period of time, a la rotating collections. Perhaps our modeling needs to distinguish between transfers and transfer requests. The former would be the record that an item is either in transit (i.e., branchtransfers where datearrived is null) or that it was successfully transferred in the past (datearrived is not null), while the later would be a request saying that at some specified future time the item *should* transit, either unconditionally or when it's not needed to fill a hold request. > A librarian might also legitimately want to have a transfer and a > reserve going at the same time and choose between them at check-in time. I think this should be unpacked as well ... when would one prefer to transit the item rather than fill a hold request? Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: [email protected] direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
