Support moving ACQ lineitems to alternate bib record

Regarding the final assumption, that is probably true for language differences, but for things like form, edition, etc, I think that would not hold.

Question for all: is getting the wrong language version of an item the most common mistake a vendor would make, or would a different edition or item form be more likely?

To confirm your suspicions, Mike, from staff here: a more common scenario would be the order staff selecting the wrong ISBN using the ISBN picker (large print vs. regular print, e.g.).

So I guess the question is whether the item that arrived replaces the originally ordered item (editions) or whether it's something else entirely (language).

Thinking out loud a little bit... If the new bib completely replaces the original bib, it seems like a bib merge would be in order. (note to self: do bib merges merge lineitems?). Otherwise, the there could be legit holds on the original record that we may not want to automatically transfer.

After further discussion, automatic holds transfer is not desired by our staff. In most cases it won't make sense to move the holds and in others it may not make sense to move all of the holds. Staff always have the option to transfer holds manually. I'm happy to help add a hold transfer option, but I'd need input on how it should work.

In the meantime, I'm looking at building code for the bug as originally described.

I'm in agreement that the holds shouldn't transfer. Once an item moves to another record, there is no way to know if the difference between the materials is one that the patron can live with or not. If the patron is okay with different formats, then it would be great if we could encourage patrons to use metarecord holds, in which case the item still may be eligible to fill that hold.

"If real copy/call-numbers exist for the lineitem, they are migrated to the new title."

Along with that, don't forget that if the copies have parts, they will need to be moved appropriately to the new record.

Code, live tests, release notes pushed. Includes XUL UI bits, too, as a separate non-required commit.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1619703-transfer-lineitems

For handling parts, I opted to leave all existing parts on the source bib record, even if all copies linked to a given part will be migrated to a matching part on the new bib record. My thinking was the source bib record still has the same parts, even if no copies link to all of them. This may be naive. If parts should behave more like call numbers, where the last copy out turns out the lights (i.e. call number is deleted or moved to the new bib, depending on whether a call number with the same label already exists on the new bib), that can be arranged.

Following the proposed workflow I marked the target bib as an order transfer destination. I then located the line item in the PO and used the new transfer command in the line item actions menu. The information displayed in the popup seems adequate, but I do think an option to enter a line item note, or automatically add the information in the popup as a note, is needed. It would be great if it was obvious, when looking at the line item, that the line item has been transferred to a different record, since the display of the bib information is not updated.

I did find issues with volumes and volume holds that need to be addressed.

1. When the line item is moved, it leaves behind an empty volume record. (Library Setting “Delete volume with last copy” was set to True for this test)

2. If there happens to be a volume hold on the volume, it stays behind with the empty volume. It should transfer with the volume. Copy holds do transfer properly.

Thanks, Christine!

My modified plan for handling the volumes in this case, where all copies on a given volume migrate to the new record, is simply to treat it as a volume merge. Holds will be migrated and the source call number will be deleted, using the existing merge code.

Another holds issue popped up as well. If a copy is targeted for a hold on Bib A and said copy is moved to Bib B, then the hold needs to be retargeted so it's not pointing at an invalid copy. I'll look at that too, unless there are other suggestions on how to address that.

A few thoughts on the copy that's targeted for the hold - if the item is already on the Holds Shelf or In transit, retargeting can be problematic and leave copies stranded.

Another option could be to transfer the hold along with the copy. This wouldn't be appropriate in Bill's use case, but another use case could be that Bib B is a different edition of the same work that was originally ordered, and eligible to fill the original hold. It's not a one size fits all.

Maybe a warning to the user that the holds will be retargeted and an option to cancel the operation so the holds could be dealt with manually before the lineitem is moved?