2014-06-02 GnuCash IRC logs
00:42:09 *** aqua___ has joined #gnucash
00:58:16 *** aqua___ has quit IRC
01:02:52 *** MechtiIde has joined #gnucash
02:23:59 *** gncbot has joined #gnucash
02:31:12 *** Jimraehl1 has quit IRC
02:53:27 <fell> mikee, can you /op gncbot?
03:15:02 *** Bodhi-Baum has joined #gnucash
03:17:47 *** Bodhi-Baum has quit IRC
03:18:58 *** Bodhi-Baum has joined #gnucash
03:47:55 *** aqua___ has quit IRC
04:01:03 *** jralls has quit IRC
04:25:40 *** jralls has joined #gnucash
05:16:49 *** wol1 has joined #gnucash
05:23:41 *** wol has quit IRC
05:44:56 <mikee> @op gncbot
05:44:56 <gncbot> mikee: Error: I need to be opped to op someone.
05:45:25 *** mikee sets mode: +o gncbot
05:45:49 <mikee> @op fell
05:45:49 *** gncbot sets mode: +o fell
05:57:00 *** wol1 has quit IRC
06:08:04 *** wol has joined #gnucash
06:26:23 *** Bodhi-Baum has quit IRC
07:09:44 *** aqua___ has joined #gnucash
07:24:32 *** aqua___ has quit IRC
07:59:39 *** StuM has quit IRC
08:00:01 *** StuM has joined #gnucash
08:35:56 <mikee> Hmm. Passing 'monkey-puzzle-tree' to qof_scan_date() gets me a valid, but obviously wrong, date. I would have expected it to return FALSE
08:36:23 *** StuM has quit IRC
08:36:56 *** StuM has joined #gnucash
08:42:03 <mikee> It returns day month year as 0 0 2000
08:44:35 *** StuM has quit IRC
08:45:22 *** StuM has joined #gnucash
08:49:23 <warlord> awesome!
08:50:00 <warlord> I wish someone would rewrite the QIF date-scanning code into C so it can be used everywhere. It's very good about detecting date formats and allowing any format, regardless of locale.
09:07:45 <mikee> I can only guess it never return FALSE no matter what you throw at it.
09:08:31 <mikee> it's in gnc-date.c
09:12:18 *** SteveG has joined #gnucash
09:21:34 *** StuM has quit IRC
09:22:25 *** StuM has joined #gnucash
10:03:31 *** benoitg has joined #gnucash
10:07:06 *** SteveG has quit IRC
10:18:04 <warlord> mikee: could be.
10:20:21 *** wol has quit IRC
10:37:32 *** benoitg has quit IRC
10:40:15 *** O01eg has joined #gnucash
10:54:23 *** wol has joined #gnucash
10:59:03 *** aqua___ has joined #gnucash
11:16:48 *** benoitg has joined #gnucash
11:28:07 *** aqua___ has quit IRC
11:38:01 *** MechtiIde has joined #gnucash
11:46:26 *** wol has quit IRC
12:11:19 *** jralls has quit IRC
12:11:50 *** jralls has joined #gnucash
12:11:50 *** gncbot sets mode: +o jralls
12:19:26 *** aqua___ has joined #gnucash
12:26:14 *** StuM has quit IRC
12:26:42 *** StuM has joined #gnucash
12:33:20 *** wol has joined #gnucash
12:36:49 *** Krzysiek_K has joined #gnucash
12:44:34 *** aqua___ has quit IRC
12:51:21 *** lmat has joined #gnucash
12:52:11 *** aqua___ has joined #gnucash
12:53:30 <lmat> jralls: yo. "C needs to be able to call size_of(GncGUID) and get the right answer without understanding boost::uuids::uuid" :)
12:54:19 <jralls> Umm, yeah. So?
12:55:07 <warlord> lmat: that is, apparently, a short-term issue so that e.g. QofInstance can be declared as: struct { GncGuid guid; ...};
12:56:05 <lmat> Is in header: struct GncGUID; in cpp: struct GncGUID : boost::uuids::uuid enough? Or should I be looking into that ?
12:56:19 <lmat> typedef boost::uuids::uuid GncGUID; I'll wager is not going to work, eh?
12:56:32 <warlord> lmat: well, perhaps:
12:56:40 <warlord> #ifdef __cplusplus
12:56:47 <lmat> warlord: ahh, right
12:56:55 <warlord> typedef ...;
12:56:57 <warlord> #else
12:57:10 <warlord> typedef struct _gncGUID { ... } GncGuid;
12:57:11 <warlord> #endif
12:57:31 <lmat> warlord: that ... is pretty important, I think :)
12:57:51 <warlord> It's only important in so far as to make sure the size is correct.
13:01:08 *** aqua___ has quit IRC
13:01:14 <jralls> Which size is 16 bytes, see http://www.boost.org/doc/libs/1_55_0/libs/uuid/uuid.html#Size
13:02:09 <jralls> The C typedef need not even be a struct. "unsigned char[16]" will work.
13:02:10 <warlord> right. so that ... is 'char reserved[16];'
13:02:24 <lmat> uh-huh
13:02:25 <warlord> .. or unsigned char. sure
13:10:31 <lmat> I'm afraid that doesn't work. guid.h is included many times in a extern "C" context.
13:11:07 <lmat> So, for instance, in qofid.h, line 28, #include "guid.h" with extern "C" up on line 27. That typedef in guid.h will blow up.
13:12:50 <jralls> The typedef to unsigned char[16]? What's the error message?
13:13:11 *** fell_ has joined #gnucash
13:13:11 *** gncbot sets mode: +o fell_
13:13:16 <lmat> jralls: I was looking at warlord 's #ifdef __cplusplus \n typedef boost::uuids::uuid
13:13:27 <lmat> jralls: Perhaps I misread ? I thought the char[16] was for the #else part
13:16:21 <jralls> It is. OIC, the problem is that __cplusplus can be defined even in extern C context. So for public consumption C or C++, the type has to be unsigned char[16] and it will have to be type-punned with a union in guid.cpp.
13:16:52 <lmat> jralls: Yeah, perhaps :)
13:17:54 <warlord> Ewwww
13:21:29 *** fell has quit IRC
13:36:08 <jralls> warlord: Yeah, it's ugly and too C-ish. Better to make class GncGUID_impl : public boost::uuids::uuid with a GncGUID_impl::GncGUID_impl(GncGUID). That would be declared in guid.cpp and called by the C API functions.
13:47:22 *** claude has joined #gnucash
13:48:37 <warlord> jralls: yeah, probably... This will all be much easier for object pointer objects that are not declared and used directly by other objects.
13:48:53 *** wol has quit IRC
13:50:37 <claude> hi, I suddenly noticed that the profits number in the bottom bar of gnucash is seemingly wrong (-59,174)
13:50:52 <claude> Net Assets number seems fine
13:51:06 <claude> (GnuCash 2.4.10)
13:51:12 <warlord> claude: maybe due to changing of periods?
13:51:34 <claude> warlord: yes, possibly
13:51:53 <claude> but I did that several time in the past without issues
13:52:09 <claude> how is it calculated?
13:53:15 <warlord> claude: honestly, I dont know. I never pay attention to that number.
13:53:29 <claude> i can live with that too, probably
14:01:09 <lmat> claude: profits is probably income accounts - expense accounts ?
14:14:36 <claude> lmat: I don't think so, what you describe is "Net Assets"
14:21:15 <lmat> claude: Net Assets is assets - liabilities or so
14:23:42 <claude> lmat: sorry you are probably right, as in my current accounts, the amounts are equivalents
14:25:35 <claude> (that is 3,084.40)
14:27:40 <lmat> claude: Sorry, I'm not sure what "Profits" means. I knew at one point :(
14:28:37 <claude> I'll check with an older file...
14:28:39 <lmat> whoa...
14:29:23 <lmat> nm :)
14:32:03 <lmat> claude: http://money.stackexchange.com/questions/16525/how-does-gnucash-calculate-profits
14:32:18 <lmat> claude: In short, income - expenses (only the current year)
14:38:29 <claude> lmat: thanks, very good pointer
14:38:50 <claude> I see the (wrong) details in Loss & profits report
14:39:49 <claude> something probably went wrong during the new year period change (sorry I don't know weel the right English terms)
14:40:00 <claude> weel/well
14:41:35 <claude> I may have ran the operation twice, that is I erased the operation after the first time and reran it a second time
14:42:15 <claude> so the global figures seems ok, but something is not right "internally"
14:43:00 <lmat> eek
14:43:08 <claude> indeed
14:45:49 <claude> I don't feel like restarting from the saved accounts of last year :-(
14:46:58 *** Krzysiek_K has left #gnucash
14:47:24 *** Jimraehl1 has joined #gnucash
14:52:45 *** MechtiIde has quit IRC
14:59:13 <warlord> claude: for the report you should check the actual report options setting.
15:07:14 <lmat> claude: You should be backing up every so-often. Also, backup before doing anything drastic (like changing periods) ^_^
15:08:01 <warlord> Eh, changing periods is easily undoable -- it's just a preference entry
15:09:05 <lmat> Oh, I was thinking about closing the books
15:09:23 <warlord> Even that is easily undoable -- it's just a transaction.
15:09:32 <warlord> .. easy to delete it.
15:09:56 <lmat> warlord: Oh ? I've never done it. I was under the impression that all the transactions were moved to a new "closed" account or something.
15:10:13 <warlord> No
15:10:14 <lmat> warlord: So you're saying that all the account balances are simply transferred (in one transaction) to the closed account ?
15:10:26 <warlord> it just adds zero-izing splits to each Income/Expense account.
15:10:42 <lmat> cool
15:10:57 <warlord> Pretty much, yeah.. It creates two multi-split txns (per currency) to the assigned equity account (tree)
15:12:59 <claude> warlord: apparently, undoing the "closing books" transaction did leave some garbage behind
15:14:05 <warlord> Did you delete both of them? (it shouldn't leave anything behind if you delete the full transactions)
15:17:57 <claude> I cannot reproduce the issue, but something went wrong at some time
15:18:31 <claude> as I said, I can live with that, but if there is some way to fix it, it would be nice
15:19:24 <warlord> depends what actually is wrong. You can just close the books again.
15:20:16 <claude> I'd rather do it at the end of the year, but I can try without saving...
15:21:27 <warlord> You can do it whenever you want -- you assign the closing date.
15:22:02 <claude> Even after re-closing it, Profits are wrong (as if there was a ghost transaction left)
15:22:18 <warlord> Profits where?
15:22:33 <lmat> claude: How are you deciding they're wrong ?
15:22:33 <claude> Bottom bar, right side
15:23:35 <warlord> Oh, that ignores the closing transactions (at least it *should*)
15:23:36 <claude> they show -59,174, while manually calculating it (income - expense), it should be something like 3,000
15:23:39 <lmat> claude: When you run Profit & Loss report, does the number match that reported on the bottom ?
15:23:53 <warlord> how are you manually computing it?
15:24:44 <claude> yes, but all reported figures are wrong
15:25:09 <claude> warlord: total income - total expenses
15:25:47 <claude> it's like I only deleted one part of a "closing books" transaction
15:25:54 <warlord> claude: that's not what the bar is computing. It's computing "(total income today - total income on Jan 1) - (total expense today - total expense on Jan 1)"
15:26:17 *** StuM has quit IRC
15:26:34 <claude> warlord: but total income/expense on Jan 1 are 0
15:26:47 <lmat> claude: Makes that easier ^_^
15:27:02 *** StuM has joined #gnucash
15:27:06 <claude> mmh
15:27:36 <claude> maybe it's an issue with closing date being on 1/1 instead of 31/12
15:27:38 <warlord> claude: well, not really -- it ignores the closing transactions. (it could also be "off" by a day)
15:27:54 <warlord> that could be, too.
15:28:35 <claude> Ahhhhhhhhh :-)
15:28:53 <warlord> yes?
15:29:03 <claude> it was exactly that, changing the closing date to 31/12 fixed the issue
15:29:16 <claude> sorry for taking your time :-(
15:29:38 <claude> and a big thank you!
15:29:43 <warlord> You're welcome.
15:44:01 *** Jimraehl1 has quit IRC
16:23:03 *** lukas has joined #gnucash
16:25:49 <lmat> claude: Congrats! (I see that you reached your goal, now I'll read the backlog so that I can share in the edification)
16:26:40 <lmat> Oh, there isn't much in the backlog..
16:27:07 <lmat> claude: So you were missing some 1/1 transactions ? So, changing the close date to 31/12 picked up those extra transactions ?
16:29:42 <claude> lmat: the key is that Profits calculation (and some other figures) start on 1/1, then if the closing books date is on that same date, calculation is affected
16:30:53 <claude> the "backwards" transaction used to reset the account to 0 might be included in calculation
16:31:26 <lmat> claude: the "backwards" transactions being the close-the-book transactions ?
16:31:36 <claude> yes
16:31:48 <claude> so the rule seems to be: always use the previous period last day, and never the new period first day
16:35:10 <lmat> claude: gotcha
16:38:21 <warlord> claude: i guess it is included.
16:39:22 <claude> it was in my case, at least
16:41:54 <claude> thanks again for your help, bye
16:42:02 *** claude has left #gnucash
16:42:39 *** wol has joined #gnucash
16:43:57 *** lmat has quit IRC
16:45:27 *** wol has quit IRC
17:10:30 *** wol has joined #gnucash
17:14:21 *** SteveG has joined #gnucash
17:30:36 *** Krzysiek_K has joined #gnucash
17:50:35 *** wol has quit IRC
17:52:47 *** lukas has quit IRC
18:07:26 *** SteveG has quit IRC
18:10:32 *** ErKa has joined #gnucash
18:26:25 *** SteveG has joined #gnucash
18:30:00 *** StuM has quit IRC
18:30:01 *** Krzysiek_K has left #gnucash
18:30:25 *** wol has joined #gnucash
18:30:54 *** StuM has joined #gnucash
18:36:58 *** warlord has quit IRC
18:44:35 *** wol has quit IRC
19:01:56 *** ErKa has quit IRC
20:01:19 *** jralls has quit IRC
20:02:13 *** jralls has joined #gnucash
20:02:13 *** gncbot sets mode: +o jralls
20:20:38 *** jralls has quit IRC
20:21:00 *** jralls has joined #gnucash
20:21:00 *** gncbot sets mode: +o jralls
20:42:39 *** ErKa has joined #gnucash
20:43:51 *** jralls has quit IRC
20:44:43 *** jralls has joined #gnucash
20:44:44 *** gncbot sets mode: +o jralls
21:03:22 *** SteveG has quit IRC
21:23:34 *** ErKa has quit IRC
21:37:52 *** StuM has quit IRC
21:38:32 *** StuM has joined #gnucash
21:42:17 *** fell__ has joined #gnucash
21:42:18 *** gncbot sets mode: +o fell__
21:42:18 *** fell_ has quit IRC
22:14:05 *** StuM has quit IRC
22:17:50 *** fell__ has quit IRC
23:55:54 *** benoitg has quit IRC