2020-06-06 GnuCash IRC logs

00:17:03 *** Mechtilde has joined #gnucash
00:28:19 *** omnireq_ has quit IRC
00:28:30 *** omnireq_ has joined #gnucash
00:46:26 *** Mechtilde has quit IRC
00:49:19 *** omnireq_ has quit IRC
00:49:30 *** omnireq_ has joined #gnucash
00:53:29 *** Mechtilde has joined #gnucash
01:02:54 *** bertbob has quit IRC
01:04:38 *** sbluhm has joined #gnucash
01:04:38 *** ChanServ sets mode: +v sbluhm
01:05:17 *** bertbob has joined #gnucash
01:05:17 *** ChanServ sets mode: +v bertbob
01:14:23 *** fell has quit IRC
01:15:19 *** omnireq_ has quit IRC
01:15:30 *** omnireq_ has joined #gnucash
01:15:46 *** fell has joined #gnucash
01:15:46 *** ChanServ sets mode: +o fell
01:20:50 *** shaggy has quit IRC
01:22:22 *** shaggy has joined #gnucash
01:25:38 *** sbluhm has quit IRC
01:27:34 *** shaggy has quit IRC
01:34:50 *** ttcs has joined #gnucash
01:36:19 *** omnireq_ has quit IRC
01:36:39 *** omnireq_ has joined #gnucash
01:37:21 <ttcs> getting some conflicting information so asking here: wells fargo is not supported through gnucash at all?
01:38:29 <ttcs> the wiki page was edited to mention that early last year but haven't found anyone complain about that not working
01:44:07 *** codesmythe has joined #gnucash
01:44:08 *** ChanServ sets mode: +v codesmythe
01:47:08 *** codesmythe has quit IRC
02:08:24 *** suukim has joined #gnucash
02:18:19 *** omnireq_ has quit IRC
02:18:30 *** omnireq_ has joined #gnucash
02:39:49 *** omnireq_ has quit IRC
02:40:00 *** omnireq_ has joined #gnucash
02:45:50 *** dtux has joined #gnucash
02:46:05 *** dtux has quit IRC
03:11:55 *** gjanssens has joined #gnucash
03:11:55 *** ChanServ sets mode: +o gjanssens
03:45:05 *** codesmythe has joined #gnucash
03:45:05 *** ChanServ sets mode: +v codesmythe
03:48:05 *** codesmythe has quit IRC
04:01:09 <gjanssens> .
04:11:39 *** fabior has joined #gnucash
04:20:00 *** User_ has joined #gnucash
04:23:49 *** keiffer has joined #gnucash
04:28:06 *** Hamaryns has joined #gnucash
04:28:06 *** ChanServ sets mode: +v Hamaryns
04:41:44 *** sbluhm has joined #gnucash
04:41:44 *** ChanServ sets mode: +v sbluhm
05:00:32 <gjanssens> chris: I'm pleased you picked up my list and show suggestions already :)
05:03:29 *** sbluhm has quit IRC
05:45:45 *** codesmythe has joined #gnucash
05:45:45 *** ChanServ sets mode: +v codesmythe
05:48:46 *** codesmythe has quit IRC
05:51:50 *** sbluhm has joined #gnucash
05:51:50 *** ChanServ sets mode: +v sbluhm
05:52:45 *** Hamaryns has quit IRC
06:05:20 *** sbluhm has quit IRC
06:09:33 *** storyjesse has quit IRC
06:27:29 <chris> gjanssens: I had to make sure it was done correctly :)
06:28:29 <gjanssens> Absolutely. In fact I hoped you would :)
06:42:32 *** sbluhm has joined #gnucash
06:42:32 *** ChanServ sets mode: +v sbluhm
06:45:15 *** storyjesse has joined #gnucash
06:46:09 *** fabior has quit IRC
06:54:16 *** storyjesse has quit IRC
07:03:07 *** User_ has quit IRC
07:17:02 *** sbluhm has quit IRC
07:46:35 *** codesmythe has joined #gnucash
07:46:35 *** ChanServ sets mode: +v codesmythe
07:49:35 *** codesmythe has quit IRC
08:09:41 <chris> gjanssens: as a follow-on change we might want to break out gnc:cmdline functions into a separate .scm - I may leave that in your hands
08:19:55 *** Jimraehl1 has joined #gnucash
08:20:53 *** Jimraehl1 has quit IRC
08:38:44 *** jervin has joined #gnucash
08:59:01 <gjanssens> jralls: https://github.com/Gnucash/gnucash/blob/master/gnucash/gnucash-core-app.cpp#L467
08:59:34 <gjanssens> Our program run currently starts by testing for the availability of a GThreads implementation.
09:00:04 <gjanssens> This stems from 2007 when in the absence of such an implementation fork was used instead (I presume on Windows)
09:00:22 *** User_ has joined #gnucash
09:00:24 <gjanssens> However these days we require GThread as a build dependency.
09:00:48 <gjanssens> Does this initial check in code still make sense ? I'm tempted to remove it as a minor cleanup.
09:01:56 <gjanssens> Longer term I expect us to move to C++'s (or STL's) built-in threading support but that would be a big change, not for 4.0
09:02:08 <gjanssens> Do you have objections to removing the check ?
09:02:36 <gjanssens> For reference https://github.com/Gnucash/gnucash/commit/74c517548c69c6ed324ae050e1f2d141adb632fd is the commit that added this check.
09:06:50 *** sbluhm has joined #gnucash
09:06:50 *** ChanServ sets mode: +v sbluhm
09:23:30 *** chris has quit IRC
09:26:48 *** chris has joined #gnucash
09:26:48 *** ChanServ sets mode: +v chris
09:44:13 *** codesmythe has joined #gnucash
09:44:14 *** ChanServ sets mode: +v codesmythe
09:47:14 *** codesmythe has quit IRC
09:49:34 *** sbluhm has quit IRC
09:56:00 *** ChanServ sets mode: +qo warlord warlord
09:56:12 *** warlord sets mode: +o gncbot
10:15:10 *** sbluhm has joined #gnucash
10:15:10 *** ChanServ sets mode: +v sbluhm
10:36:49 *** jervin has quit IRC
10:52:40 *** sbluhm has quit IRC
11:13:57 <fell> gjanssens: yes, andi5 worked on the windows port.
11:34:41 <gjanssens> fell: it looks like that indeed. However the Windows port has changed *a lot* since 2007, so I doubt that check at the beginning of gnucash-bin.c is still needed.
11:35:47 <gjanssens> (well, with the recent gnucash-bin.c to gnucash.cpp and gnucash-cli.cpp conversion, this bit has now moved to gnucash-core-app.cpp, but the principle is still the same)
11:43:46 *** David has joined #gnucash
11:45:09 *** codesmythe has joined #gnucash
11:45:09 *** ChanServ sets mode: +v codesmythe
11:48:10 *** codesmythe has quit IRC
11:53:35 <David> Hey all, I'm having a hard time with GnuCash this morning. I'm on a Ubuntu system using GnuCash 3.10, (I think it was updated yesterday). I'm trying to setup online banking, I can create an account and connect to my bank, but it will not go to the step where I match my online account with my GnuCash account. This was working for me before. Any ideas?
11:59:33 <David> BTW, I'm trying to connect using OFX-DirectConnect.
12:14:02 <gjanssens> David: I'd love to help you, but I don't use OFX-DirectConnect (nor any other online banking integration in GnuCash)
12:14:22 *** User_ has quit IRC
12:14:51 <gjanssens> You may want to ask on the gnucash-user mailing list. Or try to search the mailing list archives. Questions about online banking pop up frequently there.
12:15:33 <gjanssens> To search the archives enter your search terms in google and append it with site:lists.gnucash.org
12:15:39 *** codesmythe has joined #gnucash
12:15:39 *** ChanServ sets mode: +v codesmythe
12:15:45 <gjanssens> There's no direct search integrated in the website unfortunately.
12:18:29 <David> gjanssens: Thanks, I noticed that there was a mailing list, searching the archives is a great idea, I'll try that next.
12:30:55 *** storyjesse has joined #gnucash
12:38:37 *** codesmythe has quit IRC
12:38:50 *** sbluhm has joined #gnucash
12:38:50 *** ChanServ sets mode: +v sbluhm
12:46:42 *** codesmythe has joined #gnucash
12:46:42 *** ChanServ sets mode: +v codesmythe
12:48:34 *** sbluhm has quit IRC
12:49:37 *** suukim has quit IRC
12:55:25 *** storyjesse has quit IRC
12:56:04 <jralls> gjanssens, CMakeLists and the linker will make sure that Gthreads is there, so the fragment in gnucash-core-app.cpp is indeed superfluous.
12:58:09 <jralls> gjanssens OTOH GnuCash is so full of globals, statics, and thread-unsafe code that its use of threads is very distressing. Plus, the first example I looked at, https://github.com/Gnucash/gnucash/blob/master/gnucash/gnome-utils/gnc-tree-model-account.c#L316, is just plain stupid.
12:59:52 <fell> David, I would suggest to try https://wiki.gnucash.org/wiki/Flatpak. At least the nightlies should have more recent libraries.
13:07:04 *** omnireq__ has joined #gnucash
13:08:14 *** omnireq_ has quit IRC
13:12:04 <jralls> The XML file save is a better use-case for a thread. IIRC andi5's implementation was wrong but mta fixed it a few years ago so that it actually works. It's in io-gncxml-v2.cpp so you could rewrite it using std::async should you be so inclined.
13:14:08 <jralls> I think we should look carefully at all of the other places where we're using threads and think really hard about whether it's the right thing to do. I suspect that it mostly isn't, and what's more that it's probably done wrong. Concurrency is very easy to screw up.
13:14:39 <David> fell: thanks for the input, I installed flatpak and tried to add my user account again but there was no difference. Do I need to reboot my system before the new libraries get used?
13:16:43 <jralls> David, another user discovered that AQB won't create accounts automatically if there isn't one already. He worked around it by creating a dummy account then re-downloading the accounts from the user tab.
13:23:19 *** omnireq__ has quit IRC
13:23:44 *** omnireq__ has joined #gnucash
13:28:59 <David> jralls: I think I understand what your saying. To me it looks like the problem is that when I create a new user, and setup my bank, it should add my bank to the Accounts Tab. When I went through this process to select the bank and add my user it did not add a new account. I only see the dummy account I created before, as you suggested.
13:30:10 <jralls> David, did you click the "Retrieve Account List" button on the Bank Settings tab again?
13:33:49 <David> jralls: Yes, it returned with the message "Operation finished, you can now close this window.". It did not show me a list of the accounts as I thought it did before (last month when I had this working).
13:36:11 <jralls> That suggests that it didn't work. It should say the server successfully processed the request, list the account or accounts, and then Operation finished.
13:41:44 <David> jralls: OK, that's frustrating, there is a note on that dialog that tells me that not all banks support returning the account list and if that's the case I will need to manually create the accounts... But, this was working last month.
13:43:51 <jralls> Does it say that the server successfully processed the request but there are no banks?
13:44:50 *** omnireq__ has quit IRC
13:45:00 *** omnireq__ has joined #gnucash
13:48:51 <David> jralls: Also, I just noticed that it's not event asking me for my password anymore, I was before but not now? Perhaps it has stored it? I assume it would throw an error if it could not talk to the bank?
13:50:13 <jralls> It would report an error in that dialog. It will remember the PIN if you have that option selected in Preferences>Online Banking.
13:53:36 <David> jralls: Yeah, I that setting is turned on. I guess I will just manually download the transactions from my online bank, until I can get this resolved. Thanks all for the help.
13:54:19 <jralls> You might just set up the accounts manually. It just requires the account and bankid; the latter is the FID from the user page for credit cards and the routing number for bank accounts.
14:13:58 *** frakturfreak has joined #gnucash
14:16:51 *** guak has joined #gnucash
14:21:05 *** pkricton has joined #gnucash
14:22:03 <pkricton> I've made two check formats for the Liberty DeskSet w/ stubs and Deluxe Personal w/ stub checks. Is there a place within the GnuCash community where I can offer them?
14:28:42 *** dtux has joined #gnucash
14:29:49 *** omnireq__ has quit IRC
14:30:00 *** omnireq__ has joined #gnucash
14:37:30 *** shaggy has joined #gnucash
15:25:04 *** pkricton has quit IRC
15:40:56 *** Mechtilde has quit IRC
15:44:28 <CDB-Man_> chris: i see you made some changes to the balance sheet? layout changes aside, my balance sheet no longer balances... usiing nearest in time price source
15:49:05 <jralls> Wow, that layout *really* sucks.
15:49:48 <CDB-Man_> i like the new treatment for "parent account amount sinlcude children -- thats a good idea
15:49:56 <CDB-Man_> but the rest of the layout changes are.... meh
15:50:04 <CDB-Man_> and more importantly, it does not balance
15:52:05 <jralls> Are you sure? The Liabilities + Equity line is gone so you have to add them together and compare that to assets.
15:52:47 <CDB-Man_> jralls: hmm, did not notice that at all (and that definitely needs to be added back) -- let me hand check the math
15:53:09 <CDB-Man_> still does not balance
15:53:21 *** tmetro has joined #gnucash
15:54:20 <jralls> Have you accounted for all of your capital gains?
15:54:42 <CDB-Man_> chris: I think if you're going to re-design fundamentally these core reports, they should be moved to a beta report -- just like you did for the accounts receivable customer balance one
15:55:04 <CDB-Man_> jralls: yeah, unrealized gains and everything are included -- i'm out by $~60
15:55:11 <CDB-Man_> it's definitely some exchange related difference
15:55:20 <CDB-Man_> all accounts selected for report
15:55:32 <jralls> He did that. They were in beta for most of 3.x and are being moved to mainstream for 4.0
15:57:59 <jralls> Hmm, didn't we talk last week about you doing some funny cross-expensing CAD and JPY? Did you clean all of that up?
15:58:18 <jralls> er, *with* CAD and JPY...
15:58:19 <CDB-Man_> that's all been cleaned up, and it was fine with the old rpeorts
15:58:24 <CDB-Man_> that is not the cause of this
15:59:27 <CDB-Man_> this is purely a difference due to reporting; old b/s i/s are fine -- I had installed the most recent nightly to look at the reconciliation report credit balance issue (https://bugs.gnucash.org/show_bug.cgi?id=797770 fixed now) then saw these changed b/s i/s reports
16:00:09 <CDB-Man_> "most recent nightly" being gnucash-3.903-2020-06-06-git-3.903-17-ge4e36e684+.setup.exe
16:00:27 <CDB-Man_> reverting back to gnucash-3.902-2020-05-23-git-3.902-157-gd8aecf969+.setup.exe for now... I need my statements to balance
16:00:40 <tmetro> Hi, I'm trying to import transactions to a checking account that is partially populated with transactions. I have both CSV and OFX files to work with. With either I get to a similar looking match screen where I find lots of transactions that have the "A" column checked, rather than "U+R" or "R" as expected. I'm not so concerned that the auto-match isn't working. I am concerned that when I double-click on a row it takes me to the
16:02:24 <jralls> tmetro takes you to the what?
16:03:22 <tmetro> jralls: you'll need to be a bit mire specific about which step in the process you're asking for clarification on.
16:03:48 <tmetro> "select matching existing transaction" dialog?
16:04:27 <jralls> tmetro, if you tried to post an image, that doesn't work. Your text finished with "when I double-click on a row it takes me to the".
16:04:38 <jralls> So it takes to the what?
16:04:40 <CDB-Man_> yep. downgrading again, the reports all balance, and the totals are different, so it's definitely a reporting issue
16:05:01 <tmetro> Oh...IRC truncated. NP. I'll repost remainder.
16:05:08 <jralls> CBD-Man_, please file a bug.
16:05:23 <tmetro> ...it takes me to the "select matching existing transaction" dialog showing the import record in the top half and nothing in the lower "potential splits matching..." section, and no apparent mechanism for me to manually select the proper matching transaction. Help/wiki had no further info.
16:05:50 <tmetro> (It irks me that Pidgin never warns when you exceed IRC line length.)
16:09:42 *** sbluhm has joined #gnucash
16:11:26 <jralls> If it didn't find a matching transaction it doesn't have anything to offer. I don't know if there's a way to get it to show you the whole register. But if you know the transaction is already in there I think you can untick the A box and it will ignore it.
16:13:03 <jralls> Crud. AQBanking online account lookup is broken in 3.903.
16:14:12 *** sbluhm has quit IRC
16:15:12 <tmetro> I thought part of why you do an import is also to get an automatic reconciliation when transactions match.
16:15:12 <tmetro> But sure, just unchecking to ignore the line works in the case that the identical info is already entered.
16:15:12 <tmetro> What about when an update is required (such as a slightly off value)?
16:17:07 <jralls> No, it just turns the recocnile flag to cleared. You have to go through the reconcile dialog to actually reconcile.
16:17:28 <tmetro> ok. thanks.
16:19:20 <jralls> Well, that's what U+R is supposed to do, but if what you enter as the transaction description or the split memo is so different from what the bank enters then GnuCash doesn't know what transaction to update, so that doesn't help.
16:20:28 <jralls> So you have to fix it in the register just like you were reconciling with a paper statement.
16:20:52 <tmetro> Understood. But matching is supposed to be learning, and you'd teach it by manually selecting the matching transaction. Instead it seems that concept only extends to the selection of the category account.
16:20:58 <fell> David, you can also use the aq* command line tools to create/fetch your accounts. That would also give a hint, if tthe problem is i gnucash or aqbanking. An again, I would use the more recent aqbanking inside flatpak.
16:33:20 *** mohave has joined #gnucash
16:38:16 <mohave> I have been unsuccessful in building current master lately via xcodebuild. ninja works just fine. Tried using the latest cmake and that fails in the same place. Upgraded to the latest Xcode and same results. Here is the failure message: https://pastebin.com/1KSpYkDP
16:38:25 <mohave> Any ideas?
16:40:35 <mohave> Thanks!
16:44:59 *** tmetro has left #gnucash
16:46:32 *** User_ has joined #gnucash
16:49:14 *** ArtGravity has joined #gnucash
16:49:14 *** ChanServ sets mode: +v ArtGravity
16:50:04 *** ArtGravity has quit IRC
16:50:32 <jralls> mohave, looks like a reports.go has a dependency on the new-aging report that's not set up in cmake. Try adding reports_standard_SCHEME_2 to the DEPENDS line for gnc_add_scheme_targets(scm-rpt-reports in gnucash/report/reports/CMakeLists.txt
16:51:14 <jralls> chris: ^^^ This is your doing. Please stop making spaghetti out of report dependencies.
16:51:49 <jralls> biab
16:52:36 *** User_ has quit IRC
17:07:27 <mohave> I modified the statement to look like:
17:07:34 <mohave> gnc_add_scheme_targets(scm-rpt-reports
17:07:34 <mohave> SOURCES "${reports_SCHEME}"
17:07:34 <mohave> OUTPUT_DIR "gnucash"
17:07:36 <mohave> DEPENDS "scm-reports-standard-with-exposed-generator;${scm_rpts_GUILE_DEPENDS};reports_standard_SCHEME_2"
17:07:38 <mohave> MAKE_LINKS)
17:08:12 <mohave> Resulted in this:
17:08:16 <mohave> PhaseScriptExecution CMake\ Rules /Users/ctest/Source/gnucash/build/gnucash/report/reports/gnucash.build/Debug/scm-rpt-reports.build/Script-E946E362DA6E4071BCFDD7AD.sh
17:08:16 <mohave> cd /Users/ctest/Source/gnucash/gnucash
17:08:16 <mohave> /bin/sh -c /Users/ctest/Source/gnucash/build/gnucash/report/reports/gnucash.build/Debug/scm-rpt-reports.build/Script-E946E362DA6E4071BCFDD7AD.sh
17:08:18 <mohave> make: *** No rule to make target `/Users/ctest/Source/gnucash/gnucash/gnucash/report/reports/reports_standard_SCHEME_2', needed by `/Users/ctest/Source/gnucash/build/lib/guile/2.2/site-ccache/gnucash/reports.go'. Stop.
17:08:20 <mohave> Command /bin/sh failed with exit code 2
17:08:22 <mohave> ** BUILD FAILED **
17:13:37 <mohave> Strange to me that ninja will compile but not Xcode.
17:17:08 <mohave> That's why I was pointing fingers at cmake and Xcode
17:19:35 <jralls> mohave, sorry, a brain-fart on my part. The dependency should be the target, not the source variable. It would be DEPENDS "scm-reports-standard-with-exposed-generator;${scm_rpts_GUILE_DEPENDS};scm-reports-standard-2". But there's a problem: That target depends on scm-rpt-reports.
17:20:26 <jralls> So it's not surprising that it doesn't build with xcodebuild. It's surprising that it *does* build with ninja.
17:21:38 <jralls> CDB-Man_ I forgot to mention that if you run GnuCash-3.903 --extra the old reports are made available. They're named e.g. Balance Sheet (Legacy).
17:22:09 <CDB-Man_> jralls: got it, i'll append that to the shortcut run path
17:23:27 <CDB-Man_> okay, i think i have a sufficiently broken example for Chris now
17:23:51 <CDB-Man_> ... celebrated too early... wrong file
17:25:28 <CDB-Man_> Drat. replicating this erro in a new file is gonig to be harder than I thought... my actual ledger is far too complex (500+ accounts) for me to easily pinpoint
17:25:39 *** dtux has quit IRC
17:28:00 <CDB-Man_> hmm, running with --extra in the target, I don't see the old reports
17:29:04 <jralls> Hmm indeed.
17:31:12 <jralls> I just checked on MacOS and it worked there, installing the latest Windows nightly now...
17:34:57 <jralls> CDB-Man_ It works for me. Are you sure you put --extra in the right place in the shortcut?
17:37:32 <CDB-Man_> >> "C:\Users\CDB\Financial Statements\GNUCash Test File 2\CDB_Test.gnucash" --extra
17:37:32 <CDB-Man_> Is what I entered... unless I can't chain it to the file itself and need to do it on a direct exe shortcut
17:37:37 *** CDB-Man_ is now known as CDB-Man
17:39:03 <jralls> No, you need to put --extra on the shortcut to gnucash.exe, as in "C:\Program Files (x86)\gnucash\bin\gnucash.exe" --extra
17:40:10 <CDB-Man> directly on the exe shortcut works, i thought for sure I could do it on the file's shortcut and it worked beofre.... perhaps I'm remembering wrong... let's see if i can pinpoint the variaiton
17:41:29 <mohave> jralls: I know you have release scheduled for tomorrow, so no worries here, thanks for all your effort!
17:42:06 <jralls> mohave, that's not going to get fixed for tomorrow.
17:44:50 <CDB-Man> hmm, on initial inpsection, it might be because the new balance sheet report does not consdier closed book entries
17:45:11 <CDB-Man> retained earnings on my legacy b/s is $6k, on the new one is $113k
17:45:29 <CDB-Man> (the auto-calculated one, that is)
17:45:41 <jralls> That should be a feature, right? Closed book entries should be flushed to the actual retained earnings.
17:46:38 <CDB-Man> not sure what you mean by "feature" in this context, but I do use the "close books" tool to hard close and reduce all the P&L balances to 0
17:46:57 <CDB-Man> the legacy report reflects this correctly, as the retained earnniga accumulator only shows $6k, which is the current year P&L
17:47:14 <CDB-Man> the new report shows $113k, which is the lifetime amount covered by this gnucash file
17:47:35 <mohave> jralls, was not expecting it to and that is not what I intended to imply.
17:47:53 <CDB-Man> part of the change in behaviour is likely brought on by the fact that the new report now allows for some date range options to have balance sheets over time...
17:48:25 <jralls> Which is rubbish, there's no such thing as a balance sheet over time.
17:48:49 <CDB-Man> if you chek the general tab of the report settings
17:48:58 <CDB-Man> that's what the "period duration" stuff seems to try and do....
17:49:13 <CDB-Man> but otherwise I agree with you completely, balance sheets are at a point in time
17:50:20 <CDB-Man> i'm not quite sure what it tries to achieve, and also question the accuracy
17:50:54 <CDB-Man> the fact that the accumulator picks up on lifetime file P&L entries, probably also has something to do with my $60 variance not balancing, due to how that affects FX
17:51:02 <jralls> Maybe he has it in mind as some sort of diagnostic, creating a set of shadow accounts with only the transactions for a period. But it would be a rare period indeed where the inflows and outflows balanced perfectly.
17:52:05 <jralls> Well, comparing the old and new balance sheet numbers, what's different? IOW are total Assets the same on both reports, etc.
17:52:39 <CDB-Man> it seems that the period feature allows for creating comparative columns... if that's the case, i would expect the output per column to 100% agree to the legacy report
17:52:47 <CDB-Man> jralls: the asset side agrees 100%
17:53:14 <CDB-Man> all the variance is on equity
17:53:32 <jralls> Ah, right, it's not a balance sheet over time it's a two-column balance sheet with first date, second date.
17:54:05 <CDB-Man> I can see my manual retailed earnings account is $~100k on legacy (which is accurate, it's the total of all the closing entries in this file)
17:54:26 <CDB-Man> whereas on the new report, the balance is interstingly $19.90 (instead of $0 as I was expecting)
17:54:47 <CDB-Man> the accumulator retained earnings line, legacy report is $6k, new report is $113k, so that's where most of the balance went
17:55:04 <jralls> 6K + 100K != 113K.
17:55:10 <CDB-Man> the trading gains also mismatched, $91,276.72 legacy vs $9,217.94 new
17:57:06 <jralls> Getting closer, and supports your supposition earlier that exchange rates might be involved.
17:57:21 <CDB-Man> <jralls> 6K + 100K != 113K. <-- to be more precise: legacy $107,685.9 manual retaineed earnings + 5969.31 accumulator = 113,655.21. new report $19.90 manual + 113,635.31 = 113,655.21
17:57:37 <CDB-Man> hmm,
17:57:57 <CDB-Man> looks like if we set aside the "ignored" hard close entries for at bit, at least the total of retained earnings is correct
17:58:24 <CDB-Man> but for sure, it's the FX / unrealized that's an issue, and given this ignoring of hard close entries, likely the culprit
17:58:52 <CDB-Man> I'm curious why this $19.90 balance in RE is *not* being ignored like the other 99.99% of the balance....
17:59:11 <CDB-Man> $19.90 is 2 broker trade commissions at $9.95 each
18:00:02 <jralls> Oh, interesting. No doubt you've got more than 2...
18:00:37 <CDB-Man> Indeed, hundreds of equity trades
18:00:38 <jralls> Maybe there are 2 where you did something different, like rolling the commission into the trade net?
18:00:52 <CDB-Man> but for some reason, this particular one was not ignored
18:01:01 <CDB-Man> yeah, I'm trying to see if I can pinpoint
18:01:39 <CDB-Man> the $19.90 being precise dollars in CAD, it's won't be the culprit of the FX difference in the unrealized amount, and even if it was, $19.90 is not enough to cause the ~$60 FX variance
18:02:33 <jralls> So there's another imbalance besides R/E?
18:04:13 <CDB-Man> 1. The unrealized gains is clearly different between report versions
18:04:13 <CDB-Man> 2. Given that the new report "ignores" closing entries, and keeps all the P&L in the accumulator for R/E (my manual actual R/E account is nil), i would have expected it to be nil, but instead there's $19.90 that was "not ignored" and still sits there
18:04:29 <CDB-Man> #2 is not likely the cause of the difference in #1, it's just an interesting observation
18:04:57 <CDB-Man> aha, I've found the answer to the $19.90 quirk
18:05:51 <CDB-Man> okay, #2 is resolved, so you can disregard that one... it's really just why is there a difference in the unrealized gain
18:06:58 <jralls> What's the cause of the 19.90 and does fixing it make the out-of-balance ~$40 or ~$80?
18:07:34 <CDB-Man> working on it.... this $19.90, while identified, is not an easy fix...
18:12:08 <CDB-Man> the difference has changed slightly, the out of balance is now $58.79
18:13:39 <CDB-Man> ... nvm, the old out of balance was $91,276.72 legacy vs $91,217.94 = 58.78
18:13:44 <CDB-Man> so no impact
18:14:58 <CDB-Man> curisouly, if I run the new b/s dated 2018-12-31, there is only a 1 cent out of balance, but dated 2019-12-31 or dated 2020-06-06 (today) there is a non-rounding difference of this $~58
18:15:06 *** gjanssens has quit IRC
18:15:30 <CDB-Man> there were definitely ore f/x transiactions in 2019 vs 2018
18:15:46 <CDB-Man> that the legacy report handles, but not the new one, it seems
18:16:23 <CDB-Man> both using nearest in time
18:19:29 <jralls> You could find the first day of the larger imbalance by comparing 30 June 2019, if it's out 30 March if not 30 Sept and so on. That should make it possible to identify a transaction to analyze.
18:26:30 <CDB-Man> Good idea jralls , I'll try that after getting some dinner. After doing a quick analysis, I feel like the issue may relate to how the new report doesn't properly handle the 4010 yen that is sitting in my wallet
18:26:39 <CDB-Man> To be confirmed in an hour or so
18:27:44 <jralls> But that's only $36.59.
18:28:05 <CDB-Man> USD. Remember, I'm in CAD
18:29:59 <jralls> Right. But that's only $49.15.
18:30:37 <CDB-Man> The gross impact may be larger, due to the swing in buy price vs today's price too
18:31:57 *** dtux has joined #gnucash
18:32:00 <jralls> So you might have bought it when the CAD was higher and if GnuCash is ignoring it then it would be out by that much more. OK.
18:32:21 <jralls> Simple test, just delete it and see if the two reports agree. But after dinner.
18:49:17 *** dtux has quit IRC
18:49:21 *** ttcs has quit IRC
19:04:20 <CDB-Man> okay, so working backwards, its definitely the JPY transactions that the new report handles dirrerently than the old
19:05:05 <CDB-Man> cant say affirmatively yet though... i have JPY transactions from 2019-10-15 through to 2019-11-30, but as at 2019-10-31 it still balances
19:05:12 <CDB-Man> only in Nov does it start to not balance
19:07:39 <CDB-Man> hmm, 2019-10-30 balances, 2019-10-31 does not... lets see what's booked on the 31st... out of balance $22.77
19:17:42 <CDB-Man> ... there's nothing obviously out of place with transactions on Oct 31st...
19:18:29 <jralls> Are there any JPY transactions at all that day?
19:19:03 *** linas has quit IRC
19:19:37 <CDB-Man> yes, but the exact same transactions also happened on Oct 30th
19:19:44 <CDB-Man> ATM withdrawal
19:20:51 <CDB-Man> payrolll deposit hits on 31st, but that's all in CAD and same as prior pay period
19:21:04 <CDB-Man> I received a USD dividend, but that's the same transaction every quarter
19:21:27 <CDB-Man> USD 13.84, so not enough for the $22.77 diff
19:23:37 <CDB-Man> this is very odd that the new report generates a diff, but the old report does not
19:23:47 <CDB-Man> let's see what happens if i run the report not in common currency
19:24:15 <CDB-Man> oh wait, the legacy report only has common currency as a option...
19:25:18 <CDB-Man> interesting, running in non common currency, the new report breaks out the R/E accumulator into JPY, CAD, adn USD
19:25:45 <CDB-Man> JPY is $0, which makes sense as I do not have any JPY denominated gnucash P&L accounts
19:30:39 <CDB-Man> if in native currency, I cna tie the R/E accumulator to transactions, then I can at least eliminate accumulator issues as a cause
19:30:48 <CDB-Man> and then we can zero in on FX
19:55:58 *** dtux has joined #gnucash
20:20:11 <CDB-Man> jralls: well, on an individual basis, when using the new b/s report and disabling common currency, and reconciling the changes between the report on 2019-10-30 and 2019-10-31 on a per currency basis, the change in accumulator for CAD and USd both check out to the underlying transactions
20:20:22 <CDB-Man> there's no JPY denominated transactions on this date
20:20:37 <CDB-Man> so the delta in the reports is purely based on how the USD is being converted to CAD, it seems
20:26:48 <CDB-Man> when I enable "show exchange rates, it only shows the rate to 2 decimal places. ie US$1.00 = $1.3100 ... even though in price database it stores it to 4. can I get the report to show more somehow, so that I can see if it is a rate variance?
20:27:09 <jralls> CDB-Man Interesting. There's an exchange rates option that will print the rates at the bottom of the report. Does that shed any light on it?
20:28:27 <CDB-Man> both reports are on "nearest in time (to the report date, 2019-10-31)" -- when I change to "most recent (i.e. use the fx rate as of today, 2020-06-06)", a difference still persists
20:29:13 <CDB-Man> so it's something to do with how the accumulator is accumulating foreign currency (USD in this case) and converting to CAD, and no obvious trigger as to why Oct 31st is the turning point
20:29:39 <CDB-Man> it's not JPY since there's no JPY P&L accounts impacted
20:32:14 <jralls> Roger on JPY. No, I don't know of any way to get it to display the rates in more than pennies. Are the USD transactions on 31 October so large that the $22 difference is in fractions of a penny?
20:33:45 <CDB-Man> the only USD transaction is $13.84 USD, and the USD accumulator change is $13.84 from Oct 30th to 31st, so that's been accumulatoed properly
20:34:12 <CDB-Man> the transaction splits are the same as the dividend paid the quarter prior, so it's not like the split is funky or anything
20:35:05 <CDB-Man> the new b/s is _lower_ than the legacy b/s by $22.57 in CAD terms
20:35:36 <CDB-Man> when I reverse engineer the FX rate, it is 1.3126 which is the last fx rate in my price database, so that checks out
20:35:57 <CDB-Man> it's too bad the legacy report doesn't have an option no not report in common currency, else i could do some more isolation there
20:36:30 <CDB-Man> i was about to say its possible the legacy report is actualy the one that's incorrect.... but that wouldn't make sense, as th elegacy report balances
20:36:34 <CDB-Man> it's the new one that doe not
20:37:02 <jralls> I dunno. I guess we'll have to wait for chris to notice the bug. He can probably supply some scheme for you to paste in and extract more information from the reprots.
20:37:08 <CDB-Man> the asset side of the report is the same for both, so they are using the same logic for FX on that side
20:37:14 <CDB-Man> and there's no deviation on Oct 30th or 31sr
20:37:16 *** David has quit IRC
20:37:41 *** David has joined #gnucash
20:38:22 <CDB-Man> hmm, the manual retained earnings on legacy + the accumulator retained earnings on legacy = the retained accumulator on the new report....? interesting, I think i need to prod around a bit more
20:38:28 <CDB-Man> and double check that math
20:39:30 <CDB-Man> okay, so the issue is NOT in the r/e accumulator
20:39:35 <CDB-Man> it's actually in the unrealized gains
20:40:05 <CDB-Man> when I manual add what I expect to be in the accumulator per legacy report vs new report, they are the same
20:40:21 <CDB-Man> the variance is in the trading gains (legacy) vs unrealized gains (new) line item
20:40:42 <CDB-Man> this, given that it is based on the trading accounts, may be impacted by JPY cash balances
20:40:56 <CDB-Man> though again, there were JPY cash transactions that pre-date oct 31st, and they are all fine
20:41:15 <CDB-Man> e.g., I withdrew JPY from an ATm on oct 30th and 29th, and those caused no issues
20:41:36 <CDB-Man> the transaction template is the same, same 5 splits into the same accounts, so i'm not changing the process or anything
20:53:19 *** omnireq__ has quit IRC
20:53:30 *** omnireq__ has joined #gnucash
21:20:19 *** omnireq__ has quit IRC
21:20:39 *** omnireq__ has joined #gnucash
21:27:04 *** dtux has quit IRC
21:30:47 <CDB-Man> hmm, if i run the legacy report with ONLY my CURRENCY trading accounts selected, it reports trading loss of $126k, whereas the new report shows $0.00. i was hoping to check all the trading account with both reports, to see if they were accumulating trading gains differently
21:30:51 <CDB-Man> looks like that wont be possible
21:33:18 <CDB-Man> on the new report, if I select only lets say my JPY cash asset, then on the right hand side it will show the associated currency trading gain/loss amount
21:33:26 <CDB-Man> on the old report, can't get any similar functionality
21:33:59 <CDB-Man> old report it's all or nothing, select the entire currency account or dont. new report it attempts to associate only that portion of tradin gain/loss with the associated assets selected
21:38:01 <CDB-Man> the JPY balance on that day was 170,675 -- both reports outbut the same JPY balance and the same CAD balance on the asset side
21:38:30 <CDB-Man> it's only on the unrealized gains where there is a difference, but i cannot isolate the currency only amount, due to all my other stock holdings also being mixed in
21:41:49 *** omnireq__ has quit IRC
21:42:18 *** omnireq__ has joined #gnucash
21:42:20 *** frakturfreak has quit IRC
21:46:20 *** guak has quit IRC
21:59:16 *** fell has quit IRC
22:00:07 *** fell has joined #gnucash
22:00:07 *** ChanServ sets mode: +o fell
22:03:19 *** omnireq__ has quit IRC
22:03:30 *** omnireq__ has joined #gnucash
22:14:13 <chris> jralls: sorry for new-aging. I am not familiar with CMake enough to figure it. new-aging has code to call new-owner, similar to aging calling owner.
22:15:32 <chris> new-balance-sheet can compare balance sheet at separate dates.... useful for people who move money around
22:17:52 <chris> new balance-sheet also has capability to link the account split on the balance sheet date. ditto new multicolumn income-statement will link to a Transaction Report that illustrates IS period.
22:17:58 <chris> IS=income-statement
22:18:16 <CDB-Man> hmm, after printing all the fx and stock prices on both reports, they are both pulling the same pricing (notwithstanding the decimals beyond 2 that I can't see for USD and JPY...) so it's something else in the logic for unrealized gains that is different
22:18:18 <chris> CDB-Man: they were in beta for a long time, in the Experimental menu.
22:18:40 <CDB-Man> [2020.06.06 22:18:18] <chris> CDB-Man: they were in beta for a long time, in the Experimental menu. <-- ah, so that's why I didn't notice
22:18:55 <chris> CDB-Man: is the Balance Sheet eguile version correct for you?
22:19:10 <CDB-Man> hmm, i've never used eguile before -- what's the difference?
22:19:47 <chris> it's another report written by someone else, less old
22:20:28 <chris> it was meant to be the 'new-wave' of reports but they gave up halfway through
22:21:03 <CDB-Man> we'll find out momentarily
22:22:13 <CDB-Man> An error occurred while running the report.
22:22:15 <CDB-Man> well now!
22:22:28 <chris> how odd
22:22:52 <CDB-Man> [...]
22:22:52 <CDB-Man> In unknown file:
22:22:52 <CDB-Man> 0 (make-list -1 "<td class=\"empty\"></td>")
22:22:52 <CDB-Man> Value out of range 0 to 4294967295: -1
22:23:32 <CDB-Man> okay, it crashes when i limit sub accounts level to 2
22:23:39 <chris> ok
22:23:46 <CDB-Man> 3 or more is fine
22:23:47 <CDB-Man> how odd
22:23:53 <chris> mind a few observations about new balance-sheet: 1. I'm no accountant (I'm actually an MD) 2. I wrote these newer reports to scratch my own itches, and made them as good as I could 3. older reports are obviously more well tested but are a maintenance nigthmare because no one knows how they work
22:24:16 <CDB-Man> secret sauce indeed
22:24:16 <chris> 4. the new reports are swapped because generally they are nicer than old ones
22:24:21 <CDB-Man> you're doing pretty good for an MD
22:24:51 <chris> I don't mind at all whether they are swapped (I resisted) but it means subtle bugs are never found until a capable CPA takes notice
22:25:32 <CDB-Man> well, if it's any consolation, the eguile versino also does not balance
22:25:42 <chris> \o/
22:25:48 <CDB-Man> it's out by more
22:25:52 <CDB-Man> wait
22:26:02 <CDB-Man> hold on, it's presented differently, i need to scroll down more
22:26:32 <CDB-Man> it balances
22:26:42 <chris> yup. someone complained the RE section shouldn't be expanded in eguile version
22:26:48 <CDB-Man> agrees to the cent with the legacy report
22:27:17 <CDB-Man> expanding the RE secton adds no value... it's what the income statement or a statement of chagnes in equity is for
22:27:53 <CDB-Man> honestly without sending you my whole file, i dont think i can feasibly show you a dataset with my out of balance
22:28:07 <CDB-Man> i tried creating example, but nothing can match my 500 account production dataset
22:29:08 <CDB-Man> whatever eguile does for trading gains, it agrees with legacy
22:29:28 <CDB-Man> hmm
22:29:38 <CDB-Man> actually, sicne eguoille breaks down traiding gains per line item
22:29:47 <chris> ok. If you have isolated the discrepancy with Retained earnings calculator then it's a good clue
22:29:51 <CDB-Man> i might be able to use this to identify vsi a vis new report, which item is causing the out of balance
22:30:08 <CDB-Man> chris did you read the entire volume of comments in this channel / cc'd to the ticket?
22:30:25 <CDB-Man> or at least, the summary points the precede each transcript?
22:30:29 <chris> ^ loosely, not the actual numbers discussed
22:30:45 <CDB-Man> it's not the RE accumulator, it's the trading gains accumulator that is at issue
22:30:59 <CDB-Man> basically all the FX flux and the stock price flux
22:31:03 <chris> the "unrealized gains"?
22:31:23 <CDB-Man> yes
22:32:19 <CDB-Man> on oct 30th the reports ar ethe same (out by $0.01). on oct 31st, they are out by $22.57 out of balance on the new report... and the difference persists.. already analyzed all transactions on oct 31st, and it''s not a transactin issue, hence why I'm concluding its not the RE accumulator
22:32:53 <CDB-Man> (that and, I really dont like how the RE accumulator ignores closing entries as mentioned in comment #5... -- but that doesnt impact the problem at hand)
22:32:53 <chris> FWIW the old balance-sheet has a subtle bug which I didn't fix: it calculates TRADING-GAINS (i.e. from Trading-XXX splits) but chooses to show it depending on the book "Use trading gains" status... This means if user enables trading accounts, does check&repair, and disables trading accounts, the old balsheet will be incorrect
22:33:36 <CDB-Man> well, ive had them on since day 1, and the reports are immor images until oct 31st
22:33:51 <CDB-Man> if it was something that structurel, i would have expected the reports to be permanently different
22:34:00 <CDB-Man> rather than only have a difference creep up on a specific date
22:34:12 <CDB-Man> its not like i dont have stocks and foreign currency prior to that date
22:35:28 *** TownsendHardware has quit IRC
22:37:21 <chris> I'll follwup on bug when I can think of suitable fix candidates
22:37:34 <CDB-Man> hmm, there's no easy way to compare the eguile breakdown of trading gains vs your new version
22:37:39 <CDB-Man> since they accumulate differently
22:37:44 <chris> do you use "Trading accounts"?
22:38:01 <CDB-Man> but at least eguile matchnig legacy 100%, means that what it presents should be accurate
22:38:09 <CDB-Man> [2020.06.06 22:33:36] <CDB-Man> well, ive had them on since day 1, and the reports are immor images until oct 31st
22:38:16 <CDB-Man> so yes
22:38:19 <chris> ah
22:38:29 <chris> bingo
22:38:46 <chris> new report doesnt take them at all -- because from my experiments they didnt affect the UG at all
22:39:09 <CDB-Man> .... well...
22:39:22 <CDB-Man> again, i want to emphasize that if i date both reports 2019-10-30, they are the same
22:39:34 <CDB-Man> but when i advance the date to 2019-10-31, they mismatch, permanently
22:39:48 <CDB-Man> and its not like i didnt have forex and stocks prior to 2019-10-31
22:41:04 <CDB-Man> [2020.06.06 22:38:46] <chris> new report doesnt take them at all -- because from my experiments they didnt affect the UG at all <-- i like how when in your new report, if i for example select only the JPY cahs balance, the equity side accumulates the unrealized gain/loss on JPY to CAD
22:41:21 <CDB-Man> in theory, the inclusing of trading accounts ought to give the exact same answer
22:41:34 <CDB-Man> the fact that it doesnt... baffle me
22:41:54 <chris> "i like how when in your new report,..." --> this 'benefit' is unintentional
22:41:58 <CDB-Man> and it baffles further that it works for all dates (that i sampled) prior to 2019-10-31, but not all dates 2019-10-31 or after
22:42:47 <CDB-Man> well, using theis benefit, i could for example pick my MSFT stock and compare it to eguile's trading gains accumulation
22:42:54 <CDB-Man> i can do this easily for stocks... not so much for currency
22:43:07 <CDB-Man> since currency is used to purchase stocks, so there's multiple layers of complexity
22:45:42 <CDB-Man> hmm, for your new report,choosing only my back accounts shows the unrealized gain on the right side, but choosing a stock account yields zeros
22:45:48 <CDB-Man> so i cant use that to diagnose
22:45:51 <chris> I gtg now, breakfast. If this upgraded report isn't accurate, maybe it should return to beta status. My time on hacking will be severely reduced in a couple of months
22:46:07 <CDB-Man> that or, i chose an empty account... i have multiple MSFT accounts...
22:46:52 <CDB-Man> well chris, the likelihood of inaccuracy is definitely proportional to the complexitty of the register... and mine is definitely high on the coplexity scale
22:47:05 <CDB-Man> i havent kicked all the tires yet on IS, but that one seems more sound
22:47:14 <chris> so, maybe jralls will prefer swap the reports back to where they were (balance-sheet, income-statement, new-aging etc)
22:47:43 <CDB-Man> aging as in A/R aging?
22:48:01 <chris> mutlicol-IS will be a hoot... I made assumptions on that one (eg what date to use for currency conversions? let's pick the end date for each period)
22:48:09 <chris> yes new-aging IMHO better than old-aging
22:48:20 <CDB-Man> i don't use that report, so can't comment on that one
22:48:24 <CDB-Man> i only use the customer report
22:48:29 <chris> that too
22:48:52 <chris> try the Customer Report Display/Links option
22:49:02 <CDB-Man> the custome one ive been using beta for a while, so tired have been kicked on that
22:49:33 <CDB-Man> ... i just noticed all my previously open customer reports are dead
22:49:38 <CDB-Man> presumably due to the switch
22:50:35 <CDB-Man> yeah, I quite like the display detailed links optiom
22:52:03 <CDB-Man> in terms of styling, i really think that in the new reports, all parent accounts need to be highlighred. either highlight yellow (on technicolour), or put in the accounting style rule on the indent to show that the indended items are a subtotal
22:52:32 <CDB-Man> <chris> I gtg now, breakfast. <-- hmm, Australia / HK timezone?
22:54:26 <CDB-Man> hmm.... yeah if i filter for my MSFT holding, your report on the equity side shows the net gain, which I can only get from eguille if I include both the MSFT tading account and the corresponding offset amount in CURRENCY:USD, and there's no easy way to pick that one out
22:54:33 <CDB-Man> from eguile
22:57:17 <CDB-Man> for debug purposes, if your new b/s report were to print the complete breakdown of the unrealized gains, the i could compare it side by side to eguile, and see where it falls apart
22:58:19 <CDB-Man> the fact that your assets agree to legacy and to eguile means it's definitely on the unrealzied size, but it still puzzles me greatly why i only see errors after 2019-10-31, especialyl after having done a detailed transacton analysis....
23:17:33 <chris> from my #6 patch typo - use-trading-accts?
23:18:52 <chris> AWST here :)
23:22:39 <CDB-Man> Perth?
23:23:44 *** mohave has quit IRC
23:24:03 <CDB-Man> lets see the typo fix
23:24:10 <chris> yes
23:24:14 *** mohave has joined #gnucash
23:24:25 <CDB-Man> okay, different error
23:27:14 *** mohave has quit IRC
23:27:35 <chris> CDB-Man: you'd do well to learn yourself some scheme :)
23:27:54 <CDB-Man> the only schemes i seem to learn about are tax and accounting schemes....
23:29:06 <CDB-Man> the last time i did any coding is back in 2009 in Java 1.4.1
23:29:13 <chris> it's been said many times that "MS Excel is the most widely used functional programming language"
23:29:25 <chris> typo fix submitted
23:30:03 <CDB-Man> I do a lot of data hacking in excel, thats for sure
23:30:18 <CDB-Man> picked up on your comment #10 and there's another, another error :)
23:30:29 <chris> https://gotocon.com/amsterdam-2016/presentation/Pure%20Functional%20Programming%20in%20Excel
23:30:32 <CDB-Man> In srfi/srfi-1.scm:
23:30:32 <CDB-Man> 592:17 3 (map1 (0))
23:30:32 <CDB-Man> In gnucash/reports/standard/balsheet-pnl.scm:
23:30:32 <CDB-Man> 540:31 2 (_ 0)
23:30:32 <CDB-Man> 522:29 1 (sum-accounts-at-col (#("Trading Gains" (#<swig-…> …))) …)
23:30:34 <CDB-Man> In unknown file:
23:30:37 <CDB-Man> 0 (_ 0)
23:30:39 <CDB-Man> Wrong type to apply: (#<swig-pointer Account * 13cd6448> #<swig-pointer Account * ---- etc
23:31:06 <CDB-Man> 90% of my time at work is in Excel
23:35:07 <chris> Ok now have gtg for sure. If balsheet-pnl isn't acceptable yet then maybe it needs to remain in beta. Let jralls know what you think.
23:35:51 <chris> I'll have to pick this up during the week.
23:35:58 <CDB-Man> thanks chris. i think for regular use it's probably fune, but I donn't know what's the tipping point of "how complex is too complex" for it to break
23:36:07 <CDB-Man> and I don't know how complex some of our users get
23:36:50 <CDB-Man> i'm probably on the much higher end, and if there's anyone using this for a small business with shipping to multiple currencies, i would think they probably have a chance to hit similar issues
23:45:38 <chris> last minute patch submitted.
23:46:46 *** phebus has quit IRC