2020-01-25 GnuCash IRC logs
00:04:25 *** Gerd has quit IRC
00:09:54 *** Gerd has joined #gnucash
00:27:44 *** FH_thecat has joined #gnucash
00:32:24 *** Gerd has quit IRC
00:39:10 *** Gerd has joined #gnucash
00:39:15 *** Gerd1 has joined #gnucash
00:39:59 <chris> @tell gjanssens really annoying that gncFooGetGUID is not accessible to guile
00:39:59 <gncbot> chris: The operation succeeded.
00:42:10 *** Gerd has quit IRC
00:42:10 *** Gerd1 is now known as Gerd
00:42:20 <chris> Foo=invoice/Trans/Account/etc
00:46:46 <chris> @tell gjanssens I have *no* easy way of defining a unique txn/invoice/etc for hashing
00:46:46 <gncbot> chris: The operation succeeded.
00:56:46 *** omnireq_ has quit IRC
00:56:58 *** omnireq_ has joined #gnucash
01:01:40 *** Gerd has quit IRC
01:12:09 *** fell_laptop has joined #gnucash
01:12:09 *** ChanServ sets mode: +o fell_laptop
01:14:22 *** fell has quit IRC
01:55:33 *** sbluhm has joined #gnucash
01:55:33 *** ChanServ sets mode: +v sbluhm
02:05:33 *** sbluhm has quit IRC
02:18:00 *** kinlo has quit IRC
02:22:53 <chris> @tell gjanssens try my latest maint :) :)
02:22:53 <gncbot> chris: The operation succeeded.
02:38:40 <chris> it works but needs debugging
02:52:58 *** gjanssens has joined #gnucash
02:52:58 *** ChanServ sets mode: +o gjanssens
02:53:09 <gjanssens> .
02:53:09 <gncbot> gjanssens: Sent 2 hours and 13 minutes ago: <chris> really annoying that gncFooGetGUID is not accessible to guile
02:53:10 <gncbot> gjanssens: Sent 2 hours and 6 minutes ago: <chris> I have *no* easy way of defining a unique txn/invoice/etc for hashing
02:53:11 <gncbot> gjanssens: Sent 30 minutes ago: <chris> try my latest maint :) :)
02:57:09 *** Mechtilde has joined #gnucash
02:57:50 <chris> gjanssens: it is done, but lot-link txns aren't yet upgraded to show links :)
02:58:11 <chris> gjanssens: it is done, but lot-link txns aren't yet upgraded to add invoice-javascript tags :)
02:58:48 <chris> and apols if my javascript looks like lisp
03:02:12 *** Han has joined #gnucash
03:02:43 <gjanssens> your javascript is better than my initial attempt :)
03:02:58 <gjanssens> Though it has a few constructs I had never seen before yet
03:03:22 <gjanssens> Like [....TDs]
03:03:47 <chris> yeah thank you google
03:06:22 <chris> of note: can't use classname to uniquely identify invoices/payments because the classname is used by stylesheets to choose an appropriate tag.
03:11:28 <gjanssens> I can't follow. Can you detail that a bit more ?
03:13:30 <chris> your example has class="bill-1234 number-cell". to achiev this using api means (gnc:make-html-table-cell/markup "bill-1234 number-cell" ...) and the stylesheet will try match the whole string and fail to find a match.
03:14:01 <chris> brb.
03:14:23 <gjanssens> Oh, ok
03:14:49 <gjanssens> Shows how old/obsolete the whole stylesheet design is...
03:22:17 <chris> so: outstanding issues:
03:22:42 <chris> 1. a better invoice/transaction hashing function. i want to access GUID but .i forbids it.
03:23:27 <chris> 2. lot-link handling. needs to rewrite and add ID for javascript. when you can construct a complicated/awkward one, and the report output I'll fix it.
03:27:01 <chris> 1a. OTOH if retrieving GUID means traversing qof hash-tables then maybe allow caching in memory?
03:28:23 <gjanssens> I have a patch ready to give you guid's in guile.
03:32:14 *** Han_ has joined #gnucash
03:33:17 <gjanssens> https://github.com/gjanssens/gnucash/tree/newvendor
03:33:29 *** Han has quit IRC
03:34:23 <gjanssens> BBIAB (time for breakfast :p )
03:42:49 *** bertbob has quit IRC
03:42:59 *** Han_ has quit IRC
03:44:13 *** bertbob has joined #gnucash
03:44:14 *** ChanServ sets mode: +v bertbob
04:05:11 <gjanssens> Back
04:08:00 <chris> cool.
04:08:14 <chris> just found gncInvoiceReturnGUID is already exposed.
04:10:40 <gjanssens> Oh right. I missed that one. Better use it and drop my gnc-invoice-get-guid again
04:11:37 <gjanssens> BTW I just reopened the sample book I had for bug 797596 and to me there's another inconsistency left
04:11:47 *** fabior has joined #gnucash
04:11:49 <gjanssens> It's the book with the manipulated payment
04:12:07 <gjanssens> RHS the payment is listed as two amounts (good) and one description
04:12:26 <gjanssens> LHS the payement is listed as one amount (good) and two descriptions
04:13:00 <gjanssens> To my mind it would make more sense if the memo's of the non-APAR splits are used RHS, as are the non-APAR amounts
04:13:46 <chris> ok: change (splits->desc (list lot-split)) to (splits->desc pmt-splits) in make-invoice->payments-table should do it
04:13:49 <gjanssens> And LHS combine the memos of the APAR splits as description and the sum of the APAR split's amounts as amount
04:17:16 <gjanssens> Ok, that works RHS
04:17:23 <gjanssens> What do you think of LHS?
04:18:48 *** daudi has joined #gnucash
04:20:48 *** fabior has quit IRC
04:21:06 <chris> change (splits->desc (txn->assetliab-splits txn)) to (splits->desc (xaccTransGetAPARAcctSplitList txn #t)) somewhere around L807
04:21:35 <chris> just pushed.
04:29:07 *** fabior has joined #gnucash
04:34:26 <gjanssens> chris: for rhs, can you use the same sorting on descriptons and amounts in case of a manipulated payment ?
04:34:48 <gjanssens> That way the description will go with the amount as they are in the splits.
04:35:17 <gjanssens> (Which also means we shouldn't be deduplicating descriptions for rhs payments)
04:35:19 *** mauritslamers has quit IRC
04:35:55 <gjanssens> https://i.imgur.com/pVH7dFa.png
04:36:41 <gjanssens> The manipulated transaction has 20 cash and 80 checking. However the report as generated seems to suggest it's the other way around.
04:40:05 <chris> ok can modify.
04:40:05 <gjanssens> As for lot link transactions, you can ignore them LHS and RHS treat them as payments
04:41:28 <gjanssens> They have no non-apar splits so their total apar amount is always 0 (which may be a quality you can use to filter them out LHS as well)
04:44:08 *** fabior has quit IRC
04:45:59 *** jralls has quit IRC
04:46:29 *** jralls has joined #gnucash
04:46:32 <chris> ok just pushed again.
04:46:49 *** mauritslamers has joined #gnucash
04:46:50 *** ChanServ sets mode: +v mauritslamers
04:57:16 <chris> should pre-payments all have the same link-id?
04:57:29 <chris> and unpaid transactions?
04:58:33 <chris> ack. don't need your hack. gncTransGetGUID exists.
05:01:58 *** daudi has quit IRC
05:02:04 <gjanssens> :)
05:04:19 <gjanssens> The pre-payment and unpaid transactions link-id is tricky. They are not part of the same transaction, which is what the hightlight is signaling.
05:05:04 <gjanssens> Do you think we need more attention to the pre-payments or unpaid bits ? Thanks to their different borders they already stand out, no ?
05:05:50 <chris> don't think so. it's the fact that clicking does nothing. let's leave them alone
05:05:55 <chris> ok being summoned, brb 1h.
05:07:20 *** daudi has joined #gnucash
05:16:39 *** User__ has joined #gnucash
05:18:22 <gjanssens> chris: when running the report on my test book a bill is seemingly ignored.
05:18:49 <gjanssens> I'll send you my book in private (it used to be real accounting data, so not something for a public bug tracker)
05:19:01 <gjanssens> And then I'll tell you where to look.
05:23:45 <gjanssens> Bill 000007 for vendor Adfisc on date December 8, 2011 is missing from the report.
05:24:30 <gjanssens> If you look at the AP account and the lot viewer, you'll notice it's linked with a lot link transaction on the same date.
05:25:54 <gjanssens> This lot link transaction has a second split in another lot. That second lot has a split from a 150 payment on March 7, 2014.
05:26:15 *** maschinenhans has joined #gnucash
05:27:18 <gjanssens> The lot is still open as there's a 29 (prepayment) balance.
05:27:52 <gjanssens> Note it's this 29 that should be the total outstanding prepayment for the report as well (instead of the 150 it currently marks).
05:29:41 <gjanssens> Also note this is an uncommon construction. I don't even know how to reproduce it in current gnucash.
05:30:31 <gjanssens> Normally if a document is offset and the offsetting transaction has at least one non-APAR split, no lot link transaction should be generated.
05:31:11 <gjanssens> Clearly that used to be different in earlier gnucash versions.
05:31:25 <gjanssens> So unfortunately our reports should cope with it somehow.
05:35:35 <gjanssens> How exactly to handle it can be discussed.
05:36:32 <gjanssens> As a first start Bill 000007 should appear in the report. I don't know why it gets filtered out.
05:50:02 *** sbluhm has joined #gnucash
05:55:54 <chris> the Bil 000007 is not printed because the (RHS) payments-table is null. I'll see how to decode this weird payments list, and hopefully be compatible with new ones.
06:02:52 *** sbluhm has quit IRC
06:04:04 <gjanssens> chris: how does that make it different from an unpaid bill ? Doesn't that have a null RHS payments-table as well ?
06:05:00 <gjanssens> Stated otherwise, I think it's better to print such a bill as unpaid (though it is) than not printing it at all.
06:05:23 <gjanssens> That meant to be (though it is paid)
06:06:16 <gjanssens> You already have the payment from the other end of the odd construction in the list
06:07:10 <gjanssens> If both are added (even though not linked to each other), at least the report would help users finding the exact bits that are odd (and you'd have consistent totals in the brackets below)
06:09:38 <gjanssens> Of course if you can find a way to mark them as linked that would even be better still :)
06:11:09 *** guiloma has joined #gnucash
06:14:19 *** guiloma has quit IRC
06:14:28 *** guiloma has joined #gnucash
06:19:56 *** guiloma has quit IRC
06:20:19 <chris> no it's a lot-link txn, I'll decode it later tonight and see what was wrong. may take a few hours.
06:21:02 <chris> ^ the payment is a lot-link txn and I've never debugged it thoroughly. this is the time to do it.
06:22:42 <chris> unpaid bills have null payments but the gncInvoiceIsPaid for Bill 00007 is apparently #true
06:23:31 <gjanssens> Right. Try with my previous consideration: treat lot links as payment transactions, except they don't have a non-APAR split
06:23:51 *** guiloma has joined #gnucash
06:24:21 <gjanssens> So the payment processing logic may need tweaks to handle that particularity (no non-APAR splits)
06:26:35 *** guiloma has quit IRC
06:26:47 *** guiloma has joined #gnucash
06:35:02 *** sbluhm has joined #gnucash
06:35:02 *** ChanServ sets mode: +v sbluhm
06:36:46 *** omnireq_ has quit IRC
06:37:34 *** omnireq_ has joined #gnucash
06:40:55 *** guiloma has joined #gnucash
06:49:18 *** sbluhm has quit IRC
06:58:46 *** omnireq_ has quit IRC
06:59:34 *** omnireq_ has joined #gnucash
07:19:33 *** sbluhm has joined #gnucash
07:19:33 *** ChanServ sets mode: +v sbluhm
07:23:56 *** Jimraehl1 has joined #gnucash
07:25:49 *** Jimraehl1 has quit IRC
07:28:33 *** sbluhm has quit IRC
07:31:02 *** puck has quit IRC
07:39:39 *** puck has joined #gnucash
07:44:08 *** puck has quit IRC
07:46:21 *** puck has joined #gnucash
07:47:19 *** daudi has quit IRC
07:49:30 *** puck has quit IRC
07:51:44 *** puck has joined #gnucash
07:52:11 <chris> gjanssens: the Bill 00007 lot-link txn is unusual because it has a lot whereby gncInvoiceGetInvoiceFromLot is Null
08:06:06 <gjanssens> chris: indeed. Which makes it more like a payment
08:06:37 <gjanssens> You can create a payment via Process Payment and then a refund to cancel that payment without ever involving a bill
08:07:21 <gjanssens> Though I'd have to re-check if that would even create a lot...
08:08:35 <gjanssens> Yes, it does
08:10:47 <gjanssens> And it looks like the report currently fails to handle that scenario as well.
08:11:26 <gjanssens> https://i.imgur.com/MvE2AVp.png
08:11:48 <chris> it's the lot-split->posting-split that's flawed then
08:11:57 <gjanssens> The 120 payment is not linked to the 120 refund in your report though they are in the lots
08:13:15 *** Han_ has joined #gnucash
08:13:21 <chris> the purpose of this function is to find the 'opening split'
08:15:44 <gjanssens> In the lot viewer the "opening" split is the oldest in the list. I don't think that's what you want in all cases.
08:15:50 <gjanssens> Let's think this through
08:16:21 <gjanssens> If the lot has an invoice, the invoice's split is probably the best 'opening' split to consider
08:16:26 <gjanssens> That's what you had until now
08:17:08 <gjanssens> That 'opening' split, how will you process it further ?
08:18:00 <gjanssens> Is it used to make the LHS display list unique ?
08:18:58 <gjanssens> Well, to remove doubles from the LHS list for display. I don't know how to express this exactly.
08:19:07 <chris> no, it's to find INV<->CN corresponding document details
08:19:25 <chris> e.g. LHS=INV, RHS=CN. RHS wants to know the CN posting split.
08:20:06 <gjanssens> So lot-split->posting-split is used RHS only ?
08:21:04 <chris> for now, also used LHS=payment RHS=Document
08:21:49 <gjanssens> How do you determine RHS=Document ?
08:23:17 <gjanssens> Perhaps you can walk me through the report logic highlevel to bring me up to speed.
08:23:41 <gjanssens> I presume you start with generating a LHS list of transactions to display.
08:23:42 <chris> for LHS=payment, see payment-txn->overpayment-and-invoices -- payment gets all APAR-splits, each APAR->split->lot->invoice is accumulated into a list
08:24:39 <gjanssens> Ok let me look at that function
08:26:21 <chris> this function takes a payment transaction, and returns a list: (list OVERPAYMENT INV1 INV2 INV3 ...), OVERPAYMENT is a number, INVn are invoice objects
08:27:24 <gjanssens> It think that part may be flawed actually
08:27:52 <gjanssens> Besides overpayments or invoice offsets, there can also be refund offsets
08:28:03 <chris> yeah I never knew about these
08:28:25 <gjanssens> Unless I misunderstand your interpretation of overpayment of course.
08:28:51 <chris> nopes, overpayment is defined by any APAR split where the invoice can't be found.
08:28:56 <chris> ^ for now
08:29:10 <gjanssens> There's quite a bit behind the business features don't you think ;p
08:29:35 <gjanssens> I have a simple book for you if you like that has such payment with refund
08:29:53 <gjanssens> It's an extended version of the 797596 bug sample.
08:29:53 <chris> I managed to make one.
08:30:00 <gjanssens> Ok
08:30:01 <chris> What should the RHS show?
08:30:14 <chris> I guess the opposing payment/refund
08:30:17 <gjanssens> For the payment ? The matching refund.
08:30:23 <gjanssens> So yes
08:30:42 *** maschinenhans has quit IRC
08:31:58 <chris> how to distinguish between a prepayment and an opposing refund?
08:32:35 <gjanssens> Good question
08:33:08 <gjanssens> Probably by examining the other split's lot.
08:33:35 <gjanssens> If it has opposing splits, it's an opposing refund, if it doesn't it's a prepayment
08:34:59 <chris> (aside, the lot-split->posting-split is still flawed.... an idea is to find split->lot->splitlist, and find the ONE split which has an opposing sign :P
08:36:36 <gjanssens> Assuming there is only ONE split...
08:39:18 <chris> according to gnc-lot.h lots are designed like that
08:40:06 <gjanssens> I can't tell as I'm having trouble determining the exact context in which this function is called
08:40:58 <gjanssens> What do you start from ? A payment split and the lot it's part of ?
08:41:17 <chris> like this: https://pastebin.com/QerS9Edj always starting from a payment-split
08:41:29 <gjanssens> And it's always a payment split you pass ? Or can it also be a lotlink split (which is the same as far as I'm concerned)
08:42:04 <chris> oh a lotlink split sorry yes
08:42:39 <gjanssens> Here's your counter example: 1 payment offset by two refunds, or two payments offset by one refund
08:42:50 <gjanssens> Will that also end up in that function at some point ?
08:43:01 <chris> oh my lord.
08:43:16 <chris> being summoned again :)
08:43:22 <gjanssens> NP :)
08:48:40 *** daudi has joined #gnucash
08:58:16 <gjanssens> chris: for when you continue - https://bugs.gnucash.org/attachment.cgi?id=373555 collects several cases mentioned earlier today in this chat
08:58:59 <gjanssens> The only one I can't reproduce is the lot link that's not linking two invoice lots any more (from my private test book).
09:30:25 *** sbluhm has joined #gnucash
09:30:26 *** ChanServ sets mode: +v sbluhm
09:54:10 *** fell_laptop has quit IRC
09:54:17 *** fell_laptop has joined #gnucash
09:54:17 *** ChanServ sets mode: +o fell_laptop
09:55:49 *** fell_laptop is now known as fell
09:57:45 <chris> So: to detect payment<->refund matching, would it be safe to assume that the lot is closed?
09:57:59 <chris> this would match N payments matching M refunds too
10:01:30 *** mauritslamers has quit IRC
10:02:23 *** mauritslamers has joined #gnucash
10:02:23 *** ChanServ sets mode: +v mauritslamers
10:02:40 *** sbluhm has quit IRC
10:10:34 <gjanssens> chris: probably not :(
10:11:05 <gjanssens> That is, if you only use the Process Payment dialog, then yes, that assumption would hold
10:11:49 <gjanssens> However as with the multi-non-APAR split payments, it can be manipulated in ways it would not be closed
10:13:52 <gjanssens> Here's a use case: suppose you had a customer that pre-paid you say $110. For whatever reason the deal didn't go through and you decide to refund.
10:14:08 *** Aussie_matt has joined #gnucash
10:14:25 <gjanssens> You wire the money and apply the refund in your book.
10:14:58 <gjanssens> So now the payment and fully paid by the refund, the lot is closed.
10:15:24 <gjanssens> Then you get your bank statement and notice you mistyped and wired only $100 to the customer.
10:15:33 *** Aussie_matt has quit IRC
10:16:11 <gjanssens> So you make a correction in your books: open the checking register and lower the refund from $110 to $100
10:16:42 <gjanssens> Now the lot is no longer closed, but it has a payment and a refund.
10:16:54 <gjanssens> Do you consider this a pre-payment ?
10:17:32 <gjanssens> Only the $10 difference of that lot really is pre-payment/overpayment.
10:18:09 <gjanssens> The $100 is simply a partial payment which goes in its own row RHS
10:19:05 <gjanssens> I don't think the user in this case would possibly have imagined doing something out of the ordinary.
10:22:11 <chris> ok. looks like lot-link processor needs to call payment-processor of some sort.
10:22:52 <chris> ^ this scenario needs a dedicated book!
10:28:03 <gjanssens> The scenario I just laid out ?
10:36:41 <chris> ok just done, will review. a sample report output would still be very welcome.
10:37:11 <chris> ok night here.
10:38:11 <chris> or even a complicated payment to invoice + refund + credit-note + overpayment, and the overpayment modified afterwards...
10:40:58 *** sbluhm has joined #gnucash
10:40:58 *** ChanServ sets mode: +v sbluhm
10:41:39 *** jralls_ has joined #gnucash
10:42:28 *** jralls has quit IRC
11:52:13 *** sbluhm has quit IRC
11:53:17 *** Gerd has joined #gnucash
12:29:45 *** User__ has quit IRC
12:36:24 *** oozer has joined #gnucash
12:39:22 *** sbluhm has joined #gnucash
12:39:22 *** ChanServ sets mode: +v sbluhm
12:46:23 *** gjanssens has quit IRC
12:51:44 *** maschinenhans has joined #gnucash
12:55:51 *** sbluhm has quit IRC
12:57:36 *** khobo has joined #gnucash
12:57:37 <khobo> yoyo!
12:57:42 <khobo> how's everyone's weekend going
13:04:16 *** sbluhm has joined #gnucash
13:04:17 *** ChanServ sets mode: +v sbluhm
13:18:31 *** sbluhm has quit IRC
13:46:31 <warlord> thanks, chris
13:46:58 *** Gerd has quit IRC
13:58:39 *** sbluhm has joined #gnucash
13:58:39 *** ChanServ sets mode: +v sbluhm
14:35:10 *** oozer has quit IRC
15:42:38 *** jralls_ is now known as jralls
15:42:42 *** ChanServ sets mode: +o jralls
15:56:56 *** Unhammer has quit IRC
16:07:08 *** dellie__ has quit IRC
16:10:21 *** jervin has joined #gnucash
16:15:22 *** Unhammer has joined #gnucash
16:15:23 *** ChanServ sets mode: +v Unhammer
16:17:46 *** jimc has joined #gnucash
16:19:07 *** jimc has quit IRC
16:21:36 *** maschinenhans has quit IRC
16:23:13 *** vectorizer has joined #gnucash
16:52:53 *** oozer has joined #gnucash
16:53:47 *** Mechtilde has quit IRC
17:23:59 *** vectorizer has quit IRC
17:41:26 *** daudi has quit IRC
17:45:57 <chris> @tell gjanssens So(bis): to detect payment<->refund matching, would it be safe to assume that the lot has more than 1 split?
17:45:57 <gncbot> chris: The operation succeeded.
18:20:55 *** vectorizer has joined #gnucash
18:33:54 *** sbluhm has quit IRC
18:37:12 *** delli3 has joined #gnucash
18:39:16 *** vectorizer has quit IRC
19:29:10 *** delli3 has quit IRC
19:42:37 <CDB-Man> chris: https://bugs.gnucash.org/show_bug.cgi?id=797572#c11 sorry for late response, just saw your comments now on this and i will download the latest nightly and take a look and comment bavk
19:42:51 *** oozer has quit IRC
19:55:38 <chris> CDB-Man: yw. I've pushed some further work to add some interactivity. there's still unfinished work esp lot-link handling.
19:55:54 <chris> so, test today's build, and tomorrow's build for some more goodies :)
20:38:30 <CDB-Man> chris: will do, just finished downloading gnucash-3.8-2020-01-25-git-3.8b-89-ga9d51dd9e+.setup.exe
20:38:36 <CDB-Man> er.... or not
20:38:45 <CDB-Man> apparently my router running at 1/8 of normal speed...
20:40:31 <CDB-Man> its downloading at 40KB/s
20:40:38 <CDB-Man> just me or someone else also seeing this?
20:54:29 <chris> bit slow now
21:12:25 *** jervin has quit IRC
21:46:15 *** khobo has quit IRC
21:58:07 *** TownsendHardware has quit IRC
22:07:40 *** Gerd has joined #gnucash
22:12:43 *** Gerd1 has joined #gnucash
22:13:40 *** Gerd has quit IRC
22:13:40 *** Gerd1 is now known as Gerd
22:14:46 <chris> bit slow now
22:30:10 *** Gerd has quit IRC
22:33:13 <CDB-Man> finally finished downloading, lets test it out
22:40:46 *** omnireq_ has quit IRC
22:41:34 *** omnireq_ has joined #gnucash
22:53:06 *** jralls_ has joined #gnucash
22:53:34 *** Gerd has joined #gnucash
22:53:47 *** jralls has quit IRC
23:02:46 *** jervin has joined #gnucash
23:02:46 *** omnireq_ has quit IRC
23:02:57 *** omnireq_ has joined #gnucash
23:03:23 *** delli3 has joined #gnucash
23:03:39 *** jervin has quit IRC
23:09:20 *** jervin has joined #gnucash
23:09:50 <CDB-Man> chris: replied, thank you
23:10:00 *** jervin has quit IRC
23:10:10 *** jervin has joined #gnucash
23:13:59 *** jervin has quit IRC
23:14:45 *** jervin has joined #gnucash
23:24:16 *** omnireq_ has quit IRC
23:24:27 *** omnireq_ has joined #gnucash
23:30:06 *** christopher has joined #gnucash
23:30:45 *** christopher is now known as crparis
23:30:49 *** Gerd has quit IRC
23:52:14 *** Gerd has joined #gnucash