2021-02-04 GnuCash IRC logs
00:18:00 *** angel has quit IRC
00:27:58 *** o01eg has joined #gnucash
01:00:27 *** Mechtilde has joined #gnucash
01:17:44 *** gjanssens has joined #gnucash
01:17:44 *** ChanServ sets mode: +o gjanssens
01:21:40 *** fell has quit IRC
01:22:59 *** fell has joined #gnucash
01:22:59 *** ChanServ sets mode: +o fell
01:24:10 *** David has quit IRC
01:24:11 *** CDB-Man has quit IRC
01:24:16 *** David has joined #gnucash
01:24:35 *** CDB-Man has joined #gnucash
01:24:35 *** ChanServ sets mode: +v CDB-Man
01:36:27 *** sbluhm has joined #gnucash
01:48:51 *** CDB-Work has quit IRC
01:58:43 *** frakturfreak has quit IRC
02:04:04 *** jervin has quit IRC
02:05:35 *** jervin has joined #gnucash
02:06:17 *** marusich has quit IRC
02:13:03 *** frakturfreak has joined #gnucash
02:21:20 *** Mechtilde has quit IRC
02:29:53 *** TownsendHardware has quit IRC
02:36:25 *** Aussie_matt has quit IRC
02:59:12 *** marusich has joined #gnucash
02:59:12 *** ChanServ sets mode: +v marusich
03:15:40 *** bertbob has quit IRC
03:17:59 *** chris has joined #gnucash
03:17:59 *** ChanServ sets mode: +v chris
03:17:59 *** gncbot sets mode: +o chris
03:33:40 *** mauritslamers has quit IRC
03:34:07 *** mauritslamers has joined #gnucash
03:34:07 *** ChanServ sets mode: +v mauritslamers
03:44:09 *** Mechtilde has joined #gnucash
03:49:50 *** Aussie_matt has joined #gnucash
03:57:05 *** marusich has quit IRC
03:59:14 *** marusich has joined #gnucash
03:59:14 *** ChanServ sets mode: +v marusich
04:13:50 *** marusich has quit IRC
04:22:06 *** JayC has quit IRC
04:22:46 *** JayC has joined #gnucash
04:22:46 *** ChanServ sets mode: +v JayC
04:29:52 *** bertbob has joined #gnucash
04:29:53 *** ChanServ sets mode: +v bertbob
04:54:16 <chris> CDB-Man I think balsheet-pnl has another subtle bug - conversion to report-currency is dependent upon Acc-Commodity->Report-Currency *prices* existing. But this is not necessary: even if pricedb is empty, we should be able to convert using average-cost.
07:12:39 *** Zambyte has joined #gnucash
07:27:06 *** psmst has quit IRC
07:27:14 *** psmst has joined #gnucash
08:05:53 *** Aussie_matt has quit IRC
08:08:23 *** David has quit IRC
08:08:28 *** David has joined #gnucash
08:27:12 *** Mechtilde has quit IRC
08:34:41 *** Mechtilde has joined #gnucash
08:52:42 *** storyjesse has quit IRC
08:57:34 *** Jimraehl1 has joined #gnucash
08:58:14 *** Jimraehl1 has quit IRC
09:02:20 *** Agfarmer18 has joined #gnucash
09:17:57 *** bertbob has quit IRC
09:23:16 <warlord> ffrogman, only manually entered transactions get prices added to the PriceDB. The importer doesn't do that.
09:23:42 *** sbluhm has quit IRC
09:23:59 <warlord> I do believe there is a PriceImporter where you can import from a CSV file.
09:47:16 *** Agfarmer18 has quit IRC
09:48:03 *** JayC has quit IRC
09:48:22 *** JayC has joined #gnucash
09:48:22 *** ChanServ sets mode: +v JayC
09:50:52 *** David has quit IRC
09:50:58 *** David has joined #gnucash
09:59:16 *** codesmy__ is now known as codesmythe
10:05:48 *** Agfarmer18 has joined #gnucash
10:06:24 *** Mechtilde has quit IRC
10:12:04 *** sbluhm has joined #gnucash
10:12:04 *** ChanServ sets mode: +v sbluhm
10:36:05 *** sbluhm has quit IRC
10:37:11 *** bertbob has joined #gnucash
10:37:12 *** ChanServ sets mode: +v bertbob
10:58:57 *** shoonya has joined #gnucash
10:59:33 *** mydogsnameisrudy has joined #gnucash
11:00:15 *** mydogsnameisrudy has quit IRC
11:03:38 *** Agfarmer18 has quit IRC
11:10:21 *** AdrienM has quit IRC
11:11:35 *** AdrienM has joined #gnucash
11:11:36 *** ChanServ sets mode: +v AdrienM
11:13:40 *** jcarl43 has joined #gnucash
11:13:40 *** ChanServ sets mode: +v jcarl43
11:13:49 *** jcarl43 has quit IRC
11:25:21 *** jcarl43 has joined #gnucash
11:25:21 *** ChanServ sets mode: +v jcarl43
11:47:57 *** guak has joined #gnucash
12:18:39 *** Mechtilde has joined #gnucash
12:36:36 *** Mechtilde has quit IRC
12:40:58 *** ArtGravity has joined #gnucash
12:40:58 *** ChanServ sets mode: +v ArtGravity
12:47:05 *** Mechtilde has joined #gnucash
12:54:20 *** codesmythe2 has joined #gnucash
12:54:20 *** ChanServ sets mode: +v codesmythe2
12:54:50 *** codesmythe has left #gnucash
13:04:05 *** mydogsnameisrudy has joined #gnucash
13:04:38 *** mydogsnameisrudy has quit IRC
13:26:53 *** codesmythe2 has left #gnucash
13:27:56 *** codesmythe2 has joined #gnucash
13:27:56 *** ChanServ sets mode: +v codesmythe2
13:31:14 <CDB-Man> chris: possibly, I am still not particularly confident on how the average cost method reports work to really say anything about them
13:33:07 *** Robert847 has joined #gnucash
13:36:23 <Robert847> Hi. I am running release 3.8 in Linux and I accidentally started to edit a security account from the brokerage account window. Now it refuses to let me cancel the edit. It wants to excange stock for dollars. How do I cancel?
13:37:13 *** Agfarmer18 has joined #gnucash
13:39:54 *** Agfarmer18 has quit IRC
13:40:33 <Robert847> This happens to be a stock sale transaction where I accidentally entered a realized gain as a loss, which is what I intended to correct
13:44:41 <Robert847> If I have to let GnuCadh enter a bogus exchange in order to get to a point where I can go back and fix it will there be a bogus entry in the price database to fix too?
13:50:55 <Robert847> I guess I can see the sale price per share in the text visible in the brokerage window so maybe I can just make sure that is the exchange rate that it is forcing me to enter
13:52:37 <Robert847> that is the value it wants me to use
13:57:34 <Robert847> OK, that worked, I was finally able to cancel the edit after accepting the exchange rate. Then I could go to the security account t fix the realized gain.
13:57:55 <Robert847> Is that still a problem in release 4.4?
14:01:47 *** field^Mop has joined #gnucash
14:02:27 <jralls> gjanssens, The advantage to switching from Docbook to restructured text is that the latter is a flavor of markdown. Non-developers tend to find XML scary and are put off by Docbook.
14:03:50 <gjanssens> jralls: ok, no arguments against that.
14:05:24 <gjanssens> jralls: from the top of your head, what would be reasons the linker fails to find a c++ symbol but finds it if I wrap it in 'extern "C"' ?
14:07:53 <jralls> I'm looking at that now. The problem would usually be mangling. From the error it seems that the linker is looking for the unmangled name, so I guess that gnc_commodity.cpp is mangling it.
14:07:59 <Robert847> Now GnuCash wants to keep an extra line in the transaction for a zero value in the orphan ccount
14:10:37 <gjanssens> jralls: all related objects are C++. Shouldn't they all be able to handle mangling ?
14:11:00 <Robert847> I had to force that to appear n the brokerage account window so I could delete it from there
14:11:24 <gjanssens> Do I have to do something special to enable c++ linking ? I believe gnc-quotes is the first source file in app-utils that's c++
14:12:06 <jralls> If you're compiling a cpp file you have to tell it to use C linkage, so somewhere you are.
14:12:29 <gjanssens> That eludes me
14:12:36 <jralls> Robert847 That usually means that you have an imbalance that's too small to display.
14:12:47 <gjanssens> Is that the 'extern "C"' block ?
14:15:47 <jralls> gjanssens, yes, that's what "extern C" means. So in gnc-commodity.hpp you #include "gnc-commodity.h" to get the decls of gnc_commodity and gnc_commodity_table. The decl of gnc_commodity_table_get_quotabale_commodities is inside the extern C which I suppose is your workaround to avoid the linker error.
14:17:01 <gjanssens> That's the workaround indeed. I meant to push without, but was too fast.
14:18:02 <jralls> Aside, since both gnc_commodity and gnc_commodity_table are passed as ptrs you don't need to include gnc-commodity.h in gnc-commodity.hpp; you can just declare the types e.g. `struct gnc_commodity; struct gnc_commodity_table;`.
14:18:25 <Robert847> Thanks for listening :)
14:18:46 <gjanssens> Before only the the include for gnc-commodity.h was wrapped in extern "C"
14:18:55 <gjanssens> Then I get the error
14:19:24 <gjanssens> Let me try with just the structs
14:20:48 <jralls> That's what I thought. I don't think that forward-declaring the structs in gnc-commodity.hpp will fix the linkage problem.
14:21:11 <gjanssens> Neither do I really
14:26:56 *** codesmythe2 has quit IRC
14:30:49 <jralls> Umm, does your error mention that it's coming from swig-app-utils-guile.c?
14:31:57 <gjanssens> No?
14:32:11 <gjanssens> Is that the error you see ?
14:32:32 <jralls> Mine does. It's in app-utils.i to export it to price-quotes.scm.
14:32:59 <gjanssens> But that's a good hint. And that would make sense too to error out there.
14:33:24 <gjanssens> I'll work from there
14:33:30 <jralls> So I took it out of app-utils.i. Building happily so far...
14:35:07 <jralls> And done successfully.
14:36:07 <gjanssens> Yay! Sometimes you're in too deep to see clearly.
14:36:09 <gjanssens> Thanks
14:37:04 <gjanssens> Same here, built fine :)
14:37:34 <jralls> Make it error again and look at the output: Even if that error line doesn't say anything about swig, the linkage command just above it probably does.
14:38:48 <jralls> Part of c++options changes app-utils swig to swig-app-utils-guile.cpp. I got a lot of linkage errors like that at first.
14:39:51 <gjanssens> Ah, good to know...
14:40:42 <gjanssens> Luckily when I'm done guile won't need that function any more, so I can avoid that can of worms for this feature.
14:50:50 <jralls> Right
14:51:01 <gjanssens> By the way, with gcc there's no mention at all of sige-app-utils-guile
14:51:35 <gjanssens> What I posted on the PR is all error message there is.
14:52:00 <gjanssens> Perhaps clang does better.
14:52:31 <gjanssens> Got to go now
14:52:41 <jralls> Goodnight!
15:14:22 *** sbluhm has joined #gnucash
15:14:22 *** ChanServ sets mode: +v sbluhm
15:51:39 *** codesmythe2 has joined #gnucash
15:51:39 *** ChanServ sets mode: +v codesmythe2
15:52:00 *** gjanssens has quit IRC
15:54:28 *** Mechtilde has quit IRC
15:58:24 <codesmythe2> @tell gjanssens What's the state of CMake in gnucash-docs? Is CMakeNotes.txt in the accurate? It says what is left is special rules for Italian and Windows specific CHM stuff.
15:58:24 <gncbot> codesmythe2: The operation succeeded.
16:01:53 *** jw4 has quit IRC
16:02:13 *** jw4 has joined #gnucash
16:02:13 *** ChanServ sets mode: +v jw4
16:02:24 <codesmythe2> If we converted to rst, I guess we'd have to have a step for pandoc to convert that to docbook to keep the current website HTML the same (minus small differences the conversion might introduce).
16:06:23 <jralls> codesmythe2, gjanssens fixed the chm build in January 2020. I think it still can't compose an Italian gnucash-guide.xml from the po file.
16:06:54 *** sbluhm has quit IRC
16:08:05 <jralls> codesmythe2, how is rst normally rendered in browsers?
16:20:33 <codesmythe2> Restructured text is part of the python docutils package, which comes with rst2html.py as the simplest way. There's a patch to get html output in the chunked format we currently use if we want to keep that.
16:20:56 <codesmythe2> Then of course there's full blow Sphinx, and example of which I did in the past: https://gnucash-docs-test.codesmythe.net
16:21:06 <jralls> Chunked?
16:21:18 <jralls> Is there a php renderer out there?
16:21:48 *** Zambyte has quit IRC
16:23:36 <codesmythe2> chunked = a section (like 3.1) on a web page by itself, as opposed to having a chapter per page, or the whole doc on one page.
16:26:47 *** field^Mop has quit IRC
16:29:29 <codesmythe2> On PHP, there's this, https://github.com/Gregwar/RST, updated last year, but I don't know anything else about it.
16:29:30 <jralls> That's not important for displaying on www.gnucash.org, nor at all for the guide. We do need it for context help in the program.
16:29:48 <codesmythe2> Ah ok.
16:31:12 *** David has quit IRC
16:31:36 *** David has joined #gnucash
16:33:33 <jralls> Though we might be able to use section anchors in an html file-per-chapter layout. Not sure.
16:35:29 <codesmythe2> The build process creates share/gnome/help/gnucash-*/*/*.xml. What consumes that?
16:36:12 <jralls> Yelp.
16:40:16 <jralls> The Sphinx introduction says that it needs LaTeX to generate PDFs. That's less than ideal, TEX is huge and not terribly efficient.
16:49:51 <jralls> It also does epub but not mobi. That's also true of pandoc, so calibre is going to stay in the arsenal and it can also deal with PDFs.
16:51:56 <codesmythe2> So using calibre you would not need latex?
16:52:21 *** David has quit IRC
16:52:27 *** David has joined #gnucash
16:53:07 *** mydogsnameisrudy has joined #gnucash
16:53:50 *** mydogsnameisrudy has quit IRC
16:54:09 <jralls> Yes. RST -> epub via pandoc or Sphinx and epub->mobi and pdf via Calibre.
16:56:31 <codesmythe2> I'd be worried that that flow would produce worse looking PDFs than what we have now (which I think look pretty decent) or pdflatex.
16:56:38 <jralls> But Calibre can also read traditional daringfireball markdown so using that instead of rst could save some work and dependencies.
16:58:02 *** Aussie_matt has joined #gnucash
16:59:30 <jralls> Still more interesting, Calibre can also read MSWord docx and Libre/Open Office odt.
17:13:01 <fell> codesmythe2, one pproblem of CMake in the docs: It is not documented in plcaes like https://wiki.gnucash.org/wiki/Documentation_Update_Instructions
17:18:14 <fell> jrall, at least I found in a short trila no way to set the page size to A4 or letter in calibre.
17:24:23 <codesmythe2> fell, noted.
17:26:15 <fell> And I would suggest to apply new developement primary to cmake and note it in the wiki.
17:34:34 *** codesmythe2 has quit IRC
17:49:38 *** jervin has joined #gnucash
17:52:08 *** David has quit IRC
17:52:13 *** David has joined #gnucash
18:02:40 *** codesmythe2 has joined #gnucash
18:02:40 *** ChanServ sets mode: +v codesmythe2
18:32:06 *** codesmythe2 has quit IRC
18:44:10 *** ArtGravity has quit IRC
19:06:45 <chris> CDB-Man: that's ok. the point is average-cost doesn't require pricedb. takes all splits whereby currency!=commodity, adds, averages them.
19:07:13 <CDB-Man> Yeah and that's the wrong way to do it. We need home currency!
19:10:34 <chris> lol easily said. Some very vocal long-term users will object. If a layman argument for enforcing home currency can be done, then we'll be able to allay their (misplaced) concerns -- jralls or warlord's views won't suffice imho
19:11:06 *** jcarl43 has quit IRC
19:11:22 <chris> this would accompany a datafile upgrade
19:12:05 <warlord> Back around 1.6 every account had a commodity AND a currency.
19:12:08 <jralls> Even without the vocal users it's not easily done. Too much of GnuCash is built on per-transaction currency.
19:12:18 <warlord> Then they removed that, so each account only had a commodity.
19:12:27 <chris> the issue is the upgrade *cannot* be a silent upgrade... if my locale is en_AU and I maintain a GBP book, and its root acct is USD, I won't be happy to have the book become USD
19:12:37 <warlord> I considered that a mistake at the time, but I was a newbie and my opposition was overruled (or just ignored).
19:13:40 <CDB-PHONE> [19:12] (@chris) the issue is the upgrade *cannot* be a silent upgrade... if my locale is en_AU and I maintain a GBP book, and its root acct is USD, I won't be happy to have the book become USD
19:13:50 <CDB-PHONE> the home currency is the book currency then, GBP
19:13:55 <CDB-PHONE> not the root account
19:13:58 <jralls> warlord, I don't think that was a mistake. The mistake was having a per-transaction currency instead of forcing the root account to have a currency and always balancing in that.
19:14:13 <CDB-PHONE> accounts don't matter, everything is denominated in book
19:15:01 <CDB-PHONE> [19:12] (~warlord) Back around 1.6 every account had a commodity AND a currency. <-- this is how it should be
19:15:08 <CDB-PHONE> well
19:15:16 <CDB-PHONE> whatever the nomenclature
19:15:29 <CDB-PHONE> book currency + 2nd currency / commodity
19:15:47 <jralls> And how should GnuCash decide what is the home currency if not the root account currency?
19:16:09 <CDB-PHONE> isn't that an input when you first create a book?
19:16:24 <jralls> Yes. It sets the root currency.
19:16:50 <CDB-PHONE> so you're saying everything is inheritance from the top top level accounts
19:16:59 <CDB-PHONE> and there's nothing overriding on a book level
19:17:21 <jralls> Unfortunately chris discovered a year or two ago that you can change it in Actions>New Account Hierachy.
19:18:18 <CDB-PHONE> I think I'm lost now. does that new hierarchy redefine the book's currency, or does it simply recode the currency of all the top level accounts?
19:18:22 <jralls> There is no "book level". A book is a file/database. It has a single account hierarchy.
19:19:08 <CDB-PHONE> so basically, the top level asset, liability, equity, income, expense, trading accounts, their currency code is what defines everything
19:19:28 <chris> ^no the root is a hidden PARENT account for all visible toplevel accts
19:19:31 <CDB-PHONE> and the closest thing to book currency is ensuring uniformity across the top level accounts
19:19:52 <warlord> jralls, there was no "root account" at the time.
19:19:58 <CDB-PHONE> [19:19] (@chris) ^no the root is a hidden PARENT account for all visible toplevel accts <--- interesting, so this is the mythical book currency I'm looking for?
19:20:16 <jralls> Actions>New Account Hierarchy re-runs the New Account Hierarchy assistant. It's intended for adding more accounts from one of the templates to the current book. Unfortunately it doesn't disable the control for setting the root currency. That doesn't change any of the existing lower-level accounts.
19:20:33 <warlord> actually a book has multiple account "hierarchies" -- there are the "template transactions" too
19:20:39 <jralls> warlord, well, that was another mistake then. ;-)
19:20:57 <warlord> lol.
19:21:07 <CDB-PHONE> if this hidden parent exists, then changing book currency would be changing that hidden parent's currency
19:21:10 <chris> CDB-PHONE there's no book currency :)
19:21:13 <jralls> True about the two hierarchies, each with its own root.
19:21:50 <CDB-PHONE> Chris, a super root of all the top levels is essentially achieving a similar purpose to book currency
19:22:07 <chris> ^ yes that's my proprosal
19:22:18 <CDB-PHONE> ah, PROPOSAL
19:22:34 <CDB-PHONE> I read it as "look what I found that actually already exists"
19:22:51 <jralls> It does already exist. It's just not used that way.
19:22:59 <CDB-PHONE> such a proposal certainly would be the way to shoe horn it in
19:22:59 <chris> however the ROOT currency isn't generally used anywhere, and to suddenly promote it as book currency is bound to create issues. what if the root currency is RND? suddenly users will go huh
19:23:20 <CDB-PHONE> rnd as in Rand?
19:23:32 <chris> yes or RMB
19:23:52 <CDB-PHONE> well, it ought to be whatever was chosen with the assistant at the start, right?
19:25:33 <chris> yes - my point is so far the pricing didn't account for ROOT currency. say my book is mainly GBP, the root is USD, and I live in AU. I care little for USD changes. But with upgrade they suddenly matter.
19:26:01 <CDB-PHONE> well, the first time conversion is to get the user to select root then
19:26:13 <CDB-PHONE> and in your case, they should select GBP
19:26:39 <CDB-PHONE> detect if book is old version, and if so, prompt input
19:27:04 <chris> yes they should,
19:27:42 <chris> and what if someone used ONE book throughout their travels? US to GB 5yrs then FR 5yrs ?
19:27:56 <CDB-PHONE> you start a new book, or you choose 1 currency
19:28:02 <CDB-PHONE> that is proper hygiene
19:28:04 <jralls> The issue isn't the root/book currency. The issue is that all multi-commodity transactions are priced in one of the currencies of the splits in the transaction.
19:28:34 <chris> that too
19:28:35 <CDB-PHONE> that's where the one time price db currency import comes into play
19:28:56 <CDB-PHONE> script to convert everything into book terms
19:29:25 <CDB-PHONE> my purchase of SPY denominated in USD, is converted to CAD using the USD CAD rate
19:29:37 <CDB-PHONE> both the SPY commodity price, and the USD cash paid
19:30:02 <CDB-PHONE> logically simple... difficult in implementation
19:30:42 <chris> lol gnucash should carry historical fx for all iso4217 currencies
19:30:47 <CDB-PHONE> where your may run into issues is a transaction with 3 currencies / commodities
19:31:01 <CDB-PHONE> [19:30] (@chris) lol gnucash should carry historical fx for all iso4217 currencies
19:31:02 <CDB-PHONE> yes
19:31:08 <CDB-PHONE> this is how SAP operates
19:33:04 *** chris-phone has joined #gnucash
19:33:04 *** ChanServ sets mode: +v chris-phone
19:34:24 <chris-phone> Thus logically complicated
19:34:39 <CDB-PHONE> I would say logically simple
19:34:45 <CDB-PHONE> complicated in implementation
19:35:13 <CDB-PHONE> the logic is "always use the FX rate of transaction date to convert to book currency"
19:35:26 <CDB-PHONE> it's just a matter of doing a date lookup on a table
19:36:57 <CDB-PHONE> we already have cases like this, ie you initiate a SPY purchase in a stock account with a USD payment, but you hit a CAD cash account
19:37:12 <CDB-PHONE> so transaction currency is USD, but you need USD CAD and SPY CAD
19:37:29 <CDB-PHONE> SPY is denominated in USD, so you can dual purpose the USD CAD rate
19:38:20 <CDB-PHONE> essentially transactions should always have a transaction currency = book currency
19:38:37 <CDB-PHONE> transactions should not determine transaction currency based on the involved amounts
19:38:47 <CDB-PHONE> amounts -> accounts
19:39:37 <chris-phone> If the conversion was done, where would the currency FX imbalances then land?
19:40:16 <CDB-PHONE> there shouldn't be any...? I think
19:40:47 <jralls> I think he means unbooked realized trading GL.
19:40:48 <CDB-PHONE> in the above example you only introduce 1 FX rate, used on all splits
19:41:01 <chris-phone> Jralls correct
19:41:19 <CDB-PHONE> not sure I understand. example?
19:43:01 <jralls> You buy 100 GME on 27 Jan @371 and sell it today @55.
19:43:22 <chris-phone> 🚀🚀🚀
19:44:10 <jralls> Can you make those things point the other way? :->
19:44:49 <CDB-PHONE> if there is a USD CAD fx rate change between those dates in addition to stock price change, they are all rolled into the same gain loss p&l account
19:45:09 <CDB-PHONE> IFRS does not require you to separate FX gain loss upon realization
19:45:53 <CDB-PHONE> price movement is expressed in CAD terms only, regardless of whether the cause is FX or stock ticker
19:46:43 <CDB-PHONE> the tax jurisdictions that I'm aware of also take a similar approach, since all taxing is done only in their currency
19:47:10 <CDB-PHONE> the tax man doesn't care how the capital gain materialized, just that in home currency terms there was in fact a realization
19:47:25 <CDB-PHONE> does that answer the question? or am I missing the question
19:47:59 <CDB-PHONE> I can say this work certainty for Canada and USA tax authorities for sure
19:48:06 <CDB-PHONE> with* certainty
19:48:26 <jralls> Right. But suppose your old book kept the GME strictly in US and this script comes along and changes the transaction currencies to CAD for you. Now you have additional GL that you hadn't accounted for before. Where would the script put them?
19:49:01 <CDB-PHONE> not sure what your mean by additional GL
19:49:38 <CDB-PHONE> the number of account splits in each transaction shouldn't change
19:50:25 <CDB-PHONE> or is this a trading account thing I'm overlooking...
19:51:11 <jralls> We're talking about your hypothetical conversion script here. You keep the GME in your US broker account, bought the stock with the cash in that account and put what little you recouped back in to it, and booked the loss in a USD realized gain account.
19:52:15 <CDB-PHONE> I think I see where this is going. let me do a quick Excel and screenshot
19:52:45 <jralls> Now you upgrade to GnuCash 6 and it wants to force all of your transactions to use CAD as the currency and converts those former USD transactions to CAD using the historical exchange rates for the day of each transaction.
19:53:16 <jralls> That generates a new USD-CAD GL that needs to be accounted for somehow.
19:54:07 *** CDB-Work has joined #gnucash
19:54:07 *** ChanServ sets mode: +v CDB-Work
19:54:12 <chris-phone> Also: conversion rounding errors. FX rates have limited precision.
19:54:54 <CDB-Work> on rounding, I would simply arbitrarily round one split up or down 1 cent to make it balance
19:55:17 *** truelehr has quit IRC
19:58:37 <jralls> GnuCash can barely handle calculating simple GL. I have trouble seeing how we can make a script to convert an existing book and leave the poor user with anything less than an excruciating headache.
19:58:53 <CDB-Work> https://ibb.co/94BWWzR
19:58:54 <CDB-Work> here
19:59:12 <CDB-Work> the currency trading splits simply disappear
19:59:20 <CDB-Work> going to add the sale of stock next
20:00:32 <jralls> That's how it works once the single book currency is already enforced. The question is how to convert an existing transaction that ignored the CAD component.
20:00:58 <CDB-Work> well, the left side was done pre-CAD
20:02:02 <CDB-Work> actually, that USD trading split i dont think gets created
20:02:30 <CDB-Work> in that example
20:02:58 <CDB-Work> the only split is GME with a commodity rate of 1 GME = 100 USD
20:04:37 <jralls> I specified that you paid USD from the cash account in your US brokerage account and started the transaction in that account so that there's only USD and GME in the transaction.
20:05:03 <CDB-Work> okay, working on that now
20:05:31 <jralls> The loss on the sale of GME was also booked to a Realized Gains USD account.
20:05:48 <CDB-Work> if anything, that makes it easier
20:08:22 <CDB-Work> https://ibb.co/fH0GwWv
20:08:55 <CDB-Work> if it is all in USD terms originally, ther was no cross between currencies, so there's nothing to clean up from a trading accounts perspective
20:09:30 <CDB-Work> hmm, actually... I see, I need to account for USD a a commodity
20:09:32 <CDB-Work> re-doing
20:11:06 <CDB-Work> https://ibb.co/5hv6ZdL
20:13:23 <CDB-Work> hmm, I think I need to attach USD commodity to the GME split
20:13:26 <jralls> Did I manage to pick two days in which the USD-CAD rate was the same?
20:13:42 <CDB-Work> no, i just didnt include FX rates for now
20:13:50 <CDB-Work> that can be layered in on step 2
20:14:57 <jralls> The whole point of the question is the change in FX rates and what to do with that imbalance when the script runs n years after the transaction.
20:15:22 <CDB-Work> yes well, let's make sure I get the basics down first :)
20:15:47 <CDB-Work> https://ibb.co/hcXjBkN NOW I think this balances
20:16:45 <CDB-Work> ... no, 2 comodities in the same split doesnt make sense
20:17:18 *** ffrogman has quit IRC
20:17:29 <CDB-Work> https://ibb.co/MR9zk0K version 4
20:17:59 <CDB-Work> no... i still have 2 commodies in GME...
20:18:03 <jralls> The GME split will have two commodities: GME amount and USD value.
20:18:56 <CDB-Work> https://ibb.co/qrtNLPr take 5
20:19:31 <CDB-Work> I feel like I need a USD Trading on the left side
20:20:22 <jralls> You do.
20:20:44 <CDB-Work> https://ibb.co/Qk55KD5 take 6
20:20:56 <jralls> What are the commodity columns supposed to represent?
20:21:18 <CDB-Work> in the register, that # units column to the left of the DR CR columns
20:21:29 <CDB-Work> the onme that's beside to the left of the price column
20:21:55 <jralls> That's Amount. It's in the split-account's commodity.
20:22:26 <CDB-Work> then I don't need the 100 USD on the left side in the GME line then
20:22:50 *** CDB-PHONE has quit IRC
20:23:46 <CDB-Work> https://ibb.co/nB6LJdT take 7
20:24:24 <CDB-Work> on the right hand side, all accounts are treated as commodity accounts
20:24:46 <jralls> You don't want the 100 USD Commodity, you do want the 100 DR. Note that the trading account splits also have values so repeat the DR and CR from GME and USD Cash but reversed, so USD Trading is DR 100.
20:24:58 <CDB-Work> so the USD Cash and the USD cap gain accounts are USD commodity. the transaction DR/CR is in CAD, but the Amount is USD comodity
20:26:03 <jralls> Currently the transaction DR/CR is USD.
20:26:48 <jralls> Because as far as GnuCash 4 is concerned a transaction involving a USD cash account and a stock priced in USD is all USD.
20:26:51 <CDB-Work> https://ibb.co/GR6LJwY take 8
20:28:26 <CDB-Work> I think is the Buy transaction on the left, the USD cash CR 100 USD, i Need a -100 USD commodity value? and i need to sign reverse the commodity value in thr US trading account
20:29:08 <jralls> Yes.
20:29:31 <jralls> And likewise on the sell with cash and cap gain.
20:29:57 <CDB-Work> https://ibb.co/6B8z2SY take 9, and this time i included the column labels so we can call out cell references
20:30:54 <CDB-Work> IF.... this is good, I will now incorporate FX change
20:31:33 <chris> gtg work
20:35:02 <jralls> Some more nuance on the sell txn. The GME sell split will be -1 and CR80, balanced by the DR 80 to USD Cash. Then there's a separate GL split with no GME commodity amount. That's so that the GME sell price calculates correctly.
20:35:09 <jralls> Bye, Chris.
20:35:33 <jralls> But what you have is good enough for this purpose.
20:36:40 <CDB-Work> Then there's a separate GL split with no GME commodity amount. <-- ah right, the gain/loss
20:36:55 <jralls> ;-)
20:37:26 *** AndroUser2 has joined #gnucash
20:37:37 <CDB-Work> https://ibb.co/2ybvg86 take 10
20:38:25 *** guak has quit IRC
20:38:28 <jralls> OK, the left side looks like it would in GnuCash. On the right side shouldn't there be CAD trading splits for converting the $100 to C$130 to GME 1 and so on?
20:38:35 <CDB-Work> ... F18 and G19 need to be reversed
20:39:39 <CDB-Work> re: right side -- if the transaction currency is CAD but all the involved splits are NOT cad accounts, do you even need CAD trading splits?
20:40:09 *** chris-phone has quit IRC
20:41:07 <jralls> If the transaction currency is CAD then every non-CAD split will have a value in CAD and a corresponding pair of trading account splits to reflect the conversion.
20:42:33 <jralls> I don't know offhand if it works to create such a transaction though. You'd have to start in a CAD register and if it does as soon as you committed the transaction it would disappear.
20:42:49 <jralls> Because it wouldn't have a split in that register.
20:44:03 <CDB-Work> hmm
20:44:56 <CDB-Work> wouldn't that result in double commodities then?
20:45:54 <CDB-Work> as it stands right now on the right hand side, the value is always in CAD, and the amount is either GME or USD commodity
20:46:09 <CDB-Work> there isnt a 2nd amount column for a CAD commodity
20:46:15 <CDB-Work> nor do I see a need
20:47:00 <CDB-Work> though, there is a need to somehow store that GME = 100 USD... i see where you are going
20:48:48 <CDB-Work> perhaps this is telling us we need a 2nd Amount column...
20:48:54 *** Aussie_matt has quit IRC
20:49:23 <jralls> Like I said an hour or so ago, this is not going to be an easy change.
20:52:18 <jralls> And for it to be remotely feasible the code base needs to be thoroughly scrubbed so that there are 47 zillion side effects scattered around that can screw things up.
20:53:34 <CDB-Work> hmm, so it really sounds like there needs to be a "book currency commodity" column or something, for sTOCK accounts at least
20:53:44 <CDB-Work> the non stock accounts dont need that 2nd column
20:53:57 <jralls> Maybe by the time we can do it the whole thing will be moot because RMB will be the only legal currency.
20:55:17 <CDB-Work> https://ibb.co/Lk0Lj4t take 11
20:55:51 <CDB-Work> take 12 I will attempt to actually change hte FX rate
20:57:16 <CDB-Work> hmm, i still dont think CAD trading splits are needed, as seen on the right side
20:57:30 <CDB-Work> no CAD commodities are ever generated
20:57:33 <CDB-Work> just CAD values
20:59:21 <CDB-Work> maybe ill change my opinino when i try to do the FX rate change
21:04:42 <jralls> I did the experiment in a three-currency book, starting from a EUR account and transferring from a USD to GBP. I got trading entries only in GBP and USD, but every split has an exchange rate to EUR.
21:04:58 <jralls> So you're right, no CAD trading splits.
21:05:04 <CDB-Work> :)
21:05:25 <CDB-Work> im giving thought to the question of the "orphaned" FX gain right now
21:05:34 <CDB-Work> from a commodity perspective anyways
21:08:47 <CDB-Work> https://ibb.co/VHbZYvFtake 12
21:08:55 <CDB-Work> see in the bottom right, the sum total of the highlighted cells
21:09:11 <CDB-Work> that's the hidden fx variance that I think chris was talking about
21:09:23 <CDB-Work> it also sits in the GME stock account too
21:09:58 <jralls> Isn't it backwards though? The change would be in CAD, not USD.
21:10:09 *** Aussie_matt has joined #gnucash
21:10:28 <CDB-Work> not sure what you mean
21:10:48 <CDB-Work> the Values in CAD match, and there's no CAD commodities
21:11:56 <CDB-Work> also, the TRADING accounts offset each other, so perhaps this is a moot point?
21:12:04 <CDB-Work> the entire column there actually nets to $0
21:12:31 <CDB-Work> https://ibb.co/qgMSZnh take 13
21:13:20 <CDB-Work> the $4 USD amount is $5 CAD at 1.25, which is what the $20 USD cap loss would have been... $25 CAD, had hte FC stayeed the same
21:13:34 <CDB-Work> i.e. the $4 USD ($5 CAD) represents the FX loss portion of the cap loss
21:14:56 <CDB-Work> though, taht doesnt agree with the above example, where the cap loss is $26 CAD vs $30 here for a $4 diff
21:15:54 <CDB-Work> $130 * 0.80 = $104, for a $26 / 130 = 20% loss
21:15:57 <jralls> OK, I see what you did.
21:16:28 <CDB-Work> the math is definitely right though that $30 CAD is the total loss at the bottom
21:16:41 <CDB-Work> i paid $130 cad and get 100 cad, the loss is 30 cad
21:18:19 <CDB-Work> perhaps the $4 USD is "unitless" and it should actually be interpreted in CAD as the $4 CAD fx loss
21:25:03 <jralls> Dinnertime.
21:27:47 <jralls> I'm not sure about where the $4 goes. But consider that your book has the two left-side transactions and GnuCash has to automagically convert dozens or even hundreds of them to the right side and the trial balance report has to balance before-and-after. How would that work?
21:27:58 <jralls> I'll read your answer tomorrow.
21:28:13 *** chris_ has joined #gnucash
21:28:13 *** gncbot sets mode: +o chris_
21:28:32 <CDB-Work> https://ibb.co/wLW89DJ take 14 -- here is a more extreme example using FX rates of 2.00 and 1.00
21:29:18 <CDB-Work> and yeah, I'm drawing a blank on where the $4 goes
21:29:50 *** chris has quit IRC
21:33:42 <CDB-Work> perhaps it simply "doesnt go anywhere"... since it all nets to $0
21:34:35 <CDB-Work> https://ibb.co/2dTh0M8 take 15 -- i will also upload the excel file into the ticket
21:37:53 <CDB-Work> https://bugs.gnucash.org/attachment.cgi?id=373996&action=edit uploaded
21:43:47 <CDB-Work> to expand on "doesnt go anywhere"... since everything is recorded in CAD terms, the gain/loss in other terms is academic in that it shouldnt affect any outcomes
21:44:36 <CDB-Work> that being said, it somehow ought to show the true loss in foreign terms
21:45:05 <CDB-Work> AH
21:45:23 <CDB-Work> perhaps that delta amount should be force fed back into the USD amount of the gain/loss split
21:46:44 <CDB-Work> ah yes, that's it
21:46:53 <CDB-Work> the script needs to copy the USD amounts verbatim
21:46:59 <CDB-Work> rather than apply any FX transformation
21:47:18 <CDB-Work> the problem of course is that it is impossible for the script to come up with the yellow highlight cell
21:48:38 <CDB-Work> https://ibb.co/Rgj4x5T take 16
21:48:53 <CDB-Work> the yellow cell's -80 cad is not something solvable by formula
21:51:09 <CDB-Work> well, not a simple formula anyways
21:52:30 <CDB-Work> gain loss is something only computable with the giant ACB tool that chris and I want to build
21:52:59 <CDB-Work> well, i suppose you can shortcut it
21:53:08 <CDB-Work> by saying the current value of GME is $200 CAD for 1 share
21:53:19 <CDB-Work> so the total credit when selling needs to be -200
21:53:40 <CDB-Work> but then you run into issues of the script needs to discern long position vs short ones, where in a short the logic is reversed on buys and sells
21:56:12 <CDB-Work> it is starting to sound like a hard fork is easier...
21:57:11 *** shoonya has joined #gnucash
21:58:52 <CDB-Work> https://ibb.co/j4XhxQv take 17 -- the yellow cell is not solvable with a "simple" formula
22:01:43 <CDB-Work> https://bugs.gnucash.org/attachment.cgi?id=373997&action=edit updated file
22:06:56 *** marusich has joined #gnucash
22:06:56 *** ChanServ sets mode: +v marusich
22:09:34 *** storyjesse has joined #gnucash
22:30:48 *** marusich has quit IRC
22:34:23 *** jervin has quit IRC
22:42:04 *** shoonya has quit IRC
22:58:17 *** marusich has joined #gnucash
22:58:17 *** ChanServ sets mode: +v marusich
23:32:30 *** CDB-PHONE has joined #gnucash
23:32:30 *** ChanServ sets mode: +v CDB-PHONE
23:38:08 *** jervin has joined #gnucash
23:40:28 *** jervin has quit IRC
23:53:28 *** marusich has quit IRC
23:59:28 *** marusich has joined #gnucash
23:59:28 *** ChanServ sets mode: +v marusich