2020-08-20 GnuCash IRC logs

00:05:48 *** FH_thecat has joined #gnucash
00:32:07 *** FH_thecat has joined #gnucash
00:42:32 *** chris has quit IRC
00:43:32 *** chris has joined #gnucash
00:43:32 *** ChanServ sets mode: +v chris
00:53:15 *** sbluhm has joined #gnucash
00:53:15 *** ChanServ sets mode: +v sbluhm
00:54:35 *** Mechtilde has joined #gnucash
01:04:14 *** rigid has joined #gnucash
01:05:10 *** frakturfreak has quit IRC
01:19:52 *** frakturfreak has joined #gnucash
01:19:52 *** ChanServ sets mode: +v frakturfreak
01:25:23 *** Aussie_matt has quit IRC
01:25:33 *** Aussie_matt has joined #gnucash
01:32:02 *** FH_thecat has joined #gnucash
01:33:07 *** FH_thecat has quit IRC
01:46:10 *** sbluhm has quit IRC
01:48:38 *** fell has quit IRC
01:48:51 *** sbluhm has joined #gnucash
01:48:51 *** ChanServ sets mode: +v sbluhm
01:49:58 *** fell has joined #gnucash
01:49:58 *** ChanServ sets mode: +o fell
01:56:05 <rigid> what would be the best way to create a bill from the commandline?
01:57:54 <CDB-Work> youll need to wait for a few hours when everyone wakes up in europe/north america
01:58:22 *** CDB-Work has quit IRC
01:59:29 <rigid> i can think of those options: extend gnucash-cli, use the python API to create some separate "gnucash-billing" tool or maybe write a plugin? (if those can be used via gnucash-cli)
02:06:20 *** suukim has joined #gnucash
02:07:03 *** qwer has quit IRC
02:07:36 *** qwer has joined #gnucash
02:52:07 *** Mechtilde has quit IRC
02:52:25 *** Mechtilde has joined #gnucash
02:52:46 *** hussam has quit IRC
02:55:03 *** qwer has quit IRC
02:55:17 *** qwer has joined #gnucash
03:04:54 *** bertbob has quit IRC
03:06:06 *** bertbob has joined #gnucash
03:06:07 *** ChanServ sets mode: +v bertbob
03:23:36 *** Hamaryns has joined #gnucash
03:23:36 *** ChanServ sets mode: +v Hamaryns
03:53:04 *** qwer has quit IRC
03:53:20 *** qwer has joined #gnucash
05:15:05 *** qwer has quit IRC
05:15:18 *** qwer has joined #gnucash
05:22:04 *** qwer has quit IRC
05:23:37 *** qwer has joined #gnucash
05:29:45 *** Hamaryns has quit IRC
05:29:47 *** Hamaryns has joined #gnucash
05:29:47 *** ChanServ sets mode: +v Hamaryns
05:30:19 *** User has joined #gnucash
05:31:09 *** hussam has joined #gnucash
05:31:09 *** ChanServ sets mode: +v hussam
05:46:35 *** qwer has quit IRC
05:48:04 *** qwer has joined #gnucash
05:53:34 *** qwer has quit IRC
05:53:50 *** qwer has joined #gnucash
05:57:16 *** qwer has quit IRC
05:58:02 *** Aussie_matt has quit IRC
05:59:50 *** qwer has joined #gnucash
06:25:17 *** Hamaryns has quit IRC
07:04:27 *** rigid has quit IRC
07:10:09 *** Hamaryns has joined #gnucash
07:10:09 *** ChanServ sets mode: +v Hamaryns
07:16:07 <chris> @tell rigid python API is your best bet
07:16:07 <gncbot> chris: The operation succeeded.
07:21:34 *** fell has quit IRC
07:22:39 *** fell has joined #gnucash
07:22:39 *** ChanServ sets mode: +o fell
07:31:53 *** Aussie_matt has joined #gnucash
07:37:37 *** jw4 has quit IRC
07:37:51 *** jw4 has joined #gnucash
07:37:51 *** ChanServ sets mode: +v jw4
07:56:50 *** fell has quit IRC
07:56:54 *** fell_laptop has joined #gnucash
07:56:54 *** ChanServ sets mode: +o fell_laptop
08:03:50 *** fell_laptop is now known as fell
08:10:22 *** rigid has joined #gnucash
08:35:07 *** Mechtilde has quit IRC
08:44:44 <warlord> .
08:49:21 *** Mechtilde has joined #gnucash
08:54:16 *** Hamaryns has quit IRC
09:29:19 *** Jimraehl1 has joined #gnucash
09:29:37 *** Mechtilde has quit IRC
09:29:55 *** Mechtilde has joined #gnucash
09:48:19 *** Jimraehl1 has left #gnucash
09:52:57 *** Aussie_matt has quit IRC
10:17:48 *** Hamaryns has joined #gnucash
10:17:48 *** ChanServ sets mode: +v Hamaryns
10:26:23 *** suukim has quit IRC
11:06:37 *** Mechtilde has quit IRC
11:09:14 *** Hamaryns has quit IRC
12:00:29 *** CDB-Work has joined #gnucash
12:00:29 *** ChanServ sets mode: +v CDB-Work
12:19:00 <jralls> CDB-Man, CDB-Work, re stocks having book currency as their "currency" would create a problem for quotes. I'm conceptually on board with making transaction currency always book currency but there are practical ramifications for three-commodity transactions like your SPY trades. That will require careful thought to implement in a way that makes sense.
12:19:57 <CDB-Work> Hmm, I was (blindly) hoping for a different answer, but that was completely expected
12:20:23 <jralls> What answer were you hoping for?
12:21:33 <CDB-Work> something along the lines of "the practical ramifications are difficult, but not something requiring an overly fundamental change"
12:21:54 <CDB-Work> call it blind hope
12:22:27 <CDB-Work> The quote issue was also something I didn't anticipate, but makes complete sense
12:23:11 <CDB-Work> re quotes: when we fetch prices, since we also fetch FX, in my case, couldn't we quote by doing a 2-step conversion, ie SPY to USD, then USD to CAD, using quotes all pulled at the same time?
12:23:39 <CDB-Work> and yes, I'm aware that implementation is easier said than done (it _sounds_ easy when I say it like that)
12:23:54 *** storyjesse has quit IRC
12:24:09 <CDB-Work> that would get us the CAD price for a CAD-anchored SPY stock account
12:39:44 <jralls> That part wouldn't be too hard, and F::Q tells us the currency the quote is in. But that's not what I'm going on about... or maybe it is. I'm thinking about the buys and sells rather than daily quotes. In that case you use USD from your US brokerage account to buy SPY. You have a USD->CAD price to get the CAD value for the funds and a USD->SPY price from your broker statement which you need to divide by the USD->CAD price to get SPY->CAD. Now to b
12:39:44 <jralls> alance the book you need to add a pair of G/L splits on the USD broker account. How do we help the user figure the gain?
12:42:46 *** qwer has quit IRC
12:43:41 *** qwer has joined #gnucash
12:45:29 <jralls> There will also be a massive issue with converting the not-book-currency transactions when opening an existing file the first time. We'll obviously need at least the historical price retrieval, but also some way to calculate the basis in book currency at the time of each transaction.
12:47:02 <jralls> I suspect that will make trading accounts mandatory, though it's arguable that even now not using trading accounts when you're investing with foreign cash account is a recipe for going mad.
12:50:04 *** jervin has joined #gnucash
12:50:09 <jralls> OTOH, I think the book currency for all transactions actually solves "gnucash is the anomaly allowing for foreign currency accounts", but you seem to have figured that out too.
12:51:31 *** jervin has quit IRC
12:51:36 *** jervin has joined #gnucash
12:52:26 *** jervin has joined #gnucash
13:10:27 *** Mechtilde has joined #gnucash
13:54:32 <CDB-Work> Well, in the case of BUY SPY with USD in a CAD book, you know from your trade confirmation the SPY price in USD, and the USD cash that was deducted from your account, and the commissions paid. All of those would be entered in the # shares / units column, and the only thing that would need to be pulled, for all 3 splits, is the USD/CAD price
13:54:51 *** sbluhm has quit IRC
13:54:57 <CDB-Work> that would get everything into CAD terms, so that the transaction currency of CAD checks out
13:55:48 <CDB-Work> regarding the matter of technically realizing a gain/loss when you dispose of your USD (to buy SPY), you can use one of the "end of year" scenarios in my GAAP analysis file to do that all at once at year-end
13:56:52 <CDB-Work> i dont think the user needs to figure that out on a per-transaction basis, so we also dont need to help it either. a report to help you do it at year-end would be a good idea though, and with everything in CAD, it is doable, as the simple example in my GAAP analysis shows (or at least I think it does, can't remember from 2 months ago)
13:57:51 <jralls> Whether you think a user needs to do it is unfortunately irrelevant. Users *will* want to do it and will whine endlessly if they can't.
13:58:31 <CDB-Work> the concept of trading accounts is an interesting one. i cant say that such accounts exist in SAP or Oracle Netsuite or anything like that. it's purely a gnucash construct, to put the quoting feature into a "regular" register, rather than doing it in an external module as would be typical of SAP
13:58:54 <jralls> But maybe if we have a report that makes it easy, and it can be run at any time for any date, that would be good enough.
13:59:28 <CDB-Work> Whether you think a user needs to do it is unfortunately irrelevant. <-- note, I'm saying they ought not do it *per transaction*
13:59:49 <CDB-Work> they ought to be doing it something less frequently than "at each and every single transaction"
13:59:50 <jralls> SAP is infamous for "you do it our way", to the point of driving companies bankrupt because they couldn't manage the changes to their business practices.
13:59:56 <CDB-Work> such as monthly, quarterly, annually, wtc
14:00:29 <CDB-Work> indeed, SAP done wrong is better not started at all
14:00:36 <jralls> Depending on how often they trade that might still be per transaction.
14:00:39 <CDB-Work> i've seen that in companies ive audited
14:01:23 <CDB-Work> Depending on how often they trade that might still be per transaction. <-- indeed, if you only make a trade each quarter
14:01:27 <CDB-Work> buit even if that is the case
14:01:39 <CDB-Work> it would not be done *inside* the trade transaction itself
14:01:45 <CDB-Work> it would be done as a standalone transaction
14:01:50 <CDB-Work> that's more of what i was getting at
14:02:25 <CDB-Work> mark to market the value of your foreign currency cash (USD in my case) on a periodic basis
14:02:40 <CDB-Work> rather than attempt to mark to market each time you purchase or dispose (of USD for me)
14:02:59 <CDB-Work> periodic could be daily, monthly, whatever suits the user's fancy
14:05:57 *** jralls has quit IRC
14:07:16 *** jralls has joined #gnucash
14:07:16 *** ChanServ sets mode: +o jralls
14:07:23 <jralls> Normal people don't need to, and indeed probably shouldn't, mark to market. I don't think there's a way to report doing so on US personal taxes.
14:07:45 <CDB-Work> the mark-to-market is not a tax complaince matter. it's a GAAP compliance matter
14:08:05 <CDB-Work> cash and cash equivalents must be reported on a mark to market fair value basis
14:09:44 <CDB-Work> that said, if trading gains properly picks up on it, after new implementation, a manual mark to market might not be necessary
14:10:08 <CDB-Work> this is all theoretical until we can see for ourselves, after a first cut is done, if it balances properly without a manual mark to market
14:10:33 <CDB-Work> (e.g. the imbalance i kept seeing in the current version of the TB report run on average cost)
14:11:25 <CDB-Work> if everything is in CAD, it ought not to matter, so it ought to always balance, but I'm not going to get ahead of myself and make that assumption prima facie
14:11:28 *** sbluhm has joined #gnucash
14:11:28 *** ChanServ sets mode: +v sbluhm
14:13:15 *** jralls has quit IRC
14:19:52 *** jralls has joined #gnucash
14:19:53 *** ChanServ sets mode: +o jralls
14:20:02 <jralls> .
14:22:46 <jralls> Anyway, the Balance Sheet report will report all of your non-report-currency assets at the price on the day if you select the Nearest in Time price source and have the prices in your pricedb. That takes care of the GAAP compliance.
14:25:30 <jralls> The tax issue arises if you actually re-value in your books the non-home-currency assets and make accompanying G/L entries. Those G/Ls are either taxable gains or deductible losses, and that would have to be reported on your tax return.
14:26:58 <jralls> Having paid the taxes that also resets the basis on those assets for future dispositions. For stocks held in street name where the broker reports the basis to the IRS your basis and the reported one will be different.
14:28:47 *** qwer has quit IRC
14:29:00 *** qwer has joined #gnucash
14:29:03 *** jralls_afk has joined #gnucash
14:29:03 *** ChanServ sets mode: +o jralls_afk
14:29:36 <jralls_afk> There's an excellent chance that the IRS computer will decide you made a mistake and recalculate your taxes based on the broker-reported basis and either send you a bill or a refund.
14:29:58 *** jralls has quit IRC
14:33:05 <CDB-Work> the IRS does not allow mark to market realizations anyways, so it's a moot point
14:33:25 <CDB-Work> not for retail traders, at least. people who operate a business of trading is a different matter
14:33:39 <CDB-Work> including self-declared day traders, depending on the asset class
14:34:12 <jralls_afk> Well, day traders never hold anything long enough to mark to market anyway. ;-)
14:34:25 <CDB-Work> similarly in Canada, and most jurisdictions, retail traders are not allowed to mark to market
14:35:10 <CDB-Work> i think though, by having everything recorded in CAD, the trail balance out of balance on average cost method ought not to show up.... I think
14:35:47 *** qwer has quit IRC
14:36:01 <CDB-Work> since by recording everything in CAD, it must balance in CAD terms
14:36:03 <jralls_afk> It should show up as a non-zero balance in the trading accounts. That's their reason to exist.
14:36:21 *** qwer has joined #gnucash
14:36:50 <jralls_afk> Not so fast. There's a difference between a book with all balanced transactions (which is what GnuCash enforces) and a balanced book.
14:37:34 <CDB-Work> I am thinking the difference i saw in average cost method trial balance, which I think is what you are calling "a balanced book"
14:37:57 <CDB-Work> the out of balance was caused by my USD purchasing SPY
14:38:35 <CDB-Work> which involved no CAD splits. if everything is always reduced to CAD, i am speculating that the particular average cost method out of balance i got, should not happen anymore
14:38:58 <jralls_afk> GnuCash doesn't currently force you to book gains and losses so it's pretty common to have an unbalanced book.
14:39:06 <CDB-Work> which involved no CAD splits <-- since no CAD acounts were involved. and it also meant the transaction currency was something OTHER than CAD, USD in this case
14:39:11 *** jralls has joined #gnucash
14:39:11 *** ChanServ sets mode: +o jralls
14:39:15 <jralls> The average cost method trial balance is indeed designed to help you determine if your book is unbalanced.
14:40:19 <CDB-Work> yes, and I am theorizing that everything recorded in CAD would mean that should never happen. or perhaps, whenver it happens, you can book a "mark to market" correction at year-end to realize the curency gain loss
14:40:30 <CDB-Work> (which is tax reprotable, usually with a de minimis)
14:41:58 *** jralls_afk has quit IRC
14:42:19 <CDB-Work> DR US Cash CA$100 ($70 USD0, CR CAD Cash CA$-100 (1:1.30 fx)
14:42:43 <jralls> Aside from not liking your use of mark to market, I think you're correct. The only issue I have is that it's an adjustment = right_answer - wrong_answer kind of correction. I don't like those.
14:42:59 *** ramontjunior has joined #gnucash
14:43:36 <CDB-Work> DR SPY CA$90 ($70 USD), CR US Cash CA$-90 ($70 USD) (1:~1.28 FX)
14:44:09 <CDB-Work> there is an implied gain/loss there
14:44:22 <jralls> Yup, and it will show up in your TB.
14:44:33 <CDB-Work> that needs to be "marked" to market at year-end
14:44:46 <CDB-Work> and recognized as a gain/loss on holding a currency other than your home currency
14:44:55 <CDB-Work> (and tax reportable if it exceeds the de minimis)
14:45:28 <CDB-Work> in canada, there is a $200 CAD de minimis of currency gain loss
14:45:44 <CDB-Work> we dont have to report if the annual currency gain/loss on cash is less than $200 in the aggregate
14:46:16 <CDB-Work> which unless you held a large cash balance for a really long time (not invested in stocks, a heresy!), you would breach
14:46:57 <CDB-Work> because brokers dont usually treat non-home currency cash as an investment, it would never appear on a 1099 (or the canadian T5008 equivalent)
14:47:05 <CDB-Work> but it is still a taxable gain
14:47:16 <jralls> How many non-accountants know that?
14:47:26 <CDB-Work> probably only those that trade FX
14:48:02 <jralls> Probably only those who trade enough FX that they need to pay someone to do their taxes. ;-)
14:48:19 <CDB-Work> my point is, the TB shows this as an "imbalance", perhaps it would be better if a purpose-named report did the exact same calculation, but then called it "unbooked currency gain loss"
14:48:34 <CDB-Work> because that's what it is
14:49:09 <CDB-Work> it's not an imbalance in the traditional sense, since all your accounts balance in CAD terms. it is an imbalance purely due to the unique fact that gnucash "hides" things in the trading accounts
14:49:17 <CDB-Work> trading accounts that dont exist in other accounting systems
14:50:10 <jralls> No, it's an imbalance because Assets != Liabilities + Equity until you book the G/L.
14:50:27 <CDB-Work> trading accounts are effectively special purpose equity accounts
14:50:35 <CDB-Work> the entire register as a whole, balances
14:50:56 <CDB-Work> it only imblanaces because we have trading accoutns in gnucash
14:51:19 <CDB-Work> in a normal system, trading acounts dont exist, and everything is booked immediately into a P&L currency gain/loss account
14:51:35 <CDB-Work> and/or booked into a cmumaltive currency translation OCI account (equity)
14:51:48 <CDB-Work> trading accounts are a gnucash construct, causing this unique gnucash issue
14:52:06 <jralls> Nope, it will imbalance if you have trading accounts turned off. You've increased or decreased assets without doing the same to Equity or Liabilities.
14:52:23 <CDB-Work> then i would say we have an imporperly designed software if that's the case
14:52:44 <CDB-Work> that or the user NEEDS to necessarily book it into a P&L account
14:52:47 <CDB-Work> as you are supposed to
14:53:14 <CDB-Work> trading accounts do not exist anywhere else, and everywhere else balances just fine without them
14:53:55 <jralls> Yes, GnuCash should force the booking of the G/L. *That* would make your year-end adjustment unnecessary but gets back to how do we help the user compute the G/L?
14:55:21 <CDB-Work> the easiest way is to run that TB report, and book a year-end gain/loss transaction. if anything, you can copy the exact same mechanics into a purpose named report
14:55:22 <jralls> That sweeping claim presupposes a rather encyclopedic knowledge of the innards of every accounting program ever written.
14:55:51 <CDB-Work> i dont claim of course to have seen every single accounting system, but have seen 20+ different ones
14:56:16 <jralls> That's the easiest work around to GnuCash's failure to enforce the accounting equation at transaction commit, which you just said is a serious flaw.
14:56:42 <jralls> You've seen the UI or you've seen the code?
14:57:18 <CDB-Work> as part of audit procedures, we analyze 100% of the transactions in a register. that would involve mapping 100% of transactions against all TB accounts
14:57:33 <CDB-Work> we extract the entire TB, including all hidden, system, automated, and clearing accounts
14:57:39 <CDB-Work> no account is un-reviewed
14:58:06 <CDB-Work> we extract the entire GL and map all its activity against the entire TB
14:58:28 <CDB-Work> we would necessarily detect the imbalance if anything was going into a hidden account
14:59:09 <CDB-Work> in my GAAP analysis, one of the example actually shows how you would record USD in a purely 100% CAD book
14:59:37 <CDB-Work> without the use of any trading accounts, and a year-end realization of the net gain/loss of currency
15:00:32 <jralls> Do you accept that that book is out of balance between the first USD transaction of the year and the year-end adjustment?
15:01:12 <CDB-Work> yes, which is why i originally said at the start of the conversation, it would be insane to mark to market on a per-tranaction basis
15:01:17 <CDB-Work> wait
15:01:21 <CDB-Work> what do you mena out of balance
15:01:26 <CDB-Work> the book _always_ balances
15:01:32 <CDB-Work> https://bugs.gnucash.org/attachment.cgi?id=373770&action=edit see tab GAAP 2
15:01:35 <jralls> Assets != Liabilities + Equities.
15:01:46 <CDB-Work> the equation _always_ holds true
15:01:53 <CDB-Work> eveen before the year-end adjustment
15:01:55 <CDB-Work> see GAAP 2
15:02:04 <jralls> BS. Otherwise there would be no year-end adjustment.
15:02:20 <CDB-Work> see GAAP 2, it's better done with an example than words
15:02:35 <CDB-Work> its very possible that I am simply failing to adequately describe it
15:03:05 <CDB-Work> my definition of what is in the year-end adjustment, might be different than what you are thihnking
15:04:14 <CDB-Work> within GAAP 2, debits always equal credits, A = L + E, and there is a mark to market valuation at year-end
15:04:25 <CDB-Work> and there is no trading accounts whatsoever
15:05:23 <CDB-Work> the "semi-gaap" version of GAAP2 is what is done in practice, because "full gaap" is impractical
15:08:20 <jralls> The full-GAAP has a G/L split in every transaction so A = L + E at the end of each. Semi-GAAP doesn't, so it's out of balance. It supports my position, not yours.
15:09:08 <CDB-Work> > Semi-GAAP doesn't <-- jralls, the debits and credits are equal in every transaction. if you foot the account balances, it balances after each transaction
15:09:23 <CDB-Work> the register balances
15:09:28 <CDB-Work> the carrying values may be incorrect
15:09:31 <CDB-Work> but it _balances_
15:10:17 <jralls> Add in a sale of SPY so that the magic appearance or disappearance of cash is more obvious.
15:11:21 <CDB-Work> Okay, I will upload 2.5 right now then to show you how this would work
15:11:37 <jralls> Leaving CAD out of it: I buy 100 SPY for 10,000 and six months later sell it for 15,000. Assets are up by 5,000 and if I don't book the gain Equity isn't.
15:12:14 <CDB-Work> of course you would book the gain -- you cannot not book the gain
15:12:21 *** jervin has quit IRC
15:12:38 <jralls> Exactly my point.
15:12:49 <CDB-Work> but you are missing mine
15:12:54 <CDB-Work> and example 2.5 will clarify it
15:13:18 <CDB-Work> I think i need to be more explicit in my labelling, that gain/loss account there is CURRENCY gain loss, and not gain/loss on disposition
15:13:57 <CDB-Work> i dont think i am capable of explaining this to you in words, so I will explain it with an enhanced example
15:15:39 <jralls> Let's add back in the CAD: You transfer CAD 12000 to your US brokerage account where it's USD 10000. Six weeks later you use that to buy SPY 100 and on that date the USD 10,000 is worth CAD 12100.
15:16:46 <CDB-Work> I will be honest and say that I am not following your example, and rather than try to interpret it, I am going to finish my enhanced example with a disposition of SPY first. to show you how I would do this
15:17:19 <jralls> So that's the CAD value of the SPY100 on that date and it's a CAD 100 increase in Assets with no corresponding increase in Equity.
15:17:56 *** warlord has quit IRC
15:18:00 <CDB-Work> can you please hold off on creating further and further examples.... and wait until I have had a chance to adequately respond first? with an enhanced example?
15:18:09 <CDB-Work> have some patience?
15:18:35 <jralls> It's your GAAP2 example with easier numbers.
15:18:58 <CDB-Work> I am not following. I would rather see this in excel than in text
15:20:53 <jralls> Line 16-18, where you buy 50SPY for USD50 "with rate 1.40", implying that it's CAD 52. The book value of that USD 50 was CAD 50 so you magiced up CAD2 and didn't book it.
15:21:01 *** warlord has joined #gnucash
15:21:55 <CDB-Work> in the traditional method, you record all balances at 1:1, in home currency (CAD), and you only realize upon and reset the FX rate at year-end
15:22:08 <CDB-Work> this way, the USD account will agree to your USD bank statement
15:22:16 <CDB-Work> your carrying values are "wrong" in _CAD_ terms
15:22:20 <CDB-Work> but the book _balances_
15:22:32 <CDB-Work> the carrying values are correct in USD terms though
15:23:19 <jralls> Then you're not really keeping your book in CAD, are you? If we make the transaction currency the book currency in GnuCash *that will break*.
15:23:19 <CDB-Work> the CURRENCY gain or loss goes unrecorded (carrying values are wrong), but the BOOK still balances, since DR = CR
15:23:42 <CDB-Work> you would not do it this way in GNUcash, since we have trading accounts
15:23:53 <CDB-Work> GAAP 2 is what it looks like in a non-trading account universe
15:24:02 <CDB-Work> it is not what you would do for gnucash
15:24:58 <CDB-Work> note I didnt say that it ought to be what gnucash needs to do (and if I did, i didnt intend it). BUT, it is what everyone else without trading accounts does, and it still balances
15:25:33 <CDB-Work> the example is to point out that trading accounts are a gnucash construct, and that without this construct, it is still entirely possible to run a book that handles multiple currencies
15:25:37 <jralls> You do understand that you don't have to use trading accounts, right? Nor, for that matter, do trading accounts stop you from doing that: You currently create that transaction in USD with no reference to CAD.
15:25:48 <CDB-Work> that is the point I am trying to illustrate
15:26:17 <CDB-Work> > You currently create that transaction in USD with no reference to CAD. <-- not sure what this means
15:26:26 <CDB-Work> you are saying transaction currency =/= CAD?
15:26:55 <jralls> sorry, don't understand =/=.
15:27:06 <CDB-Work> =/= --> "does not equal"
15:28:47 *** qwer has quit IRC
15:28:53 <jralls> Ah, ASCII-art. The programmer's way to say that is !=, ! meaning "not".
15:29:21 <jralls> Yes, currently the transaction currency in your USD->SPY transaction will be USD.
15:29:27 <CDB-Work> or the Excel way is "<>"
15:29:42 <jralls> Some older languages use that.
15:30:04 <CDB-Work> transaction currency in <> CAD is how we get these imbalances in the first place, that need to be picked up at year-end
15:30:19 <CDB-Work> and right back where we started, before being side tracked on how non-gnucash systems handle this
15:30:20 *** qwer has joined #gnucash
15:31:18 <jralls> The thing is that if we change the transaction currency to the book currency then when you do that transaction you'll need to enter an exchange rate for USD->CAD and for SPY->CAD.
15:31:41 <jralls> And the transaction will be balanced in CAD.
15:31:45 <CDB-Work> indeed
15:33:32 <jralls> If you fetch the current price for that USD exchange rate you'll have to use the same resulting CAD value for the SPY and you'll have a change in asset value because that isn't going to be the book value of the USD.
15:35:15 <jralls> So in order to use the semi-gaap method you'll need to find out the current average cost of the USD and put that in for the price.
15:35:41 <CDB-Work> the semi-gaap method does not rely on knowing the average cost of USD
15:35:58 <CDB-Work> it's the the full gaap method that does need to know
15:36:18 <jralls> It will, because that will be the only way of hiding the change in asset value from GnuCash.
15:36:21 <CDB-Work> (row 17)
15:36:53 <jralls> That *is* the average cost of USD in that book.
15:37:58 <CDB-Work> I don't follow. Row 17 in full GAAP recognizes the USD basis of 1.30, vs the USD disposition at $1.40, hence picking up the $5.00 gain
15:38:21 <CDB-Work> in semi-gaap, this is entirely ignored, since it lives with not knowing the CAD value of the USD until year-end valuation
15:38:56 <CDB-Work> (notwithstadning how you are saying gnucash will interpret all this, i havent gotten there yet in my understanding of what you're trying to describe)
15:39:17 <jralls> Row 12 where you book a 30 Gain to to convert the cost of USD from CAD 130 to CAD 100.
15:39:39 <CDB-Work> the account is named "gain", but it's not a true "gain"
15:39:52 <CDB-Work> this is why it's semi-GAAP... the nomenclature is misleading
15:40:06 <CDB-Work> it only _accurately_ reflects the gain at year-end after mark to market
15:40:42 <CDB-Work> i would think of row 12 more as a plug.... so that the USD Cash account is forced to numerically display 100.00
15:40:50 <CDB-Work> in line with your USD bank statement of 100.00 USD
15:41:17 <CDB-Work> effectively, Semi-GAAP is an accumulation of plugs, and at year-end you wash it with mark to market
15:41:23 <jralls> Looks more like Book-Cookery 101.
15:41:34 <CDB-Work> (or more frequently than year-end if you have more frequent reporting)
15:42:03 <jralls> So it balances, it just doesn't reflect reality day-to-day.
15:42:05 <CDB-Work> it's the mechanically easiest way to directly record a USD numeric balance into a CAD register
15:42:16 <CDB-Work> So it balances, it just doesn't reflect reality day-to-day. <-- correct
15:42:35 <CDB-Work> this is why I keep saying, it always balances, but the balances themselves are inaccurate
15:42:52 <jralls> That rather misses the point of GnuCash, which is to accurately reflect reality at all times.
15:43:01 <CDB-Work> the cardinal rule of A = L + E is never broken. the balances are simply inaccurate (in aggregate, in CAD terms)
15:43:13 <jralls> That's why there's no need to close the books at year end.
15:43:44 <CDB-Work> yes, the advantage of gnucash is the live market values, but gnucash does it without actual journal entries, and that is what causes disconnect
15:44:02 <CDB-Work> because GAAP demands actual mark to market journal entries at each quarter end
15:44:40 <CDB-Work> what I (as in CDB here, for ease of discussion) am capping "semi-gaap" is used in practice in many companies
15:45:08 <CDB-Work> full GAAP is impractical, precisely of the extreme practical difficulty of always knowing your USD cash cost basis
15:45:24 <CDB-Work> am capping --> am calling*
15:45:34 <jralls> Yeah, I figured. ;-)
15:46:01 <CDB-Work> gnu trying to do something more "elegant" in always live values, has created a construct of trading accounts that exists nowhere else
15:46:05 <CDB-Work> for better or for worse
15:46:34 <CDB-Work> is there a way to make both coesist? perhaps, but requires some careful tinkering
15:47:36 <jralls> Well, if nobody else is interested in live values that does explain why nobody else has trading accounts. But as I keep saying, they're optional.
15:49:06 <CDB-Work> to be quite honest
15:49:14 <CDB-Work> when i forst adopted gnucash 5 years ago
15:49:17 <jralls> But if they work the way they're supposed to they solve the "what's the current book value of my USD" and provide a way for GnuCash to ensure that A = L + E and make Full-GAAP practical.
15:49:21 <CDB-Work> i was originalyl going to to semi-GAAp
15:49:31 <CDB-Work> then i saw live values, and hve lived with its imperfections since
15:53:29 <CDB-Work> https://bugs.gnucash.org/attachment.cgi?id=373835&action=edit --- for your reading pleasure: GAAP 2.5, with the aforementioned sale of SPY
15:53:37 <CDB-Work> and how semi vs full GAAP would handle it
15:54:14 <CDB-Work> and now, back to auditing my hedge fund (yuck)
15:56:02 *** qwer has quit IRC
15:56:11 <CDB-Work> .... and of course, just as a close the Excel, I spot a formula error. nothing that changes the overall picture, but I will push a v7.1
15:57:25 *** qwer has joined #gnucash
15:59:21 <CDB-Work> https://bugs.gnucash.org/attachment.cgi?id=373836&action=edit
16:02:51 <jralls> BTW, it's confusing to use both DR & CR columns and use negative numbers in the CR one.
16:04:35 <CDB-Work> interesting, because thats actually preferred by a lot of accountants
16:04:40 <CDB-Work> to always see the CR as negative
16:04:58 <CDB-Work> https://bugs.gnucash.org/attachment.cgi?id=373837&action=edit -- last update (I hope)
16:07:07 <jralls> I don't understand how the CAD 13 turned into CAD11.
16:07:11 *** ramontjunior has quit IRC
16:08:00 <jralls> Oh, yes I do.
16:08:16 <CDB-Work> 13 CAD was incorrect. I had over-simplified it by doing ($15 USD - 10 USD) * 1.3. the 11 is off to the right
16:08:54 <CDB-Work> and the $1 PLUG in semi-gaap is because this STOCK GAIN is in CAD (basically the plug appears when you interface a CAD and non-CAD in the same transaction)
16:09:05 <CDB-Work> mono-currency transactions dont need to hit the plug
16:12:33 <jralls> But doesn't that mean that in Semi-GAAP you have to compute the Full GAAP gain and then "plug" it so that it balances? Why not just book the gain at CAD 10?
16:14:26 <CDB-Work> every account is in CAD. meaning your STOCK GAIN account is in CAD. meaning it always needs to be hit with CAD. unlike the USD bank account, it is not a "USD proxy"
16:14:33 <CDB-Work> so it needs to be always recorded in CAD
16:14:45 <CDB-Work> note though, that the CAD basis of your USD cash is irrelevant
16:14:52 <CDB-Work> since what is being disposed here is SPY, not USD cash
16:15:29 <CDB-Work> and (as good practice anyways) you should always be accumulating your stocks' cost basis in your tax reporting currency (i.e. accumulate my SPY basis in CAD at all times)
16:15:44 <CDB-Work> so calculating the STOCK GAIN on SPY, in CAD terms, should not be (too) onerous)
16:19:17 <jralls> Seems onerous: You need to keep two accounts for SPY, one valued effectively in USD but pretending to be in CAD and one actually in CAD. Your example doesn't show it but I think you've said that in Canada you always use average cost for the basis of a sale.
16:19:34 *** qwer has quit IRC
16:20:29 *** jervin has joined #gnucash
16:20:29 *** sergiomiguelrp has joined #gnucash
16:25:16 *** sbluhm has quit IRC
16:25:28 <CDB-Work> I think you've said that in Canada you always use average cost for the basis of a sale. <-- correct
16:25:50 <CDB-Work> the chris ACB tool accurately picks up on it as well
16:26:08 <CDB-Work> since its modeled after my excel, which is canada tax compliant, and also reasonably close to GAAP as well
16:26:43 <CDB-Work> Seems onerous: <-- well it depends what you consider more onerous
16:26:56 <CDB-Work> tracking SPY (or any stock) in CAD, or tracking your USD in CAD
16:27:08 <CDB-Work> i would argue that tracking your USD in CAD is probably way, way more difficult
16:27:10 *** jralls has quit IRC
16:28:27 *** User has quit IRC
16:29:10 *** jralls has joined #gnucash
16:29:10 *** ChanServ sets mode: +o jralls
16:29:10 *** qwer has joined #gnucash
16:29:28 <CDB-Work> jralls: did you catch all 6 messages i sent between your last and your ping-out?
16:30:11 <jralls> I saw nothing after "seems onerous". Lemme check the log.
16:30:50 <CDB-Work> we should put the link to the logs into the channel subject, for easier access. i always have trouble finding it
16:31:22 <CDB-Work> right next to "publicly logged channel"
16:31:37 <jralls> Good idea. I'll do that in a moment.
16:32:36 <CDB-Work> Seems Onerous: https://lists.gnucash.org/logs/2020/08/20.html#T16:19:17
16:33:03 <jralls> On the tradeoff between keeping double books for stocks vs. keeping track the foreign currency basis, I think that trading accounts are supposed to make that easy. I say supposed to because I haven't tested it, I don't use them.
16:33:51 <CDB-Work> well, with the new chris report, it might just achieve the "easy" part
16:33:55 *** qwer has quit IRC
16:34:02 *** jralls changes topic to "Free GPL Personal and Small Business Accounting || Moderation note: To get voice register with NickServ, then re-join. || Please don't ask to ask, just ask and wait! (Possibly a few hours!!) || publicly-logged channel @ https://code.gnucash.org/logs || latest stable: 4.1 || https://www.gnucash.org || https"
16:34:15 <CDB-Work> all hinges on people recording the transactions in a certain manner, though
16:34:52 <CDB-Work> in any case, i still think doing true full gaap for usd cash would be the bigger of nightmares
16:35:11 <CDB-Work> since all dividends and other cash activity would possibly need a realization as well
16:35:35 <CDB-Work> that and broker statements give you plenty of info on your stocks... not so much on your cash
16:35:44 <CDB-Work> you get units, cost basis, etc for stocks, not cash
16:35:51 <jralls> Right, which is why I have in mind using them along with transaction currency is book currency to automatically generate the GL splits. But that's going to be a bit of work and probably won't happen for 5.0.
16:37:01 <CDB-Work> indeed, other systems get around currency by effectively "ignoring" currency until you mark to market at year end
16:37:12 <CDB-Work> gnucash, having the quirk of trading accounts, has other options
16:37:23 <CDB-Work> perhaps more or less elegant, perhaps more or less complex
16:37:57 <jralls> Hmm, there's a limit to how long the topic can be and adding the log location made it go over. ;-(
16:38:26 <jralls> Oh, but we don't need the modertation note anymore.
16:42:10 *** jralls has quit IRC
16:44:30 *** jralls has joined #gnucash
16:44:30 *** ChanServ sets mode: +o jralls
16:45:02 *** jralls changes topic to "Free GPL Personal and Small Business Accounting || Please don't ask to ask, just ask and wait! (Possibly a few hours!!) || publicly-logged channel @ https://code.gnucash.org/logs || latest stable: 4.1 || https://www.gnucash.org || https://wiki.gnucash.org/wiki"
16:47:19 *** Mechtilde has quit IRC
16:47:24 <CDB-Work> OK, with that, back to hedge fund auditing
16:53:11 *** qwer has joined #gnucash
17:03:28 *** jralls_afk has joined #gnucash
17:03:28 *** ChanServ sets mode: +o jralls_afk
17:04:30 *** jralls has quit IRC
17:04:52 *** frakturfreak has quit IRC
17:12:27 *** jralls_afk has quit IRC
17:30:49 *** jralls has joined #gnucash
17:30:49 *** ChanServ sets mode: +o jralls
17:32:58 *** jervin has quit IRC
17:33:14 *** jervin has joined #gnucash
17:45:28 *** jervin has quit IRC
17:50:08 *** jervin has joined #gnucash
19:10:37 *** sergiomiguelrp has quit IRC
20:05:38 *** Aussie_matt has joined #gnucash
20:08:21 *** TownsendHardware1 has joined #gnucash
20:08:34 *** AdrienM has quit IRC
20:08:36 *** TownsendHardware has quit IRC
20:08:36 *** TownsendHardware1 is now known as TownsendHardware
20:08:49 *** warlord2 has joined #gnucash
20:08:56 *** bertbob has quit IRC
20:09:00 *** warlord has quit IRC
20:09:00 *** lmat has quit IRC
20:09:03 *** lmat has joined #gnucash
20:09:04 *** PowaBanga has quit IRC
20:09:13 *** CDB-Man has quit IRC
20:09:16 *** CDB-Man has joined #gnucash
20:09:16 *** ChanServ sets mode: +v CDB-Man
20:09:17 *** qwer has quit IRC
20:09:19 *** PowaBanga has joined #gnucash
20:09:33 *** parsnip has quit IRC
20:09:35 *** AdrienM has joined #gnucash
20:09:35 *** parsnip has joined #gnucash
20:09:58 *** bertbob has joined #gnucash
20:09:58 *** ChanServ sets mode: +v bertbob
20:11:35 *** qwer has joined #gnucash
20:25:42 *** AdrienM has quit IRC
20:27:45 *** AdrienM has joined #gnucash
20:27:45 *** ChanServ sets mode: +v AdrienM
20:45:17 *** qwer has quit IRC
20:45:30 *** qwer has joined #gnucash
20:47:22 *** rigid has quit IRC
20:55:34 *** qwer has quit IRC
20:56:07 *** qwer has joined #gnucash
21:01:06 *** fell has quit IRC
21:01:12 *** jervin has quit IRC
21:01:14 *** fell_laptop has joined #gnucash
21:01:15 *** ChanServ sets mode: +o fell_laptop
22:03:58 <chris> it is done! 3.6kg this 1:51am O_o
22:17:31 <CDB-Work> Congrats!!!!
22:18:09 <CDB-Work> 7.93lbs, that's a _heavy_ baby
22:18:14 <CDB-Work> boy or girl? how's mom doing?
22:25:44 *** Aussie_matt has quit IRC
22:29:17 *** qwer has quit IRC
22:29:50 *** qwer has joined #gnucash
22:33:17 <chris> both mum and daughter well
22:36:35 *** Aussie_matt has joined #gnucash
23:44:24 *** jervin has joined #gnucash
23:55:13 *** FH_thecat has joined #gnucash