2017-12-09 GnuCash IRC logs
00:41:42 *** storyjesse has joined #gnucash
00:48:46 *** jotrago has joined #gnucash
01:07:08 *** frakturfreak has quit IRC
01:22:25 *** frakturfreak has joined #gnucash
02:17:48 *** Mechtilde has joined #gnucash
02:21:54 *** jotrago has quit IRC
02:31:08 *** jotrago has joined #gnucash
02:43:42 *** gjanssens has joined #gnucash
02:43:42 *** ChanServ sets mode: +o gjanssens
02:43:56 <gjanssens> .
03:36:10 *** fabior has joined #gnucash
03:40:38 *** Mechtilde has quit IRC
04:27:36 *** hoijui has joined #gnucash
04:29:50 *** fabior has quit IRC
04:33:06 *** Mechtilde has joined #gnucash
04:37:09 *** Groan has quit IRC
04:38:55 *** O01eg has quit IRC
05:40:45 <gjanssens> jralls: I happened to stumble on your wiki talk page. I think it's due for an update :)
05:41:01 <gjanssens> Sorry I meant your user page
06:15:01 *** storyjesse has quit IRC
06:27:43 *** fabior has joined #gnucash
06:37:06 *** chf has quit IRC
06:46:52 *** mikee has quit IRC
07:05:28 *** fabior has quit IRC
07:12:28 *** User has joined #gnucash
07:27:22 *** User has quit IRC
07:41:05 *** warlord has quit IRC
07:41:17 *** warlord has joined #gnucash
08:19:05 *** chris has joined #gnucash
08:29:55 *** chf has joined #gnucash
08:30:22 *** fabior has joined #gnucash
09:41:29 *** noah has joined #gnucash
09:43:26 *** noah has quit IRC
09:44:13 *** noah has joined #gnucash
09:52:18 *** noah has quit IRC
09:53:42 *** noah has joined #gnucash
10:04:52 *** markvandenborre has joined #gnucash
10:06:17 <markvandenborre> I'm trying to find out what would be a good way to structure our personal accounting as a couple, using gnucash
10:06:41 <markvandenborre> in a way that I can keep a good overview of my personal finances, _and_ our common finances
10:08:31 *** VigilantSky has joined #gnucash
10:10:30 <chris> markvandenborre: no particular advice apart from the fact that gnucash can handle having multiple Asset accounts (such as yours and spouse), multiple Expenses (e.g. household, individual), multiple Incomes (yours, spouse, welfare)
10:10:57 <chris> best to try with personal only, and learn how to use gnucash. later you'll find out how to add spouse accounts as well
10:11:48 <markvandenborre> I have a fairly good grasp of the basic things, personal use is already covered quite well
10:12:24 <markvandenborre> but I'm still a bit confused on how to do the total thing
10:13:05 <markvandenborre> so much to be honest that I have some difficulties expressing what I want from gnucash :-)
10:13:15 <markvandenborre> chris: thx for the hint
10:14:22 <markvandenborre> ideally, I'd like to keep an eye on my personal net worth, and at the very least, keep an eye on the liquidity and solvability of what we do in common
10:15:35 <markvandenborre> there are a few messy things though. As an example, we use my personal credit card only (not one linked to a common account).
10:18:07 <chris> well, no accounting software can fix relationship issues :)
10:18:30 <chris> if you design your charts of accounts carefully you will be able to extract useful data
10:18:37 <markvandenborre> chris: no worries, definitely not a relationship issue :-)
10:18:37 <chris> but first need to define your question exactly
10:19:09 <chris> lots of the inbuilt reports will assume personal / joint accounts as a single entity
10:19:23 <chris> but with tinkering you can definitely answer most personal finance questions from it
10:19:54 <markvandenborre> I probably have to focus on the joint bits at this point
10:19:57 <chris> I personally advocate ALWAYS obey the correct rule wrt INCOME/EXPENSE/EQUITY/ASSET/LIABILITY
10:20:17 <chris> and try to structure your accounts according to your personal rules
10:20:17 <markvandenborre> that speaks for itself if you ask me...
10:20:51 <markvandenborre> (the correct rule wrt income/expense/equity/asset/liability that is)
10:21:26 <chris> well yes but most beginners mistake mortgage payments as expense instead of liability repayments
10:22:04 <markvandenborre> heh, no worries about that
10:22:27 <chris> I use "Expenses:Household:*" for joint expenses eg Rent/Insurance/Utilities, Expenses:Chris:* for my own toys, Expense:Spouse:* for hers
10:23:05 <chris> Our joint investments should be "Assets:Investments:*"
10:24:34 <chris> my retirement plan could be "Assets:Investments:Chris:Retirement"
10:24:35 *** VigilantSky1 has joined #gnucash
10:25:15 <chris> again best to play with the structure for a while and restructure when needed
10:25:19 <markvandenborre> our/my situation is comically simple
10:25:24 <markvandenborre> for the moment
10:25:48 *** VigilantSky has quit IRC
10:25:49 *** VigilantSky1 is now known as VigilantSky
10:26:22 * markvandenborre is the only one bringing in any realy money here...
10:26:43 <markvandenborre> and the only one with any asset worth mentioning
10:26:46 <markvandenborre> (house)
10:27:10 <markvandenborre> and a bit of retirement savings
10:27:16 <markvandenborre> so in that regard, things are easy...
10:35:48 <chris> well then, set up a Expense:Spouse:* structure and watch the amounts increase rapidly :)
10:36:19 <chris> in your above question - "common finances" don't quite exist don't they?
10:39:09 <chris> "personal net worth" would be available from Report > Assets & Liabilities > Net worth
10:40:09 <chris> "liquidity" assets:bank, assets:savings, assets:investments
10:40:30 <chris> conclusion- experiment, experiment
10:42:19 <markvandenborre> chris: we basicly throw all of our wages together (for now)
10:42:32 <markvandenborre> which means me paying everything at the moment
10:42:50 <markvandenborre> or almost everything
10:43:20 <markvandenborre> but that can be modeled using this system I guess
10:44:15 <chris> yups
10:44:17 <markvandenborre> the workflow currently is basicly: throw everything into one big pot, pay necessary expenses, and give each the same (small) amount of pocket money
10:44:44 <markvandenborre> these "pocket money" expenses don't have to be accounted for even
10:45:05 <markvandenborre> it can just go under Expense:Spouse:PocketMoney
10:45:07 <markvandenborre> :-)
10:45:28 <chris> yes if it works for you
10:45:38 <markvandenborre> actually: Expense:Househould -> Expense:Spouse:PocketMoney
10:45:58 <markvandenborre> sorry, typo there, you see what I mean
10:46:11 <chris> hm generally I'm not sure good to transfer between expense accounts
10:46:15 <chris> although I do it sometimes too
10:48:09 <markvandenborre> it would go from the common "checking" account -> Expense:Spouse:Pocket
10:49:20 <chris> this makes more sense
11:05:27 <markvandenborre> chris: you've really helped me a lot by answering my (in hindsight) rather obvious questions
11:05:31 <markvandenborre> thank you so much for that
11:07:33 * chris is away: I'm busy
11:46:24 *** hoijui has quit IRC
12:34:26 <jralls> gjanssens: re my wiki page, I suppose you mean the bit about GObject compliance. Just a *little* out of date... ;-)
12:38:09 *** Mechtilde has quit IRC
12:43:39 *** fbruetting has joined #gnucash
12:57:26 *** Mechtilde has joined #gnucash
13:04:43 *** noah has quit IRC
13:08:29 *** noah has joined #gnucash
13:23:13 *** fiddlerwoaroof has joined #gnucash
13:39:24 *** noah has quit IRC
13:43:52 *** hoijui has joined #gnucash
14:02:17 *** Mechtilde has quit IRC
14:05:42 *** kael has joined #gnucash
14:13:08 *** VigilantSky has quit IRC
14:33:24 *** fabior has quit IRC
14:47:07 *** User has joined #gnucash
15:05:32 *** VigilantSky has joined #gnucash
15:08:18 <CDB-Away> <CDB-Away> hmm, it looks like the subaccount renumbering feature doesnt work properly re leading zeros
15:08:18 <CDB-Away> <CDB-Away> for example, if my accout is 01-10-X, and I have X = 1 through 10, it does not add leading zeros to the 1 thru 9
15:08:18 <CDB-Away> <CDB-Away> when I add an 11th account and go to renumber, it orders them as 1,10,11,2,3,4 ... 9 --- rather than 1,2,3,...9,10,11
15:08:18 <CDB-Away> <CDB-Away> due to lack of leading zeros
15:08:25 <CDB-Away> shall i file a bug report for this?
15:43:02 *** fbruetting has quit IRC
15:43:07 <markvandenborre> I'm looking for the best way to add my home loan (as a liability) to gnucash
15:43:44 <markvandenborre> and I'm reading up the relevant docs
15:45:45 <markvandenborre> the interest rate changes every 5 years
15:47:44 <markvandenborre> should I make a manual calculation every month how much of my payment is principal, and how much interest, or is there a more elegant way to solve this?
15:48:03 <CDB-Away> there should be a mortgage calculator in the tools
15:49:59 <markvandenborre> CDB-Away: there is, I've found it; but I don't really see how it fits into the workflow, other than
15:50:17 <markvandenborre> me calculating every month how to distribute the principal and interest
16:10:52 <CDB-Away> ive never used the mortgage calculator so cant really comment
16:11:13 <CDB-Away> but i thought that you can program it to do the calculation and then generate the journal entries each month
16:11:34 <markvandenborre> CDB-Away: it's not a lot of work to do manually either, so not too big a deal
16:11:55 <markvandenborre> I'm now thinking how to structure the interest versus pricipal payments
16:12:13 <markvandenborre> so that it is easily visible the interest is paid against this specific loan
16:13:51 <jralls> CDB-Away: IIRC the account "number" field is really text so it's going to get sorted like a string rather than a number. Even if it does have logic to convert it to a number it's not going to be smart enough to break up 01-10-X into two integers and a letter and sort the result piece-wise.
16:25:19 <CDB-Away> jralls: I realize it's a string, but I think you may have misunderstood what I meant with the X
16:26:14 <CDB-Away> for example, if I have accounts currently numbered 01-10-1, 01-10-2, ... 01-10-9, 01-10-10, 01-10-11
16:26:22 <CDB-Away> and I go to renumber them with the tool
16:26:25 <CDB-Away> the result is:
16:26:26 <jralls> CDB-Away: Doesn't matter. Even if it was 01-10-23 it still wouldn't know how to convert that into three separate number fields to be sorted sequentially.
16:27:18 <CDB-Away> 01-10-1 --> 01-10-1,
16:27:18 <CDB-Away> 01-10-11 --> 01-10-2,
16:27:18 <CDB-Away> 01-10-2 --> 01-10-3
16:27:24 <CDB-Away> where 01-10 is specified as the prefix
16:27:29 <CDB-Away> and my increment is 1
16:27:48 <CDB-Away> whereas, if I had entered leading zeros:
16:27:48 <jralls> CDB-Away: What part of "string" eludes you?
16:28:30 <CDB-Away> 01-10-01 --> 01-10-1
16:28:30 <CDB-Away> 01-10-11 --> 01-10-11
16:28:30 <CDB-Away> 01-10-02 --> 01-10-02
16:28:37 <CDB-Away> 01-10-02 --> 01-10-2 **
16:28:52 <CDB-Away> jralls: none, but that's not my point
16:29:12 <jralls> It's mine. It's a string and it's going to get sorted like a string.
16:29:13 <CDB-Away> my point is, since it's using string recognition, the lack of leading zeros being inserted by the renumbering tool is what's causes the issues
16:29:31 <CDB-Away> if the renumbering tool inserts leading zeros, it will sort byy string correctly
16:29:47 <CDB-Away> if I had manually added leading zeros, then the result from the renumbering is as expected from a numrical sense
16:30:00 <jralls> No, the character '0' is encoded as 0x30 and '1' is encoded as 0x31. It sorts before 1 in a string.
16:30:12 <CDB-Away> yes, Im aware
16:30:42 <CDB-Away> currently, it will sort 1, 11, 2, in that order. if I had leading zeros, it will sort it as 01, 02, 11
16:30:45 <CDB-Away> due to precisely what you said
16:31:03 <CDB-Away> if the existing accounts contaiin leading zeros, the parser correctly parses them for the reason you said
16:31:18 <CDB-Away> but when the tool re-generates the numbers, it does not include leading zeros
16:31:25 <CDB-Away> meaning that future renumbering will fail
16:31:34 <CDB-Away> unless I manually add leading zeros before using it to renumber
16:31:41 <CDB-Away> which at that point, I may as wlel manaully renumber them all
16:31:57 <CDB-Away> in other words: feature request: have the renumbering tool always inser leading zeros
16:32:06 <CDB-Away> as it currently does not
16:32:40 <CDB-Away> (that or, make it an optionally available flag/checkmark, for those that do not like leading zeros
16:33:16 <jralls> Not likely to happen unless you write the code.
16:33:50 <jralls> But go ahead and file the request, maybe someone else will come along.
16:34:05 <CDB-Away> Aye aye, captain
16:36:27 *** Robert has joined #gnucash
16:39:16 <Robert> Hi, Since upgrading GnuCash on my Windows 7 computer from release 2.6.15 to 2.6.18 I have noticed that there is a vry long (over a minute) delay between clicking on the start icon to seeing a window appear on the desktop. In fact, no icon appears in task manager either.
16:40:04 <Robert> I find myself clicking again because of this. Then I need to kill the second instance once th first fiaally appears
16:41:34 <Robert> If I reset the splash screen, will that appear earlier?
16:44:01 <jralls> Robert: Do you have the splash screen turned off in preferences?
16:58:35 *** hoijui has quit IRC
17:00:22 *** ah has joined #gnucash
17:06:49 *** VigilantSky has quit IRC
17:13:42 <Robert> yes
17:22:05 <jralls> Well, if you turn it back on you'll get to see the user entertainment as it loads the modules and your data file. That might help with the temptation to click again. I don't know at what point during start up Windows puts the icon on the task bar but I can imagine it being when the first window is shown.
17:31:34 <markvandenborre> ok, so I have split up our (non-fixed) assets into gf and me
17:32:05 <markvandenborre> and common account
17:32:20 <markvandenborre> and our expenses all get paid by one of those
17:32:43 <markvandenborre> now I would like to generate a monthly report that says who has paid how much of the common expenses
17:32:56 <markvandenborre> I hope my question is clear
17:33:04 <markvandenborre> is there an easy way to do something like that?
17:37:24 <Robert> ty. bye
17:37:27 *** Robert has left #gnucash
17:37:31 <chris> markvandenborre: good question but not yet
17:38:51 <chris> for now, if you're new to this software, you should experiment with the transaction report and the Filter By... options until you get a useful report. Most users will use the resulting figures
17:59:44 <markvandenborre> ok, cool, will have a look at it
18:03:49 <jralls> chris: What was it about Western Australia and Summer Time between 1970 and 2010? It seems they'd turn it on for one year every 10, except they did it for 2 years in 2008-2009. I suppose that was so they don't have to this decade?
18:04:34 <jralls> (Yes, that means that I'm fixing up the timezone code and picked Australia/Perth as one of my test time zones.)
18:05:19 <chris> jralls: gad, I have no idea, only been in Western Australia past 4 years myself -- in Mauritius too they tried Summer Time for 1 year only as an experiment for god knows why
18:06:49 <chris> I'd be nervous if an accounting package has to keep up with summer time changes; these things are very fluid
18:08:18 <jralls> Fortunately the US National Institute of Standards and Technology takes care of keeping up and publishes the zoneinfo database that all of the OS vendors use to manage system time.
18:09:17 <jralls> GnuCash needs to parse it too so that it can reliably convert between the computer's time and UTC.
18:10:29 <jralls> Unfortunately the POSIX standard time is still 31 bits worth of seconds from 1970 and becomes useless in about 20 years. That makes life difficult for 30 year mortgages.
18:13:29 <chris> what a pain... sounds like a lot of work ahead to fix all these time conversion calls
18:15:25 <chris> I'm working on the git rewriting... so much fun
18:16:47 <gjanssens> jralls: yes, I was referring to the gobject part :)
18:17:14 <chris> I anticipate it will be ready for scrutiny in less than 2 weeks and merging before NYE
18:18:52 <jralls> gjanssens: I want to wrap up the MySQL 1970-01-01 bug. I've already changed the schema in 2.7 and discovered that GnuCash doesn't care what it is, so it *should* be backward compatible to change it in 2.6 as well.
18:19:17 <jralls> But no-one on the bug would test it and weirdly I can't even reproduce the problem on any of my VMs.
18:20:13 <jralls> So I'm equally tempted to just make the change in 2.6 and to just close the bug as fixed in 2.8. Which do you think better?
18:21:34 <jralls> That's https://bugzilla.gnome.org/show_bug.cgi?id=784623...
18:21:56 <gjanssens> Hmm, difficult. If you think the change should work on 2.6, I'd apply your patch there, considering it currently is not working.
18:22:29 * gjanssens is going to bed now...
18:22:34 <gjanssens> See you
18:22:39 <chris> Night!
18:23:01 *** gjanssens has quit IRC
18:39:54 *** ah has quit IRC
19:51:50 *** VigilantSky has joined #gnucash
20:00:59 *** kael has quit IRC
20:11:43 *** phebus has quit IRC
20:14:47 *** phebus has joined #gnucash
20:34:39 *** User has quit IRC
20:59:21 *** fbruetting has joined #gnucash
21:54:59 *** VigilantSky has quit IRC
22:03:24 *** Groan has joined #gnucash
22:13:11 *** VigilantSky has joined #gnucash
22:15:08 <lmat> jralls: features are stored in KVP under a particular key.
22:15:22 <lmat> jralls: Are they stored as a GList? or a Frame?
22:16:42 <lmat> I'm looking here:
22:16:45 <lmat> oops https://github.com/Gnucash/gnucash/blob/115c0bf4a4afcae4269fe4b9d1e4a73ec7762ec6/libgnucash/engine/qofbook.cpp#L1144
22:18:00 <lmat> Oh, maybe I'm misreading...
22:18:28 <lmat> Yeah, I got feature_slot and feature mixed up. I'm dealing with a memory corruption issue and not sure where to point the gun.
22:23:55 <lmat> Ah! I'm passing a pointer, but casting it as a **, then getting its value. oof
22:53:51 *** fbruetting has quit IRC
23:27:56 *** kael has joined #gnucash
23:39:43 *** Groan has quit IRC
23:42:55 *** Groan has joined #gnucash