2020-06-14 GnuCash IRC logs
00:00:12 *** omnireq_ has joined #gnucash
00:05:25 <CDB-Man> jralls: hmm, just for curiosity, i ran the account sumary report in USD average cost to see what would happen. in USD, SPY has a value, but so does TRADING. same for TB, TB average cost still does not balance in USD
00:13:28 <fell> Funny, the Hakka claim like the Magyar in Europe the Huns as ancestors.
00:33:59 *** Guest18 has joined #gnucash
00:34:01 *** Guest18 is now known as p07r0457
00:34:12 *** ChanServ sets mode: +v p07r0457
00:34:47 *** p07r0457 has quit IRC
00:38:22 *** Guest18 has joined #gnucash
00:38:56 *** Guest18 has quit IRC
00:39:09 *** p07r0457 has joined #gnucash
00:39:09 *** ChanServ sets mode: +v p07r0457
00:39:51 *** Mechtilde has joined #gnucash
00:39:59 *** p07r0457 has quit IRC
00:46:38 *** marusich has joined #gnucash
00:46:38 *** ChanServ sets mode: +v marusich
00:54:53 *** chris has quit IRC
00:58:09 *** chris has joined #gnucash
00:58:09 *** ChanServ sets mode: +v chris
01:06:27 *** fell has quit IRC
01:07:45 *** fell has joined #gnucash
01:07:45 *** ChanServ sets mode: +o fell
01:11:47 *** Mechtilde has quit IRC
01:13:55 *** Mechtilde has joined #gnucash
01:27:15 *** sbluhm has joined #gnucash
01:27:15 *** ChanServ sets mode: +v sbluhm
01:34:39 *** marusich has quit IRC
01:43:14 *** marusich has joined #gnucash
01:43:14 *** ChanServ sets mode: +v marusich
01:51:13 *** sbluhm has quit IRC
02:05:04 *** dtux has quit IRC
02:10:05 *** dtux has joined #gnucash
02:23:30 *** suukim has joined #gnucash
03:19:42 *** dtux has quit IRC
03:24:37 *** sbluhm has joined #gnucash
03:30:37 *** sbluhm has quit IRC
04:02:53 *** Aussie_matt has joined #gnucash
04:13:00 *** gjanssens has joined #gnucash
04:13:00 *** ChanServ sets mode: +o gjanssens
05:42:35 *** User_ has joined #gnucash
05:56:09 *** chris has quit IRC
05:59:25 *** chris has joined #gnucash
05:59:25 *** ChanServ sets mode: +v chris
07:04:35 *** sbluhm has joined #gnucash
07:04:35 *** ChanServ sets mode: +v sbluhm
07:45:48 *** sbluhm has quit IRC
07:52:09 *** sbluhm has joined #gnucash
07:52:09 *** ChanServ sets mode: +v sbluhm
07:57:23 *** sbluhm has quit IRC
08:08:42 *** finster has joined #gnucash
08:08:42 *** ChanServ sets mode: +v finster
08:30:53 *** Aussie_matt has quit IRC
08:47:23 *** sbluhm has joined #gnucash
08:47:23 *** ChanServ sets mode: +v sbluhm
08:53:21 *** sbluhm has quit IRC
09:10:03 *** sbluhm has joined #gnucash
09:10:03 *** ChanServ sets mode: +v sbluhm
09:35:30 *** sbluhm has quit IRC
10:25:34 *** bertbob has quit IRC
10:31:51 *** bertbob has joined #gnucash
10:31:51 *** ChanServ sets mode: +v bertbob
10:34:22 *** David has quit IRC
10:34:26 *** David has joined #gnucash
10:43:09 *** Agfarmer18 has joined #gnucash
10:59:15 *** PowaBanga has joined #gnucash
11:07:54 *** jost has quit IRC
11:09:17 *** jost has joined #gnucash
11:15:03 *** Agfarmer18 has quit IRC
11:22:47 <jralls> CDB-Man was that on your book or on the minimal test DB from bug 797796?
11:30:57 <jralls> gjanssens, BobIT pushed onto master overnight so I need to rebase and retag. That's not a problem as I haven't pushed the tag. The problem is that I'd already pushed to flathub so yesterday's tarball is built and published.
11:31:49 <jralls> Should I do a 3.905-1 with the new tarball or should we skip 3.905 and do 3.906?
11:45:19 <chris> to clarify for jralls and CDB-Man: balance-sheet is now back to legacy. commodity-utils.scm is unchanged. further testing to use this as baseline. things get very confusing otherwise.
11:46:10 <jralls> Otherwise? ;-)
11:46:28 <chris> (balance sheet has recent bugfix described in https://bugs.gnucash.org/show_bug.cgi?id=797796#c36
11:47:14 *** dtux has joined #gnucash
11:47:16 <chris> Otherwise I am not sure what report is being described in bug reports
11:47:53 <chris> Ideally Balsheet-PNL will become gold standard, all exchange conversions behave according to legacy in every column
11:48:01 <chris> ^ This is not currently the case
11:48:03 <jralls> No, I meant that the other way around. It's confusing both ways.
11:49:18 <jralls> As for legacy, I tested the 797796 test book all the way back to 2.4. That's been broken forever.
11:50:42 <chris> agreed. Charles Day's commit is confusing and probably unwarranted. I suspect it's triggered when Currency conversion is initiated from the foreign currency instead of domestic. But this testing will wait.
11:51:17 <CDB-Man> [11:22:47] <@17b339jralls> CDB-Man was that on your book or on the minimal test DB from bug 797796?
11:51:20 <CDB-Man> On mine
11:51:54 <jralls> chris, Did you read the email thread linked in 797796?
11:52:02 <jralls> CDB-Man, thanks.
11:53:00 <chris> I think the email thread refers to 'weighted-average', not relevant to the commit
11:53:41 <chris> 'weighted-average' will (abs share-val) so no negation is needed
11:53:56 <jralls> It's about both weighted average and average cost.
11:53:59 <chris> weighted-average: gnc:get-exchange-totals
11:54:08 <chris> average-cost: gnc:get-exchange-cost-totals
11:54:25 <jralls> IIRC the reason for Charles Day's changes is in there.
11:56:44 <chris> Not convinced. Anyway gtg.
12:08:11 *** Hirppa has joined #gnucash
12:10:48 <CDB-Man> chris: I saw your reply in the ticket with a list of hypothetical transactions
12:11:12 <CDB-Man> Let me do something in Excel on how I would convert it using "average cost" and I'll attach it
12:13:03 <CDB-Man> (after lunch that is, so probably you'll see it in the morning your time)
12:15:34 *** David has quit IRC
12:15:38 *** David has joined #gnucash
12:49:21 *** sbluhm has joined #gnucash
12:49:21 *** ChanServ sets mode: +v sbluhm
13:25:03 *** suukim has quit IRC
14:02:29 *** frakturfreak has joined #gnucash
14:02:29 *** ChanServ sets mode: +v frakturfreak
14:27:36 *** sbluhm has quit IRC
14:37:21 *** jervin has joined #gnucash
14:41:21 *** linas has joined #gnucash
15:31:05 *** sbluhm has joined #gnucash
15:48:55 *** Mechtilde has quit IRC
15:57:13 *** User_ has quit IRC
16:03:00 <CDB-Man> hmm, trying to do chris' example, even when his last transaction dated Jan 21 giving a CAD EUR shortcut, still represents a challenge....
16:03:47 <CDB-Man> for average cost anyways. for nearest in time it will always work
16:08:12 *** dtux has quit IRC
16:09:39 *** dtux has joined #gnucash
16:13:26 <jralls> Nearest in time is easy, but it creates unrealized gains so it can't be used to test if the whole book balances.
16:15:58 <jralls> Average cost is intended to ensure that realized gains are correctly booked as income, but it fails when currency gets to complicated.
16:20:35 *** sbluhm has quit IRC
16:23:19 <jralls> CDB-Man you said earlier that for computing weighted-average that the e.g. SPY <-> USD transactions would ideally be converted back to CAD using the exchange rate for that day. But that would create USD<->CAD trading gains and so put the value out of whack for computing the actual G/L amount.
16:24:25 <CDB-Man> Yeah, there is no real good answer jrall. I'm about to upload an excel file that illustrates just that
16:24:43 <CDB-Man> Chris' example with 3rd and 4th currencies GBP and EUR effectively illustrate the same issue
16:24:56 <CDB-Man> since the GBP EUR transactions have no direct attachment to CAD
16:25:10 *** shaggy has joined #gnucash
16:25:10 *** ChanServ sets mode: +v shaggy
16:25:25 <CDB-Man> I get a CAD $6.69 unrealized gain even with average cost (without using a theoretical CAD rate in effect at the date of the GP EUR trans)
16:25:32 *** shaggy has left #gnucash
16:25:33 *** shaggy has joined #gnucash
16:25:33 *** ChanServ sets mode: +v shaggy
16:26:18 <jralls> So how, using paper-and-pen books, would you compute the correct realized gain amounts to get the book to balance overall?
16:27:15 <CDB-Man> well, technically your ledger should ALWAYS be in home currency
16:27:41 <CDB-Man> that an account has a separate currency would be tracked at the subledger level, rather than the general ledger
16:28:01 <CDB-Man> for example, I have a multinational entity that I audit, and they natuarally hold multiple currencies
16:28:34 <CDB-Man> their SAP GL accounts are always in CAD, with foreign currencies tracked only in the subledger, and every entry posting in CAD
16:29:35 <CDB-Man> because under GAAP (as in general GAAP, not US GAAP or IFRS in particular), you always record transactions in your GL ccurency
16:30:01 <CDB-Man> using USD to buy SPY is technically a disposition of USD, and therefore you *realize * the gain/loss vs CAD
16:30:14 <CDB-Man> it is no longer unrealized at that point, as you've disposed the USD
16:30:28 <CDB-Man> technically, using USD to buy SPY is recording the transction net
16:30:33 <CDB-Man> the gross transaction is
16:30:36 <CDB-Man> 1> sell USD into CAD
16:30:44 <CDB-Man> 2> use that CAD to buy SPY
16:31:13 <CDB-Man> net effect is use USD to buy SPY, but that hides the tecnical in between step of taking a tour through CAD
16:31:42 <CDB-Man> so in other words...
16:31:55 <jralls> Except that you have to pay for SPY in USD, the NYSE market-maker doesn't take CAD.
16:32:02 <CDB-Man> > But that would create USD<->CAD trading gains
16:32:03 <CDB-Man> exaclt,y and as you mentioned last week, this sugests an unrecorded gain, to which you are exactly right
16:32:14 <jralls> Sorry, NYSE specialist. NASDAQ has market-makers.
16:32:40 <CDB-Man> right, but you have to remember, that accounting stratifies reality a bit
16:32:51 <CDB-Man> that's why the net effect is still SELL USD BUY SPY
16:33:05 <CDB-Man> but the "gross" effect, for a GL in CAD, is SELL USD BUY CAD, then SELL CAD BUY SPY
16:33:57 <CDB-Man> the "correct" way to think about things 9for lack of better term), is to always think about it in home currency, no exceptions
16:35:47 <CDB-Man> therefore, any disposition of something non-CAD, which includes USD, is a disposition, and therefore you are realizing a gain / loss in CAD terms
16:36:55 <jralls> So GnuCash's way of handling it is non-GAAP even though it makes rational sense to everyone else. Hmm.
16:37:19 <CDB-Man> indicentally, if you were to treat USD as a "full"commodity like SPY
16:37:25 <CDB-Man> that would actually be more correct, but less intuitive
16:38:14 <jralls> Oh, there's no difference between currencies and commodities under the hood except that we force all transactions to have a currency. Barter isn't supported.
16:38:20 <CDB-Man> if I were to record in SAP for my client a CAD to USD conversion, then a subsequent USD transaction to buy SPY, it would be as follows (on a gross basis, you cna net the impact later)
16:40:40 <CDB-Man> 1. Convert CAD to USD (Fx rate 1.30)
16:40:40 <CDB-Man> DR USD Cash $130 CAD
16:40:40 <CDB-Man> CR CAD Cash $(130) CAD
16:40:40 <CDB-Man> 2. Buy 1 SPY for $100 USD (Fx now 1.40)
16:40:40 <CDB-Man> Dr CAD clearing $140 CAD
16:40:41 <CDB-Man> Cr USD Cash $(130) CD
16:40:43 <CDB-Man> Cr Gain on dispostion of USD $(10) CAD
16:40:46 <CDB-Man> Dr SPY $140 CAD
16:40:48 <CDB-Man> Cr CAD Clering $(140) CAD
16:41:08 <CDB-Man> that's technicalyl what happens
16:41:21 <CDB-Man> #2 of course can be stated in net terms, with the clearing account removed from the splits
16:41:40 <CDB-Man> Dr SPY $140 CAD
16:41:40 <CDB-Man> Cr USD Cash $(130) CD
16:41:40 <CDB-Man> Cr Gain on dispostion of USD $(10) CAD
16:41:56 <jralls> Is a SAP clearing account more-or-less comparable to a GnuCash trading account?
16:42:11 <CDB-Man> i would say no
16:42:27 <jralls> Then what is it for?
16:42:41 <CDB-Man> the SAP clearing account is a true GL account
16:42:47 <CDB-Man> not a "Trading" type account
16:43:04 <CDB-Man> in SAP, you wouldnt have (a need for) trading accounts, since everything is recorded in CAD always
16:43:16 <CDB-Man> SPY is a CAD account, no concet of share units (at the GL level)
16:43:22 <CDB-Man> USD Cash is aa CAD account
16:43:37 <CDB-Man> the clearing account is to illustrate the in between stepp
16:43:46 <CDB-Man> in practice, everyone records the net version of th transaction
16:44:28 <CDB-Man> there is no "actual" CAD clearing account in real life usage, since everyone implictly understands that it happens, and you just skip to the net transsaction and record that
16:45:30 <gjanssens> jralls: for flathub you can do a 3.905-1 with the new tarball.
16:45:39 <CDB-Man> the understandin gis implicit, because everyone's mind is always thinking "so, what is the value of each individual split in CAD terms today"?
16:45:46 <CDB-Man> s/CAD/home-currency
16:45:49 <jralls> gjanssens, that's what I decided to do.
16:46:06 <gjanssens> Very good!
16:46:15 <gjanssens> And... Good night!
16:46:24 <jralls> Good night!
16:46:33 *** gjanssens has quit IRC
16:47:22 *** dtux has joined #gnucash
16:47:43 <CDB-Man> I definitely understand how gnc organically came up with the idea of foreign currency accounts, and intuitively it makes sense
16:48:00 <CDB-Man> but that's not how it "ought" to be done
16:48:05 <jralls> CDB-Man, GnuCash could do something similar by using the root account currency (which we take to be the home currency for the book) as the transaction currency in all cases.
16:48:30 <CDB-Man> probably
16:48:57 <CDB-Man> teh difficulty of course, is getting, in this example a CAD price into price DB on transaction date
16:49:06 <jralls> That would force the "value" half of every split into the home currency.
16:49:53 <CDB-Man> everyone understands that on July 15th, i bought 1x SPY for $100 USD. a bit harder to also get someone to enter the CAD fx rate on this date, when you are keying in the transaction from the USD broker statement
16:50:48 <CDB-Man> would be easier if pricedb can lookup fx rates in the past, from alphavantage
16:51:36 <jralls> I don't think we want the pricedb in the middle. That's always at best an approximation, not the actual price.
16:53:22 <CDB-Man> well, the difficulty is that me buying SPY with USD on July 15th never "hysically" impacts CAD... but for GAAP purposes you still need to price everything in CAD, CAD being the home currency of the general ledger in my example
16:53:25 <jralls> Though maybe for the USD-CAD rate when buying SPY in a USD brokerage account it's good enough since it would be applied to both the USD and SPY splits.
16:53:46 <CDB-Man> correct, and
16:54:09 <CDB-Man> taken a step further, suppose I converted my USD to GBP, that is also a dispostion of USD, and you would realize, in CAD terms, a gain/loss
16:54:24 *** jervin has quit IRC
16:54:28 <CDB-Man> then suppose I use that GBP to purchse HSBC stock, i would realize, in CAD terms a gain loss on the disposition of GBP
16:55:05 <CDB-Man> you would have to enforce a CADUSD fx rate on both splits in the 1st instance, and a CADGBP rate on noth splits in the 2nd instance
16:55:23 <CDB-Man> for this purpose, pricedb is probably sufficient, since again, you dont impact CAD in a "physicaly way" in both instances
16:55:50 <CDB-Man> pricedb needs to query alphavantage for a rate on transaction date
16:56:04 <CDB-Man> and the difference is a true, realized, gain/loss, that needs to impact P&L
16:56:12 <CDB-Man> into a currency gain/loss account
16:57:00 <CDB-Man> it's anti intuitive, until you can mentally drop the pretext that "cash is cash, and USD is cash, therefore no gain loss"
16:57:16 <CDB-Man> from an accounting persoective, "cash is cash" only applies to cash of your GL's home currency
16:57:59 <jralls> I don't have that preconception, though I know that some users do.
16:58:32 <CDB-Man> right, I say "you" in the plural sense
16:58:52 <CDB-Man> "vous" in french rather than "tu", if you know your french pronouns
16:59:10 <jralls> Those users who whine that their trial balance doesn't balance and I tell them it's because they haven't been booking GL on their foreign currency transactions.
16:59:43 <jralls> I remember enough of French to know that 'tu' is for my wife and 'vous' is for you. ;-)
17:00:16 *** frakturfreak has quit IRC
17:00:53 <CDB-Man> yeah, it's not an easy concept that's for sure, and one that trips up a lot of people
17:01:23 <CDB-Man> a common audit difference i find, is at my lss sophisticated clients that don't have dedicated accounting, they improperly book Fx
17:03:03 <CDB-Man> if I were to go back to my example of 1.30 / 1.40 and SPY
17:03:28 <CDB-Man> suppose you didn't pre-purchase $100 USD, and just directly bought SPY at $100 USD when Fx was 1.40
17:03:34 <CDB-Man> it cost you $10 CAD more this way
17:03:51 <jralls> So back to booking your USD->SPY transaction. If the transaction currency is CAD and you're entering it in split mode, you'll get the Transfer Dialog for a USD->CAD exchange rate when you CR USD 1000.
17:03:53 <CDB-Man> the fact that you "saved" $10 im CAD terms by pre-buying and therefore realizing an appreciation in the USD
17:03:58 <CDB-Man> that's the implied gain
17:05:14 <CDB-Man> jralls: when you get that transfer dialog and you press the "get fx rate" button, does that get 1) *today*'s fx rate, or 2) the rate as of the date of that transaction? I assume #1
17:05:18 <jralls> And then when you DR SPY 500 you'll get another one asking for CAD->SPY. Which will confuse the heck out of you because you don't know what the SPY costs in CAD.
17:05:54 <jralls> It gets whatever Alphavantage provides. If the market is open it's the latest price.
17:06:24 <CDB-Man> is it that 1) alphavantage lacks historic lookup, or 2) it has historic, but we are not setup that way or 3) both?
17:07:06 <CDB-Man> <jralls> And then when you DR SPY 500 you'll get another one asking for CAD->SPY. Which will confuse the heck out of you because you don't know what the SPY costs in CAD. <-- well, i simply wouldnt ask for this, since you can take the fx rate from the USD->CAD transfer dialog, and apply it to the USD SPY price
17:07:26 <CDB-Man> same CADUSD rate for both sides of the split
17:08:08 <jralls> But at the split level GnuCash won't know about the USD, just the SPY and the CAD.
17:08:18 <CDB-Man> right, which is where the confusion comes in
17:09:04 <CDB-Man> and you cannot simply plug debit = credit, since that would eliminate the fxgain on disposition of USD
17:09:23 <CDB-Man> speaking of which
17:09:36 <CDB-Man> <jralls> So back to booking your USD->SPY transaction. If the transaction currency is CAD and you're entering it in split mode, you'll get the Transfer Dialog for a USD->CAD exchange rate when you CR USD 1000. <-- this already misses the fx gain
17:09:37 <jralls> Plus we don't know if you have more splits to enter.
17:11:18 <jralls> GnuCash doesn't compute trading gains on transactions, that's up to the user.
17:11:47 <jralls> Which they'd do in an all-CAD split.
17:12:18 <CDB-Man> right, but you cannot enter 1.40 as the transaction split fx as the credit to USD, you would have to know and enter 1.30, with the remaining .10 going into P&L
17:12:39 <CDB-Man> (using my earlier example)
17:13:21 <jralls> Because the cost of the USD when you funded the brokerage account two months ago was 1.30?
17:13:26 <CDB-Man> yes
17:13:40 <jralls> GnuCash doesn't know how to keep track of that either.
17:13:44 <CDB-Man> wlel, yes and no
17:14:02 <CDB-Man> if your GL is in CAD, each time you fund the USD cash account, you record the funding amount in CAD terms
17:14:43 <CDB-Man> in other words, if you funded $100 USD at 1.30, and another 100 at $1.50, the USD balance is $200, but since you *always* record in CAD, the debits to the USD cash account are Dr 130 and Dr 150
17:14:57 <CDB-Man> total Dr 280, 280/200 = 1.40
17:15:00 <jralls> Oh, I didn't mean that it's not recorded in the book, I meant that GnuCash doesn't know how to find it in the book.
17:15:44 <CDB-Man> gnucash would simply need to take total account value in CAD (which it ought to be, since you force the register to be CAD), divided by total units of USD currency commodity
17:16:36 <CDB-Man> basically whatever is the value balance in CAD at transaction date, dividend by whatever is the units/shares/commodity balance at transaction date
17:17:10 <CDB-Man> which you would see just by looking at the running total of the register's last tranaactio prior to the date of the transaction you want to input
17:17:39 <jralls> That's conceptually how the average-cost computation works.
17:17:46 <CDB-Man> right
17:18:08 <CDB-Man> it just falls on its face when you have a transaction that is between 2 commodities
17:18:24 <CDB-Man> which is the case of USD buying SPY -- 2 commodities, no CAD involved
17:18:39 <CDB-Man> since "USD isn't cash" to a home currency CAD register
17:19:19 <jralls> And that works fine as long as transactions are always entered in sequence. But if you try to enter a transaction retrospectively then the prices of all existing transactions with later post dates have to be recomputed.
17:19:52 <CDB-Man> you are correct on that front
17:20:38 <CDB-Man> that or, at year end you do a correcting entry for Fx
17:20:56 <CDB-Man> which brings me to method #2 for doing this, as you've just reminded me of it
17:21:11 <CDB-Man> method #2 is... how shall i say it
17:21:24 <CDB-Man> "not technicalyl GAAP compliant, but is simpler and produces a similar result"
17:21:54 <jralls> Is it closer to GAAP than what we're doing now?
17:21:54 <CDB-Man> i've nearly forgotten about it for this reason, until you jogged my memberoy here
17:22:22 <CDB-Man> i'm going to say most likely yes, but i need to create an example for myself first just to backtest and make sure it still works
17:22:30 <CDB-Man> need to remind myself of the mechanics
17:24:09 <CDB-Man> it is simpler for sure, and thinking back, it was done by one of my extremely unsophisticated clients.... they went through 3 controllers in 5 years
17:24:45 <CDB-Man> Controller being the accounting profession, "compttroller" is some other countries
17:25:15 <CDB-Man> uno momento as a create an excel example for myself to validate that it still works
17:25:19 <jralls> Yeah, I know about comptrollers.
17:38:04 <CDB-Man> okay, i think it works, fishing off this example and posting in a few mins
17:38:31 <CDB-Man> it is simpler conceptiually, but i'll let you tell me how well it jives with gnucash (or not jives) after you see it
17:43:55 <CDB-Man> OK, this works
17:46:26 *** David has quit IRC
17:46:30 *** David has joined #gnucash
17:46:48 <CDB-Man> from alphavan
17:46:51 <CDB-Man> ...
17:46:59 <CDB-Man> ignore that
17:47:59 <CDB-Man> jralls: see example file i attached to 797796
17:48:18 <CDB-Man> take a gander at semi-GAAP 1 and 2 tabs, and before i explain it, just see if it makes sense to you
17:48:44 <CDB-Man> left side is the semi-gaap method, right side is full gaap with per-transaction conversions as we've been discussing all afternoon
17:49:20 <CDB-Man> effectively, the semi-gaap methods is to knowingly record "USD numbers" into a *CAD* register, then doing 1 plug at year-end. this gets the same ending balance as GAAP
17:49:38 <CDB-Man> both examples assume SPY stays at $100 for simplicity
17:49:58 <CDB-Man> err, SPY at $50
17:56:11 <jralls> The YE transactions are effectively marking the USD values to market, right?
17:56:22 <CDB-Man> During the year, the number in the account is USD so you visually see your USD balance agree to for example a bank statement. At year end, you value it to CAD (and of course this means it mismatches the bank). On Jan 1 you reverse that valuation entry and the balance agrees to the bank statement again
17:56:54 <CDB-Man> Correct re mark to market
17:57:09 *** dtux has quit IRC
17:57:11 <CDB-Man> All done with purely CAD registers
17:57:58 <CDB-Man> No USD units, no SPY units
18:00:36 <jralls> Well, you could do that in GnuCash, of course, but you'd have to maintain how many actual shares of SPY you had somewhere else and you'd have to keep a lot of notes somewhere about what everything really means.
18:01:00 <CDB-Man> Yes, therein lies the issue
18:01:28 <CDB-Man> I'll also note that this is effectively doing nearest in time, but on currency only and just leaving out stocks
18:01:45 <jralls> I don't think I'd want to try to teach users to do that. Would you?
18:01:55 <CDB-Man> I agree
18:02:34 <CDB-Man> At the end of the day, you can also simply say that GNUCash is non GAAP compliant with respect to average cost
18:02:49 <CDB-Man> And is only GAAP compliant for nearest in time
18:03:52 <jralls> I think rather we have to say that GnuCash isn't GAAP compliant for multiple currency.
18:04:02 <CDB-Man> It just means your average cost TB will never balance as soon as you introduce transactions where home currency is not a split
18:04:20 <CDB-Man> Agree, that's a more accurate statement
18:05:31 <CDB-Man> [18:04:02] <+CDB-Man> It just means your average cost TB will never balance as soon as you introduce transactions where home currency is not a split <-- more accurately, a transaction containing only non home currency
18:10:05 <jralls> Well if that's true then we can work out a procedure for booking your SPY transaction that can get the TB to balance. There's nothing stopping you from creating the transaction starting from the register in your CAD bank account. That would force the transaction currency to CAD.
18:11:41 <jralls> It would be up to the user to work out the right rate to use for USD->CAD and CAD->SPY and the gains on the former.
18:11:43 <CDB-Man> I don't think GNUCash can handle 2 fx rates in the same transaction, can it? CAD split, USD split, and SPY split
18:12:56 <jralls> I don't know if the trading accounts can handle it but it will be interesting to try. But later, I need to finish the release.
18:15:09 <CDB-Man> In my personal case, since I always use nearest in time, the fact that average cost does not balance... Does not bother me
18:15:27 <CDB-Man> Nearest in time being the most GAAP compliant
18:17:56 <jralls> From the standpoint of balances, but not income & expense. That USD expense from January wouldn't be valued at today's USD->CAD rate, would it?
18:20:51 <CDB-Man> Well, using my uploaded example
18:21:15 <CDB-Man> Suppose instead of SPY, the account was Amazon purchases
18:21:27 <CDB-Man> You can still do the year end conversion
18:21:40 <CDB-Man> Just using the average rate for the year, rather than the December 31 rate
18:22:02 <CDB-Man> P&L is converted using the average rate, balance sheet using the year end rate
18:23:45 <CDB-Man> Hmm, I see what you are saying
18:23:58 <CDB-Man> Right, nearest in time fails for P&L
18:25:45 <CDB-Man> I'll note that Average FX is a shortcut
18:25:59 <CDB-Man> Acceptable under GAAP, but still a shortcut
18:26:09 <CDB-Man> Fully correct is per transaction conversion
18:26:13 <CDB-Man> Which is weighted average
18:27:00 <jralls> Or better to just keep your income and expenses in CAD, converting at the time they occur.
18:27:10 <CDB-Man> But again, if all your P&L registers are in CAD, as they "ought" to be under GAAP, it's a non issue
18:27:19 <jralls> That way no pricing required at year-end.
18:27:22 <CDB-Man> Beat me to the punch
18:27:50 <CDB-Man> It's just a matter of practicality at that point
18:29:17 <jralls> I think that it's more practical to book that dividend as CR the USD brokerage cash account, DR the CAD income:dividends-US Stocks.
18:30:16 <jralls> That way the income is correctly priced on the day and the balance is converted with nearest-in-time pricing.
18:30:44 <CDB-Man> Sorry, when I said practical, I was thinking what you just said, vs just booking to a USD income account and living with the imperfection
18:31:12 <CDB-Man> The USD P&L total is overall immaterial, so I'm willing to live with the imperfections
18:31:51 <CDB-Man> That and, with the new Chris multi column income statement, I can get a segmented USD P&L, to do the single step conversion
18:32:33 <CDB-Man> So it's actually more practical to continue recording USD into USD income accounts, using that year end report to correct it afterwards
18:33:13 <jralls> OK, that part is up to you.
18:34:21 <CDB-Man> Indeed, and I will need to give thought on how this impacts the capital gains in USD vis a vis the USD cash balance and embedded FX gain in CAD terms
18:35:17 <CDB-Man> With nearest in time pricing, it solves a lot of the problems, but not all
18:37:02 <jralls> Right. I don't imagine you'd get in much trouble reporting USD dividends converted to CAD at the year-end price. Where things might get interesting is when you repatriate that USD cash. What's the basis and what's the gain?
18:38:08 <CDB-Man> Exactly, that is the biggest unknown. On my part, I've essentially deferred answering this question from a GNUCash mechanics perspective, as I've never done an actual repatriation thus far
18:38:31 <CDB-Man> I do track all my purchases of stocks in a capital gains spreadsheet
18:38:52 <CDB-Man> The answer might be to treat USD as a stock and track that there too
18:39:13 <CDB-Man> The problem of course still being what happens when "new USD" is created
18:39:37 <CDB-Man> Such as via dividends, and via capital gain on sale of USD stocks
18:39:52 <CDB-Man> All "newly created" since not purchased with CAD
18:40:25 <jralls> That's income, which you book as USD income and convert at the end of the year, right?
18:40:59 <jralls> Unless of course this is one of those tax schemes you keep mentioning. ;-)
18:41:04 <CDB-Man> Yep, USD register capital gains and dividend income
18:41:28 <CDB-Man> The problem is I don't have a CAD basis for these new USD
18:42:06 <jralls> Sure you do. The CAD value you converted it to at end-of-year and paid tax on.
18:43:24 <CDB-Man> I don't actually use GNUCash for tax purposes
18:43:41 <CDB-Man> I have a separate Excel that tracks everything in CAD for tax purposes
18:43:54 <CDB-Man> As at transaction date for all purchases and sales
18:44:30 <CDB-Man> I do this because I am not clear/confident on the GNUCash FX mechanics... Prior to this month anyways
18:44:44 <jralls> Now you
18:44:58 <jralls> Now you're more clear and less confident I imagine.
18:45:29 <CDB-Man> That and, currently all my USD investments are in my RRSP and TFSA, which respectively are functionally equivalent to the USA traditional IRA and Roth IRA respectively
18:45:46 <CDB-Man> So no tax on my USD holdings, I've never had to deal with the issue for tax purposes
18:45:52 <CDB-Man> It's all for internal reporting
18:46:27 <CDB-Man> [18:44:58] <@jralls> Now you're more clear and less confident I imagine. <-- indeed!
18:49:02 <CDB-Man> I need some further creative accounting mechanics to make GNUCash work with GAAP
18:49:30 <CDB-Man> When I first started years back, I contemplated not using stock accounts and doing everything by hand
18:49:40 <CDB-Man> That way I would know everything is GAAP
18:49:51 <CDB-Man> The biggest drawback of course is no live pricing
18:50:12 <CDB-Man> I've got live pricing now, but less GAAP compliance
18:50:36 <CDB-Man> Just need some creative mechanics to bridge that GAAP (excuse the pun :) )
18:51:35 <jralls> Puns are always welcome!
18:53:21 <CDB-Man> On an unrelated matter
18:53:38 <CDB-Man> Have you noticed that GNUCash does not handle monitor scaling perfectly?
18:54:14 <CDB-Man> What I mean is, my 12" Windows tablet screen is 2560*1440 or something, so I set the scaling to 125%
18:54:28 <CDB-Man> The external monitor is 22" 1920*1080
18:54:55 <CDB-Man> GNUCash scales the UI okay from a sizing perspective, but everything has a blur on it
18:55:16 <CDB-Man> There's no blur on the primary monitor, that being the tablet's screen
18:55:32 <CDB-Man> There's a faint blur on the external monitor
18:55:36 <jralls> No, because I don't use Windows. Gtk decided not to do Windows-style floating-point scaling. There's just regular and HiDPI, the latter being 2x regular (or 4x depending on how you think of it).
18:57:02 <jralls> IIRC there's a fiddle that you can set in GnuCash's shortcut properties (the one where you right-click on the icon in Windows Explorer), but I don't remember offhand what it is.
18:59:17 *** Aussie_matt has joined #gnucash
19:00:59 <CDB-Man> hmmm, i'll give that a shot now
19:01:50 <CDB-Man> on a somewhat related note
19:02:28 <CDB-Man> I've also noticed on windows that I cannot single click on gnucash title bar to select and drag the window when gnucash is not the currently focused window
19:03:08 <jralls> It's HiDPI settings at the bottom of the compatibility tab.
19:03:11 <CDB-Man> in other words, suppose microsoft word is focsed on monitor 1. gnucash is on monitor 2. if i attempt to click and drag gnucash, it will instead select and pickup whatever window is sitting behind gnucash
19:03:28 <CDB-Man> i have to first click to make gnuicash the active wndow, then click again to drag gnucash around
19:04:11 <jralls> That's interesting. I'd not heard of that one before.
19:04:48 <CDB-Man> its not unique to gnucash either
19:05:01 <CDB-Man> happens to libreoffice, and also to pdfxchagne viewer
19:05:20 <CDB-Man> PDF-xChange viewer*
19:05:26 <CDB-Man> all 3 of which suffer the blur issue as well
19:11:34 <jralls> I don't know about the other two except that the MacOS version of LibreOffice doesn't use gtk or Qt. The dragging thing probably has to do with registering with the whatever M$ calls their window manager. (It used to be workplace shell, but I think that went away with Vista.)
19:13:31 <CDB-Man> hmm, enabling the override high dpi scaling (systme ehhanced option) makes it so that scaling is now the saem on both monitors, but the blur still persists. interestingly, the blur goes from the external monitor, to the main monitor
19:15:14 <CDB-Man> gnucash also overhangs the monitor
19:15:52 <CDB-Man> what i mean is, i have 2 external monitors. when placed on the left monitor, i see the right edge of the gnucash window show up on the left side of the right hand mobitor
19:16:05 <CDB-Man> this also happens to libreoffice and pdf-xchange viewer too
19:16:18 <CDB-Man> this is when the program window is maximized, of course
19:29:06 <jralls> I'm not too familiar with the gdk-win32 code but it probably reads the larger monitor size and uses that when maximizing. That's what gdk-quartz did until I fixed it a couple of years ago.
19:36:05 <CDB-Man> Well, my 2 external monitor are the same resolution
19:36:23 <CDB-Man> It's an overhang of maybe 1-4 pixels
19:36:45 <CDB-Man> Small enough to not bother, but large enough to be noticeable and annoying ;)
19:37:27 <jralls> Huh. Maybe Windows changed the decoration width and gdk-win32 didn't adjust.
19:39:06 <CDB-Man> These 2 issues to over hang and blur, if LibreOffice also uses gtk, then your theory on a library issue looks spot on
19:39:38 <CDB-Man> Such is the troubles of cross platform!
19:40:02 <CDB-Man> Interesting note, the blur also exists on the GNUCash Windows installer too...
19:40:37 <jralls> Yes indeed. The only way to get truly native behavior is to use the native GUI library.
19:41:00 <jralls> Which *is* a native Windows program, so that's a bit odd.
19:41:41 <CDB-Man> I wonder if it's because I launch the installer from qdir
19:41:51 <CDB-Man> Rather then Windows Explorer
19:42:03 <CDB-Man> Qdir suffers from all the same issues
19:42:37 <CDB-Man> Will give that a shot when back at laptop
19:47:07 <jralls> I wouldn't think how you launch it would matter.
19:47:20 <jralls> Release is finally done, time to go make dinner.
20:02:26 <chris> I wonder if aycinena's currency-accounting is the trying to make it work
20:03:20 <chris> CDB-Man I know you're thinking in terms of 'CAD=base currency' - I wonder if 'report-currency=base-currency' is feasible as well
20:05:54 <chris> ^ makes all calculations need to be redone whenever report-currency changes
20:08:41 *** omnireq_ has quit IRC
20:28:26 <CDB-Man> Chris: ideally report currency = base currency yes
20:28:51 <CDB-Man> But as all the GAAP talk has illustrated, that isn't exactly easy
20:29:15 <CDB-Man> Further, report currency and functional currency is another chapter of GAAP altogether!
20:29:37 <CDB-Man> Let's worry about getting functional currency accurate first
20:30:05 <CDB-Man> Functional currency is the accounting term, the GNUCash equivalent is book currency (CAD for me)
20:43:59 <CDB-Man> Some "light" reading for the IFRS implementation of foreign currency: https://www.iasplus.com/en/standards/ias/ias21
20:46:47 <CDB-Man> In particular, the section "Translation from the functional currency to the presentation currency" describes how to report in a currency other than functional currency
20:47:01 <CDB-Man> Which is what you are saying Chris regarding running the report in other currencies
20:49:36 <CDB-Man> Long story short, there is only so much we can feasibly and practically do within the confines of a GNUCash scheme report
20:52:04 <CDB-Man> If anything, the multi column multiple currency version of the balance sheet and income statement, giving the original currency amounts, are what people should really use as a starting point, if they are serious about GAAP compliance
20:52:15 <CDB-Man> Nearest in time is a best efforts basis
20:53:02 <CDB-Man> Reasonably accurate for balance sheet, not so much for income statement
20:57:42 <CDB-Man> [17:06:24] <+ffffffCDB-Man> is it that 1) alphavantage lacks historic lookup, or 2) it has historic, but we are not setup that way or 3) both?
20:57:59 <CDB-Man> jralls: forgive me if you already answered this, but which is it?
21:27:48 *** dtux has joined #gnucash
21:37:29 *** TownsendHardware has joined #gnucash
21:40:44 *** jost has quit IRC
21:43:23 <CDB-Man> [2020.06.14 19:47:07] <jralls> I wouldn't think how you launch it would matter. <-- you were right, it did not make a dfiference
21:54:44 *** jost has joined #gnucash
22:07:35 *** jralls_afk has joined #gnucash
22:07:35 *** ChanServ sets mode: +o jralls_afk
22:08:20 *** jralls has quit IRC
22:12:34 <dtux> Is something like FasTrak or Good to Go (i.e. prepaid accounts that reload $30-$50 every so often and deduct $3-$5 tolls) an asset or a negative liability?
22:25:16 <shaggy> Asset as you can use the 30-50, and the tolls are expenses.
22:25:56 <shaggy> You could also do it as a liability, but it'd look weird as you'd regularly show it as overpaid.
22:29:10 <dtux> shaggy: ty, that's what thought... but thinking about how the recommendation to do a negative liability for income tax withholding in the FAQ had me second guessing :p
22:50:02 <shaggy> dtux: that's referring to employers income tax withholding. is a liability (because it is money you have but you owe to the govt). Then it gets transfered to an 'expense' when you pay it to the gov't monthly, quarterly, or yearly.
22:50:08 <shaggy> https://lists.gnucash.org/pipermail/gnucash-user/2003-March/005841.html
22:52:49 <dtux> shaggy: ah! so from the employee's perspective (i.e. my perspective).. it's an expense as soon as it's withheld from my paycheck?
22:53:09 <shaggy> correct. that's usually how it's entered.
22:53:57 <dtux> that definitely seems simpler haha
22:55:23 <shaggy> on that I don't track my stuff, I let my employer do that, I just track my net income not my gross.
23:01:47 *** storyjesse has joined #gnucash