2018-09-14 GnuCash IRC logs
00:06:02 *** Mechtilde has joined #gnucash
00:09:06 *** Mechtilde has quit IRC
00:17:48 *** CDB-Away_ has joined #gnucash
00:18:07 *** CDB-Away has quit IRC
00:22:49 *** Mechtilde has joined #gnucash
00:25:53 *** Mechtilde has quit IRC
00:37:05 *** Mechtilde has joined #gnucash
01:43:18 *** Mechtilde has quit IRC
01:43:48 *** fell has quit IRC
01:44:38 *** fell has joined #gnucash
02:00:24 *** fell has quit IRC
02:07:38 *** fell has joined #gnucash
02:10:16 *** gncbot sets mode: +o fell
02:23:07 *** fekepp has joined #gnucash
02:40:08 *** gjanssens has joined #gnucash
02:40:09 *** ChanServ sets mode: +o gjanssens
02:59:21 *** chf has quit IRC
03:01:00 *** chf has joined #gnucash
03:09:31 <gjanssens> .
03:55:44 *** ncv has joined #gnucash
04:00:35 *** GabrieleV has joined #gnucash
04:09:10 *** Mechtilde has joined #gnucash
04:15:33 *** ncv has quit IRC
04:15:44 *** ncv has joined #gnucash
04:20:58 *** ncv has quit IRC
04:21:39 *** ncv has joined #gnucash
04:25:28 *** ncv has quit IRC
04:28:27 *** ncv has joined #gnucash
04:30:03 *** ncv has quit IRC
04:30:14 *** ncv has joined #gnucash
04:37:23 <chris> fell I re-read the bug report - it aims to add (gncOwnerGetID owner) into customer's section. this number is usually autogenerated - is it really useful to add another option into the Display tab??
04:40:37 *** Mechtilde has quit IRC
04:56:01 *** pilotauto has quit IRC
04:59:18 *** Mechtilde has joined #gnucash
05:00:53 *** bertbob has quit IRC
05:03:30 *** bertbob has joined #gnucash
05:06:37 *** bertbob has quit IRC
05:10:23 *** fell has quit IRC
05:13:01 *** fell has joined #gnucash
05:13:47 *** al has joined #gnucash
05:15:02 *** gncbot sets mode: +o fell
05:16:34 *** Mechtilde has quit IRC
05:18:14 *** boldstripe has joined #gnucash
05:22:35 *** bertbob has joined #gnucash
05:27:49 *** boldstripe has quit IRC
05:32:44 *** boldstripe has joined #gnucash
05:47:12 *** ncv has quit IRC
05:47:35 <fell> Chris, I came along it from https://bugs.gnucash.org/show_bug.cgi?id=742086 over https://bugs.gnucash.org/show_bug.cgi?id=430259. Somewhere we suggest to use the customer number.
05:48:25 *** ncv has joined #gnucash
05:48:54 *** fekepp has quit IRC
05:50:17 <chris> hmm the OWN customer-id is rendered; perhaps CUSTOMER customer-id should be printed too. do we make it a Display option, or not??
05:51:03 <fell> The first bug asks for more fields, all are related to billing. So in the Customer/Client information they belong to the billing tab.
05:51:41 <fell> and from there they should be fetched into the invoice.
05:51:41 *** fiddlerwoaroof has quit IRC
05:54:53 <chris> id think the customer's tax-id is specific to "customer" instead of "invoice" so should belong in cusotmer section
05:55:50 *** fiddlerwoaroof has joined #gnucash
05:56:40 <fell> If gjanssens orders with his VAT-ID he becomes invoiced without tax. If he forgets, he has to pay tax already here.
06:01:27 <gjanssens> chris: with "OWN" you mean owner ?
06:03:10 <fell> gjanssens, I think from file->property:Company ID
06:03:12 <chris> OWN=gnucash's book owner is currently already rendered
06:03:42 <chris> CUSTOMER's customer-id (i.e. autonumbers 0001 etc) could be added into the CUSTOMER section
06:04:53 <fell> As workaround we can overwrite that with "BExxxxxxx" oe "DExxxxxx"
06:04:59 <gjanssens> Ok, so from reading the two bug reports this is meant as a workaround for not having a proper tax id field
06:05:09 <gjanssens> fell: right
06:05:09 <fell> making it VAT IDs
06:05:17 <gjanssens> That's reasonable
06:05:27 <chris> this is how it could be done: https://imgur.com/a/ZtR5pCN
06:05:56 <chris> i.e. the client's section gets client's id too
06:07:11 <chris> notice owner (i.e. section on right) already has id rendered
06:07:19 <gjanssens> It does have drawbacks of course
06:07:43 <chris> my concerns too
06:07:51 <gjanssens> Not all customers will have a tax id so for those customers it would print the internal number
06:08:11 <gjanssens> For individual printing one could of course tweak the preview report each time
06:08:30 <gjanssens> However we also support batch printing, and there it gets more complicated.
06:08:35 *** Cork has quit IRC
06:09:20 <gjanssens> Secondly on an invoice the tax number is typically prepended with a label, something like "VAT No:" or "BTW:"
06:09:28 <fell> Numbers starting with country codes or tax ids in EU, but other countries?
06:09:35 <gjanssens> This can obviously not be coded
06:10:00 <gjanssens> So users will also have to enter this label each time in the customer's id field
06:10:46 <gjanssens> in Germany it would be "UStID"
06:10:52 <fell> yep
06:12:24 *** chf has quit IRC
06:14:22 *** chf has joined #gnucash
06:15:12 <gjanssens> fell: the alternative was hinted at in one of the bug reports: use one of the address lines to store the VAT/Tax number
06:15:44 <gjanssens> Visually it would have the same net effect as the screenshot chris posted
06:16:45 <fell> But on long term it should be on the billing tab before the taxtable, which depends from it.
06:16:51 *** Pupeno has quit IRC
06:19:14 <chris> fell - are you talking about the "Billing ID" field in the invoice-details? this is already rendered
06:20:08 <fell> No, edit/New Customer dialog, tab "Billing information"
06:21:13 <fell> Menu Business Customer, New Customer
06:21:55 <fell> same for vendor
06:22:40 <chris> but there's no "VAT Number" field there
06:23:22 <fell> But there the tab is named "Payment Information"
06:23:37 <fell> (should be unified)
06:24:35 *** oozer has joined #gnucash
06:25:09 <chris> please send screenshot:)
06:25:43 <gjanssens> fell: I agree on the New/Edit customer tabs. That is however not a job for our current guile expert ;)
06:26:22 <gjanssens> Adding these formal fields also involved data model changes, so these can only happen in major releases
06:27:06 <gjanssens> For completeness, regardless of whether the tax ID should go in address or not for now, it would make sense to allow the customer ID to be displayed in invoices.
06:27:53 <gjanssens> This happens quite frequently here to have both a tax Id and a customer number. This customer number is often used in notes on bank payments
06:28:45 <fell> gjanssens, can you put the notes on the bug, so we do not forget them?
06:30:21 <chris> so, conclusion for now, new-invoice stays put?
06:33:01 <gjanssens> chris: what does "new-invoice" refer to ? Does that have the option to display customer number or not ?
06:34:18 *** Jimraehl1 has joined #gnucash
06:35:59 <chris> new-invoice means the current super css-enabled invoice.scm which also does easy-invoice and fancy-invoice
06:36:04 <chris> merged in a few days ago
06:40:11 *** Mechtilde has joined #gnucash
06:41:18 <chris> it doesn't currently display the customer-id for now. it could be added, and could be toggled either via "display" option or css
06:42:07 <fell> I would prefer display options. Not all users speak CSS.
06:42:31 <gjanssens> For now that's probably the best solution still.
06:43:29 *** Jimraehl1 has left #gnucash
06:46:58 <chris> i'd vote to leave it disabled by default
06:47:25 <gjanssens> chris: that's ok
06:47:31 <gjanssens> fell: comments added
06:47:40 <fell> thx
06:51:57 <chris> I'm not sure how to name it - "customer ID" "vendor ID" or "client ID" - what's the common terminology for all uses of invoice which can display customer/vendor/job report?
06:52:43 <fell> Owner intern
06:54:41 <fell> Owner means it can be a vendor, customer or employee, which is related to the document.
06:55:03 <fell> So I would name it Onwer Id
06:55:14 <chris> I think from an end user I'd get confused :)
06:55:33 <chris> because as the Gnucash user, *I* am the owner :-D
06:55:38 <fell> Partners id?
06:57:44 <chris> or the generic and versatile "Customer/Vendor ID"
06:58:01 <chris> (btw I've just opened "New Employee" window for the first time... oh my so many fields)
06:59:18 <fell> The GUI editor might have seen SQLedger before.
06:59:30 *** mtemmerm has joined #gnucash
07:04:49 <fell> Hi, mtemmerm
07:08:03 <chris> next question -> i guess customer/vendor invoice prints "customer/vendor id" and job invoice prints "job's owner's id"
07:09:33 <fell> I know nothing about job invoice. Do we have that?
07:10:22 <chris> yes customers/vendors can have jobs
07:14:25 <chris> I'll call it "Client ID" to match the option in the "Layout" tab
07:16:01 *** Cork has joined #gnucash
07:17:11 *** fell has quit IRC
07:29:44 *** fell has joined #gnucash
07:29:44 *** gncbot sets mode: +o fell
07:35:42 *** boldstripe has quit IRC
07:36:22 <fell> I think, that is OK, chris.
07:36:45 *** boldstripe has joined #gnucash
07:46:42 <chris> fwiw i still am not convinced this information is useful, but here you go, it's piggybacked onto #411
07:49:28 <gjanssens> chris: I gave you a real use case :) I don't know how much more useful it could be
07:49:52 <gjanssens> But thanks for implementing it
07:51:57 <fell> All checks have failed
07:52:25 <chris> sugar
07:52:56 <gjanssens> chris: I was afk while you discussed the name of the field.
07:53:27 <gjanssens> I didn't realize your new-invoice referred to "Clients" exclusively in the layout tab.
07:53:47 <gjanssens> Which is confusing in case the user wishes to print a vendor invoice.
07:54:17 <gjanssens> Frankly I don't know why one would do that it has always been possible
07:54:32 <gjanssens> So I do prefer a more universal name
07:55:10 <gjanssens> Customer/Vendor is a bit cumbersome, but I think Partner is sufficiently neutral
07:55:25 <fell> I like Partner, too.
07:55:34 * chris likes "Own" vs "Other"
07:56:31 <chris> to me partner sounds like "My business partner"
07:56:32 <fell> or the long form Business partner where more space is.
07:57:07 <gjanssens> chris: that's what it's supposed to sound like :)
07:57:38 <gjanssens> "Other" feels ambiguous to me. It can also mean "still from my company but other info"
07:57:53 <chris> difference of opinions :-o
07:57:59 <fell> Geschäftsfreunde in German
07:58:24 <gjanssens> Isn't a customer or a vendor not a business partner where you live ?
07:58:25 <chris> or, simply "My details" "Their details"
07:59:06 <chris> in anglo countries, business partner means my business associates, i.e. the co-owners, the shareholders, the people I consult in a business team meeting
07:59:34 <gjanssens> Aah, right.
07:59:36 <chris> customers/vendors don't take part in business team meetings unless we're trying to extract more money from them
08:00:22 <chris> so, the least confusing terms would be "Our details" "Their details"
08:01:45 <gjanssens> Still sounds very informal to me, but for now this is probably the best we can do.
08:02:16 <gjanssens> The issue is probably deeper in that the report is trying to do too much under one flag
08:02:44 <fell> (we could every month start a user survey for best terms)
08:03:08 <gjanssens> I would consider splitting the menu items in the report menu already in Vendor invoice, Customer invoice and Employee voucher
08:03:50 <gjanssens> Internally they'd be based on the same single report code, but with a few terms adjusted and restricting the list of viewable objects
08:04:19 <gjanssens> It would match how the other business objects are split up.
08:05:30 <fell> But as translator, I had the feeling, we got too much redundancies.
08:06:35 <gjanssens> fell: this decision should not be based on translator work, but on end user experience
08:07:09 <gjanssens> It doesn't require many more strings per se. With some luck we can simply reuse existing strings
08:07:30 <gjanssens> We already use separate terms in other locations
08:07:42 <gjanssens> It's mostly a matter of consistency
08:07:57 <gjanssens> Note I don't expect this to happen right now.
08:10:30 <chris> still, back to string, I think I'd code as "Display" "Invoice owner ID", at least it's unambiguous for now, and allow users to experiment and discover it incorporates vendor/customer/job-owner ID
08:12:32 <gjanssens> Ok, that's close enough.
08:14:30 <chris> I've renamed layout elements to "Our details" "Their details" too, hope this is satisfactory?
08:14:53 <chris> oops need to make these strings translatable
08:20:38 <gjanssens> Yes, that's fine at this point.
08:49:37 *** fabior has joined #gnucash
09:17:38 <warlord> .
09:33:09 *** chris has quit IRC
09:34:03 *** storyjesse has joined #gnucash
09:34:11 *** mtemmerm has quit IRC
09:34:18 *** fell has quit IRC
09:34:25 *** fell has joined #gnucash
09:34:25 *** gncbot sets mode: +o fell
09:36:25 *** boldstripe has quit IRC
09:37:23 *** boldstripe has joined #gnucash
09:49:51 *** btr has joined #gnucash
09:51:24 *** btr has quit IRC
09:56:42 *** storyjesse has quit IRC
10:04:47 *** storyjesse has joined #gnucash
10:40:51 *** O01eg has quit IRC
10:51:27 *** Mechtilde has quit IRC
10:54:44 *** O01eg has joined #gnucash
10:59:45 *** boldstripe has quit IRC
11:09:25 *** storyjesse has quit IRC
11:14:27 *** kael has joined #gnucash
11:41:55 *** al has quit IRC
11:48:02 *** fabior has quit IRC
12:20:50 *** fabior has joined #gnucash
12:22:05 *** Mechtilde has joined #gnucash
12:27:48 *** JayC has quit IRC
12:28:08 *** JayC has joined #gnucash
13:09:49 *** fabior has quit IRC
13:11:05 *** fabior has joined #gnucash
13:12:24 *** fabior has quit IRC
13:13:31 *** fabior has joined #gnucash
13:16:23 *** fabior has quit IRC
13:29:25 *** calvinct has joined #gnucash
13:32:00 *** calvinct has quit IRC
13:34:27 *** fell has quit IRC
13:34:49 *** ncv has quit IRC
13:56:43 *** calvinct has joined #gnucash
13:57:05 <gjanssens> jralls: I'm currently waiting for Monster DB™ to load after changing the load order (forcing Transactions to load before business objects)
13:58:02 <gjanssens> The sql log spewed lots of sql queries for the first minute, but now it has been silent for more than 20 minutes
13:58:55 <gjanssens> The last queries were for lots of slots after querying the transaction table
13:59:06 <gjanssens> So I assume these are all transaction related slots
13:59:34 <gjanssens> While waiting I have briefly attached sysprof to the running process (about 20 seconds)
14:01:04 <gjanssens> I found 94% of these 20 seconds were spend running xaccAccountRecomputeBalance which eventually spends most of its time in the internals of GncInt128 running sums, multiplications and so on
14:02:12 *** calvinct has quit IRC
14:02:13 <gjanssens> I profiled a full run earlier (without the Transaction prioritization -- is that a word?) and saw similar results: 8% was spent in GncInt128
14:02:57 <gjanssens> Unfortunately I can't provide more details of that run any more. Apparently sysprof's profile data becomes useless when the related binaries change.
14:03:15 <gjanssens> And I did a rebuild since that full profile run...
14:05:42 <gjanssens> I wonder if the sql backend is doing account balance recomputation too early/too often...
14:06:37 <gjanssens> Did another sample, now 10 mins later and it's still 94% recomputing balances...
14:08:52 *** greenshoe has joined #gnucash
14:11:40 <gjanssens> All of this of course happens on one cpu core as gnucash is still single threaded...
14:12:03 * gjanssens doesn't know anything about multi-threading, but wonders if it would make sense for a future gnucash
14:22:45 <gjanssens> Another sample at 45 mins loading -> 92% recalculating account balances
14:29:14 <gjanssens> Ah, after 53 minutes of heavy calculation, db loading suddenly continued with loading bill terms
14:29:40 <gjanssens> It took gnucash only 15 seconds more to go to complete UI from that point.
14:30:12 <gjanssens> So I think it's safe to conclude it's not the slot loading itself that's hogging down db loading
14:30:41 <gjanssens> It looks like we're doing way too many account balance recomputations while parsing the transaction data.
14:33:40 *** frakturfreak has joined #gnucash
14:45:03 *** Mechtilde has quit IRC
15:31:52 *** greenshoe has quit IRC
15:33:38 *** greenshoe has joined #gnucash
15:36:39 *** greenshoe has quit IRC
15:53:11 *** boldstripe has joined #gnucash
15:53:43 <gjanssens> For comparison, loading the same book from xml, only 0,29% of the time is spent in xaccAccountRecomputeBalance
15:54:02 <gjanssens> (It also only takes about 2 minutes)
15:54:45 <gjanssens> Most of the time in that scenario is spent in checked_char_cast
15:56:28 *** greenshoe has joined #gnucash
16:01:34 *** O01eg has quit IRC
16:01:55 *** O01eg has joined #gnucash
16:02:22 *** boldstripe_ has joined #gnucash
16:02:33 *** greenshoe has quit IRC
16:02:36 *** boldstripe has quit IRC
16:02:36 *** boldstripe_ is now known as boldstripe
16:02:54 *** greenshoe has joined #gnucash
16:05:54 *** greenshoe has quit IRC
16:06:23 <gjanssens> Hmm, perhaps wrapping transaction/split loading in a xaccAccountBeginEdit/xaccAccountCommitEdit may defer calculations until all splits are loaded.
16:06:38 <gjanssens> We may have to sort splits on account or something.
16:07:19 <gjanssens> I haven't investigated the nitty gritty details yet and it's getting late here so the brain is getting a bit foggy :)
16:08:07 <gjanssens> Hopefully there are some good pointers in my findings that can help you figure it out, jralls
16:08:15 *** boldstripe has quit IRC
16:15:44 *** gjanssens has quit IRC
16:19:20 *** boldstripe has joined #gnucash
16:25:23 *** greenshoe has joined #gnucash
16:42:29 *** warlord has quit IRC
16:43:14 *** warlord has joined #gnucash
17:10:30 *** boldstripe has quit IRC
17:36:24 *** greenshoe has quit IRC
17:38:12 *** greenshoe has joined #gnucash
17:43:14 *** greenshoe has quit IRC
18:00:57 *** Robert847 has joined #gnucash
18:04:25 <Robert847> hi While I happen to be using release 2.6.19 or so, I think my problem is still current. I opened a general ledger view then I searched for transactions containing certain text in the description. This left the results in the general ledger view. How do I return to th the general ldeger view before the search?
18:15:16 *** frakturfreak has quit IRC
18:20:32 <jralls> @tell gjanssens Sorry, I didn't intend to be AFK all day, but had a plumbing leak that i needed to do a temp repair on.
18:20:32 <gncbot> jralls: The operation succeeded.
18:21:56 <jralls> @tell gjanssens Interesting about xaccAccountRecomputeBalance. I'll have a look at the XML backend to see what it does to avoid that.
18:21:56 <gncbot> jralls: The operation succeeded.
18:25:19 <jralls> Robert847: Search results are always in Transaction Ledger view because they don't necessarily have a "home" account.
18:38:53 <Robert847> now I cannot get back to the unsearched ledger view because the seach did not put the results into a 'new' search results view like it does when starting a search in a regular register view or the coa view
18:44:30 <jralls> How did you get it to do that?
18:44:52 <jralls> It creates a new register for me.
18:45:43 <Robert847> that is what I am asking. I was in a general ledger view and I started wth ctrl-F
18:48:36 <Robert847> I see that the search box has the refine current search button selectetd
18:49:11 <Robert847> is that the default? I did not touch it today
18:52:25 <Robert847> if it is not, the button to clear the current search results should clear the results, but if I try that I get a message that I need to enter search text
18:56:19 <jralls> Ah, you started from General Journal/Ledger. That does indeed reuse the same tab. Ticking "start a new search" doesn't seem to matter, though it might if you had already done one search and added more conditions.
18:57:00 <jralls> To get back to a full journal, change contains to matches regex and enter .* for the regex.
18:58:15 <jralls> And check "add results to current search" in the search type radio box.
19:00:25 <Robert847> that worked.
19:02:14 <Robert847> it is hardly obvious. I am waiting for help to appear to see what it eays
19:04:50 <Robert847> help is not appearing
19:11:47 <Robert847> looking at the online manual Chapter 8 section 8.1 the manual does not cover starting from the General Ledger window and the criteria relating to regex help is unhelpful
19:13:24 <Robert847> That must be why David T is trying to work on it
19:15:29 *** O01eg has quit IRC
19:36:10 *** calvinct has joined #gnucash
20:25:06 *** greenshoe has joined #gnucash
20:33:16 *** greenshoe has quit IRC
20:34:05 *** greenshoe has joined #gnucash
20:37:05 *** greenshoe has quit IRC
20:42:44 *** calvinct has quit IRC
20:48:20 *** pilotauto has joined #gnucash
21:14:08 *** storyjesse has joined #gnucash
21:30:37 *** oozer has quit IRC
22:20:09 *** fell has joined #gnucash
22:55:11 *** pilotauto has quit IRC
22:58:37 *** pilotauto has joined #gnucash
23:36:10 *** kael has quit IRC