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

Bug #1905028 reported by Garry Collum
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

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.

Garry Collum (gcollum)
tags: added: wishlist
tags: added: acq circulation
Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Revision history for this message
Jason Etheridge (phasefx) wrote :
tags: added: pullrequest
Changed in evergreen:
assignee: Jason Etheridge (phasefx) → nobody
Revision history for this message
Jason Etheridge (phasefx) wrote :

added an extra commit for the upgrade script

Andrea Neiman (aneiman)
Changed in evergreen:
milestone: none → 3.8-beta
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Garry Collum (gcollum) wrote :

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

tags: added: signedoff
Revision history for this message
Jeff Godin (jgodin) wrote :

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.


Revision history for this message
Jason Etheridge (phasefx) wrote :

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.

Revision history for this message
Garry Collum (gcollum) wrote :

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.

Revision history for this message
Mike Rylander (mrylander) wrote :

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!

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.