Marking a lost item Claimed Returned does not void lost charges

I'm going to take the approach of using YAOUS to configure whether or not claims returned voids lost charges.

I see this as a feature and not a bug.

A potential branch to add this feature is at

working/user/dyrcona/lp980296

I removed the pull request tag for now. I am going to add a commit to also void the lost processing fee with its own ou setting.

Force pushed a rebased branch with some tweaks to add voiding of the lost processing fee to

user/dyrcona/lp980296

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp980296

Seems to be working for me so far in testing.

Sign-off: user/bshum/lp980296

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp980296

I have removed the pullrequest tag from this bug for a couple of reasons:

1. Dan Wells' comment on https://bugs.launchpad.net/evergreen/+bug/793550 has me thinking of a "better" solution of making a generic "void_bills" function in CircCommon or wherever as necessary.

2. There are known issues with voiding bills that have payments, even partial payments. Many of these are listed in this other bug,
https://bugs.launchpad.net/evergreen/+bug/1009049. I am therefore not sure if this bug should be fixed in the absence of a good solution to voiding bills with payments issues.

I may still do a version of the code for this bug that uses a more generic void function anyway. If you void bills where there are no payments, then voiding works just fine.

I am now working on a solution for this as part of:

https://blueprints.launchpad.net/evergreen/+spec/billing-enhancements

More information here:

http://www.sigio.com/evergreen/billing2013.html#voidlost

It's the top 5 commits, so far, on http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp980296-Void_Lost_for_Claims_Returned

I pushed to a collab branch so it would be easier for Kathy to add the release notes.

This branch depends on the code from http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1198465-Conditional-Negative-Balances

That branch is actually included in this one for testing purposes. The code in the latter branch *should* go into master first, if not, it will have to go in with this branch or this branch won't work.

Just adding a comment that I've tested this branch and found that it works as expected. I didn't add a sign-off because I wasn't sure if the negative balance branch should go in first before signing off.

Also, I wasn't successful in pushing the release notes to the collab branch. I was going to give it another go, but I ran out of time and won't be available to look into it over the next ten days. I did add a release notes entry to the working repository if somebody wants to add it to this branch.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/release-notes-void-lost-claims-returned

After some back and forth and messing other branches requiring the conditional negative balance work that has not gone in, yet, it was decided to revive the orignal branch for this bug.

I rebased bshum's signed off branch on master and added two commits:

1. To handle the new longoverdue bills for that status and to fix up a few possible logic issues in the original code.
2. To add pgtap tests that the new settings get created.

I also cherry-picked kmlussier's release notes branch.

I force pushed over my old branch working/user/dyrcona/lp980296

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp980296

I added the pullrequest tag 'cause I'm requesting that this be tested for inclusion into master.

Tested with different combinations of voiding lost fee and processing fees. The behavior works as advertised. Sign-off branch at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp980296

I did notice that we have a similar issue with the "Claims Never Checked Out" action, but I can document that problem on a separate bug report once I have had a chance to look at the behavior more closely.

Thank you Jason!

Reviewing the latest iteration of this branch for inclusion in 2.next (i.e. 2.8)

Pushed to master, thanks Jason! And Kathy for the signoff!