2020-04-30 GnuCash IRC logs
07:52:40 *** gncbot has joined #gnucash
07:52:45 *** warlord sets mode: +o gncbot
07:53:54 <chris> warlord knows: every decision made will be questioned, every reasonable assumption will be debated, every design constraint will be argued ad nauseam
07:54:12 <warlord> Sorry, chris, what did I miss?
07:54:47 <warlord> My network has been bouncing all night (for whatever reason)
07:57:43 <chris> users always wish to push boundaries
08:00:04 *** FH_thecat has joined #gnucash
08:01:14 <FH_thecat> when using the mysql backend for Gnucash, does it also support the encrypted / tls connections ?
08:06:16 *** FH_thecat has quit IRC
08:06:25 *** FH_thecat has joined #gnucash
08:41:35 *** gncbot` has joined #gnucash
08:43:39 *** gncbot has quit IRC
08:43:39 *** tonysoar has joined #gnucash
08:45:32 *** gncbot has joined #gnucash
09:16:46 *** gncbot has joined #gnucash
09:22:33 *** sbluhm has quit IRC
09:26:37 *** FH_thecat has quit IRC
09:28:04 *** phoenix has quit IRC
09:30:16 <chris> jralls: I suppose now is a good time to upgrade income-gst-statement.scm in master?
10:00:28 *** tonysoar has quit IRC
10:09:57 *** warlord sets mode: +o gncbot
10:10:42 <warlord> Okay... Moved my AT&T gateway out of the way of my network. Next I just need to get my switch installed to re-enable SIP... And then I should be good to go with a clean network.
10:15:42 *** storyjesse has quit IRC
10:30:53 *** lcanaska has joined #gnucash
10:48:02 *** fell_laptop is now known as fell
11:33:57 *** angel has joined #gnucash
11:37:10 *** guak has joined #gnucash
11:59:06 *** sbluhm has joined #gnucash
11:59:07 *** ChanServ sets mode: +v sbluhm
12:00:23 *** Cuare has joined #gnucash
12:00:23 *** ChanServ sets mode: +v Cuare
12:00:23 *** lcanaska has quit IRC
12:13:34 *** codesmythe has joined #gnucash
12:13:34 *** ChanServ sets mode: +v codesmythe
12:21:32 <gjanssens> fell: I fixed the default settings on the initializing documentation build environment page. That was a copy/paste error on my behalf
12:23:07 <warlord> gjanssens, fyi, flatpak master built but maint failed last night.
12:24:17 <gjanssens> tx warlord
12:24:43 <warlord> NOte that it is possible it was a network issue..
12:24:49 <warlord> I didn't look at the build logs.
12:25:45 <gjanssens> There is no build log uploaded so probably it was a network issue indeed
12:26:02 <gjanssens> (well the start of build was uploaded, but it wasn't moved/updated when the build failed)
12:26:27 <warlord> Let's see if it fails tonight.
12:27:06 *** lcanaska has joined #gnucash
12:28:16 *** jervin has joined #gnucash
12:31:07 <gjanssens> Ok
12:43:39 <jralls> chris, You have until May 31 to get in whatever last features you can.
12:45:02 *** angel has quit IRC
12:45:25 *** jervin has quit IRC
12:51:53 *** Hussam[m] has joined #gnucash
12:55:36 *** lcanaska has quit IRC
13:13:44 *** angel has joined #gnucash
13:14:16 *** PowaBanga has quit IRC
13:15:05 *** PowaBanga has joined #gnucash
13:18:40 *** jervin has joined #gnucash
13:20:13 <jralls> gjanssens, have you noticed the Working with dates in PostgresqlDB thread on gnucash-user?
13:20:30 *** jervin has quit IRC
13:21:37 <gjanssens> jralls: I have not followed it. Is there something I should look at ?
13:22:40 <jralls> The correspondent has discovered that when Invoice creates a transaction it sets the posted time to local midnight instead of normalized time.
13:23:38 <gjanssens> Ok, I can't imagine a good use case for that
13:23:49 <gjanssens> So probably one more date inconsistency to clean up
13:24:14 <jralls> That's easy enough to fix, just change the call from xaccTransSetDatePostedSecs to xaccTransSetDatePostedSecsNormalized. But the next line sets the Invoice posted date. Does that need to match the time of the transaction's posted date?
13:25:06 <gjanssens> Hmm, no idea. I think that code existed before I worked on it. warlord ?
13:25:18 <gjanssens> I'd set it to the same for consistency
13:25:30 <gjanssens> Don't know if any code would depend on it
13:25:50 <jralls> All it takes is one comparison somewhere.
13:26:04 <gjanssens> True
13:27:05 <gjanssens> I don't know of such a comparison. To my mind all links between transaction and invoice is via the invoice guid in a transaction kvp
13:28:02 <gjanssens> s/is/happen/
13:28:19 <jralls> But as you say it's probably best just for consistency. Plus, of course, having invoice dates at local midnight mean that they shift when you change time zones.
13:29:05 *** sbluhm has quit IRC
13:30:40 <warlord> I dont think anything depends on it being the same.. But probably should be.
13:30:57 <jralls> We should probably concoct a Julian Number Date and just use that instead of time64 except in the very few places where we care about time.
13:31:26 <gjanssens> That would simplify a lot
13:31:40 <jralls> It would indeed.
13:36:12 *** phoenix has joined #gnucash
13:37:31 <warlord> I do believe we use seconds for closing transactions.
13:37:45 <warlord> .. to ensure it is the last transaction of the "last day"
13:39:31 <jralls> I hope it's only a few seconds so that it doesn't change days with TZ shifts.
13:40:46 <jralls> But closing txns are flagged with a KVP tag. We could use that to force the split to sort at the end instead.
13:40:49 *** sbluhm has joined #gnucash
13:41:00 <warlord> It's +1s
13:41:11 <warlord> or at least it was when I wrote the code.
13:42:05 <jralls> That's fine, 10:59:01Z instead of 10:59:00Z; it will always be in the same date.
13:42:12 *** suukim has joined #gnucash
13:45:24 *** Han has joined #gnucash
13:45:26 *** Han_ has joined #gnucash
13:47:01 *** Han has quit IRC
13:47:17 *** Han_ has quit IRC
14:04:39 *** CDB-Man_ has joined #gnucash
14:04:39 *** ChanServ sets mode: +v CDB-Man_
14:04:54 *** CDB-Man has quit IRC
14:06:04 *** keiffer has joined #gnucash
14:23:04 <gjanssens> warlord, jralls: the +1 s was the initial implementation, it has been amended with the kvp tag as jralls points out
14:23:14 <gjanssens> All tests nowadays happen based on that flag
14:23:38 *** jervin has joined #gnucash
14:23:43 <jralls> gjanssens, including sorting the splits in the register?
14:25:25 <gjanssens> Good question... Probably not
14:25:45 <gjanssens> I was more thinking of filtering in reports
14:26:58 <warlord> We need to ensure register (and balance computation) also use htat.
14:27:49 <jralls> I remember chris went through the reports last year with that in mind. IIRC he had to look at both because the KVP tags didn't start until 2010 or so.
14:29:59 <gjanssens> As I remember it he dropped the extra date check exactly because it has been introduce so long ago and that it would be easy for the user to redo the closing transaction in case the reports don't show right for older years
14:32:24 *** suukim has quit IRC
14:38:10 <jralls> xaccTransOrder does sort on xaccTransGetIsClosingTxn, so the post_date timestamp doesn't matter.
14:39:29 *** frakturfreak has joined #gnucash
14:39:29 *** ChanServ sets mode: +v frakturfreak
14:39:42 <gjanssens> Yay
15:00:38 *** PowaBanga has quit IRC
15:00:49 *** jervin has quit IRC
15:24:36 *** PowaBanga has joined #gnucash
15:26:53 *** gjanssens has quit IRC
15:48:41 *** lcanaska has joined #gnucash
16:09:03 *** User has quit IRC
16:09:23 *** oozer has joined #gnucash
16:28:25 *** omnireq_ has quit IRC
16:29:12 *** omnireq has joined #gnucash
16:29:12 *** ChanServ sets mode: +v omnireq
16:31:47 <warlord> YAY
17:00:18 *** sbluhm has quit IRC
17:12:11 *** lmat has joined #gnucash
17:21:39 *** keiffer has quit IRC
17:39:11 *** pohly has quit IRC
17:45:14 *** giuseppef has joined #gnucash
17:46:36 *** ChanServ sets mode: +v giuseppef
17:49:10 <giuseppef> Hi, is there a way, with phyton bindings, to get a Customer number (not ID)? Thanks
18:36:47 <Trel> Wanted to follow up from yesterday. If I export LD_LIBRARY_PATH, the maintenance branch builds successfully now
18:37:02 <Trel> (without any other changes)
18:37:55 *** omnireq has quit IRC
18:40:17 *** omnireq has joined #gnucash
18:40:17 *** ChanServ sets mode: +v omnireq
18:40:42 *** bertbob has quit IRC
18:40:55 <jralls> Trel: Thanks for following up.
18:42:00 <Trel> Yup, least I could do :)
18:42:33 *** bertbob has joined #gnucash
18:42:34 *** ChanServ sets mode: +v bertbob
18:43:26 <jralls> giuseppef: Customer Number and customer_id are the same thing.
18:46:23 *** lcanaska has quit IRC
18:47:08 <giuseppef> No, if on Customer (obj) I use getID I get an ID created when I create the customers and it is progressive. On Gnucash, in customer editing before customer name I can set a "customer number" that is a string different from the ID
18:48:56 <giuseppef> I set this numbers to differ between kind of customers (eg. one category has numbers starting with 1, like 100001, 100002 etc), another one has numbers starting with 2, etc..
18:49:31 <giuseppef> GetId returns ID all starting with 0 and different from those numbers
18:55:46 <jralls> Just to make sure we're on the same ui entry, this is the first item on the Customer tab of the dialog that opens when you pick Business>Customer>New Customer, right? The tooltip/hover text says "The Customer ID number. If left blank a reasonable number will be chosen for you."
18:56:51 <giuseppef> Yes
18:57:27 *** Aussie_matt has joined #gnucash
18:57:48 <jralls> That control is named id_entry. https://github.com/Gnucash/gnucash/blob/maint/gnucash/gnome/dialog-customer.c#L216 calls gncCustomerSetID with the text in that control.
18:58:43 <giuseppef> Just a second, I copy code somewhere to show
19:04:00 *** giuseppef_ has joined #gnucash
19:04:07 <giuseppef_> https://pastebin.com/a3zUmtLJ
19:07:20 <jralls> Is the second character of the value returned by customer.GetID x by any chance?
19:07:48 <giuseppef> No, now on a Db I have for test, it works
19:08:32 <giuseppef> On other one I tried yesterday it gave me different results (just IDs ordered)
19:10:21 <jralls> I don't understand what "just IDs ordered" is supposed to mean.
19:10:27 <giuseppef> I looked at the code you posted before, and I was sure this should have been the id. Maybe I had some mess up in the Db. Thanks
19:10:37 <jralls> NO
19:10:42 <jralls> Sorry, NP
19:10:50 <giuseppef> jralls: It returned different numbers
19:11:18 <giuseppef> In order of insertion, even if later I modified that values in gnucash
19:11:54 <giuseppef> Are there any cache mechanisms in place (I am running 3.7)?
19:12:08 <jralls> What backend?
19:12:30 <giuseppef> Just files .gnucash
19:13:33 <jralls> Meaning XML? You have to save the file for it to be written to disk. Unless you're running your python script in the python console (and you have to build GnuCash yourself in order to do that) you don't get the same session.
19:14:33 <chris> jralls: I'll upgrade Income_GST_Statement in master then. This closes #500.
19:14:34 <jralls> Remember that GnuCash, even when using a SQL backend, doesn't support multiple simultaneous users. It loads the whole file/database into memory and never reads the file or database after that.
19:15:00 <giuseppef> I understand. I have built gnucash on Gentoo, but I was calling python from bash. So the problem was just, I didn't save before running...
19:15:03 <giuseppef> Thanks
19:15:24 <jralls> You're welcome.
19:15:28 <jralls> chris, OK.
19:16:52 <chris> jralls: What I removed last year was in BALSHEET-PNL: remove the full-text/regex search for Closing Transactions, relying on kvp flag only. There are still fulltext searches in Trial Balance, Income Statement, Equity Statement.
19:17:37 <giuseppef> Just another stupid question: changing customer ID later, can make problems with invoices issued before?
19:17:45 <jralls> chris, as long as nothing is depending on the post_date being 10:59:01 instead of 10:59:00 all is well.
19:19:55 *** omnireq has quit IRC
19:20:05 *** omnireq has joined #gnucash
19:20:05 *** ChanServ sets mode: +v omnireq
19:20:10 <jralls> giuseppef: Depends on what kind of problem. The customer is linked to the invoice by GUID, so if you change the customer id then print an invoice it will show the new customer id.
19:20:14 <chris> jralls: I don't think so.
19:20:48 <jralls> chris, I hope that means that you don't think anything depends on the seconds in the post_date.
19:20:53 <giuseppef> Thanks again
19:22:07 <chris> jralls: Yes, I don't think anything depends on post_date seconds for Closing handling... however my gnc:accumulate-at-dates function does sort time64 so I'll review it later...
19:23:06 <jralls> Thanks, chris. You might use xaccTransOrder() instead.
19:25:07 <jralls> Note that it's a predicate callback, I expect scheme has a sorting function that can deal with that.
19:26:27 <chris> sure: (lambda (a b) (< (xaccTransOrder a b) 0))
19:34:37 *** nick_ has joined #gnucash
19:38:12 *** phoenix has quit IRC
19:38:18 *** nick_ has quit IRC
19:45:28 *** codesmythe has quit IRC
20:08:51 *** zoid has quit IRC
20:10:43 *** zoid has joined #gnucash
20:10:43 *** ChanServ sets mode: +v zoid
20:22:37 *** codesmythe has joined #gnucash
20:22:37 *** ChanServ sets mode: +v codesmythe
20:24:04 *** guak has quit IRC
20:58:21 *** lcanaska has joined #gnucash
21:02:12 *** oozer has quit IRC
22:02:45 *** frakturfreak has quit IRC
22:10:18 *** fell has quit IRC
22:11:12 *** fell has joined #gnucash
22:11:13 *** ChanServ sets mode: +o fell
22:29:46 *** jervin has joined #gnucash
23:09:48 *** codesmythe has quit IRC
23:56:08 *** Cuare has quit IRC
23:58:16 *** lcanaska has quit IRC