If for some reason all the items from the least cost branch fail ( can't be transferred, fail the hold policy, non-matching itemtype filter, etc ), Koha does not check the next cheapest branch, but instead moves onto the "fall back to basics" code. We should loop over all the branches from least costly to most costly to find the least costly items that can be used.
Created attachment 151541 [details] [review] Bug 33796: Holds Queue builder should check more than just least cost branch for TCM If for some reason all the items from the least cost branch fail ( can't be transferred, fail the hold policy, non-matching itemtype filter, etc ), Koha does not check the next cheapest branch, but instead moves onto the "fall back to basics" code. We should loop over all the branches from least costly to most costly to find the least costly items that can be used. Test Plan: 1) Set up TCM so it's cheapest to transport item from A to C than from B to C. 2) Place hold for record with items at A and B, for pick at C 3) Disable transfer from A to C 4) Build the holds queue 5) Note the B item was selected over other more costly items, but not the less costly A item ( which cannot be transferred ).
Unit tests are failing, but are so complicated I cannot figure out how to fix them!
*** Bug 34673 has been marked as a duplicate of this bug. ***
I think that we should go further. I am working on a solution for optimizing the item allocation based on the transport cost matrix. The greedy algorithm that currently is used does not produce optimal allocation. I have created bug 35826 for this.
As 35826 does a better job and is perfomant, closing this in favor of that *** This bug has been marked as a duplicate of bug 35826 ***