Bug 8042 - Batch numbers aren't committed as used until an item is added
Summary: Batch numbers aren't committed as used until an item is added
Status: RESOLVED DUPLICATE of bug 12911
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low normal
Assignee: Chris Nighswonger
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-03 16:18 UTC by shawn
Modified: 2014-11-02 11:44 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description shawn 2012-05-03 16:18:12 UTC
We ran into an issue where 2 branches decided to create a label batch around the same time. Both had the blank batch screen up and they were the same batch number. We have found that the batch isn't actually committed as being used until the first item is added. In this case we had 2 branches adding items to the same batch number.

This can be duplicated by creating a new batch in 2 separate browsers. If party 2 refreshes the screen after party 1 enters an item to the batch they are presented with a new batch but if they don't refresh (which most wouldn't) then both parties are editing the same batch.  We have tested it in 3.6 and 3.8.
Comment 1 e-Libris Technologies 2012-09-28 14:08:54 UTC
Until this problem is fixed one workaround is to click the Add Item button as soon as the very first barcode has been scanned. This way Koha will assign a new batch number. The rest of the barcodes can then be scanned. It's not a perfect solution but should reduce the chances of barcodes from multiple libraries ending up in the same batch.
Comment 2 Katrin Fischer 2014-11-02 11:44:07 UTC
I believe this is the same problem as bug 12911 - marking them duplicate so discussion can continue on one report.

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