Time |
Nick |
Message |
01:51 |
|
lualaba joined #evergreen |
02:08 |
|
barbara joined #evergreen |
05:51 |
|
book` joined #evergreen |
06:06 |
|
serflog joined #evergreen |
06:06 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
06:47 |
|
TARA joined #evergreen |
08:00 |
|
ericar joined #evergreen |
08:13 |
|
mrpeters joined #evergreen |
08:21 |
|
Dyrcona joined #evergreen |
08:34 |
|
JBoyer joined #evergreen |
08:37 |
|
mmorgan joined #evergreen |
08:43 |
kmlussier |
Good morning #evergreen! |
08:43 |
kmlussier |
@coffee [someone] |
08:43 |
* pinesol_green |
brews and pours a cup of Stars of Formosa Blend, and sends it sliding down the bar to mtj_ |
08:43 |
kmlussier |
@tea [someone] |
08:43 |
* pinesol_green |
brews and pours a pot of Top Leaf™ Green Tea, and sends it sliding down the bar to egbuilder (http://ratetea.com/tea/mellow-monk/top-leaf/1186/) |
08:44 |
mmorgan |
Good Morning! |
08:45 |
rhamby |
morning |
09:08 |
|
yboston joined #evergreen |
09:27 |
|
maryj joined #evergreen |
10:22 |
Bmagic |
@coffee me |
10:22 |
* pinesol_green |
brews and pours a cup of Kenya Ndiara Full Flavor Roast, and sends it sliding down the bar to me |
10:25 |
Bmagic |
mmmmm delicious |
10:32 |
|
krvmga joined #evergreen |
11:34 |
|
rlefaive joined #evergreen |
12:02 |
|
kitteh_ joined #evergreen |
12:10 |
mmorgan |
Anyone using Long Overdue status run into this? lp 1562061 |
12:10 |
pinesol_green |
Launchpad bug 1562061 in Evergreen "Marking a Long Overdue transaction Lost adds a second bill to the patron record" [Undecided,New] https://launchpad.net/bugs/1562061 |
12:13 |
|
tarac_ joined #evergreen |
12:31 |
mmorgan |
related question. Is a database query to update money.billing.voided = true sufficient to void a billing, or does something else need to happen? |
12:32 |
phasefx |
mmorgan: I believe there's also voider and void time |
12:34 |
mmorgan |
Ah. Ok. Of course, that makes sense. Thanks. |
12:35 |
* mmorgan |
will try it out on a test system. |
12:36 |
mmorgan |
phasefx++ |
12:37 |
phasefx |
mmorgan: I would sanity check the associated transaction in money.materialized_billable_xact_summary |
12:37 |
|
sandbergja joined #evergreen |
12:37 |
phasefx |
mmorgan: I don't know how, but sometimes I would get that table out of sync with stuff I did with the payments and billings tables, and would have to recreate it |
12:38 |
* mmorgan |
was wondering about exactly that sort of thing. |
12:41 |
phasefx |
there are triggers that are supposed to keep it in sync |
12:41 |
tsbere |
The triggers miss a few things |
12:41 |
tsbere |
<_< |
12:42 |
phasefx |
fun |
12:43 |
tsbere |
I think some of them are incomplete things (payment voiding?) and others are things like "you changed an ID!" |
12:45 |
* mmorgan |
is looking at materialized_summary_billing_update() |
12:49 |
* mmorgan |
needs now to decide whether to void the Long Overdue billing or the Lost billing to make sure the right info is in the summary table. |
13:02 |
|
rlefaive joined #evergreen |
13:46 |
kmlussier |
@dessert |
13:46 |
* pinesol_green |
grabs some Mint Chocolate Chip Ice Cream for kmlussier |
13:47 |
bshum |
Aww, my favorite :) |
13:56 |
|
sandbergja joined #evergreen |
14:15 |
Dyrcona |
@bartender |
14:15 |
* pinesol_green |
fills a pint glass with Matilda, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/1146/4318) |
15:11 |
|
mmorgan joined #evergreen |
15:40 |
Dyrcona |
@bartender get 11 |
15:40 |
* pinesol_green |
fills a pint glass with Samuel Adams Summer Ale, and sends it sliding down the bar to get 11 (http://beeradvocate.com/beer/profile/35/103/) |
15:48 |
kmlussier |
Nice! I haven't spent enough time with my pal Sam lately. |
15:57 |
kmlussier |
I was looking at the 'o africa' bug fix, which works very nicely. But in addition to the issue miker mentioned with the anchors, I noticed that in one of mmorgan's problem searches "61*", the asterisk is working as a wildcard. |
15:57 |
kmlussier |
See http://mlnc1.mvlcstaff.org/eg/opac/results?query=%2261*%22&qtype=keyword&fi%3Asearch_format=&locg=1 |
15:58 |
kmlussier |
Is that expected behavior? It seems odd to have a wildcard within quotation marks. |
15:58 |
kmlussier |
But I'm not thinking clearly this afternoon either. |
16:06 |
bshum |
kmlussier: https://evergreen-ils.org/conference/eg16/venuehotel-reservations/ has the alternate suggestions |
16:07 |
|
jlitrell joined #evergreen |
16:18 |
tsbere |
kmlussier: All things considered, wildcard inside the quotes isn't that odd. "some string*" makes sense, the quotes being needed for the space and all. |
16:33 |
|
gsams joined #evergreen |
16:52 |
|
mrpeters left #evergreen |
17:00 |
miker |
friday afternoon gift to all ... here's a bookmarklet that will let you highlight an LP bug number in your browser (or, ask for the number if you don't have it highlighted) and jump straight to that bug in LP ... because sometimes I don't have anything but the bug number |
17:00 |
miker |
javascript:(function() { function se(d) { return d.selection ? d.selection.createRange().text : d.getSelection() } s = se(document); for (i=0; i<frames.length && !s; i++) s = se(frames[i].document); if (!s || s=='') s = prompt('Enter a Launchpad bug number',''); open('https://bugs.launchpad.net/evergreen/+bug/'+s).focus(); })(); |
17:01 |
miker |
cribbed heavily from a similar one for wikipedia |
17:13 |
|
mmorgan left #evergreen |
17:31 |
kmlussier |
miker++ |
18:00 |
jeff |
most recent comment on bug 1174498 makes me concerned |
18:00 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" [Wishlist,Triaged] https://launchpad.net/bugs/1174498 |
18:00 |
* jeff |
looks |
18:00 |
jeff |
well that's unfortunate. |
18:01 |
jeff |
my fault for not being more forceful with my feedback. |
18:02 |
jeff |
it seems that we've moved away from a linear timeline with billings and payments, though i could be wrong. more digging required. |
18:03 |
jeff |
if that is the case, i'm strongly in favor of fixing it. the bad news is that it will probably take some work. the good news is that it will probably result in a lot more tests being written. ;-) |
18:05 |
jeff |
drat. dug, found it. |
18:05 |
jeff |
# Try to map payments to bills by amounts starting with the |
18:05 |
jeff |
# largest payments: |
18:05 |
jeff |
|
18:06 |
jeff |
that's not how this works. that's not how any of this works. :-) |
18:23 |
jeff |
first i should catch up on the rest of the billing changes. |
18:47 |
jeff |
I wonder if there's a way to fix this without resorting to two types of transactions. |
19:08 |
|
kitteh__ joined #evergreen |
19:48 |
* jeff |
reads old bugs |
20:24 |
|
rlefaive joined #evergreen |
21:18 |
miker |
jeff: oh, I should have been paying more attention too... yeah, matching amounts seems like a non-starter to me |
21:29 |
jeff |
@praise SIGSTOP |
21:29 |
* pinesol_green |
In days of old, it was prophesied that a hero would come and restore karmic balance to #evergreen. SIGSTOP is that hero. |
21:29 |
Bmagic |
jeff: I could use some more details on the concern |
21:29 |
jeff |
@praise Session.sublime_session |
21:29 |
* pinesol_green |
Session.sublime_session is one of the few who deserves to be praised |
21:30 |
jeff |
(I hit "Don't Save" when I meant to save -- recovered the buffer from ~/Library/Application Support/Sublime Text 2/Settings/Session.sublime_session |
21:30 |
jeff |
) |
21:31 |
jeff |
(which is 258599 bytes of json representing a bunch of unsaved buffers) |
21:32 |
Bmagic |
phew, that was close! |
21:32 |
jeff |
Bmagic: I'll comment on the bug once I've gathered my thoughts a bit more, but I think the new behavior in 2.9 is the bug, and while your change probably works around it very well, I'm partial to fixing the underlying behavior that made your change necessary in the first place. |
21:32 |
Bmagic |
ah, gotcha |
21:33 |
jeff |
Bmagic: but while you're here -- do you find the new behavior introduced in 2.9 useful / desirable? |
21:33 |
Bmagic |
I like the easy peasy adjust to zero feature for sure |
21:33 |
jeff |
Or is it just a matter of "2.9 does it this way, I want mmpbbt to work, so I fixed mmpbbt to acommodate how 2.9 works"? |
21:34 |
Bmagic |
I was a little surprised to learn that action triggers marking items lost, will void out the overdues by creating the opposite account_adjustment payments instead of voiding the overdues like it used to |
21:34 |
jeff |
Hrm. That sounds strance. |
21:34 |
jeff |
strange, even. |
21:34 |
Bmagic |
tons of lines in money.payment are generated by automated voids |
21:35 |
Bmagic |
instead of really voided=true |
21:35 |
Bmagic |
but yeah, "I want mmpbbt to work, so I fixed mmpbbt to acommodate how 2.9 works" - I don't really see an issue with the behavior, just different |
21:35 |
jeff |
"tons" of rows in money.payment for a given transaction? |
21:36 |
jeff |
or for lots of transactions? |
21:36 |
Bmagic |
if there was .05 overdue per day for 50 days, the voiding mechanizm creates 50 rows in money.account_adjustment (derived from money.payment) |
21:36 |
jeff |
Sorry, I'm taking advantage of the fact that you're running this and have had your head in it recently. |
21:37 |
jeff |
oof. |
21:37 |
Bmagic |
oh, no problem man, fire away |
21:37 |
jeff |
As opposed to saying "there are $2.50 worth of overdues to be adjusted/voided, make a single $2.50 payment" |
21:38 |
Bmagic |
right, it makes an opposing row in money.payment FOR EACH billing line. Which is sort of nice, because I can match amounts with mmpbbt |
21:39 |
Bmagic |
I don't know what I would do if it made a single row in money.payment that was supposed to cover many billing lines |
21:39 |
jeff |
that's what we use mmpbbt for here. |
21:39 |
Bmagic |
I guess if it made a single row counter for each billing_type..... |
21:40 |
Bmagic |
oh, are you running mmpbbt with my changes (before today)? |
21:40 |
jeff |
i don't think so. |
21:40 |
jeff |
we're running it either before your changes or with our own changes. |
21:41 |
Bmagic |
The original code that you posted to the bug, had a problem (for me) where it would pay the same billing line more than once sometimes |
21:42 |
jeff |
yeah, i have to compare things to see if we have that issue, if we fixed it ourselves or avoided it for some reason, or if it's there but gone undetected for a while. |
21:42 |
Bmagic |
happy hacking :) |
21:42 |
jeff |
in your usage of mmpbbt, do you ever "change" what you attribute payments to? |
21:44 |
jeff |
as in, "last week you paid us $2 for overdues on this transaction, but now we're marking the item lost and we're going to credit that $2 toward the price of the item that we just billed you"? |
21:44 |
Bmagic |
the latest version starts with the oldest payment and pays the oldest billing and leftover money spills from one row to another. The special case for account_adjustment causes the code to skip biling lines that do not match the payment amount, but then if it doesn't find one, it will settle for any unpaid billing line |
21:44 |
jeff |
(please say no, please say no) |
21:46 |
jeff |
in our case, once you've paid some overdues, if it then goes to longoverdue/lost and we bill you, we wipe the remaining overdues, but not the overdues you paid. you're then charged for the item. |
21:46 |
Bmagic |
I leave voided billings in the first loop, so voided billings can still gather up payments. Later the refunds come in and subtract it back |
21:46 |
Bmagic |
if there hasn't been a refund yet, then the payments will still stick on the voided billings |
21:47 |
Bmagic |
Perhaps we should resume then when you have had a chance to take deeper look at the changes? |
21:48 |
jeff |
Sorry, I'm asking about your local practice, not the code in mmpbbt. |
21:49 |
jeff |
As in, "does your finance department / etc consider the money taken in as payments 're-purposed' after the fact" |
21:50 |
Bmagic |
oh, honestly, Im not really sure what the libraries do. But I think that the money that the libraries take from the patrons which get voided, can apply toward more billing lines on the same bill. In short, yes, they are repurposed in the expierences I have had with some of our libraries |
21:51 |
jeff |
because your libraries void billings after the billings have been paid? |
21:51 |
jeff |
do your libraries also refund payments under certain circumstances? |
21:52 |
Bmagic |
so, if a patron paid $2 towards overdues, then those are voided and $2 worth of billing lines are added to the same bill, you would rather give the $2 back to them so they could pay you another $2 for another purpose? |
21:52 |
jeff |
speaking in terms of local practice here, we don't void/adjust paid billing line items. |
21:53 |
Bmagic |
oh right yeah, we have settings that allow paid lines to get voided (I believe most are starting to see the wisdom in not allowing that, but we have not erradicated that yet) |
21:53 |
jeff |
so given $10 overdues, $29.99 lost item charge, lost item returned and $10 overdues re-billed, if you come in at the end and pay for it, you pay $10 and you're all set. |
21:54 |
jeff |
but if you have $10 overdues, you pay $6 to get under our $5 limit that blocks checkout, then you still don't return the item and we bill you $29.99 for it, then you return the item and we re-bill $4 worth of overdues, you pay another $4 and you're all set. |
21:54 |
jeff |
having still paid only $10 |
21:55 |
Bmagic |
sure, Im with you |
21:56 |
jeff |
however, if you have $10 overdues, pay $6, then get billed for the item at $29.99 (and the remaining $4 in overdues goes away), pay $25 to get to a $4.99 balance... |
21:57 |
jeff |
...then return the item, now I can't remember without checking if we re-bill the $4 in overdues or not, but regardless we don't take some of that $25 and say "it was for lost materials last week, but now it's for overdues" |
21:58 |
jeff |
so in our case, mmpbbt would show $4 for overdues and $25 for lost materials. |
22:00 |
jeff |
ah well. ever complicated. |
22:00 |
jeff |
thanks for your time and code. :-) |
22:00 |
jeff |
i'll stop babbling for now. :-) |
22:04 |
Bmagic |
sorry, I was afk |
22:05 |
jeff |
heh |
22:05 |
Bmagic |
yeah, it gets muddy for sure. I look at mmpbbt as "best effort" or "best guess" |
22:05 |
Bmagic |
and I think our libraries undestand that. Sometimes, a human still needs to step in and make a call |
22:07 |
Bmagic |
with that said - I have put untold hours into testing and watching the code interact with the data, and I'm feeling pretty good about the job that it will do for our libraries who look at the results |
22:20 |
jeff |
Bmagic++ |
22:21 |
Bmagic |
jeff++ |