This is a great idea.  Makes sense.  I wonder if it would be better to do away with the "Book drop" checkbox all together and put a button next to the calendar field to "Set last open date"?  Maybe wordy.  Just a thought.

Christopher

(In reply to Christopher Brannon from comment #1)
> This is a great idea.  Makes sense.  I wonder if it would be better to do
> away with the "Book drop" checkbox all together and put a button next to the
> calendar field to "Set last open date"?  Maybe wordy.  Just a thought.

I'm not in favor of always displaying the calendar widget, as there's a user permissions issue here: circ staff may be permitted to set the effective return date to the previous open day, but may not be permitted to set it to an arbitrary date.

I suppose we could make bookdrop mode find the last date open and recalculate the fine in full from there. That way it looks the same from a user perspective.

The problem with bookdrop mode is that it is quite fragile. For example, if fines.pl doesn't run for a night, and does the following night, then using bookdrop mode will decrement the fine by double the expected amount. The backdating returns feature does not suffer from this kind of fragility.

We could keep the preference and use it to switch between the date being set automatically and being able to change it. Would that work?

(In reply to Katrin Fischer from comment #4)
> We could keep the preference and use it to switch between the date being set
> automatically and being able to change it. Would that work?

Yes, I think that's a good idea. Bookdrop mode should find the last date open and recalculate the fine in full from there. That way it looks the same from a user perspective. Right?

(In reply to Kyle M Hall from comment #5)
> (In reply to Katrin Fischer from comment #4)
> > We could keep the preference and use it to switch between the date being set
> > automatically and being able to change it. Would that work?
> 
> Yes, I think that's a good idea. Bookdrop mode should find the last date
> open and recalculate the fine in full from there. That way it looks the same
> from a user perspective. Right?

That should look the same from the user perspective. I like not having to tell the staff to mess with the calendar every time as I feel like when we do use the calendar someone always selects the wrong day. 

Lisette

(In reply to Kyle M Hall from comment #3)
> I suppose we could make bookdrop mode find the last date open and
> recalculate the fine in full from there. That way it looks the same from a
> user perspective.
> 
> The problem with bookdrop mode is that it is quite fragile. For example, if
> fines.pl doesn't run for a night, and does the following night, then using
> bookdrop mode will decrement the fine by double the expected amount. The
> backdating returns feature does not suffer from this kind of fragility.

It should be noted that we are seeing that the bookdrop mode is backdating based on the last open day of the item's owning library, not the library the item was checked in at.  Maybe this is a separate bug issue, but thought I would mention it.  Ideally, the back dating should be based on where it was returned.  Otherwise, patrons are being fined inconsistently and unfairly because the owning library was open the previous day, regardless that the library they dropped the item off at wasn't.

I hope that makes sense.

Also, perhaps the calendar widget could be made to default to the last open day when clicked on.  If we went the route of doing away with bookdrop mode, the permissions that were brought up in comment to could control weather the date could actually be changed to anything else or not.  ???   Just a thought.

(In reply to Kyle M Hall from comment #3)
> I suppose we could make bookdrop mode find the last date open and
> recalculate the fine in full from there. That way it looks the same from a
> user perspective.
> 
> The problem with bookdrop mode is that it is quite fragile. For example, if
> fines.pl doesn't run for a night, and does the following night, then using
> bookdrop mode will decrement the fine by double the expected amount. The
> backdating returns feature does not suffer from this kind of fragility.

One thing to mention here, especially as this related to 21969, is how to manage payments on accruing items. Right now there is no way to see an accruing fine, so there's no way to stop from taking payment on the item, but if we are recalculating fines on checking, what happens to that payment?

The broader question of taking payment on accruing fines is probably worth discussing as well. I feel we need to do that, especially if a user needs to make a payment to get below the checkout threshold. Users will expect to be able to pay that regardless.

> One thing to mention here, especially as this related to 21969, is how to
> manage payments on accruing items. Right now there is no way to see an
> accruing fine, so there's no way to stop from taking payment on the item,
> but if we are recalculating fines on checking, what happens to that payment?

> 
> The broader question of taking payment on accruing fines is probably worth
> discussing as well. I feel we need to do that, especially if a user needs to
> make a payment to get below the checkout threshold. Users will expect to be
> able to pay that regardless.


Yes, I believe Koha should disallow paying accruing fines, but it *should* allow payments to create credits. That way the account balance can be paid down and have the credit pay off the fine as soon as it is closed out.

Specifically, it makes sense to allow a patron to pay up to the current amount owed in fees and fines. For if a patron owes $5 on a closed fine, and $3 on an accruing fine, the patron should be able to pay $8 right now with the $5 fine being paid off and $3 in credit staying on the account. That way the account balance is 0 and when that item is returned the credit will be automatically used to pay some or all of the balance of the fine.

*** Bug 14373 has been marked as a duplicate of this bug. ***

(In reply to Kyle M Hall from comment #10)
> Specifically, it makes sense to allow a patron to pay up to the current
> amount owed in fees and fines. For if a patron owes $5 on a closed fine, and
> $3 on an accruing fine, the patron should be able to pay $8 right now with
> the $5 fine being paid off and $3 in credit staying on the account. That way
> the account balance is 0 and when that item is returned the credit will be
> automatically used to pay some or all of the balance of the fine.

I think this would work well and solve several issue. The one proviso is that a method of dealing with credits would need to be a part of this. Right now you need to create a manual invoice to offset a credit and that's already a hassle. A "pay credit" option that allows you to pay out the credit to the patron would be necessary.

I just discovered this bug Wednesday so I'm late to the party here.  I have the same concern as Lisette with specifying return dates, but after reading all of the previous comments my recommendation incorporates some of the discussion that's already been going on.  My overriding concern is for making these ideas as simple as possible for staff.

Currently staff see "Forgive overdue charges" and "Bookdrop mode" in the set of options on the right hand side of the check in screen.  If the "SpecifyReturnDate" system preference is set to "Allow" they see the "Specify return date" options under the checkin barcode input box.  If the "SpecifyReturnDate" system preference is set to "Don't allow," they don't see anything under the barcode input box.

Also, currently, if the "Bookdrop mode" checkbox is checked, an "alert" class is added to the barcode input box.

My recommendation is that the checkbox options on the right hand side of the screen be expanded to include "Forgive overdue charges," "Bookdrop mode," and "Specify return date."  And the ability to use "Forgive overdue charges" and "Specify return date" should be tied to permissions.

Then, under the checkin barcode input box, only have the "Specify return date" options appear if "Bookdrop mode" or "Specify return date" were selected.

On selecting the "Bookdrop mode" checkbox, the "Specify return date" options would display under the checking barcode box and would lock the date to the last open date on the logged in library's calendar.  Checking "Bookdrop mode" would also automatically check the "Remember for next checkin" checkbox and add the "alert" class to the barcode input box.

On selecting the "Specify return date" checkbox, the "Specify return date" options would display under the checking barcode box and staff would be able to select valid dates in the past from the datepicker calendar.  Checking the "Specify return date" checkbox would no automatically check the "Remember for next checkin" checkbox - but it would add an "alert" class to the barcode input box.

Currently we have "SpecifyReturnDate" turned off in our system and we ask staff to use bookdrop mode because it's less complicated than specifying a return date.  Since we have 52 libraries all using the same shared Koha, and since working in Koha is only a portion of staff's job responsibilities, making Koha as easy to operate for staff is very important to us.  When training staff, it's a lot easier to train them on "When you check things from the book-drop in every morning, check the 'Bookdrop mode' checkbox" than it is to train them on "Enter the date as the last date your library was open, then click the little checkbox next to that date that says 'Remember for next check in.'  I would be opposed to anything that makes setting a due date for checking in book drop items more complicated than checking one checkbox.

(In reply to George Williams (NEKLS) from comment #13)
> I just discovered this bug Wednesday so I'm late to the party here.  I have
> the same concern as Lisette with specifying return dates, but after reading
> all of the previous comments my recommendation incorporates some of the
> discussion that's already been going on.  My overriding concern is for
> making these ideas as simple as possible for staff.
> 
> Currently staff see "Forgive overdue charges" and "Bookdrop mode" in the set
> of options on the right hand side of the check in screen.  If the
> "SpecifyReturnDate" system preference is set to "Allow" they see the
> "Specify return date" options under the checkin barcode input box.  If the
> "SpecifyReturnDate" system preference is set to "Don't allow," they don't
> see anything under the barcode input box.
> 
> Also, currently, if the "Bookdrop mode" checkbox is checked, an "alert"
> class is added to the barcode input box.
> 
> My recommendation is that the checkbox options on the right hand side of the
> screen be expanded to include "Forgive overdue charges," "Bookdrop mode,"
> and "Specify return date."  And the ability to use "Forgive overdue charges"
> and "Specify return date" should be tied to permissions.
> 
> Then, under the checkin barcode input box, only have the "Specify return
> date" options appear if "Bookdrop mode" or "Specify return date" were
> selected.
> 
> On selecting the "Bookdrop mode" checkbox, the "Specify return date" options
> would display under the checking barcode box and would lock the date to the
> last open date on the logged in library's calendar.  Checking "Bookdrop
> mode" would also automatically check the "Remember for next checkin"
> checkbox and add the "alert" class to the barcode input box.
> 
> On selecting the "Specify return date" checkbox, the "Specify return date"
> options would display under the checking barcode box and staff would be able
> to select valid dates in the past from the datepicker calendar.  Checking
> the "Specify return date" checkbox would no automatically check the
> "Remember for next checkin" checkbox - but it would add an "alert" class to
> the barcode input box.
> 
> Currently we have "SpecifyReturnDate" turned off in our system and we ask
> staff to use bookdrop mode because it's less complicated than specifying a
> return date.  Since we have 52 libraries all using the same shared Koha, and
> since working in Koha is only a portion of staff's job responsibilities,
> making Koha as easy to operate for staff is very important to us.  When
> training staff, it's a lot easier to train them on "When you check things
> from the book-drop in every morning, check the 'Bookdrop mode' checkbox"
> than it is to train them on "Enter the date as the last date your library
> was open, then click the little checkbox next to that date that says
> 'Remember for next check in.'  I would be opposed to anything that makes
> setting a due date for checking in book drop items more complicated than
> checking one checkbox.

Perhaps I'm misunderstanding this, but doesn't the proposed functionality of defaulting the date to the last day the library was open obviate the need for any checkboxes? We could create a syspref to default check-in date to that last day the library was open, then perhaps a permission that allows staff to change (or not) this date on demand. Then no one needs to check anything. I also think "remember date" should be the default functionality.

(In reply to Benjamin Daeuber from comment #14)

> 
> Perhaps I'm misunderstanding this, but doesn't the proposed functionality of
> defaulting the date to the last day the library was open obviate the need
> for any checkboxes? We could create a syspref to default check-in date to
> that last day the library was open, then perhaps a permission that allows
> staff to change (or not) this date on demand. Then no one needs to check
> anything. I also think "remember date" should be the default functionality.

Or perhaps if library's want to turn bookdrop mode on or off on demand, a single checkbox that sets the date to the library's last open date, and a permission that gives certain staff the ability to manipulate the calendar.

I want the interface and the options displayed on screen to be as simple as possible for staff.

99% of the time staff are using returns.pl, they are doing normal check ins - no book drop mode, no due date other than the current date and time, and they're not forgiving fines.  If staff don't need to use the "Specify due date options," why have those options clutter up the screen.  Currently, if SpecifyReturnDate is set to Allow, the #return_date_override input box, the date picker calendar, the "Remember for next checkin" checkbox, the "Clear" button, the "Specify return date" hint, and the "Remember for next check in" label appear on the screen whenever returns.pl is open.  If staff are doing normal check ins, then all of this stuff is just a distraction on the screen.  By having a "Specify due date" checkbox or toggle on the right side of the screen where the "Forgive fines" and "Book drop mode" checkboxes are located, all of that stuff on the screen related to spcifying a due date can be removed from the screen for the 99% of the time that staff are doing normal checkins.

Simplicity is the same reason that I'd like a checkbox or a toggle for "Book drop mode."  "Book drop mode" is incredibly simple to explain to staff because the words "Book drop mode" are virtually self-explanatory.  When you're training front-line staff on checking in items and you talk about how to handle things left in the book drop overnight, all you have to really say is "When you check in items from the book drop every morning, click on the box that says 'Book drop mode.'"  The existing "Book drop mode" option communicates its purpose on the screen more efficiently than subordinating that function to the "Specify due date" feature would.  No matter how simple we make selecting the last open date when choosing to specify a due date, "Book drop mode" is a much simpler way of communicating the function to the user.

"Forgive overdue charges" is simple and easy to understand.  "Book drop mode" is simple and easy to understand.  A checkbox or toggle for "Specify due date" would also be easy to understand option on the right hand side of returns.pl, especially if checking that box caused all of the specify due date options to display where they are currently displayed under the checkin input box.  And having a way of preventing those options from displaying when they are not needed makes this page easier to scan for the 99% of the time staff are doing normal checkins.

George

*** Bug 12144 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 14591 ***