2022-09-05 GnuCash IRC logs
00:06:06 <chris> CDB-Man_ I cant find a difference in the reports. purchase-val both $0 for SPY1 and SPY2. I'll add a small modification to IFRS report today do dump the options being used, so that you can attach the html for both SPY1 and SPY2 reports including options used.
00:06:08 <chris> https://imgur.com/a/9hXPmnM
00:07:12 <CDB-Man_> OK
00:07:20 <CDB-Man_> also, looks like you double posted the SPY 1 screenshot :)
00:07:47 <chris> oops yes
00:08:18 <chris> should be fine now
00:09:16 <CDB-Man_> does the .gnucash file attached contain the reports as I set them up?
00:09:26 <CDB-Man_> or is the files only the data without currently open reports
00:09:48 <CDB-Man_> because if the former, you should see exaclty what i see
00:10:17 <chris> no .gnucash doesn't contain reports
00:10:33 <CDB-Man_> OK
00:10:45 <chris> the next build will modify ifrs to unceremoniously dump the options changed.
00:11:12 <CDB-Man_> well i can also jsut screenshot the options panel
00:11:17 <CDB-Man_> and post to imgur
00:11:46 <CDB-Man_> https://imgur.com/a/knzAuOg
00:12:46 <chris> hmm wonder why yours doesn't have start/end-dates
00:13:00 <CDB-Man_> Build ID: git 4.11-173-gefde151ad7+(2022-09-02)
00:13:54 <chris> could you be using an old acb-tool.scm? are you launching via Report > Experimental > IFRS?
00:14:03 <CDB-Man_> unless the ACB tool in miant isnt getting updated...
00:15:09 <CDB-Man_> hmm, i dont think I'm usin ghte "IFRS one"
00:15:15 <CDB-Man_> I'm still using "ACB tool"
00:15:22 <CDB-Man_> let's switch to the new one and see what heppens
00:15:24 <chris> if you've added an acb-tool.scm it'll stay bitrotted
00:16:01 <CDB-Man_> most likely. what is hte windows path wher ei can go to expunge it?
00:16:35 <chris> with a recent build you can Help > About and explore the paths being shown
00:17:27 <CDB-Man_> i was hoping you knew the specific sub-path within > GNUcash :P
00:18:21 <CDB-Man_> found hte old one
00:19:12 <CDB-Man_> well now, the new report produces a different kind of error
00:19:40 <CDB-Man_> the SELL transaction on 2020-03-18 for SPY 1, it picks up the proceeds val as $9.95 instead of $12k
00:20:03 <CDB-Man_> nvm, my fault
00:22:05 <chris> in any case the dividend lines seem to be misinterpreted swomewhere
00:22:19 <CDB-Man_> https://imgur.com/a/knzAuOg
00:22:38 <CDB-Man_> new report, still missing
00:23:13 <CDB-Man_> total is off $200 relative to SPY 1, and as expected the cause is the missing $200 in the compensatory div
00:23:50 <chris> I suspect the long dividend may still be incorrect
00:24:29 <CDB-Man_> which transaction?
00:24:46 <chris> IIUC there's no long dividend in your book
00:24:57 <CDB-Man_> not yet anyways for SPY 2
00:25:01 <CDB-Man_> there's a long div on SPY 1
00:25:16 <CDB-Man_> but aggain, that compensatory notional distro on SPY 1 works fine, just not SPY 2
00:25:27 <CDB-Man_> the 2020-06-19 trans on both accounts
00:25:56 <chris> hmm right
00:26:20 * chris was looking at dividend instead of notional distribution !!!
00:27:24 <chris> I believe the bug is the Compensatory ND isn't being flagged as a "Purchase" to populate the purchase-val column
00:29:06 <chris> https://github.com/Gnucash/gnucash/blob/7366de94847cc82e58657679d7e080d4d77ad842/gnucash/report/reports/standard/ifrs-cost-basis.scm#L417
00:29:20 <chris> see the criteria - somewhere the Compensatory ND is making it false
00:31:49 <CDB-Man_> well, if it worked for SPY 1 but not SPY 2
00:32:04 <CDB-Man_> the conditions must be correct except for the fact that one is CAD and the other us USD
00:32:40 <chris> hmm right, will check again
00:33:21 <CDB-Man_> is it because in SPY 1
00:33:29 <CDB-Man_> i have the blank split to CASH but SPY 2 lacks it?
00:33:54 <CDB-Man_> YES
00:33:55 <CDB-Man_> that's it
00:34:01 <CDB-Man_> adding the blank split made it work
00:34:30 <chris> then the criteria must be changed :P
00:35:12 <CDB-Man_> if i look at the truth table, for compensatory notination distro the check for CASH is N/A in cell F25
00:35:27 <CDB-Man_> so you must have introduced something I did not anticipate
00:35:43 <CDB-Man_> (the truth table tab is in the Excel in the ticket, unchanged from when i first created it)
00:36:21 <CDB-Man_> you must be checking for a CASH split when one is not required
00:38:21 *** FH_thecat has quit IRC
01:17:05 *** chris has quit IRC
01:17:10 *** storyjesse has quit IRC
01:19:28 *** storyjesse has joined #gnucash
01:20:17 *** chris has joined #gnucash
01:20:18 *** ChanServ sets mode: +v chris
01:20:18 *** gncbot sets mode: +o chris
01:20:41 *** FH_thecat has joined #gnucash
01:22:45 *** Gandalf has joined #gnucash
01:24:58 *** Aussie_matt has joined #gnucash
01:26:21 *** sbluhm has joined #gnucash
01:34:38 *** fell has quit IRC
01:35:27 *** fell has joined #gnucash
01:35:28 *** ChanServ sets mode: +o fell
02:13:54 <chris> CDB-Man_ I think the issue is - in your report, what's the criteria that you use to determine whether a purchase-val exists?
02:14:38 <CDB-Man_> You mean in the truth table?
02:14:42 <chris> no, in the report
02:15:07 <chris> long: during a regular buy
02:15:08 <CDB-Man_> Well if you look at the screenshot
02:15:56 <CDB-Man_> During a regular buy, some asset (usually cash) goes down and stock goes up
02:16:27 <CDB-Man_> In the case of div reinvestment, div income gets credited
02:17:09 <CDB-Man_> Notional distribution is more like a special case of dividend reinvestment
02:17:38 <CDB-Man_> The income is there, but no cash and no new units
02:19:37 <chris> Could you condense it mathematically? (1) LONG: stock_amt increasing except blabla (2) SHORT: stock_amt increasing to zero except blabla
02:22:47 <chris> IIRC I determined the purchase? criteria by trial-and-error hence the missing pieces
02:26:31 <chris> another truth table beckons :)
02:27:20 <CDB-Man_> Well the existing truth table should already work
02:27:36 <CDB-Man_> I don't think there are any scenarios where the same parameters exist twice
02:28:08 <CDB-Man_> You are definitely checking for a cash split unnecessarily somewhere in that compensatory notional check
02:28:34 <CDB-Man_> Given that was the only transactional difference between spy 1&2
02:28:55 <CDB-Man_> Time for bed, g'night!
02:30:06 <chris> Ok I'll tease it out from the existing truth table then
02:30:08 <chris> nite
02:37:20 <chris> Looks like the only criteria for purchase-val is: Open Long, Open Short, Long Buy, Short Sell, Long&Short Divi+Reinvestment, Long&Short ROC, Long&Short ND
03:09:04 *** Aussie_matt has quit IRC
03:16:14 *** gjanssens has joined #gnucash
03:16:14 *** ChanServ sets mode: +o gjanssens
03:16:59 *** tomk_dk has joined #gnucash
03:29:38 *** kyew has quit IRC
03:40:02 <chris> CDB-Man_ here's a fun changeset: https://pastebin.com/raw/uNVp6xY5 instead of trying to derive a new truth table, use the identified txn-type and choose from the list directly
03:48:45 *** Gandalf has quit IRC
03:50:59 *** Gandalf has joined #gnucash
04:44:19 *** Aussie_matt has joined #gnucash
05:04:57 *** Aussie_matt has quit IRC
05:12:48 *** ArtGravity has quit IRC
05:13:04 *** ArtGravity has joined #gnucash
05:13:04 *** ChanServ sets mode: +v ArtGravity
05:32:04 *** PowaBanga has quit IRC
06:11:32 *** FH_thecat has quit IRC
06:11:51 *** FH_thecat has joined #gnucash
06:13:15 *** FH_thecat has quit IRC
06:13:47 *** FH_thecat has joined #gnucash
06:15:20 *** FH_thecat has quit IRC
06:15:45 *** FH_thecat has joined #gnucash
06:17:10 *** FH_thecat has quit IRC
06:18:04 *** FH_thecat has joined #gnucash
06:20:51 *** FH_thecat has quit IRC
06:58:48 *** tomk_dk has quit IRC
07:32:31 *** Hamaryns has joined #gnucash
07:32:31 *** ChanServ sets mode: +v Hamaryns
08:24:23 *** chipxxx has joined #gnucash
08:25:16 *** PowaBanga has joined #gnucash
08:31:07 *** tomk_dk has joined #gnucash
08:32:00 *** celeste has quit IRC
08:35:54 *** celeste has joined #gnucash
08:35:54 *** ChanServ sets mode: +v celeste
08:39:15 *** celeste has quit IRC
08:39:18 *** celeste has joined #gnucash
08:39:18 *** ChanServ sets mode: +v celeste
08:42:31 *** celeste has quit IRC
08:42:59 *** chipxxx has quit IRC
08:43:02 *** celeste has joined #gnucash
08:43:02 *** ChanServ sets mode: +v celeste
08:56:31 *** chipxxx has joined #gnucash
08:57:04 *** Hamaryns has quit IRC
08:59:52 *** celeste has quit IRC
09:00:25 *** celeste has joined #gnucash
09:00:25 *** ChanServ sets mode: +v celeste
09:17:50 *** bertbob has quit IRC
09:20:43 *** bertbob has joined #gnucash
09:20:43 *** ChanServ sets mode: +v bertbob
09:29:21 *** sbluhm has quit IRC
09:54:11 *** kyew has joined #gnucash
09:54:11 *** ChanServ sets mode: +v kyew
09:56:17 *** chipxxx has quit IRC
10:09:50 *** tomk_dk has quit IRC
10:55:01 <CDB-Man_> chris: well, I think ANY debit or credit to the stock account should always cause a value to appear in either the purchase or proceeds columns, at least 1 of them must appear. Only regular dividends don't affect the stock account with a $ value or a unit value
10:57:38 <CDB-Man_> The other thing is that every $ transaction to the stock account will always be on the purchase column except for a sale
10:57:52 <CDB-Man_> And you can check for sales by checking if there is a capital gain split
11:13:48 *** guak has joined #gnucash
11:35:58 <chris> CDB-Man_ I've solved this by expanding the truth-table to add two columns: sale? and purchase?
11:36:05 <chris> It seems to work well
11:36:46 <chris> you could copy&paste overwriting ifrs-cost-basis.scm completely: https://pastebin.com/raw/DMZMuUDV
11:46:49 <CDB-Man_> For clarity, an allowable state is something that is neither a purchase or a sale
11:46:57 <CDB-Man_> That would be a regular dividend
11:54:01 <CDB-Man_> going to overwrite my ifrs report now with your pastebin
11:55:48 <CDB-Man_> new report works
11:55:54 <CDB-Man_> deleted the cash split and the $200 remains
11:57:06 <CDB-Man_> ill continue some more testing after lunch!
12:03:43 <chris> \o/
12:04:42 <chris> conclusion- as long as the heuristics work (the note column is correct), the appropriate sale/purch columns will be shown
12:07:55 <CDB-Man_> Hmm I didn't actually specifically look for your new columns
12:08:01 <CDB-Man_> Will check for that
12:08:56 <chris> it's only in the .scm file
12:09:34 <CDB-Man_> Ah
12:10:57 <CDB-Man_> If anything, all transactions "default" to purchase unless it matches the parameter of a sale
12:11:26 <CDB-Man_> With certain transactions having no impact at all on cost basis, such as a regular dividend
12:12:14 <CDB-Man_> Stock splits also do not impact the total cost basis
12:12:21 <CDB-Man_> They only impact the cost basis per unit
12:13:07 <CDB-Man_> Both splits and reverse splits. Reverse splits with fractionals will have an impact though as that's essentially a special sale
12:13:18 <CDB-Man_> The cash in lieu
12:13:36 <CDB-Man_> Haven't gotten to that transaction yet in the testing
13:06:58 *** bertbob has quit IRC
13:13:45 *** bertbob has joined #gnucash
13:13:45 *** ChanServ sets mode: +v bertbob
13:28:45 *** jralls_afk is now known as jralls
13:29:53 *** storyjesse has quit IRC
13:38:33 <jralls> chris, the pastebin looks good, please redo PR 1421 to do that. 2 commits please, one for gnc_g_list_stringjoin and one for gnc_ab_description_to_gnc.
13:41:02 <jralls> chris, as for std::accumulate, the lambda would be { return b.empty() ? a : a + sep + b; }.
13:46:08 *** Hamaryns has joined #gnucash
13:46:08 *** ChanServ sets mode: +v Hamaryns
14:10:47 *** FH_thecat has joined #gnucash
14:16:11 *** Hamaryns has quit IRC
14:24:17 <jralls> fell, Yeah, I got notified of the test failures shortly after pushing, I just didn't have time to fix it until now.
14:35:40 <jralls> gjanssens, fell, chris: I think we should start using https://github.com/fmtlib/fmt for string formatting in C++ code, including replacing boost::format with it. It's the source of C++20's std::format, but neither gcc nor clang have implemented it.
14:37:49 *** chipxxx has joined #gnucash
14:39:05 *** PowaBanga has quit IRC
14:40:59 <jralls> Unlike printf it supports numbered parameters so that translators can reorder them if it makes more sense in their languages, and according to the authors benchmarks (that he presented to the C++ Standard Committee, so he'd have been caught if they're bogus) it's 10x faster than boost::format, compiles 5x faster, and compiled code is 1/6 the size of boost::format.
14:41:02 *** chrko has quit IRC
14:41:13 *** FH_thecat has quit IRC
14:41:20 *** PowaBanga has joined #gnucash
14:41:22 <jralls> s/authors/author's/
14:44:02 <jralls> It's pretty small, so we could stuff it into borrowed, but it's also pretty widely distributed: https://repology.org/project/fmt/versions
15:28:28 *** Hamaryns has joined #gnucash
15:28:28 *** ChanServ sets mode: +v Hamaryns
15:42:10 *** sbluhm has joined #gnucash
15:44:28 *** Gandalf has quit IRC
15:59:39 *** Hamaryns has quit IRC
16:00:39 <CDB-Man_> chris: does the latest build filter out placeholder accounts? or not yet
16:01:26 <CDB-Man_> "Assets:Broker Account USD" is selectable for cash account even though it is a placeholder. the only valid option i wouldexpect is "Assets:Broker Account USD:USD Cash" of course
16:20:47 *** chipxxx has quit IRC
16:25:43 <gjanssens> jralls: that sounds like a good idea. The only thing to check is how it cooperates boost::locale. IIRC that came with its own format-like syntax.
16:26:44 <gjanssens> You'll find examples in my code in gnucash-cli.cpp (line 132 and others) and the csv importer code (I think)
16:28:41 *** sbluhm has quit IRC
16:30:01 *** gjanssens has quit IRC
16:33:39 <jralls> gjanssens, Hmm. In theory it should be OK, but isn't bl::translate there just a wrapper for gettext()? Or is it doing its own search of the msg catalog?
16:36:05 <jralls> Bigger picture I think we need to get rid of all of the standard lib localization and switch to ICU. Both POSIX/libc and std localizations are much less flexible than Microsoft or ICU (Apple uses ICU) and that frustrates users who customize their localizations.
16:37:24 <jralls> But I don't think there's time to do anything with that for GC5.
16:45:18 <jralls> Oh, I remember. Boost::locale is because gcc's glibc doesn't implement any localization on Windows. Hmm, but that does raise something that I haven't yet looked at: What locale does fmt: use for numeric and date formatting?
16:49:23 <CDB-Man_> chris: i think we can actualyl delete dividend reinvestment w/o remainder as an option. its really just a special case of dividend reinvestment with remainder, where the remainder is 0
16:49:55 <CDB-Man_> i think we can simply call it "Dividend reinvestment" and always generate a cash split, and if there is no cash remainder, the split is simply $0 value but we still create the split
16:52:13 <CDB-Man_> chris: is there a list of strings somewhere of all the strings used in stock editor? i wouldn't mind doing a revirew of the text. if not such string exists, would it be too hard for you to put that together into an excel file and post into ticket? then i can upload a 2nd copy with a column 2 for proposed wording changes
17:05:20 <CDB-Man_> chris: reverse stock split with cash settlment for fractionals -- i dont like that it does both the split and the fractional sale in 1 transaction
17:05:31 <CDB-Man_> i think it needs to produce 2 transactions, just like the manual transaction isd SPY 1
17:06:22 <CDB-Man_> that or we delete this possibility and force users to enter it in 2 steps: step 1 sale, step 2 reverse split
17:06:25 <jralls> CDB_Man_ I disagree. A split with cash in lieu is a single transaction.
17:06:33 <CDB-Man_> unless you can walk them through both in 1 workflow
17:06:46 <CDB-Man_> functionally yes
17:06:59 <CDB-Man_> jralls: in a journal entry no, because of trading accounts
17:07:16 <CDB-Man_> screenshot and you'll see why:
17:07:49 <CDB-Man_> https://i.imgur.com/yGxwfPX.png
17:08:01 <CDB-Man_> 101 shares were reverse split to 50, with the 1 remainder sold
17:08:23 <CDB-Man_> the problem is you can see, gnucash treats it as 51 shares ON THE SALE< so generates an absurd stock price
17:08:27 <CDB-Man_> which also goes into priceDB
17:08:30 <CDB-Man_> and causes reporting issues
17:08:55 <CDB-Man_> while the $$ values are correct, the price displyaed and therefore fed into price DB is not
17:10:04 <CDB-Man_> https://i.imgur.com/fW0qatd.png I suppose you could do this
17:10:06 <jralls> That's a trading account logic bug that we'll have to fix.
17:10:15 <CDB-Man_> but at that point, you may as well have 2 transactions
17:10:30 <CDB-Man_> method 2 is at least accurate in unit values
17:10:54 <CDB-Man_> as a broker, procedurally you redeem the fractionals with the depository before executing the reverse split
17:11:12 <CDB-Man_> so while it "appears" to be 1 transaction to the end customer, the behind the scenes is most certainly 2 steps
17:11:45 <jralls> Neither is correct. Trading accounts should ignore zero-value splits.
17:12:24 <CDB-Man_> if not for a zero value split, how would you exercise a (reverse) stock split?
17:12:32 <CDB-Man_> a split is quite literally a change in units without change in $ value
17:12:39 <CDB-Man_> vy definition a "zero $ value split"
17:13:54 <CDB-Man_> trading accounts have both a $ value and a # unit value, and a (reverse) split impacts onl the # unit value
17:14:02 <jralls> Right. And since it has no value there's nothing to balance.
17:14:15 <CDB-Man_> what do you mean by that
17:14:47 <CDB-Man_> the 2nd method results in the correct # of units, the correct $ value, and no incorrect entries to price DB
17:15:08 <CDB-Man_> if there is an issue with method 2, i don't see it
17:15:42 <CDB-Man_> (notwithstanding that I believe they should be recorded as 2 separate transactions)
17:16:21 <CDB-Man_> the transfer agent and the depository (DTCC) would have to mechanically do it as 2 steps anyways -- i say this from having done work for those entities before
17:17:55 <jralls> CDB_MAN_: Apple's 7:1 split from 2014:
17:17:58 <jralls> https://imgur.com/a/SceJQQ2
17:18:34 <CDB-Man_> that looks like a non-trading account book
17:18:55 <CDB-Man_> that's also a forward split, fractionls appear in reverse splits
17:19:49 <CDB-Man_> chris: if stock assistant needs to generate a single transaction for reverse split with cash in lieu, then instead of the current method 1 tnx that you generate, at least it should generate method 2: https://imgur.com/a/dRHpTvx
17:19:54 <jralls> It is, but in this case a trading account book should look the same. Fractionals can appear in forward splits too, e.g a 3:2 in your example with 101 shares.
17:20:18 <CDB-Man_> in trading accounts, it will always generate the other split line
17:20:40 <CDB-Man_> https://i.imgur.com/5g5PVeY.png like so
17:20:45 <CDB-Man_> it wont balance without it
17:20:51 <jralls> One more time: That's a bug in the trading account logic. Trading accounts should ignore zero-value splits.
17:21:06 <CDB-Man_> i dont see that as a bug
17:21:23 <CDB-Man_> how can you create units in the stock account, without offsetting negative units in the trading account?
17:21:41 <CDB-Man_> your # units will not balance, even in the $ balances
17:21:59 <CDB-Man_> if you were to do a "1 sides" stock split, when you liquidate, your trading account will have a non-zero unit balance in it
17:23:10 <CDB-Man_> simple example, suppose you buy 100 units of SPY, SPY stock account has 100 units and SPY trading account has -100. it then splits 2:1, so you have 200 units in SPY stock but only -100 in trading based on your statement. when you liquidate 200 units of SPY later, your stock account will have 0 units but the trading account will now have +100
17:23:42 <CDB-Man_> if you are saying that this +100 at the end is the intended behaviour... then I would say that this appears incorrect vs the current behaviour which is fine
17:23:45 <jralls> OK. That just means the trading account must also generate a balancing zero-value split.
17:24:02 <CDB-Man_> which is exactly what both of my screenshots demonstrate
17:24:04 <CDB-Man_> based on current logic
17:24:08 <CDB-Man_> so there is no "bug"
17:25:31 <CDB-Man_> i do not see any bugs in trading account behaviour with respect to how it handles # units today. it works just fine with splits and reverse splits, which will generate transactions with # units but without $ values
17:26:01 <CDB-Man_> https://i.imgur.com/5g5PVeY.png as illustraded here. the split to the trading account was automatically generated by the software when I hit the return key
17:26:37 <CDB-Man_> zero $ value split, but non-zero # units
17:27:04 <CDB-Man_> which is what is represented in method 2 in my other screenshot to chris
17:27:26 <jralls> Ah, good. Then the only problem is that the logic consolidates the zero-value and cash-in-lieu splits and calculates the wrong price.
17:27:41 <CDB-Man_> which is why i rpoposed method 2
17:29:23 <jralls> But then you lose the connection between the split and the cash-in-lieu.
17:30:53 <CDB-Man_> you would if done in 2 transactions (my preference), but if you look at method 2, it is all within the same transaction, just multiple splits to STOCK and TRADING accounts: https://imgur.com/a/dRHpTvx
17:33:51 <CDB-Man_> chris: I have repackaged the conversation here directly into the ticket instead, enumerated
17:33:58 <jralls> You had to manually override the automatic trading split creation to do that, and as soon as you try to commit that transaction the balancing logic will remove all of the trading splits and regenerate method 1.
17:34:26 <CDB-Man_> it did not remove the trading splits when i hit enter
17:34:37 <CDB-Man_> remove / consolidate
17:34:51 <CDB-Man_> it maintained the transaction as shown in screenshot after i hit enter
17:35:12 <CDB-Man_> stock assistant could also be setup to create the transaction exactly as shown
17:35:45 <CDB-Man_> sorry, i take that back slightly and clarify: I manually created 2 trading split lines
17:36:06 <CDB-Man_> so you're right, by default it would create it 1 line. but that's what stock assistant is for!
17:38:11 <jralls> Right, that's not a take back. But I thought that the latest state of the balancing code was to always remove the trading splits and recalculate them because we had problems with users messing things up and making transactions that couldn't balance.
17:38:54 <CDB-Man_> indeed, after method 1 was created by stock assistant, i could manual override to method 2, and it did stick as shown after i hit enter
17:39:06 <jralls> But I think that caused problems for mta and it got turned into almost always. I'll have to go look at the code.
17:39:09 <CDB-Man_> stock assistant could therefore generate that transaction as shown
17:39:45 <CDB-Man_> indeed, IDK how tax lots or legacy advanced portfolio would interact with this transaction
17:39:59 <CDB-Man_> which again, is why I propose and prefer 2 separate transactions as the cleanest solution
17:40:01 <jralls> It could, but it would be better for the trading account balancer to do it.
17:40:11 <CDB-Man_> yes, as you say, you lose the linkage, but it breaks the least number of other processes
17:41:05 <CDB-Man_> well, this one is "relatively simple" that I dont think you need to rely on trading account balancer, as you only need to "pull out" into the $0 value line the non fractional shares, ie the majority of the shares in a reverse split
17:41:29 <CDB-Man_> I'm manually specifying the 50 shares to be canceled in the 1:2 reverse of 101 shares
17:41:33 <jralls> Neither APR nor the lots engine care about trading accounts.
17:41:44 <CDB-Man_> not rocket science (especially if stock assistant is doing it for you)
17:41:54 <CDB-Man_> APR?
17:42:34 <CDB-Man_> while they do not care about trading accounts... do they care that hte STOCk account has 2 splits in the single transaction?
17:42:42 <CDB-Man_> 2 splits with # units
17:42:56 <jralls> Advanced Portfolio Report. It's the "new" one.
17:43:34 <CDB-Man_> i find the APR does not handle capitalized fees correctly. it ONLY capitalizes fees that are deibted to an expense account
17:43:50 <CDB-Man_> it does not capture fees that are debited into the stock account (which is actually what you would expect from a JE perspective)
17:43:53 <CDB-Man_> but I digress
17:44:47 <CDB-Man_> this particular behaviour of APR encourages you to always debit fees to expense, which means that your stock account is never actually capitalizing fees except when you use APR
17:45:08 <jralls> The APR won't, it doesn't really even care about transactions, just totals. The lot scrubber understands both in-transaction cap gains splits and separate-transaction ones, so it will be OK too.
17:49:33 <jralls> Not exactly. The APR can't see properly capitalized fees/commissions because they're buried in the buy/sell splits. If you break them out into a separate no-shares split then both APR and the lot scrubber will think it's a cap gains split.
17:50:01 <CDB-Man_> i do in fact have them as no share splits
17:50:23 <jralls> And it screws up APR and the lot scrubber, right?
17:51:07 <CDB-Man_> i dont use lots, but the APR is for sure not as i expect the values to be
17:53:39 <jralls> All down to way too much ad-hoc workarounds for multi-commodity accounting.
17:54:33 <CDB-Man_> stock assistant will be a good way to at least drive a certain level of consistency
17:56:36 <jralls> That's one way of looking at it I guess. And I suppose if we formalize the workarounds in code and get users to use the assistant instead of doing it by hand we can then formalize the internals and modify the stock assistant accordingly without upsetting the users because we've changed "the way I've always done it".
17:57:24 <CDB-Man_> indeed
17:59:07 <jralls> It's that bit about getting them to use the assistant that's the hard part. If you've been doing it by hand for 20 years you'll be hard to convince to work through an assistant that takes 3x longer to fill in than just creating the splits and firing away.
17:59:59 <CDB-Man_> especially with split pre-population / auto complete
18:00:18 <CDB-Man_> well, for those folks, if they continue to use old transactions, they can also continue to use deprecated reports and tools
18:00:50 <CDB-Man_> my guess (?) is that if in fact new tools were built around stock assistant standardized tranasactions, they would be new reports and the old ones deprecated
18:00:54 <jralls> For a while. "Deprecated" usually means "we're going to remove this".
18:01:20 <CDB-Man_> also, I suspect (?) that things like tax lots (like you said) probbly "dont care" about these changes
18:13:06 *** chipxxx has joined #gnucash
18:21:02 *** chip_x has joined #gnucash
18:22:17 *** chipxxx has quit IRC
19:24:55 <chris> jralls: re: {fmt} can you do some CMake magic that uses a minimum-version in borrowed, or users' later version if it's available?
19:29:11 <chris> jralls: #1421 I tried to implement gnc_g_list_stringjoin to handle/skip NULL data but it makes the code much more complex, hence I gave up. eg GList of NULLs should return NULL. GList of {"a",NULL,"b",NULL} should return "a:b" rather than "a:b:" hence the surrendering. It seemed too much work at that time.
19:29:42 <chris> ^ can certainly try again and get distrated about it...
19:32:54 <chris> CDB-Man placeholder account filtering is currently stalled and I'm not sure how complex it is to complete. https://github.com/Gnucash/gnucash/pull/1332
19:33:25 <chris> as far as the accounting type queries I'd rather wait before trying a quick reply :)
19:34:39 <CDB-Man_> (Y)
19:34:45 *** CDB-Man_ is now known as CDB-Man
19:36:35 <chris> CDB-Man: if you are happy the IFRS report now works well then I'll merge it asap.
19:36:57 <CDB-Man> i dont see any obvious red flags
19:37:02 <CDB-Man> and it looks like you also fixed the fees stuff
19:37:12 <CDB-Man> i would say go ahead and merge
19:52:02 <chris> merged.
20:11:52 <jralls> chris, What went wrong with the code you posted in https://pastebin.com/raw/dyRv6mX6?
20:12:51 <chris> jralls: IIRC GList of {NULL,NULL...} wouldn't work very well
20:13:15 <chris> or {"a",NULL,"b",NULL} would output "a:b:"
20:13:20 <jralls> OK, I'll have a look.
20:50:37 *** storyjesse has joined #gnucash
21:08:28 <jralls> chris, how about https://gist.github.com/jralls/bb3723e46679d37dba39cf01d2465640
21:10:25 <chris> https://pastebin.com/raw/5Qq6SUmJ also handles GList of NULLs
21:10:43 <chris> we dont wanna g_malloc a negative length :)
21:11:18 <chris> maybe.
21:12:21 <chris> segfaults. bit annoying isn't it.
21:12:31 <chris> gtg soon.
21:12:40 <jralls> Yes, good thought to check length.
21:15:46 <jralls> I like p != retval, that's cleaner than mine, but you need to test sep too, g_stpcpy asserts if sep is NULL.
21:19:28 <chris> \o/ bingo
21:19:31 <chris> it works
21:20:00 *** guak has quit IRC
21:21:06 <jralls> I added two empty strings and tested for NULL without checking length and g_malloc0 didn't crash so I guess it's not really needed, but leave it in anyway.
21:21:49 <chris> the idea is stringjoin{NULL,NULL} would leave length as a negative, which must be handled.
21:23:01 <jralls> Yeah, understand. That what I just said: It does the right thing without checking for length < 0, but for clarity it's better to leave it in anyway.
21:23:19 <chris> oh ok
21:24:09 <chris> stringjoin({"",""},":") should still return ":"
21:24:26 <chris> gtg
21:24:27 <jralls> Why?
21:26:31 <chris> because "" is a string with 0 chars, rather than NULL denotes absence of string?
21:27:26 <jralls> Right, but some string-getting functions return "" instead of NULL for no value, especially if they're written in C++ and returning std::string.c_str().
21:28:32 <chris> ok will modify later. gtg now...
21:28:40 <jralls> Bye.
21:42:03 <fell> @tell gjanssens I wonder why we copy the old gnucash-docs/stylesheet/ images instead of the more recent and complete gnucash-docs/xsl/1.79.2/images/
21:42:03 <gncbot> fell: The operation succeeded.
21:58:00 *** fell has quit IRC
21:58:06 *** fell has joined #gnucash
21:58:06 *** ChanServ sets mode: +o fell