Bug 16461

Thank you Alex and Sophie, this would indeed come very handy to our Koha installation.

However, in the long term, (especially if this is to be used the whole community), I think it would be far better if separate columns were created in the accountlines table to hold (at least) the branchcode and/or the item barcode[1]. 

In the same context, an ideal situation would be if branchcode/barcode would be displayed in separate columns in the fines table (and not concatenated in the description).
This way description text would not be unnecessarily long and would not include hardcoded "Branch" and "Barcode" strings (which instead would be shown as translatable table headers in the fines table).

Just as food for thought :)

[1] if you don't want to keep barcodes both in items and accountlines table (also useful if barcode was changed in the meantime), it could be dynamically read during fines display (using itemnumber as key)

Another advantage of the 'separate columns for Branch/Barcode in fines' approach would be that instead of branch CODE, the branch NAME could be displayed in the separate "Branch" column (as it happens with other item-related tables) which is more clear to staff librarians.

Of course, similarly due date could be a separate column in the fines table!

So to wrap the whole idea up: My proposal for the long run would be something like:

Fines & charges | Description | Barcode | Due Date | Branch | Payment note | Account type | Notify id | Level | Amount | Amount outstanding

(The table seems to hold too much information to fit into the screen, but description is no longer required to be that long!)


Having said that, the disadvantage of this approach is that not ALL fines are related to items, in which case Barcode and Due Date columns will be empty. If this is acceptable and you're willing to make the change in the database schema of the accountlines table, I think it would be fairly easy to implement and would worth the time and effort...

Based on the case description, the proposed fix does the trick.

However, in order to keep track of the 'more advanced' solution that we would like to have, I created separate RFE:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16639

QA comments:
1/ Please add a test plan
2/ This patch adds 3 strings which are not translatable "Due", "Barcode" and "Branch".
Note that "Branch" should be renamed with "Library".

Created attachment 61042 [details] [review]
Bug 16461 - Add branch and barcode in accountline table for overdues

Missing a test plan

Looks like this patch doesn't apply :
Applying: Bug 16461 - Add branch and barcode in accountline table for overdues
Using index info to reconstruct a base tree...
M	C4/Overdues.pm
M	installer/data/mysql/kohastructure.sql
M	koha-tmpl/intranet-tmpl/prog/en/modules/members/pay.tt
M	t/db_dependent/Circulation.t
Falling back to patching base and 3-way merge...
Auto-merging t/db_dependent/Circulation.t
CONFLICT (content): Merge conflict in t/db_dependent/Circulation.t
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/members/pay.tt
Auto-merging installer/data/mysql/kohastructure.sql
Auto-merging C4/Overdues.pm
error: Failed to merge in the changes.
Patch failed at 0001 Bug 16461 - Add branch and barcode in accountline table for overdues

This is a partial duplicate of bug 19066 (which adds branchcode to the accountlines table)

QA Comment: The SQL side of this is now basically covered by bug 19066 for branchcode and I would prefer not to add barcode from the items table alongside the existing item_id.. you can just use a simple join to get the barcode ;).

Please can this be updated to depend upon 19066 if we still want the included UI changes here.

It would be useful if this table contained more information in general. We have a job identifying what type of item has a fine. Quite often we will have book, audio and movie of the same item. Rather than have to explore the system to get that information by including the item type and call number all the information would be collected together when you need it.
We are part of a consortium so knowing which library the item belongs to would help us to know if a payment needs forwarding to a different library.

Updated to reflect changes on master and comments. Setting back to NEW for now, as I think this will require a different/new approach than the existing patch.

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

This is possible now using OVERDUE_FINE_DESC in 'notices and slips'.