2025-08-11 GnuCash IRC logs

01:42:44 *** fell has quit IRC
01:43:57 *** fell has joined #gnucash
01:43:57 *** ChanServ sets mode: +o fell
02:20:47 *** hamaryns has joined #gnucash
02:20:47 *** ChanServ sets mode: +v hamaryns
03:58:26 *** hamaryns has quit IRC
06:19:51 *** chf1 has quit IRC
06:21:00 *** chf has joined #gnucash
06:21:00 *** ChanServ sets mode: +v chf
07:34:55 *** hamaryns has joined #gnucash
07:34:55 *** ChanServ sets mode: +v hamaryns
08:08:11 *** bauen1 has joined #gnucash
08:51:19 *** hamaryns has quit IRC
14:28:43 *** bauen1 has quit IRC
14:58:14 <jralls> witcher, I give up. The package support in Alpine 3.22.1 is too broken to build a debug GnuCash with all of the symbols and there doesn't seem to be a way to download an image tarball or iso for edge to set up a VM.
14:59:37 <jralls> I got far enough to determine that int64_ts are getting converted to int32_t when written into Sqlite3 but I can't tell where.
15:02:51 <jralls> Tests don't work in MINGW32 but I'll see if I can replicate the write problem there. If I can I should be able to debug it.
15:05:07 <jralls> CDB-Man, leaks are possible, maybe even likely, but UI performance problems are more often due to graphics, especially if you have a HiDPI monitor.
15:06:43 <jralls> Gtk3 doesn't use accelerated graphics so drawing anything in HiDPI is compute-bound.
15:09:23 <jralls> CDB-Man you can use the performance pane in Task Manager to get a general idea of what might be slowing things down.
15:24:57 *** hamaryns has joined #gnucash
15:24:57 *** ChanServ sets mode: +v hamaryns
15:47:33 *** hamaryns has quit IRC
15:47:52 *** hamaryns has joined #gnucash
15:47:52 *** ChanServ sets mode: +v hamaryns
15:48:47 *** hamaryns has quit IRC
16:06:52 *** bauen1 has joined #gnucash
18:44:00 *** Caleb_W has joined #gnucash
18:44:01 *** ChanServ sets mode: +v Caleb_W
18:46:35 *** warlord has quit IRC
18:47:36 <Caleb_W> Is there a good way to corretly handle capital gain with stock splits? I note that stock split just creates a single lot with cost basis 0, which is incorrect
19:17:33 <chf> I'd do that manually, Caleb_W: create a new split transaction on the split date -(old number of stocks)×(old nominal value)+(new number of stocks)×(new nominal value), the "other account" being the one where you track your gains and losses.
19:24:22 *** Caleb_W has quit IRC
19:26:00 *** Caleb_W has joined #gnucash
19:26:00 *** ChanServ sets mode: +v Caleb_W
20:39:41 *** fell has quit IRC
20:40:23 *** fell has joined #gnucash
20:40:23 *** ChanServ sets mode: +o fell
20:45:33 <Caleb_W> I see. Basically one sells the lot and reconstruct the lot by rebuying it. But how to correctly track the cost basis and capital gain of the lot? My current idea is to buy/sell at the cost basis and note the actual opened date in the new lot.
21:02:46 <chf> First part: yes, it's "like" selling and re-buying, to note the difference, I'd create ONE transaction with 4 split parts and 1 date, with a text like "stock split" or something like that, so you can distinguish it from real sales and purchases. The 2nd part: not sure, the "overall prices" would probably be the same? Because at split day, the value of the company won't "jump" for no reason?
21:05:00 *** warlord has joined #gnucash
21:05:00 *** gncbot sets mode: +o warlord
21:23:12 <Caleb_W> First part: Why 4 splits?For example, say 1 share of XYZ is bought @ 100. It splits 2:1. Then the transaction is:Sell 1 share of XYZ @ 100Buy 2 shares of XYZ @ 50What are the other splits?Second part: I think one needs to make sure the fake sell does not generate any capital gains; otherwise, the cost basis would be stepped up, which would lead to incorrect CG computation if one actually sells in the future.
21:23:26 <Caleb_W> (I don't think GnuCash can correctly separate LTCG and STCG in this workaround anymore though)
21:34:33 <chf> 1 transaction consisting of 4 parts (lines) instead of 2×2 (as usual), so this is "one thing" with one date.
21:35:39 <chf> The other splits are the same values on the other account, you've always got 2 in each transaction.
21:39:10 <chf> I'm not an english native speaker and not an accountant, so don't know what "LTCG" and "STCG" mean. Perhaps we should ask CDB-Man, he's good at such things…
21:42:59 <CDB-Man> chf: long term capital gain vs short term capital gain. This is specific to US taxation only
21:43:39 <chf> Ah, therefore I don't quite understand the problem.
21:44:36 <CDB-Man> For US tax purposes, if you hold the stock for more than 365 days before selling, it is a long term gain and receives a more favorable tax rate
21:44:52 <CDB-Man> Otherwise, short term gains have a much higher tax rate
21:45:20 <chf> In DE you'll pay taxes only on real gains, if you sell stocks.
21:45:26 <CDB-Man> The Americans generally use FIFO to track holding period of stocks, for the purposes of short vs long term gains
21:45:37 <CDB-Man> I'm talking about sales here for the Americans
21:46:08 <CDB-Man> Real sales. They need to track their stock holdings like inventory. Yes it is a lot of excess work. I'm glad I'm in Canada
21:46:37 <chf> Oh, that is the same here < 1 year = normal tax rate, not sure if it's 10 years for stocks.
21:46:44 <Caleb_W> yeah it's a pain
21:46:47 <Caleb_W> But can I just credit and debit from the stock account without touching the cash accounts?
21:47:55 <CDB-Man> jralls: the thing driving CPU in task manager is definitely gnucash. My gnucash always has 30+ tabs open, perhaps that's the issue. I use all of these tabs on my routine weekly transaction workflow (a mix of reports and account registers), so while I COULD open them each upon use... I'd rather not. Understood on gtk3, unfortunate!
21:48:50 <CDB-Man> Caleb_W: gnucash has the concept of "tax lots" to track specific units of stocks for the purposes of short vs long term.i have no idea how the tax lot Manager thing works
21:50:09 <CDB-Man> Stock splits in the rest of the world is easy, I just enter a zero dollar transaction that increases the # of held units in gnucash
21:50:10 <chf> You must at least have another "fake account", I think, if there isn't already something like that, I'd create one: "stock splits" or so.
21:50:21 <CDB-Man> With the usage of lots, I have no idea how this works
21:50:49 <chf> For each lot a split? Or a whole transaction?
21:51:03 <Caleb_W> Yes I'm using the tax lots. Without stock splits they work perfectly.
21:51:33 <CDB-Man> Not knowing fully how it works, I would create a new lot for the granted split shares
21:52:11 <Caleb_W> Yep. I think to track the cost basis correctly one needs to create one new lot for each old lot that has a stock split
21:52:24 <CDB-Man> You might need jralls or another of the Americans on here who understands the tax lot implementation in gnucash better to help you on this
21:53:08 <Caleb_W> fortunately stock splits are rare... :P
21:53:35 <CDB-Man> If you only hold 1 lot in that stock, then you'd only need to duplicate once
21:53:45 <CDB-Man> If you bought multiple lots though ..
21:55:22 <Caleb_W> yep... big pain. The wiki says here that tax lots do not work well with stock splits https://wiki.gnucash.org/wiki/Concept_of_Lots
21:55:52 <chf> You could probably simplify that: make 2 new lots manually combining those where the time is already over at split date, and where it is not.
21:58:23 <CDB-Man> It's a bit more than that chf, he would need multiple lot duplicates for EACH lot, since lots track not only date but also the purchase price. And you cannot co mingle the price
21:58:23 <chf> Don't know anything about the implementation, it would involve making all "old lots" to "disappear tax-invariantly" for the algorithm.
22:01:15 <Caleb_W> I think the proposed workaround will work, no? I don't use gnucash for long-term and short-term capital gains tracking so this is not a problem. I just need gnucash to be able to calculate the capital gain correctly for me when I sell a lot with stock splits
22:03:22 <chf> Taking into account what CDB-Man said, I think it would only calculate correctly if you "translated" each lot seperately.
22:05:20 <chf> Even then, there's the problem of the split date: the algorithm must not take this as the new purchase date, but will probably do so, or is there a separate "lot date" stored elsewhere?
22:05:34 <Caleb_W> yes. Given that I haven't really encountered a split yet, this sounds acceptable. I just realized this caveat of stock splits so tried to find a workaround
22:05:56 <Caleb_W> I don't think there is a date, but one can just put the original opened date in the title of the lot
22:06:25 <Caleb_W> https://imgur.com/24HGExo it seems that I can debit and credit the commodity account directly?
22:09:53 <chf> Normally you can edit every field manually, and create new manual transactions in any non-placeholder account.
22:12:31 <chf> I don't basically know anything about all those "US-centric" "helpers", they generally won't work in the EU because of tax differences and another "accounting habit" in continental Europe (closer to the "italian original way").
22:18:39 <Caleb_W> ok thanks. Let me play around a little to see if it really works
23:10:01 *** jonakeys has quit IRC
23:10:09 *** jonakeys has joined #gnucash