Wishlist: Option to have lost items be charged the Acquisitions Cost

[Garry Collum]

Possibly another YAOUS.

When an item is set to lost, the price of the item is set as the lost value.

Our staff would like to have an option to have the Acquisition's Cost of an item be charged as the lost value of the item. Then if that does not exist, the price, and then a default cost.

[Jason Etheridge (phasefx)]

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=023ef553797702a714e50d54e13140894c7fca67

branch pushed to collab/phasefx/lp1905028-acq-price

[Jason Etheridge (phasefx)]

added an extra commit for the upgrade script

[Garry Collum (gcollum)]

Thoroughly tested all combinations of the new library settings. Works great! A signed-off branch is at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gcollum/lp1905028-acq-price-signoff

[Jeff Godin (jgodin)]

Jason, Garry-

Can either of you provide a use case for this?

What is the scenario where a library would want to use this?

Is it a situation where you lack data in the Price field, or a situation where you are prohibited from charging more than the acquisition cost by law/policy? Something else?

A use case might be a useful addition to the release notes.

-jeff

[Jason Etheridge (phasefx)]

Jeff, I can imagine various price/cost concepts like original acquisition cost vs replacement cost vs re-sale value vs insured value, and this functionality gives some flexibility in how to use the two fields we have available to us. One function that can't be replicated with workarounds like changes to workflow or batch changes to the data would be the fall-through behavior. I don't like how Evergreen has been baking concepts like charge lost on zero into the bottom-most get_item_price function, but I think separate development could disentangle that. Does this help? Maybe Garry can give us a concrete example.

[Garry Collum (gcollum)]

Hi Jeff,

Basically our Heads of Circulation felt it was unfair to the patron to charge the retail price of an item, if the library didn't pay retail price. So it's an attempt to charge the patron the actual cost that the library paid for the item.

We plan to use it as follows:

If there's an acquisition cost, charge this as the lost value.
If there's not an acquisition cost, but there's price, charge the price.
If neither, charge the default value.

[Mike Rylander (mrylander)]

Hi all,

I've added Garry's stated use case to the release notes per Jeff's request, squashed the upgrade script commit, and pushed it to master for 3.8 inclusion. Thanks, all!