2020-08-16 GnuCash IRC logs
00:03:32 <CDB-Man> chris: just uploaded
00:03:40 <CDB-Man> see also comment sin ticket
00:05:55 <CDB-Man> okay, i think that's about all the output I can handle for today, so nothing further new from me. if you manage to make shorts work before either you leave for the morning, or i leave for the night, I can kick the tires on that
00:50:06 <chris> cdb-man: interesting that your sale-value doesn't include cap gains
00:50:19 <CDB-Man> hmm?
00:50:29 <CDB-Man> oh, you mean the split?
00:50:48 <CDB-Man> the reason is to have gnucash function properly...
00:50:49 <chris> your column I proceeds-val - gives me 18000 in SPY->USD but you want 12000
00:50:59 <CDB-Man> or at lest my definition of properly....
00:51:09 <chris> this means we need another option: asset-account for sale proceeds
00:51:14 <CDB-Man> whenever your split involves stock units, it should be done at gross
00:51:28 <CDB-Man> and the non-unit split going into the stock account is where the gain/loss resides
00:51:52 <CDB-Man> wait, are you talking about the excel or the book, chris
00:51:57 <chris> excel
00:52:39 <CDB-Man> well, proceeds is exactly that, the actual proceeds received from disposition
00:52:49 <CDB-Man> proceeds means specifically cash in hand
00:53:19 <CDB-Man> capital gain (loss) = proceeds (actual cash transacted) -- cost basis (computer)
00:53:27 <CDB-Man> s/computer/computed
00:53:54 <CDB-Man> so proceeds would of course never "contain" the gain or loss
00:54:35 <chris> ok. I think we do need a proceeds account option then - which will be your USDCash acct
00:55:06 <CDB-Man> hmm, but what if someone sells the security into multiple proceeds accounts?
00:55:25 <CDB-Man> for example, when I sell a stock, I have the option of depositing it in 1 of 2 of my broker's USD accounts
00:55:35 <CDB-Man> it doesnt always have to be the same account
00:55:45 <chris> well how to calculate 12000?
00:56:32 <chris> (a gnucash question, not arithmetic question...)
00:56:43 <chris> ^ analyzing 18/03/2020 txn
00:57:08 <CDB-Man> the 12000 is given to you
00:57:12 <CDB-Man> its not a calculated value
00:57:16 <CDB-Man> the user has to provide it
00:57:29 <CDB-Man> oh, i see what you mena now
00:57:42 <CDB-Man> okay, you cannot identify it just from looking solely at the register for the stock
00:57:46 <CDB-Man> hmm, I see your issue
00:58:00 <CDB-Man> and likewise for commissions
00:58:10 <CDB-Man> hence why you requre the commissions as n input
00:59:01 <CDB-Man> as a tangent, my solution ofr commissions was to use the "fee" flag rather than looking for specific accounts, but these flags are definitely not consistntly used by users, and its still not obvious if they have other knock on effects or not
00:59:08 <CDB-Man> but there's no flag available for proceeds
00:59:17 <chris> ^exactly
01:00:39 <CDB-Man> maybe the solution is to make both the commission selector and the cash selected
01:00:42 <CDB-Man> selector*
01:00:47 <CDB-Man> use the tree based selecting mechanism
01:00:53 <CDB-Man> so that multiple accounts can be specified?
01:01:11 <CDB-Man> so each should probably have its own tab, if that's the case
01:01:28 <chris> so the solution is that proceeds must be an option
01:01:35 <chris> i'll keep it 1-account for now for simplicity
01:02:08 <CDB-Man> indeed
01:02:36 <CDB-Man> i suppose you could do reverse math and get the proceeds by subtracting the gain and fee, but that assumes everyone actually inputs all of those properly
01:02:42 <CDB-Man> probably safer to pull the proceeds directly
01:02:47 <CDB-Man> that way we know with cetainty
01:02:51 <CDB-Man> cause cash is king!
01:05:29 <chris> i'll keep it 1-account for now for simplicity
01:05:32 <chris> oops
01:09:15 <chris> CDB-Man: your sale/purch inconsistency between short-sell and longs isn't good
01:09:27 <chris> I want 1 formula to determine purchase-val from txn-data
01:09:36 <CDB-Man> it is sadly the only way to d it within 1 tool
01:09:50 <CDB-Man> otherwise you would need a separate tool
01:10:04 <CDB-Man> a short sale is a "negative" purchase
01:10:10 *** SEOboss has quit IRC
01:10:25 *** qwer has joined #gnucash
01:10:27 <chris> hmm
01:10:27 <CDB-Man> if i were to continue using proceeds for short sales, well you wouldnt accumulate any cost basis
01:10:42 <CDB-Man> mathematically, you can see its the exact same formulas
01:10:51 <CDB-Man> that elegance is lost if you try to make anything separate
01:11:00 <CDB-Man> since it would become an order of magnitude more complex
01:11:28 <chris> so. to determine short-sell status I can use: delta-units is negative, and accumulated-units <= 0?
01:11:47 <CDB-Man> indeed
01:11:49 <CDB-Man> and note that
01:11:56 <CDB-Man> if you see the 2 transactions on june 10th
01:12:02 <CDB-Man> 915+85=1000
01:12:08 <CDB-Man> it's a single 1000 sale block
01:12:19 <CDB-Man> but the user needs to consciously break it apart
01:12:32 <CDB-Man> the 915 being a closing of the currnet LONG position, and hence realise a gain/loss
01:12:42 <CDB-Man> and the remainder -85 being opening a SHORT position
01:12:45 <CDB-Man> hence a new purchase
01:13:10 <CDB-Man> from a trading mechanics perspective, you're "just selling 1000 shares"
01:13:25 <CDB-Man> but in terms of tracking positions, well, it's a sale + opening a new position
01:13:38 <CDB-Man> so yes, which side of the 0 you alnd on matters
01:13:46 *** qwer has quit IRC
01:13:50 <CDB-Man> and negative delta on a current balance of 0 or lower, is short
01:26:14 *** qwer has joined #gnucash
01:27:27 <chris> ok nearly there. on 18/06 I'm getting proceeds-val = 9.95 instead of -5000.
01:27:48 <chris> how to analyse 18/06 to get -5000?
01:29:39 *** qwer has quit IRC
01:29:45 <chris> ah because your 5000 wento to Asset:SPY rather than Asset:USDBank
01:30:11 <CDB-Man> hmm
01:31:03 <CDB-Man> is it because you are checking for only debits to the cash account?
01:31:41 <CDB-Man> also intreresting that your porceeds is +9.95 not -9.95
01:31:47 <CDB-Man> unless that;s just a typing oversight
01:32:52 <chris> yes was analyzing cash acct
01:32:55 <CDB-Man> for all "dispositions", i add the text descriptions in th ememo
01:32:58 <chris> yes was analyzing proceeds acct
01:33:00 <CDB-Man> so that should help
01:33:03 <CDB-Man> net proceeds being cash
01:33:11 <CDB-Man> gross proceeds being # units * unit price
01:33:30 <CDB-Man> gross profit being proceeds minus ACB (before commissions, hence gross)
01:40:53 <chris> Hmm you'll have to explain how you obtained the purch-val and proceeds-val for the short-sell txns
01:41:25 <chris> why B28 * 140
01:43:32 <chris> see latest github - purch/proceeds are fine except the 9.95 one
01:43:55 *** David has quit IRC
01:44:03 *** David has joined #gnucash
01:48:25 *** qwer has joined #gnucash
01:51:46 <chris> CDB-Man: I wonder if your 18/06/2020 is recorded correctly - the USD_Cash split has value=-5009.95 but amount=0
01:51:56 *** qwer has quit IRC
01:52:00 <chris> see the uncompressed XML search for f07c11f6c492431193c813cf4e28729e
01:52:01 <CDB-Man> well
01:52:08 <CDB-Man> you have the gnucash file if you wanna check the XML
01:52:09 <CDB-Man> :)
01:52:44 <CDB-Man> hmm maybe its because its missing the values in the shares and price column
01:52:55 *** fell has quit IRC
01:52:59 <CDB-Man> yes, that has got to be it
01:53:01 <chris> may be a data-entry error
01:53:47 *** fell has joined #gnucash
01:53:47 *** ChanServ sets mode: +o fell
01:54:02 <CDB-Man> got it
01:54:04 <CDB-Man> chris do this
01:54:04 <CDB-Man> https://i.imgur.com/LyVAiMx.png
01:55:05 *** hannes has joined #gnucash
01:56:20 <hannes> Hello, is it possible to display in the accounts-tab just all active accounts and to hide all placeholders?
01:56:26 <chris> please resend - i can't rid trading:cad acct
01:56:37 <CDB-Man> chris: already done
01:56:40 <CDB-Man> just uploaded to ticket
01:57:15 <CDB-Man> hannes: i think you can only hide accounts with the hidden flag turned on
01:57:24 <chris> bingo
01:57:26 <CDB-Man> most people want to see placeholders, since they are your hierarchy
01:57:42 <CDB-Man> chris: is that bingo ad my file, or at his question? lol
01:58:18 <CDB-Man> hannes: actually, in the View Menu, go to Other tab, and you could uncheck "show zero total accounts
01:58:22 <CDB-Man> thjat might achieve the same thing
01:58:34 *** qwer has joined #gnucash
01:58:58 <chris> CDB-Man: bingo to data entry. Now try latest on github :)
01:59:17 <CDB-Man> okay, downloading
01:59:37 <chris> the data-entry error is partly why I'd want some report to do 'data-integrity report'
02:00:01 <chris> I already have some work pending to reverify all balance assertions i.e. reconciliation balances at bank statements
02:00:02 <hannes> CDB-Man: I understand, but sometimes it is quite cumbersome to go to a specific account and open all the placeholder to go down the hirarchy.
02:00:07 <CDB-Man> chris: i womnder if thats what was causing nmy $0 issue with SPY on the balance sheet
02:00:22 <CDB-Man> though that only occured for exactly 10 shares, so i doubt it. but its probably related
02:01:04 <CDB-Man> > in the View Menu, go to Other tab <-- I forgt to say go to the Filter option in the View menu @ hannes
02:01:41 <hannes> unchecking the zero accounts is also not the thing I'm looking for as I want to see all my accounts even if they are empty at the moment.
02:01:51 *** qwer has quit IRC
02:02:01 <hannes> is there a way to collapse and uncollapse the complete hirarchy?
02:02:06 <CDB-Man> well, then your only choice in the current environment is to mark accounts with the hidden flag as well
02:02:10 <CDB-Man> then filter those out
02:02:28 <CDB-Man> collapse entire hierarchy yes, just collapse the top levle parent. uncollapse, no
02:03:27 <CDB-Man> you could also CTRL I and use the find account feature
02:03:39 <CDB-Man> (or Edit menu > Find account)
02:04:21 <hannes> if I hide a placeholder which has accounts underneath they will be hidden as well :-(
02:05:12 <CDB-Man> chris this works quite well it seems!
02:05:18 <chris> \o/
02:05:48 <CDB-Man> it's a bit past time to hit the sack, but i'll have to leave futher stress testing to tomorrow
02:05:55 <CDB-Man> but this is quite a bit of progress
02:06:06 <CDB-Man> s/but/so
02:06:21 <CDB-Man> (on the 1st message's but)
02:07:49 *** dtux has quit IRC
02:10:03 <CDB-Man> i'll see if i can come up with siome more convoluted (but still common enough that it should be considered) scenarios tomorrow to stress test
02:10:19 <CDB-Man> but i think we cover 95+ of occurrences
02:10:26 <CDB-Man> 95%+ *
02:12:54 <chris> don't forget the remaining 5% = documentation :)
02:14:06 <CDB-Man> by 95% i meant 95% of likely transactions
02:14:26 <CDB-Man> as in im not gonig to try and model the odd p > 0.05
02:14:52 <CDB-Man> the best documentation is probably just to upload that gnucash file as an example somewhere
02:14:59 <CDB-Man> and/or take screenshots from it
02:15:10 <CDB-Man> I can also add more text into the memo splits for narration
02:17:01 <chris> The idea is to teach users how things should be recorded, so they don't try to massage the data in spurious ways then demand the report fits their flawed assumptions
02:18:17 <CDB-Man> indeed. and what better way to do that than to give someone an actual gnucash file with all the examples
02:18:31 <CDB-Man> I'll beef up the memo notes in that file... tomorrow
02:19:53 <chris> the report handles FX well too I think
02:20:46 <CDB-Man> inedeed, but i cant really test that easily since the neirest neighbour fx pricing doesnt equate to whats in my spreadsheet
02:20:57 <CDB-Man> i suppose i could manaully replicate the necessary prices into price db....
02:21:00 <CDB-Man> tomorrow!
02:21:45 *** qwer has joined #gnucash
02:27:08 <CDB-Man> k i'm out, gnight (or g'day in your case)
02:27:44 <chris> Nite!
02:38:26 *** qwer has quit IRC
02:44:50 *** Aussie_matt has joined #gnucash
02:54:01 *** qwer has joined #gnucash
02:54:04 *** dtux has joined #gnucash
02:57:01 *** qwer has quit IRC
03:22:11 *** qwer has joined #gnucash
03:24:41 *** David has quit IRC
03:24:49 *** David has joined #gnucash
03:25:21 *** qwer has quit IRC
03:44:57 *** lmat has quit IRC
03:47:55 *** lmat has joined #gnucash
03:55:22 *** qwer has joined #gnucash
04:00:57 *** qwer has quit IRC
04:06:23 *** lmat has quit IRC
04:09:28 *** lmat has joined #gnucash
04:11:52 *** JayC has joined #gnucash
04:11:53 *** ChanServ sets mode: +v JayC
04:16:29 *** hannes has quit IRC
04:16:44 *** lmat has quit IRC
04:17:56 *** dtux has quit IRC
04:19:46 *** lmat has joined #gnucash
05:00:35 *** lmat has quit IRC
05:01:19 *** lmat has joined #gnucash
05:18:47 *** lmat has quit IRC
05:19:41 *** lmat has joined #gnucash
05:23:39 *** sbluhm has joined #gnucash
05:23:39 *** ChanServ sets mode: +v sbluhm
05:29:38 *** sbluhm has quit IRC
05:52:22 *** lmat has quit IRC
05:52:26 *** lmat has joined #gnucash
05:58:25 *** User has joined #gnucash
06:08:32 *** User has quit IRC
06:44:31 *** qwer has joined #gnucash
07:00:50 *** qwer has quit IRC
07:27:07 *** qwer has joined #gnucash
07:33:22 *** qwer has quit IRC
07:37:41 *** qwer has joined #gnucash
07:41:24 *** lmat has quit IRC
07:49:30 *** lmat has joined #gnucash
08:03:03 *** FH_thecat has joined #gnucash
08:04:59 *** qwer has quit IRC
08:07:15 *** qwer has joined #gnucash
08:39:01 *** qwer has quit IRC
09:45:56 *** Aussie_matt has quit IRC
09:46:20 <chris> jralls: I'll add CSV export for net-charts. This is now trivial.
09:56:56 <chris> jralls: if this direction of reports is not desirable feel free to revert.
10:19:39 <linas> jralls fell yes, the logs showed a merge conflict. I did a reset, it should be back to normal now. I think warlord has access to the site but maybe not...
10:22:37 *** qwer has joined #gnucash
10:26:19 *** qwer has quit IRC
10:36:05 <fell> Linas: Thanks! Beta looks nice again.
10:51:02 <warlord> linas, I do not.
10:51:10 <warlord> (at least I do not believe I do)
10:57:53 <chris> if linas is around, maybe I can ask why test-lots must iterate 30 times creating 320 transactions... takes 76s for no reason... is it a type of stress-test?
10:59:42 <linas> chris I no longer recall
11:00:15 <linas> I don't even recall writing a unit test for it :-)
11:00:23 <chris> ok, no reason to keep it so long... IMHO of course
11:01:05 <linas> It might be trying to force something to wrap ...
11:01:08 <chris> IMHO test-lots has raised global warming by a midge for no reason ;)
11:01:40 <linas> I don't recall thinking much about threading, but lots of repeats is typical for something trying to trigger a thread race condition
11:02:33 <chris> .... well after creating 320 txns and scrubbing them, the comment says " * XXX not implemented"
11:03:12 <linas> maybe it was trying to trigger a rounding error? e.g. generaing random floats for prices, an getting a mis-balance?
11:04:12 <linas> heh "not implemented" ... maybe whatever it is should be implemented?
11:04:52 <linas> There was something about closing books or end-of-period or something that was unimplemented...
11:05:22 <chris> yes... period-archiving and new-book
11:06:11 <linas> it wasn't implemented because it was difficult and convoluted and I just got tired at that point ...
11:06:27 <linas> and I guess no one cares, no one wants or needs this?
11:06:54 <chris> both I guess
11:07:53 <linas> Hmm. Strange. The ability to "close the books" was considered to be a big deal, for a while.
11:08:37 <chris> Maybe the reality is we've all learned to cope without it
11:08:54 <linas> Heh.
11:11:58 <chris> still, no one knows what was the intent of test-lots, and how to trigger it.
11:12:24 <linas> ?
11:13:12 <chris> https://github.com/Gnucash/gnucash/blob/maint/libgnucash/engine/test/test-lots.cpp#L51
11:13:36 <chris> tests that it doesn't crash. ok. the next test for unrealized gains etc- not implemented.
11:17:47 <linas> Oh. OK, so "not crashing" seems a straight-forward test, and should not need lots of repetitions. There must have been some old, data-dependent crash once upon a time .. probably due to rounding errors.
11:18:16 <linas> some combination of values that left 0.000001 of something unbalanced.
11:18:48 <linas> On the other hand running 3200 transactions should not take 76 seconds .. that seems alaramingly excessive to me.
11:21:26 <chris> well... here you go. over time the transactions have accumulated a lot of crufty on-the-fly balance-checks.
11:22:49 <chris> gtg now
11:23:14 <linas> Yes, reduce the num-iterations from 10 to 1
11:23:40 <linas> but the "XXX not implemented" in the unit test just means .. the unit test should be strengthened, that's all .
11:23:55 <linas> by chris
11:29:00 * chris checking out now!
11:37:27 <chris> fwiw i know only modern api calls and these are very well tested thx to jralls. no idea how things like xaccSplitRegister does. so, no.
11:37:42 <chris> much appreciations towards the early groundwork though.
11:49:09 *** Unattributed has joined #gnucash
11:49:10 *** ChanServ sets mode: +v Unattributed
11:52:58 <Unattributed> I just migrated to Majaro linux (from PopOS! -- an Ubuntu based spin). Everything seems to have mgirated okay: opening files, adding / editing transactions, etc. However, it seems that I can't get quotes anymore. I tried running with --debug to see if there were any errors, but I didn't see any. All my funds/securities/etc are configured to get quotes from Yahoo in JSON format. GnuCash is version 4.0, and Finance::Quote is
11:52:58 <Unattributed> version 1.49. Any help is welcome.
11:54:16 <Unattributed> (And, yes, it was working before I migrated to Manjaro -- I have over a week of quotes in the database, which display properly.)
12:12:39 *** Unattributed has quit IRC
12:30:36 *** Unattributed has joined #gnucash
12:30:36 *** ChanServ sets mode: +v Unattributed
12:30:44 <fell> jralls, warlord: I don't see Jeblad in https://wiki.gnucash.org/wiki/Special:ConfirmAccounts.
12:31:46 <fell> Ah, because it was accepted.
12:34:43 <fell> Unattributed>, did you migrate your key for https://wiki.gnucash.org/wiki/Online_Quotes#Source_Alphavantage.2C_US
12:42:17 *** User has joined #gnucash
12:43:15 <Unattributed> fell, I'm not using Alphavantage -- I'm using Yahoo! as my source.
12:50:13 <jralls> Unattributed, do you mean yahoo_json or yahoo_yql?
12:50:26 <Unattributed> json
12:51:29 <Unattributed> Maybe I should set up an Alphavantage key...but as I was getting things up and running, I figured it was one less thing to worry about.
12:51:53 <jralls> Did you run gnc-fq-check to make sure that GnuCash can find FQ?
12:54:48 <Unattributed> I hadn't, and that may have identified the issue.... "Can't locate Mozilla/CA.pm in @INC (you may need to install the Mozilla::CA module)"
12:56:44 <jralls> chris, CDB-Man, I have something more elegant in mind for historical quotes. It may take several years before it has enough priority to do, and it probably depends on other engine changes to be practical.
12:59:47 <Unattributed> Well, I found the perl-mozilla-ca module and installed it -- now gnc-fc-check doesn't complain, but I still can't get price quotes...
13:00:52 <jralls> CDB-Man, Right now exchange rates apply only when a split's account commodity is different from the transaction currency. In light of your comments a few months ago about everything reducing back to the home currency I think that should change but it will be a very deep change indeed.
13:02:14 <jralls> Unattributed, next try gnc-fq-dump yahoo_json CSCO. If that works try some of your stocks.
13:06:28 <Unattributed> jralls: yup - worked for CSCO and several of my stocks...and now I see why I thought it wasn't working: Yahoo doesn't return "after hours" trading quotes... All the quotes in my database were from market close on Friday...and Yahoo is still returning the same quotes.
13:07:04 <Unattributed> (And, just to be certain, I tried stocks from several exchanges...)
13:08:53 <Unattributed> So, now I can get on with my real work for today... :) Thank you.
13:12:01 <jralls> There might be a way to get after-hours trading prices from yahoo, but F::Q doesn't know it. Most people regard those as not-real prices because they often represent thin or bogus trades and are contradicted early in the next normal session.
13:17:55 *** User has quit IRC
13:25:36 <Unattributed> jralls: makes sense... I was using it mainly as proof that everything was working correctly after my migration. Normally I wouldn't be checking quotes on the weekend. :)
13:27:06 *** dtux has joined #gnucash
13:27:24 <Unattributed> The other part of this was that I was planning to set up a cron job using gnucash-cli to update the quotes @ market open every morning...
13:35:57 <jralls> Unattributed, it would make more sense to run it every weekday afternoon after the close.
13:37:11 <jralls> Do remember that GnuCash is for accounting, not for trading. Do you really need/want daily prices?
14:19:10 *** sbluhm has joined #gnucash
14:19:10 *** ChanServ sets mode: +v sbluhm
14:28:17 *** frakturfreak has joined #gnucash
14:55:23 *** jw4 has quit IRC
14:56:00 *** jw4 has joined #gnucash
14:56:00 *** ChanServ sets mode: +v jw4
14:59:51 *** Mechtilde has joined #gnucash
15:04:18 *** Agfarmer18 has joined #gnucash
15:20:48 <Unattributed> jralls: It's more that I'm in a position at this time that I want to record daily quotes... If things were normal here, I'd probably only be getting quotes weekly.
15:21:11 <jralls> OK.
15:23:23 <Unattributed> Right now I'm trying to figure out why the mozilla-ca package didn't get installed... Sounds like a broken dependency somewhere, but I'm not sure if it's the F::Q package that should be updated, or the GnuCash package that should be updated. (IE, in the Manjaro distro...)
15:28:08 <Unattributed> Ahh - looking at meta::cpan it lists mozilla::ca as a depency for f::q -- so I'll report the broken dependency to the f::q package maintainer for Manjaro.
15:31:16 *** Mechtilde has quit IRC
15:34:44 <Unattributed> Weel, guess I don't need to report it...it's already been reported: https://bugs.archlinux.org/task/65347?project=5&string=perl-finance-quote
15:42:20 <CDB-Man> <jralls> CDB-Man, Right now exchange rates apply only when a split's account commodity is different from the transaction currency <-- hmm, can you take a look at the uploaded gnucash file in the ticket then? the involved splits are SPY (stock account with SPY being a USD stock), USD cash account, and USD commissions expense account. unless i have something coded incorrectly there someone? when I look at price DB, it has some CAD prices for SPY, buy not
15:42:20 <CDB-Man> sure how that would have sneaked into there given all the accounts are USD
15:44:49 *** Agfarmer18 has quit IRC
15:47:19 *** David has quit IRC
15:47:26 *** David has joined #gnucash
15:53:33 <CDB-Man> https://bugs.gnucash.org/attachment.cgi?id=373828&action=edit this file, that is
15:54:04 <CDB-Man> or perhpas yesterday's, before i corrected a related (?) input error https://bugs.gnucash.org/attachment.cgi?id=373825&action=edit
16:10:07 <CDB-Man> jralls: belh, final version of the gnucash file: https://bugs.gnucash.org/attachment.cgi?id=373829&action=edit ---- in particular, the 2nd last SPY transaction, the BUY to close short, every split is with a USD account, buy you can see the FX rates in there in the SPY account's register. and th rate is 1.000 of course since all USD https://i.imgur.com/PX3l2U3.png
16:10:22 <jralls> CDB-Man, all of the transactions in that book have CAD as the currency, as does the Root Account. The transaction currency is the currency of the account who's register you start the transaction in, or if that account is a non-currency commodity, the currency of the first parent account that has a currency. The parent of the SPY stock account is Assets:Broker Account and that is denominated in CAD.
16:11:00 <CDB-Man> hmm, am I correct to say then that STOCK tyle accounts are "currency agnostic... a nd inherit their currency from the parent account?
16:11:39 <CDB-Man> STOCK type*
16:11:43 <jralls> Not currency agnostic, but yes, they do inherit their currency from the nearest parent denominated in a currency.
16:12:26 <CDB-Man> I see. in my own book, all USD stocks have a parent of "XXX Broker:Account 123456:CAD" and "XXX Broker:Account 123456:USD"
16:12:34 <CDB-Man> all err
16:12:53 <CDB-Man> *** I see. in my own book, all stocks have a parent of "XXX Broker:Account 123456:CAD" and "XXX Broker:Account 123456:USD" depending on if the stock is CAD or USD (or JPY, HKD, etc)
16:13:27 <CDB-Man> so in my own case, I never get 3rd currency, since I've enforced 2 change rates (stock's native currency and stock price in said currency)
16:14:19 <CDB-Man> hmm, would a quick "hack" then to get everything priced in root currency (CAD in my book then) be to always hold all STOCk accounts in a CAD parent? though of course I get the feeling this will probably break things spectacularly if I just change those account parents today
16:16:50 <jralls> It will indeed break things spectacularly. But something else is amiss with that transaction: The file says that the transaction currency is CAD, but there are no splits to Trading:CURRENCY:CAD.
16:18:25 <CDB-Man> exactly! all splits are to USD accounts. the only way CAD weasels its way in... is what I learned from you just now regarding the parent being CAD, and thus (I suppose?0 making SPY a "CAD" account
16:18:35 <CDB-Man> even though it is a STOCk account of commodity SPY
16:19:09 <jralls> You didn't create the trading splits by hand, did you? They all have exchange rates on them to CAD: 1.00 for USD and 153.846 for SPY.
16:19:53 *** sbluhm has quit IRC
16:23:58 <CDB-Man> To be honest I don't remember
16:25:51 <CDB-Man> I was getting imbalance amounts, and my goal was to eliminate those as quickly as possible to make the example work for Chris to test. I think at one point I saw something wacky like 1 units for price 2357 for a 2357 capital gain, or something to that effect
16:25:57 <jralls> If I delete the two trading splits and let gnucash balance the transaction and re-create them the CAD->SPY price changes and the commissions split amount gets converted to SPY, which is really weird.
16:26:08 <CDB-Man> I didn't realize it was a CAD rate I was messing with
16:26:34 <CDB-Man> In my head I was thinking it's all USD, so on that basis I would have forced everything to price 1.0000
16:27:51 <CDB-Man> Yes, the null unit split to SPY for the commissions was giving a lot of grief
16:28:26 <CDB-Man> Needs to be null units, but the auto balancer didn't like that when trying to balance currencies
16:32:30 <jralls> Ah, that explains it. The amount is 4.98 SPY at $1.00. When viewed in the SPY register everything except the Gross P/L split is screwed up.
16:36:04 <CDB-Man> Wait
16:36:19 <CDB-Man> It should be 0.00 spy
16:37:13 <CDB-Man> Commissions don't add units, just increase the cost basis
16:39:19 <CDB-Man> jralls: on a separate but related note, the FX dialogue that appears when you enter a foreign currency split. That button to pull FX rate, is changing that from "pull today's rate" (current behaviour) to "pull rate on split date" am easy change?
16:39:55 <CDB-Man> This would at least let new transactions entered going forward have access to historical rates
16:40:24 <jralls> Changing the label is easy. Getting it to actually work requires completely rewriting online price retrieval.
16:40:27 <CDB-Man> (and for the ambitious among us, go and hand update some of the historical transactions)
16:41:48 <jralls> Not on this year's agenda, and unless c++options and in-memory-sql come together a lot faster than I think they will, not for GnuCash 5.0 at all.
16:41:48 <CDB-Man> Ah okay, so not an easy fix. In that case, at least changing the label to specify "this pulls today's price, not the price at transaction date" is a good idea. Label + a tool tip arrive m since the string is so long
16:42:47 <CDB-Man> I can file a text tweak ticket in this regard if you want one
16:43:32 <jralls> For full disclosure it should say "This retrieves the current average spot price on the Forex futures market, not to be confused with anything vaguely resembling the rate you'll get from your bank for this transaction."
16:44:14 <CDB-Man> .+ "And/or the historical rate on the date of this transaction"
16:56:26 <CDB-Man> https://bugs.gnucash.org/show_bug.cgi?id=797912 and there we hav eit
16:56:44 <jralls> OK.
16:58:31 <CDB-Man> alright. time to work on this audit file from work that I have been puttin goff. fair value of private placements and hedge fund investments. yuck
16:59:14 *** frakturfreak has quit IRC
17:02:29 <jralls> I'll distract you a little longer. ;-) I realize that I, and perhaps you, was/were looking at the shares and price columns wrong. It's not shares in every case. It's amount. So if the account is USD Cash then shares is the USD amount and TotBuy/TotSell is the dr/cr in CAD and price is the exchange rate. GnuCash correctly won't let you blank the amount and price columns because those splits aren't in the transaction currency.
17:06:02 <CDB-Man> Well, when you look at the very last transaction in the final upload
17:06:08 <CDB-Man> The last purchase
17:06:32 <CDB-Man> I have an amount of 4.98 commissions there without an exchange rate
17:06:49 <CDB-Man> Does that mean that 4.98 is in CAD?
17:07:07 <CDB-Man> But if yes, wouldn't that not balance since everything else is USD?
17:07:55 <jralls> That's the problem: Everything else is CAD.
17:08:20 <CDB-Man> The transaction still balances though
17:08:30 <CDB-Man> At least on the surface
17:08:48 <jralls> It does. It doesn't make much sense, but it does balance.
17:09:33 <jralls> If you start the transaction in the USD Cash account then the transaction currency is USD and everything ends up looking the way you'd expect.
17:10:46 <jralls> https://imgur.com/a/MBMnhCl
17:11:40 <CDB-Man> This whole thing about hiding what is the transaction currency... Is very opaque
17:11:59 <CDB-Man> There ought to be an indicator somewhere telling you "this is a CAD transaction"
17:12:24 <CDB-Man> Perhaps in the transaction name's header line or something
17:12:51 <CDB-Man> Or perhaps another column to say this is CAD
17:13:14 <CDB-Man> Or perhaps changing the "debit" label to "debit (CAD)"
17:13:23 <CDB-Man> Or whatever is the current currency
17:13:44 <CDB-Man> Actually that's a good idea, I'll file that ticket too before I head back to work
17:15:57 <jralls> That would be very hard to implement. What you might want to do is edit USD in the security editor to change its symbol from $ to US$.
17:17:13 <CDB-Man> hmm, now there's an idea
17:17:19 <jralls> And you can always check the transaction currency using Edit Exchange Rate. If the split has the same currency as the transaction it will pop up a little message box saying that there isn't one, otherwise you'll get the transfer dialog.
17:17:54 <CDB-Man> well, right click open exchange rate on EVERY transaction is quite cumbersome
17:18:06 <CDB-Man> especially if I have a series of transactions to enter
17:18:13 <CDB-Man> I like your idea of changing the signs better
17:18:24 <CDB-Man> I'm going to make the change right now, CA$ and US$
17:19:54 <CDB-Man> hmm, so GNUCAH does NOT show the currency symbol when the split's currency is the same as the account's currency?
17:20:31 <jralls> There's one other little wiggle: GnuCash displays *no* currency symbol if the currency is the same as the one in Preferences:Accounts, so you might want to change that to something you don't use so it always shows the symbol.
17:20:34 <CDB-Man> https://i.imgur.com/7csaZKt.png
17:20:58 <CDB-Man> aha, your explanation came at the same time as my question
17:21:30 <jralls> Great minds think alike. Doesn't exlpain us, of course, but still. ;-)
17:21:56 <CDB-Man> but if you do that, will it mess with a bunch of other considerations? of course there's benign but annoying things such as reports defaulting to that other currency
17:22:25 <CDB-Man> but what about the impact on the overall book's Root currency? or since this is a software preference setting, not a book setting, the book and its underlying mechanics are unaffected?
17:22:43 <jralls> Probably. It would be better to have a pref to always show a currency symbol, but gjanssens will object that there are too many prefs already.
17:22:48 <CDB-Man> I suppose changing the software prefernce, when you create new accounts, it will default to that unused currency then?
17:23:05 <CDB-Man> > too many prefs <--- variety is the spice of life!
17:24:40 <CDB-Man> well, i just changed my setting to BDT to try it out, and I am not seeing my "CA$" currency indicator in any CAD accounts
17:24:47 <jralls> The root currency is alomst immutable. There's a way to change it that chris discovered a year ago, but it's seriously non-obvious.
17:25:30 <CDB-Man> also not seeing "US$" in my USD commissions register
17:26:25 <CDB-Man> maybe if i close and reopen all the rgisters...
17:26:32 <jralls> Hrmph. Your're right. The register shows no symbol on amounts in the register's currency, so it will help only in Stock registers.
17:26:34 <CDB-Man> Nope.
17:26:46 <CDB-Man> indeed
17:27:10 <CDB-Man> well then, all my Forex transactions CADUSD, USDJPY, CADJPY, HKDUSD, etc will all be a mystery
17:27:23 <CDB-Man> (except for JPY with 100:1 inflated numbers, of course)
17:27:52 <CDB-Man> i will file a preference setting request then to _always_ show currency indicators
17:30:06 <jralls> Not quite that bad. In a JPY register you should see both US$ and CA$ depending on which was involved in that transaction.
17:30:30 <CDB-Man> yes, JPY is probably the least concerning
17:30:43 <CDB-Man> but all those other dollar currency pairs will be a challenge
17:31:12 <jralls> And if you have a USD/CAD txn then when you're in the USD account the CAD amounts will have CA$ and vice-versa.
17:36:41 <CDB-Man> though jralls, evne if we display the currency for each split, that still provides no transaprency at all on the "transaction currency" though?
17:37:11 <CDB-Man> i will be able to see that this is USd and this is CAD, but i still don't know whether it's I need to convert my CAD into USD, or my USD into CAD
17:37:17 <CDB-Man> until i trial and error
17:37:27 <CDB-Man> and see which one gnucash wants me to enter an FX rte
17:37:33 <CDB-Man> this is what often happens for me
17:37:49 <CDB-Man> my face is a confused look as I get the message "the currencies equal each other:
17:37:59 <CDB-Man> and i trial and error until i find the split that needs a rate
17:43:35 <jralls> Well, either the split with the currency symbol is the txn currency or the one without is. If none of them have a currency symbol then there's no exchange rate because all of the splits are the same currency.
17:44:19 <jralls> Though I guess you could make that not true by creating an all-USD transaction in a CAD register.
17:46:10 <CDB-Man> Which is more or less what I did in the SPY example, right?
17:48:27 <jralls> Yes. I don't recommend making a habit of it. ;-)
17:50:21 <CDB-Man> Well, hard to not make this a habit when I don't even know what currency is the current register! Especially for stock accounts that don't necessarily have a currency
17:51:16 <jralls> But they do, and now you know the rule!
17:51:41 <CDB-Man> Going to modify my feature request then
17:52:10 <CDB-Man> I see that sometimes, in some registers, there is an additional column to the right that shows an exchange rate
17:52:52 <jralls> That happens when you mess up resizing. It's supposed to be a hidden column.
17:53:01 <CDB-Man> When does this show, and what exactly is it showing? And can we make it show all the time? So that it's always clear what the conversion is, and therefore another way to identify the transaction currency?
17:53:24 <CDB-Man> I go out of my way to unhide it everywhere
17:53:43 <CDB-Man> And quite frustrated when the UI doesn't let me resize it into visibility
17:54:55 <CDB-Man> Perhaps this should also be a preference setting
17:55:02 <CDB-Man> Always show the exchange rate column
17:56:49 <jralls> I'd think that using a stock-style register for all accounts would be a better option. Then you have the amount column in the account's currency/commodity and the DR/CR value column in the transaction currency.
17:57:25 <jralls> And if the commodity symbol is always shown then it's immediately obvious what is the transaction currency.
17:57:51 <CDB-Man> Well not if you have multiple currencies
17:58:09 <Simon> the stock-style register for all accounts would be confusing...
17:58:46 <CDB-Man> If I see both CA$ and US$ in SPY, that doesn't tell me if the transaction is CAD or USD
17:59:30 <jralls> Simon, it would be for normal single-currency users. Not so much for others.
18:00:21 <Simon> I do some things in other currencies but most of the time it's single-currency
18:01:12 <CDB-Man> 60% of my transactions involve more than 1 currency
18:01:16 <jralls> CDB-Man, yes it would, because whatever is in the DR/CR columns is the transaction currency. What's called the shares column in the stock register is more generally the amount and that is in the split account's currency/commodity.
18:01:36 <CDB-Man> Ah, okay, I see what you mean
18:06:06 <CDB-Man> [18:01:11] <+ffffffCDB-Man> 60% of my transactions involve more than 1 currency <-- I should be more specific. 60% of transactions, by volume not by value, income involve a currency other than my home currency of CAD
18:06:08 <jralls> I guess ideally if the split-account is the txn currency then the amount and price cells could be disabled and blank to make data entry easier. The other downside is that all not-transaction-currency entries would have to use + and - instead of dr and cr columns, forcing users to remember which goes with which for the account in question.
18:06:56 <CDB-Man> I would not go the field disabling route
18:07:24 <CDB-Man> Rather, auto populate, and or make the auto balancer populate, those with a price of 1.00
18:08:04 <CDB-Man> Often hiding things in complex situations makes it harder to truly recognize what's going on
18:10:40 <jralls> Sometimes, but for the 99 44/100 % of the time when everything is going well simplifying abstractions make it easier to understand the big picture and make the work go a lot faster.
18:11:05 <CDB-Man> Sounds like another preference setting!
18:11:30 <CDB-Man> It's a shame that Geert isn't here to read this and roll his eyes
18:11:59 <CDB-Man> (he appears to be offline)
18:12:33 <jralls> Yeah, he's away for the weekend, but even if he had been here today he'd be in bed by now.
18:13:07 <CDB-Man> At the very least, he would awake to mentions of him
18:13:17 <CDB-Man> If he was here to log it
18:14:41 <jralls> The channel is logged at https://code.gnucash.org/logs/2020/08/ I dunno if he reads them, he tends to use dot to see if anyone did an at-tell gjanssens.
18:15:50 <CDB-Man> Back to matters at hand, it sounds like I will amend my request to the following
18:16:05 <CDB-Man> 1. Always show currency indicator for all currencies in all registers
18:16:55 <CDB-Man> 2. Allow use of the stock account register in all accounts so to allow viewing of exchange rates between transaction currency and split account currency
18:17:23 <CDB-Man> These in combination will make it apparent what is the transaction currency, since the debit credit amounts are always in transaction currency
18:17:34 <CDB-Man> The split currency will show up in the units columns
18:18:11 <CDB-Man> And both of these are preference settings
18:18:23 <jralls> OK, just don't hold your breath. ;-)
18:18:36 <CDB-Man> Since single currency users, especially single currency users that don't trade stocks, don't need either of these options
18:19:04 <CDB-Man> Oh don't worry, I have long since came to the conclusion that breathing is a non starter ;)
18:25:31 <jralls> You must be an awesome free-diver!
18:38:32 <chris> jralls: the test-lots.cpp issue annoys me immensely. After building, try amending the .cpp file. It doesn't recompile.
18:39:28 * chris wishes to nuke it. waiting for it at every ninja check adds to Blood pressure.
18:40:28 <chris> gtg now
18:40:41 <jralls> I'll take a look at it.
18:42:16 <jralls> But ISTM it can't possibly take as long as compiling a single .scm file to .go. The whole test suite takes only ~100 seconds.
18:46:12 <jralls> test-lots takes 16.24 seconds vs. test-stress-options 19.75.
18:48:04 <jralls> chris, OTOH turning transaction_num to 32 and max_iterate to 5 cuts that down to 0.63 seconds. No compilation issue, either. What did you try to do?
18:50:08 *** Aussie_matt has joined #gnucash
19:06:26 <jralls> chris, I cut it down to one iteration on 32 txns, for less than a second. Now it's your turn to speed up test-stress-options so it takes > 1 second.
19:06:28 <CDB-Man> https://bugs.gnucash.org/show_bug.cgi?id=797913 and there we have it
19:07:04 <CDB-Man> [2020.08.16 18:25:31] <jralls> You must be an awesome free-diver! <-- if only my basic swimming skills (let's not even talk about diving) were even a fraction as good as my finance and accounting skills....
19:07:11 <CDB-Man> and with that, off to work on this silly audit
19:10:54 *** CDB-Work has joined #gnucash
19:10:54 *** ChanServ sets mode: +v CDB-Work
19:42:29 *** User has joined #gnucash
19:52:37 *** User has quit IRC
20:22:46 *** David has quit IRC
21:09:07 *** David1 has joined #gnucash
21:41:39 *** Unattributed has quit IRC
21:42:02 *** Unattributed has joined #gnucash
21:42:02 *** ChanServ sets mode: +v Unattributed
21:44:36 <CDB-Man> CDB-Work: Todo on the CDB Excel: 1) add cumulative gross and cumulative net profit columns, 2) add option to capitalize vs expense purchase commissions, 3) add dividend activity that can roll into one of the cumulative profit columns (TBD which column or both), 4) add these comments on the ticket so that I don't forget about it and so that Chris will see it
21:46:18 <CDB-Man> Maybe need a third column called total return for the regular dividends received while long + compensatory dividends paid while on short
21:47:45 <CDB-Man> 5) add a disclaimer that this is never to be used "as is" for stock options. Those scenarios are too complex to model, and anyone trading options ought to be personally knowledgable on their own to do their own reporting
22:27:12 <chris> CDB-Man: nice summary. Part of my motivation for the 'note' is a 'sanity-check' test - eg regular BUY must have +ve stock-units, +ve stock-value, -ve cash amount, -ve cash value, >=0 fees. anything fails = must show warning
22:27:34 <chris> you get the idea
22:28:12 <chris> jralls: thanks for test-lots. still odd that whenever I modify test-lots.cpp and run ninja, it doesn't recompile at all. must be a cmake error somewhere.
22:28:22 <chris> ^ must rebuild to recompile test-lots.
22:28:46 <CDB-Work> indeed, a transaction not having that is most likely a linked dividend or return of capital event
22:28:51 <CDB-Work> and require special treatment
22:29:05 <chris> anyway test-stress-options would be difficult to speedup; each report takes 1-2s to run completely.
22:29:07 <CDB-Work> at least return of capital still debits/credits the STOCK account
22:29:11 <CDB-Work> but a dividend will not
22:29:50 <CDB-Work> also chris, see my last reply in the ticket
22:30:05 <CDB-Work> given the hour of the day here (1030 PM), its probably a next weekend thing
22:30:22 <CDB-Work> i'm still dealing with a file from work (auditing investments in hedge funds, yuck)
22:33:19 <chris> saw it. well chaps, the wife is expecting anytime soon now so my commit rate will take a severe downturn soon.
22:33:37 <CDB-Work> congrats, soon to be father!
22:33:43 <CDB-Work> boy or girl?
22:34:00 <CDB-Work> 1st or 2nd child?
22:34:12 <chris> unknown, firstborn :)
22:38:23 <CDB-Work> well, you'll be able to teach the new kid the wonders of "weighted average cost basis accumulation with capitalized commissions, all while holding the position SHORT, in conformance with IFRS!"
22:38:38 <CDB-Work> be sure to whisper all this in their ear as they sleep ;)
22:45:20 <chris> and don't pay for accountancy software...
22:55:36 <CDB-Work> btw, do you use gnucash for your practice? as in for your medical practice
22:57:09 <chris> I don't because I work for a corporate and pay %+GST of my income
22:57:29 <chris> Hence I needed to write my own GST report and got sucked in
23:18:24 <CDB-Work> ah, so you invoice a corporate (dental i believe?) chain for your services
23:18:31 <CDB-Work> or were you a GP
23:18:33 <CDB-Work> I forget
23:55:13 *** Unattributed has quit IRC