2025-01-05 GnuCash IRC logs
01:58:06 *** fell has quit IRC
01:59:25 *** fell has joined #gnucash
01:59:25 *** ChanServ sets mode: +o fell
05:03:07 *** jonakeys has quit IRC
05:29:33 *** sunyibo has joined #gnucash
05:29:33 *** ChanServ sets mode: +v sunyibo
06:20:30 *** sunyibo has quit IRC
06:27:34 *** jonakeys has joined #gnucash
10:42:12 *** chris has joined #gnucash
10:42:13 *** ChanServ sets mode: +v chris
10:42:13 *** gncbot sets mode: +o chris
10:44:54 <chris> @tell warlord the invoice report does render the Entry->Quantity with 2 decimal. what do you think is a reasonable improvement for the qty? integer (+/- fraction) ?
10:44:54 <gncbot> chris: The operation succeeded.
10:45:27 <chris> IMHO it should allow and render exact fractions
10:46:18 <chris> hmm odd it does render as exact fraction
10:46:27 <chris> @tell warlord ignore last message^
10:46:27 <gncbot> chris: The operation succeeded.
11:59:26 *** chris has quit IRC
13:16:50 *** warlord has joined #gnucash
13:16:50 *** gncbot sets mode: +o warlord
13:17:20 <warlord> .
13:17:20 <gncbot> warlord: Sent 18 hours and 3 minutes ago: <jralls> fell I put the Gnome runtime back to 47. Fingers crossed...
13:17:21 <gncbot> warlord: Sent 2 hours and 32 minutes ago: <chris> the invoice report does render the Entry->Quantity with 2 decimal. what do you think is a reasonable improvement for the qty? integer (+/- fraction) ?
13:17:22 <gncbot> warlord: Sent 2 hours and 30 minutes ago: <chris> ignore last message^
13:17:50 <warlord> jralls, did it work? (I didn't check)
13:21:17 <warlord> I don't see a build from last night. Looks like there was an error:
13:21:18 <warlord> fusermount3: failed to access mountpoint /home/builder/flatpak/.flatpak-builder/
13:21:18 <warlord> rofiles/rofiles-NGJ2D7: Permission denied
13:21:18 <warlord> ========================================================================
13:21:18 <warlord> Building module gc in /home/builder/flatpak/.flatpak-builder/build/gc-1
13:21:19 <warlord> ========================================================================
13:21:20 <warlord> error: Build directory /home/builder/flatpak/.flatpak-builder/rofiles/rofiles-NG
13:21:22 <warlord> J2D7 not initialized, use flatpak build-init
13:25:41 <warlord> The mountpoint looked all frotzed:
13:26:05 <warlord> root@gnucash-flatpak:~# ls -la /home/builder/flatpak/.flatpak-builder/rofiles/
13:26:05 <warlord> ls: cannot access '/home/builder/flatpak/.flatpak-builder/rofiles/rofiles-NGJ2D7': Permission denied
13:26:05 <warlord> total 0
13:26:05 <warlord> drwxr-xr-x. 3 builder builder 55 Jan 2 17:41 .
13:26:05 <warlord> drwxr-xr-x. 9 builder builder 106 Jan 2 17:41 ..
13:26:06 <warlord> d?????????? ? ? ? ? ? rofiles-NGJ2D7
13:26:17 <warlord> -rw-------. 1 builder builder 0 Jan 2 17:41 rofiles-NGJ2D7-lock
13:26:46 <warlord> I cleared out that mount, so hopefully it'll run properly tonight. but not sure why it got wedged.
15:44:00 *** sunyibo has joined #gnucash
15:44:00 *** ChanServ sets mode: +v sunyibo
15:49:13 <CDB-Man> So I received a BCC email today from the mailing list for an issue "Re: [GNC] Feature Request: Add Support for Functional Currency Amount in Transactions" -- don't know how I got looped into the issue, and the email only shows the last message by user flywire without any way to find the rest of the thread
15:49:45 <CDB-Man> 1. Is there a way for me to find the rest of the thread?
15:50:54 <CDB-Man> 2. I don't know who is flywire and why I was BCC, but this looks related to the issue of currency transactions in non book currency I flagged 2 years ago (and how a fix would be a fundamental change)
15:58:32 *** doc has joined #gnucash
16:23:33 *** sunyibo has quit IRC
16:49:12 *** jralls has quit IRC
16:49:20 *** jralls has joined #gnucash
16:49:20 *** ChanServ sets mode: +o jralls
16:51:20 <jralls> CDB-Man, you may have gotten flagged by my taking your name in vain in an earlier post on the thread. Here's the head of the thread: https://lists.gnucash.org/pipermail/gnucash-devel/2025-January/047007.html
16:56:26 <jralls> CDB-Man, flywire is a user who has been around for a couple of years. They've filed bugs, submitted PRs, and contributed to the wiki.
17:22:38 *** jralls has quit IRC
17:22:46 *** jralls has joined #gnucash
17:22:46 *** ChanServ sets mode: +o jralls
17:42:07 <warlord> I just find it amusing that the request is to re-insert a field that GnuCash had 25-30 years ago but was removed by the developers at that time (before my time as a dev, but I was starting into the ecosystem at the time)
17:48:41 <CDB-Man> jralls: thanks for sharing the link. I will read into the details. I tend to agree with the suggestion by Kevin, it's substantively similar to what I suggested, and it's how corporations do it in the real world
17:49:18 <CDB-Man> warlord: hah! Curious to know if at the time of removal, if any accountants were consulted at the time
17:51:42 <CDB-Man> jralls: minor detail... "CDB-Man is a licensed accountant in Vancouver, BC" -- actually Ontario! makes no difference to the matter at hand :)
17:53:13 <CDB-Man> in the real world, all transactions are generally recorded in book currency 100% of the time, any foreign currency amounts are stored in a 2nd column, with the FX rate as a calculated value in the 3rd column
17:53:37 <CDB-Man> each split would be: book value / foreign value / FX rate
17:54:33 <CDB-Man> the challenge is of course equities priced in something other than book currency. in real life, if you're not an investment firm where daily mark to market valuation amtters, typically it's a month end transaction to update value of securities at end of month, recorded in book currency
17:55:43 <CDB-Man> more advanced accounting systems (ie used by investmenr firms, or non-investment firms with large holdings), might have extra columns for 3rd currency and fx rate, or simply translate the security currency using an FX source to convert to book
17:56:10 <jralls> CDB-Man, as you know we almost already do that, and if the transaction currency was always the book currency we would completely do that. The amount is in the foreign currency and the value would be in the book currency.
17:58:27 <CDB-Man> right, agreed on that front if all transactions were forced to book currency. but then what happens when pricedb updates, how would that be factored in when we display market value? likely just a gap in my understanding. are you saying that for example, an HKD stock would be first priced in HKD (eg 100 shares * $5 = $500 HKD), then it would also translate that $500 HKD to USD to display on a report (ie balance sheet)?
17:58:55 <jralls> Yup. Already does.
17:59:25 <CDB-Man> interesting. ok, now I understand your reply where you said adding a 3rd pair
18:00:04 <jralls> For the accounts page you have to turn on the Balances(CAD) column.
18:02:02 <jralls> Where it blows up now is in the average cost price source because that can't handle the double conversion. That's what got bug 797796 started. It kind of went astray from there.
18:02:13 <CDB-Man> so the splits would be, for a purchase:
18:02:13 <CDB-Man> Cash USD $100 USD
18:02:13 <CDB-Man> Stock AAA account: stock commodity units (in HKD) 100 shares $500 HKD
18:02:13 <CDB-Man> STOCK commodity split: AAA commodity 100 shares $500 HKD
18:02:13 <CDB-Man> CURRENCY: USD $100 USD
18:02:16 <CDB-Man> CURRENCY: HKD ... ???
18:02:18 <CDB-Man> ...
18:02:20 <CDB-Man> I think I'm missing something here
18:02:24 <jralls> But I think that if the value was always book currency that it would be fixed.
18:03:22 <CDB-Man> > Balances(CAD) column <-- you're referring to the tab which cannot be closed, the master account listing
18:05:10 <jralls> 4 splits: Dr AAA 100, cr HKD 500, Dr HKD 500, Cr USD 100.
18:05:38 <CDB-Man> reading up on bug 797796 again, I remember we also looked into alphavantage and if we could pull historical FX rates, and the answer was yes up to a certain date (I think it was around 2003 or something)
18:07:57 <CDB-Man> those 4 splits make snese, but, I thought you would need a 5th split to create the AAA commodity with Cr 100 shares?
18:08:25 <jralls> Huh? Coming from where?
18:10:05 <CDB-Man> when you DR the Stock asset, we're recording 100 AAA share commodity units at $5 HKD/share
18:10:05 <CDB-Man> then Cr Cash HKD $500 HKD to pay for it
18:10:05 <CDB-Man> if the book was in HKD, we would have a Cr AAA commodity account, and Dr the USD commodity account -- total 4 splits
18:10:26 <CDB-Man> in the case where the book is USD though, we would need to add the 3rd pair like you said
18:10:38 <CDB-Man> so... that's where I'm confused
18:12:18 <jralls> And I realize I was thinking in terms of trading splits and that's not right. What you'd really get is two spilts, amount AAA 100 price 1, value USD Dr 100 and amount HKD -500 price .20 value USD 100, then the 4 trading splits.
18:15:46 <CDB-Man> https://i.imgur.com/R7yMczo.png
18:15:58 <CDB-Man> if I'm following you... I got this far with the first 4 splits
18:16:41 <CDB-Man> err, rather, this one: https://i.imgur.com/e82L0Mz.png
18:17:25 <CDB-Man> I hav ethe regular splits and the first 2 obvious trading splits -- the confusion is on trading splits 3 and 4
18:18:07 <CDB-Man> (I think i have the signs reversed on the HKD price column
18:19:10 <CDB-Man> https://i.imgur.com/BauC9Ty.png -- 3rd time's the charm... fixed the signs, but unclear on trading splits 3 and 4
18:19:54 <jralls> The prices should all be positive. CRs are represented as negative numbers in GnuCash.
18:20:22 <CDB-Man> ok, that makes more sense (and consistent with standards too)
18:21:51 <jralls> But that's not important to the discussion. I was thinking that the HKD trading account balance needs to net out, but that's wrong. Having the txn currency be USD means there don't need to be any USD trading splits.
18:22:22 <CDB-Man> ok, that makes more sense to me, and why I was a bit confused when you suggested the 3rd trading split
18:22:43 <CDB-Man> the challenge is that you have 2 FX's in the transaction: AAA <> HKD, and HKD <> USD
18:23:13 <jralls> Yeah, that's what you're demanding: Everything gets priced into the book currency.
18:24:00 <CDB-Man> yep. and my understanding (if I haven't mixed it up!) is that transactions currently can only handle 1 FX, not 2
18:25:37 <CDB-Man> in real world, we specify the FX per split, which also means doing AAA <> USD instead, and if we want to store HKD, it's done "outside of the journal entry". that or, you have extra columns to also store AAA<>HKD + HKD<>USD for that stock account split
18:26:18 <CDB-Man> I've finally reached the end of the mailing list thread, I see flywire replied to the OP, which is why his thread looked to cut everything off. flywire's solution would record everything in book... but then it would also render useless priceDb and the benefit of mark to market updates of stock values
18:26:54 <jralls> In GnuCash too, so at present the user would have to calculate AAA <> USD and enter it (or the USD amount) in the exchange rate dialog.
18:27:10 <CDB-Man> his reply there feels a bit dismissive, but that's beside the point
18:28:12 <CDB-Man> right: and if the user manually does that, they would also need to setup the AAA security as USD, which prevents them from using priceDB updates since priceDB would pull HKD prices (and your security is coded USD)
18:28:13 <jralls> He's used to the way some other program does it and he wants GnuCash to be just like that.
18:28:58 <CDB-Man> gotcha. doing it his way technically does work (record everything in functional/book currency), but it would come at a cost of inability to use priceDB live price updates
18:29:53 <CDB-Man> this has been enlightening, the comment from warlord on having this field a long time ago and seeing it deleted... :)
18:29:59 <jralls> Not when the txn currency is USD as long as we don't change the pricedb's currency understanding.
18:31:01 <CDB-Man> if AAA is setup in security editor as HKD, can you even manually put in a split (today in gnucash) with an AAA/USD FX when the txn fx is USD?
18:31:29 <CDB-Man> if yes, and taken with your priceDB comment... priceDB will do the double convert? or rather, that sounds like the enhancement perhaps\
18:31:43 <jralls> The cool thing is that you can use GnuCash today to experiment with this: Use transaction journal view (so split view is always on) and start the transaction in a book-currency register, then create your AAA and HKD splits.
18:32:38 <CDB-Man> hmm, I'll have to test this in a dummy book after dinner
18:34:08 <jralls> The non-currency->currency relationship is determined by the placement of the accounts. The commodity itself knows nothing about currency, and the pricedb records arbitrary commodity/currency pairs.
18:36:54 <CDB-Man> Interesting. Though, the AAA commodity account would have a parent account of HKD, and would inherit HKD -- so in this transaction we have 3 units: USD txn currency, AAA asset and AAA commodity HKD (inherited from parent), HKD cash
18:37:20 <jralls> Which brings up a problem that you'll discover when you experiment: The AAA split will create a AAA-USD price, but FQ will create AAA-HKD prices. Since the pricedb lookup functions always look for the one-step price before the two-step price you won't see the latest prices reflected in reports or the Accountspage.
18:38:18 <CDB-Man> This reminds me how my own main book's price DB has a few stray CAD entries... Even though my personal book is CAD already
18:39:57 <CDB-Man> Following your logic of always enforce txn currency to book currency, the enhancement here is for price conversion to add a 2nd step. Right
18:40:22 <CDB-Man> And hence how we got to the topic of alpha vantage historical FX lookup
18:40:43 <jralls> Right. So we'll need to smarten up the pricedb about creating prices from transactions and I guess the Stock Assistant to pay attention to a stock's pricing currency so that it can ask for the stock price in the right currency and the exchange rate to the book currency, then do the calculations for the user.
18:43:08 <jralls> The catch with Alphavantage is that since we had that discussion they put a 25 query per day limit on free accounts. It could take a while to collect all the historical rates that you need.
18:44:34 <CDB-Man> Hmmm. I assume you may have thought about this, but a few ideas:
18:45:05 <CDB-Man> 1. On the "initial setup/conversion", rather than looking up every day, only lookup dates with foreign transactions
18:45:45 <CDB-Man> 2. On the go forward, do the lookup at the transaction entry level (still imperfect if user needs more than 25 queries in a single sitting)
18:46:42 <CDB-Man> By #2 I mean that FX button on the fx entry window, but make it look up the transaction date rather than today's date (which is current behaviour IIRC)
18:47:28 <jralls> I hadn't actually thought about converting existing transactions.
18:48:16 <CDB-Man> It was the conversion of existing that prompted us looking up what AF allowed
18:48:34 <jralls> Oh, I hadn't thought about the need for a historical rate when making a new transaction either. That's a good point.
18:48:39 <CDB-Man> Otherwise your book will have legacy non book currency transactions in it that need to be cleaned
18:49:24 <CDB-Man> Indeed: I might do my bookkeeping on Friday, entering this week's transactions, including a purchase on Monday, so I'll need the Monday rate
18:50:59 <jralls> Is it actually Monday's rate? If you trade on Monday it settles on Wednesday, at least for now. The SEC was making noises a couple of months ago about tightening it up.
18:51:21 <CDB-Man> Right, the point is it's not Fridays rates
18:51:39 <CDB-Man> Current behaviour would pull Friday's rate when you press the button IIRC
18:52:11 <jralls> It is. At present GnuCash only knows how to fetch the latest price/rate.
18:52:23 <CDB-Man> If the user wants to record trade vs settlement date that's their prerogative IMO. We should not as a software try to interpret that, we should just read the date as entered
18:52:32 <CDB-Man> So if the user records Monday, we convert Monday
18:52:43 <CDB-Man> If they want to record settlement, they can enter Wednesday
18:52:45 <jralls> OK.
18:53:09 *** brook_ has quit IRC
18:53:39 <CDB-Man> Re SEC: I think they actually moved to T+1 this summer, I remember hearing about that
18:56:28 <jralls> Could be. I didn't pay too close attention. I trade so infrequently that I'm not affected at all.
18:56:31 *** brook has joined #gnucash
19:08:00 *** brook has quit IRC
19:08:22 *** brook has joined #gnucash
19:09:08 *** chris has joined #gnucash
19:09:08 *** ChanServ sets mode: +v chris
19:09:08 *** gncbot sets mode: +o chris
19:11:22 *** brook has quit IRC
19:57:21 *** chris has quit IRC
20:24:30 *** chris has joined #gnucash
20:24:30 *** ChanServ sets mode: +v chris
20:24:31 *** gncbot sets mode: +o chris
20:29:25 *** fell has quit IRC
20:29:51 *** fell has joined #gnucash
20:29:51 *** ChanServ sets mode: +o fell
20:59:56 *** brook has joined #gnucash
21:30:52 *** brook has quit IRC
21:31:55 *** brook has joined #gnucash
21:36:15 *** brook has quit IRC
22:14:43 *** chris has quit IRC
23:10:01 *** jonakeys has quit IRC
23:10:07 *** jonakeys has joined #gnucash
23:20:17 *** chris has joined #gnucash
23:20:17 *** ChanServ sets mode: +v chris
23:20:17 *** gncbot sets mode: +o chris
23:36:35 *** brook has joined #gnucash
23:39:35 *** brook has quit IRC
23:42:30 *** chris has quit IRC