2020-06-07 GnuCash IRC logs

00:02:57 <CDB-Man> chris: no more errors!
00:03:14 <CDB-Man> i'll do a dive now to try and pinpoint
00:04:40 <CDB-Man> ........ huh.
00:05:14 <CDB-Man> ..... very intresting
00:32:18 *** mohave has joined #gnucash
00:35:19 *** mohave has quit IRC
00:37:15 *** Mechtilde has joined #gnucash
01:12:19 *** omnireq__ has quit IRC
01:12:30 *** omnireq__ has joined #gnucash
01:13:08 *** fell has quit IRC
01:14:26 *** fell has joined #gnucash
01:14:26 *** ChanServ sets mode: +o fell
03:07:24 *** mohave has joined #gnucash
03:10:24 *** mohave has quit IRC
03:17:35 *** suukim has joined #gnucash
03:19:56 *** chris has quit IRC
03:20:08 *** jervin has joined #gnucash
03:21:13 *** jervin has quit IRC
03:21:20 *** jervin has joined #gnucash
03:27:39 *** jervin has quit IRC
03:30:42 *** bertbob has quit IRC
03:33:51 *** jralls_afk has joined #gnucash
03:33:51 *** ChanServ sets mode: +o jralls_afk
03:34:05 *** jralls has quit IRC
03:42:52 *** bertbob has joined #gnucash
03:42:52 *** ChanServ sets mode: +v bertbob
03:43:37 *** storyjesse has joined #gnucash
03:52:31 *** chris has joined #gnucash
03:52:31 *** ChanServ sets mode: +v chris
05:10:14 *** mohave has joined #gnucash
05:15:32 *** mohave has quit IRC
05:45:45 *** Aussie_matt has joined #gnucash
05:49:39 <chris> jralls: it'd be fine to revert #706 entirely.
05:49:47 <chris> jralls_afk: it'd be fine to revert #706 entirely.
05:50:38 <chris> except c6e102951. this one is good.
05:57:45 <chris> except c6e102951. this one is good.
05:57:48 <chris> oops
06:01:12 *** Aussie_matt has quit IRC
06:08:30 *** gjanssens has joined #gnucash
06:08:30 *** ChanServ sets mode: +o gjanssens
06:10:25 <gjanssens> .
06:24:35 <chris> gjanssens: I don't understand CMake enough - new-aging.scm and new-owner-report.scm have created dependency spaghetti. If you manage to fix, please explain in commit message how they tie up together.
06:28:36 <gjanssens> chris: what do you mean with dependency spaghetti ? What errors do you get ?
06:29:56 <chris> I don't but mohave did... check irc logs
06:31:54 <chris> https://code.gnucash.org/logs/2020/06/06.html#T16:33:20
06:33:50 *** David has quit IRC
06:33:59 *** David has joined #gnucash
06:55:41 *** angel has joined #gnucash
06:58:52 *** angel has joined #gnucash
07:07:11 *** User_ has joined #gnucash
07:25:48 *** finster has joined #gnucash
07:25:48 *** ChanServ sets mode: +v finster
07:34:51 *** angel has joined #gnucash
07:42:29 *** angel has quit IRC
07:43:03 *** suukim has quit IRC
08:07:04 *** sbluhm has joined #gnucash
08:07:04 *** ChanServ sets mode: +v sbluhm
08:51:32 *** fell has quit IRC
08:51:51 *** fell has joined #gnucash
08:51:52 *** ChanServ sets mode: +o fell
08:56:37 *** suukim has joined #gnucash
08:56:43 *** mohave has joined #gnucash
08:59:44 *** mohave has quit IRC
09:05:49 *** jost has joined #gnucash
09:09:44 <jost> Hi! I've got another weird situation, where I probably got double entry wrong. I have an income account for my salary. I book my gross salary there, and in a split transaction I put it into different accounts (expense account for social security, checking account, and an equity account (a german "Bausparvertrag"). 40 Euros from my income go to the equity account - after that, my equity account is at -40 Euro. Shouldn't the equity accoun
09:09:44 <jost> t be at 40 Euro?
09:10:52 <jost> What am I doing wrong? The split transaction in the income account has one income part (my gross salary) and multiple charge parts, one for each account a part of my income goes to.
09:17:45 <warlord> Server Upgrade beginning.. Code will be going down shortly.
09:18:05 *** CedF has joined #gnucash
09:18:13 <Simon> jost: if the direction is correct in your income account then it is correct in the Equity account, but you perhaps should not be using an Equity account?
09:18:42 <warlord> Why are you putting Salary into Equity?
09:18:52 <Simon> jost: if the "Bausparvertrag" is a loan you're repaying then why is there nothing in it so that it goes negative?
09:18:59 <Simon> you should have a Liability for a loan
09:19:12 <jost> Simon, warlord: The Bausparvertrag is a kind of savings account
09:19:59 <jost> So no liability - if there is enough saved, it makes one eligible for a loan, but it is not in that phase yet
09:22:29 <warlord> jost, what is the Account Type? If it's a Savings account it should be Type Asset (not type Equity)
09:23:42 <Mechtilde> jost, it depends on how do you look at it
09:23:52 <Mechtilde> For me it can be both
09:24:09 <warlord> CODE going down now.
10:18:02 *** gncbot has joined #gnucash
10:18:58 *** psmst- has joined #gnucash
10:21:58 <CDB-Man> chris: Hmm, just woke up (EST here) and saw your comments. I'll give it some thought and reply back later today
10:22:29 <warlord> FYI, code is going to have one more reboot. Sorry about that.
10:30:09 *** psmst has quit IRC
10:39:07 *** gncbot has joined #gnucash
10:54:11 *** psmst- has quit IRC
10:57:18 *** psmst has joined #gnucash
11:00:22 *** bertbob has joined #gnucash
11:00:23 *** ChanServ sets mode: +v bertbob
11:12:22 *** storyjesse has quit IRC
11:17:30 *** psmst has quit IRC
11:19:34 *** warlord sets mode: +o gncbot
11:19:40 <warlord> And... everything should be back now.
11:22:53 *** psmst has joined #gnucash
11:25:09 <chris> CDB-man: I'm sure you know how complex these things are. Not only the non-CPA needs to understand UG and RE, but there's also variants of gnucash-book in existence.
11:25:43 <chris> CDB-man: and you're also using pricedb-latest... do average-cost, weighted-average and pricedb-nearest need to balance too?
11:25:43 <CDB-Man> What do you mean by variants?
11:25:59 <chris> use-trading-accts yes vs no
11:26:26 <CDB-Man> Well, it should always balance for all fx methods 100% of the time... But the other ones aren't easy to do that
11:26:37 *** jervin has joined #gnucash
11:27:28 <CDB-Man> Besides, nearest in time is in most conformance with GAAP
11:28:18 <chris> I guess this means 'nearest to balance-sheet date point'
11:28:26 <CDB-Man> Yes
11:29:08 <chris> (Multicol Income-statement chose the fx date points to be end-date for each period)
11:29:14 <chris> (For better or for worse)
11:29:25 <CDB-Man> Per GAAP, you translate balance sheet accounts using the FX at balance sheet date (December 31). You translate P&L using the average rate during the calendar period
11:29:41 <chris> ^Argh.
11:29:52 <CDB-Man> The balance sheet part is easy
11:29:59 <CDB-Man> The P&L one harder
11:30:27 <CDB-Man> The difference is your cumulative translation difference, a component of equity
11:31:23 <CDB-Man> It's compounded by the fact that GNUCash pulls FX on a daily basis, which is fine for transactional use, but doesn't give you the yearly average
11:31:36 <chris> then be prepared to file bugs for multicol is
11:32:27 <CDB-Man> Using year end rate for p&L is a decent alternative, but I don't think you can feasibly do it in the software without requiring a manual entry of the average rate
11:32:41 <CDB-Man> Feasibly do it per GAAP that is
11:32:54 <chris> define average rate?
11:33:15 <CDB-Man> The average FX rate for the calendar year, as is often published by central banks
11:34:08 <chris> ah i.e. pricedb entries added divided by 365
11:34:15 <CDB-Man> E.g. the straight line average FX rate for CAD to USD for the 365 days ending December 31 2019 was 1.2985 if I remember right, vs the rate on December 31 itself was 1.32 or something
11:34:32 <CDB-Man> That would also require someone actually running price DB everyday
11:34:38 <chris> amen
11:34:47 <CDB-Man> As I say, not feasible
11:34:57 <CDB-Man> To do programmatically anyways
11:34:58 <chris> plus, calendar year in some countries, 1-jul to 30-jun in others
11:35:01 *** jralls_afk is now known as jralls
11:35:05 <CDB-Man> Exactly
11:35:08 <chris> fun
11:35:16 <CDB-Man> It's a manual input
11:35:24 <chris> nice to know the principles
11:35:54 <chris> the gnucash way would be to ensure there's pricedb at each calendar boundary, and use 'nearest'
11:35:54 <CDB-Man> If you record all foreign currency transactions in native currency accounts, it becomes a non issue
11:36:18 <CDB-Man> Ie, if I record my USD dividend into a CAD dividend income account
11:36:22 *** bertbob has quit IRC
11:37:05 <CDB-Man> Well, even if you had the FX rate on December 31 for 2018 and 2019 let's say
11:37:06 <chris> I have to say we're just geeking out and there's no way gnucash pricedb + balsheet-pnl + book will be able to do it exactly
11:37:13 <jralls> CDB-Man, doesn't some gov agency publish a table of average exchange rates?
11:37:15 <CDB-Man> And you average those to get the 2019 actual average
11:37:32 <CDB-Man> That doesn't necessarily even approximate the calendar 2019 rate
11:37:50 <CDB-Man> For example what if 10 months of 2019 the rate was unusually high
11:38:05 <CDB-Man> The average of beginning and end wouldn't account for the
11:38:27 <CDB-Man> jralls: the IRS publishes, along with several Central banks
11:38:36 <CDB-Man> Everyone has their own methodology
11:38:51 *** shaggy has quit IRC
11:38:59 *** bertbob has joined #gnucash
11:39:00 *** ChanServ sets mode: +v bertbob
11:39:12 <chris> everyone uses methodology "to suit their needs" :)
11:39:16 <CDB-Man> [11:37:06] <+chris> I have to say we're just geeking out and there's no way gnucash pricedb + balsheet-pnl + book will be able to do it exactly <-- indeed, not practical to implement, at least not without requiring manual rate input
11:39:27 <chris> j/k aside this is useful for the wiki
11:41:05 <CDB-Man> In a "serious" attempt to implement something closer to GAAP using what GNUCash is currently capable of doing, your register should have zero P&L accounts in foreign currency
11:41:09 <jralls> chris does the new Income Statement share the Balance Sheet's ability to not consolidate to a single currency?
11:41:35 <CDB-Man> And always translate all transactions to home currency on a per transaction basis for anything impacting income statement
11:42:10 <CDB-Man> I didn't kick the tires on income statement yet, but it seems to be okay on initial look
11:42:23 <CDB-Man> At least my YTD statement agrees to legacy
11:42:52 <CDB-Man> The income statement doesn't accumulate unrealized gains, so it should probably (?) Be fine
11:43:11 <fell> warlord: wiki is Ok.
11:43:45 <chris> jralls: yes, by default the BS & IS don't convert to target currency
11:44:12 <chris> it was gjanssens who advised need to learn conversion and start this rabbit hole :)
11:44:21 *** chris is now known as chris_afk
11:44:47 <CDB-Man> As a matter of good practice, all my accounts always have a currency sub parent to separate currency
11:44:55 <CDB-Man> What I mean is
11:45:17 *** jervin has quit IRC
11:45:43 <CDB-Man> Dividend income > CAD > stocks/ETF/etc
11:45:51 <CDB-Man> Dividend income > USD > stocks/ETF/etc
11:46:27 <warlord> fell, great.
11:47:41 <jralls> OK. So for the complex case where conversion using average currency is required I think the procedure would be to run the IS in multi-currency mode, paste it into a spreadsheet, and apply the average exchange rates there.
11:48:40 <jralls> I don't think that there are enough users with the need to do this to justify the effort to create a UI for providing the rates.
11:50:30 <CDB-Man> Indeed, I agree
11:50:54 <CDB-Man> Export everything in native currency, and apply transformations in Excel
11:51:03 <CDB-Man> It's what I currently do, incidentally
11:51:35 <CDB-Man> I get to it via running the report by limiting the accounts included as per my currency groupings
11:52:11 <CDB-Man> The new multi currency BS IS definitely help in this regard
11:52:41 <jralls> So if you run the BS in multicurrency does it balance?
11:52:59 <CDB-Man> That is a loaded question...
11:53:21 <CDB-Man> By definition it won't ever balance... Due to the currency unrealized gains
11:54:26 <CDB-Man> Chris replied with a proposed fix, to use trading accounts for accumulating unrealized gains when the register uses these accounts... Though
11:54:55 <CDB-Man> I still find it very interesting that him computing it using the cost basis does not get the same answer
11:55:02 <CDB-Man> As it ought to be the same
11:55:22 <CDB-Man> And furthermore, that it was the same prior to Oct 31, but not after Oct 31...
11:55:57 <CDB-Man> One would think that even if it was a structural issue, it would be consistently inaccurate rather than sporadically...
11:56:03 *** chris_afk is now known as chris
11:56:16 <jralls> Yeah, the 31 Oct thing is puzzling. Does the trial balance report balance on 30 Oct and go out on 31 Oct too?
11:56:44 <CDB-Man> I haven't used the trail balance report in ages, it never worked for me
11:56:52 <CDB-Man> For the unrealized gains
11:56:55 * chris wonder about cbdman's pricedb entries - 30-oct and 31-oct may use different ones
11:56:58 <CDB-Man> I can try again after lunch
11:57:12 * chris also happy to hear trial-balance isn't very good
11:57:27 <CDB-Man> chris: when I date the report today, it still doesn't match, after I run price db today
11:57:43 <CDB-Man> Which would have ensured all prices as of today
11:57:45 <chris> ^with newest patch?
11:57:57 <CDB-Man> Haven't tried that yet
11:58:15 <CDB-Man> But I mean yesterday, prior to all attempts to fix
11:58:35 <CDB-Man> It really bothers me that you computing using cost basis disagrees with trading accounts
11:58:52 <CDB-Man> They are offset entries, it ought to be the same
11:59:11 <jralls> Run the trial balance report with average cost so there aren't any unrealized gains. That's the only way it works.
11:59:37 <CDB-Man> Though, the fact that my funds traverse from CAD > USD > USD stocks > CAD income account ... Might be too many layers of entropy
12:00:27 <jralls> There should be one more layer of entropy in there: USD stocks pay divs in USD.
12:00:36 <CDB-Man> jralls: I'll give that a try after lunch, and Chris I'll try today's date with the patch from last night after lunch
12:00:44 <chris> ok :)
12:00:56 * chris assumes 'cost basis' = average-cost
12:01:11 <CDB-Man> Indeed jralls , and it is deposited in a USD cash account with a CAD parent
12:01:26 * chris don't understand 'weighted-average' either
12:01:45 <jralls> Right, so it's USD Stocks->USD Income->CAD Income.
12:01:47 <chris> gtg soon; your breakfast is my bedtime
12:01:48 <CDB-Man> I also don't understand average cost and weighted average in the GNUCash context...
12:03:11 <jralls> It's messy. I rewrote average cost about three times, and it works OK as long as there are no more than 3 commodities per transaction.
12:03:24 *** shaggy has joined #gnucash
12:03:24 *** ChanServ sets mode: +v shaggy
12:03:49 <jralls> That's average cost. I've stared at the weighted average code for hours and I still can't figure out what use case it's trying to address.
12:05:13 <jralls> chris, before you go to bed, the issue with spaghetti in reports isn't about Cmake, it's about guild. If an scm has a use-modules foo, guild expects to find a foo.go in GUILE_COMPILED_LOAD_PATH. If it doesn't, it barfs.
12:08:04 <jralls> report/reports/report.scm has (use-modules (gnucash new-aging)) so new-aging.scm needs to be compiled first. But new-aging.scm has (use-modules (gnucash report)) so report.scm needs to be compiled first. They can't both be compiled first.
12:08:35 <chris> ahhh
12:09:13 *** jervin has joined #gnucash
12:09:47 <chris> I wonder why the previous (use-modules (... payables)) worked
12:10:20 <chris> I'll see about removing this circular dependency
12:10:35 <jralls> That's what's weird: It compiles anyway with ninja but fails with xcodebuild.
12:11:02 <chris> (weighted-average is related to something about 1000GBP->1600USD has more weight than 1.00GBP->1.50USD ? or is this average cost?)
12:11:19 <jralls> Neither. I hope.
12:11:58 <CDB-Man> chris: also, to ensure I'm using the right version when I check after lunch...
12:12:19 *** warlord has quit IRC
12:12:20 <CDB-Man> In addition to the patch changes posted, can you also attach you final SCM file?
12:12:27 *** warlord has joined #gnucash
12:13:34 <jralls> Average cost sums up all of the buys and all of the sells between two commodities for the whole book and nets them out. That works OK for the trial balance as long as all of the transactions are reasonably simple.
12:13:42 <CDB-Man> Side note: when I ran it last night, the output as you saw on the screenshot shows both the trading account total and your computed total, so it was double counting trading gains in total equity. Not sure if that is an oversight, or done purposefully to help me debug (it certainly helped in the debug part)
12:14:41 <chris> ^ this is an oversight indeed
12:15:00 *** chris is now known as chris-zzz
12:15:38 <CDB-Man> [11:59:11] <@17b339jralls> Run the trial balance report with average cost so there aren't any unrealized gains. That's the only way it works. < So you're saying this will provide everything in book value, as entered in the register? Intuitively I would think this can't balance ever when there is so many currencies and stocks... But I'm not thinking particularly hard before lunch
12:17:21 <CDB-Man> Or rather, if what you mean is it takes the register transaction exchange rates and leaves it at that, Hmm
12:18:13 <CDB-Man> For example, DR $800 USD, CR $-1000 CAD. So the exchange rate is 1.25. and the USD amount will be presented as 1000 CAD using this rate
12:18:36 <CDB-Man> And therefore should balance, no unrealized gains being considered
12:20:58 <jralls> That's the intent. What it really does though is net out all of the buys and sells between a pair of commodities--with up to one intermediate commodity--and applies that net rate to convert all of the balances to the report commodity.
12:21:36 <chris-zzz> (jralls: https://pastebin.com/raw/WZMDye3k)
12:22:00 <jralls> So it will work for a balance sheet but not for an income statement, and it may not work for you because some of your transactions are more complicated than it can handle.
12:22:47 <jralls> chris-zzz I'll give it a try after I get the release builds started.
12:23:18 <CDB-Man> chris-zzz: thanks for the upload, will check later
12:23:23 <CDB-Man> Last question
12:23:43 <CDB-Man> Was it intentional that the new report "ignores" closing entries?
12:24:22 <CDB-Man> jralls: when you say not work for income statement, what do you mean? The purpose of the trial balance being to identify income statement accounts to close...
12:25:10 <chris-zzz> CDB-Man: all should ignore closing entries!
12:25:46 <CDB-Man> Legacy sites e not
12:25:51 <CDB-Man> Does not*
12:26:13 <CDB-Man> Retained earnings $6k in legacy for 2020, $113k in New
12:26:26 <CDB-Man> 6k is my current YTD P&L
12:26:28 *** sbluhm has joined #gnucash
12:26:28 *** ChanServ sets mode: +v sbluhm
12:27:14 <CDB-Man> The difference of $107 is the amount I've closed into my retained earnings with a closing entry
12:30:04 <jralls> The average cost calculation is for the whole book, not for a period, so while it will price all transactions in an income statement with the same rate it's unlikely to be the right rate for that period.
12:30:37 <CDB-Man> Hmm
12:31:23 <jralls> So for the purposes of bouncing the income statement against the trial balance report to figure out where you didn't account for some realized gain it's fine, but if you use those numbers for reporting taxes you'll get in trouble.
12:31:57 <CDB-Man> 1. Dr $100 USD cash, CR $-130 CAD interest income, rate 1.3
12:32:21 <CDB-Man> 2. Dr $100 USD cash, CR $-140 CAD interest income, rate 1.4
12:32:46 <CDB-Man> If these are my only 2 transactions, my blended rate is 1.35,
12:33:04 *** bertbob has quit IRC
12:33:16 <CDB-Man> And that should work, right?
12:34:15 <jralls> If they're both in the same period, sure. But if the first one was in 2015 and the second one in 2019 that's not what you want to use for your 2019 taxes.
12:35:08 <CDB-Man> I wouldn't use trial balance for tax reporting
12:35:21 <CDB-Man> It's only used for ensuring the books balance
12:35:24 <jralls> No, I mean on the income statement.
12:36:04 <jralls> The average cost calculation is correct only on balances.
12:36:08 <CDB-Man> Hmm, well, multi year income statement is never a good idea
12:36:29 *** bertbob has joined #gnucash
12:36:29 *** ChanServ sets mode: +v bertbob
12:36:43 <CDB-Man> For tax reporting, I export everything in native currency and hand convert
12:37:11 <jralls> I'm not explaining well enough. The average cost calculation looks at the whole book regardless of the period of the report.
12:37:22 <CDB-Man> Ah... Okay
12:37:29 <CDB-Man> It's entire register all the time
12:37:41 <CDB-Man> Disregards report date parameters
12:38:25 <jralls> No, the whole book all the time.
12:39:29 <CDB-Man> Sorry, in my head the entire file is called a register
12:39:33 <jralls> So if you have ten accounts in USD it will calculate one price and use that to convert all 10 balances to CAD.
12:39:55 <CDB-Man> Your use of the word register in GNUCash is "per account"
12:40:32 <CDB-Man> Put another way, nomenclature, "GL register" in accounting is "the entire book" for GNUCash
12:41:26 <CDB-Man> What GNUCash calls an "(account) register", accounting calls a "GL account"
12:41:26 <jralls> Right, as long as GL is "General Ledger" not "Gains/Losses".
12:41:37 <CDB-Man> Yes, general ledger
12:42:08 <CDB-Man> This mismatch in nomenclature really gets me
12:43:07 <jralls> I only had accounting 101. We didn't get much into GL, ledgers were per-account.
12:45:03 <CDB-Man> "general ledger" is the entire book. Pet account ledger would be the subset of entries for a given account
12:47:01 <jralls> That's one way to think of it, but it's really only applicable in the computer age. In the pen-and-ink days there were only per-account ledgers.
12:47:29 <jralls> And that's the way GnuCash is structured, for better or worse.
12:48:00 <CDB-Man> Well, yes and no, in addition to physical per account ledgers, there was also a physical general journal
12:48:34 <CDB-Man> Which is a continuous record of all entries, a duplicate record to the individual account ledgers
12:48:47 <CDB-Man> I've audited that one before!
12:51:03 <jralls> Note the difference in terminology: Journal vs. Ledger. IIUC the journal was kept as the transactions happened and then transcribed into the ledgers, then the ledgers checked for balance. Out of balances were corrected with non-transactional "journal entries".
12:53:32 <jralls> If there were several people making transactions they'd each have a "day book" which would be collected at the end of the day and transcribed into the journal, then that would be transcribed into the ledgers.
12:54:40 <CDB-Man> The general ledger would be where the journal entries from the general journal are recorded, yes. As you said, in today's usage the general ledger now also refers to the aggregation of all the account ledgers
12:55:11 <CDB-Man> Ah yes, day books are fun .. in that they never matched
12:57:25 <jralls> All of that transcribing is bound to have mistakes.
13:01:13 <jralls> Day books are great for historians though because there's often a lot of information in them that has nothing to do with accounting.
13:10:54 *** shaggy has quit IRC
13:30:23 *** suukim has quit IRC
13:41:27 *** sbluhm has quit IRC
13:52:51 *** jervin has quit IRC
13:55:32 *** Han has joined #gnucash
14:17:54 *** Han has joined #gnucash
14:18:35 *** Han has quit IRC
14:26:50 *** David has quit IRC
14:26:57 *** David has joined #gnucash
14:41:18 *** TownsendHardware has joined #gnucash
14:48:33 *** frakturfreak has joined #gnucash
14:48:33 *** ChanServ sets mode: +v frakturfreak
15:06:35 *** sbluhm has joined #gnucash
15:06:36 *** ChanServ sets mode: +v sbluhm
15:12:23 *** gjanssens has quit IRC
15:27:32 <fell> That has been an interesting conversation. CDB-Man, could you write down this relations somewher in the wiki?
15:29:17 <fell> It could help e.g. translators, special the differences in the terminology.
15:38:40 <jralls> fell, any suggestions about where "somewhere in the wiki" might be? https://wiki.gnucash.org/wiki/Glossary perhaps?
15:46:21 *** sbluhm has quit IRC
15:52:25 <fell> jralls: if the format (only one section per keyword) is not to restrictive.
15:53:12 <fell> Else we could create something like "Accounting Terminology"
16:13:13 *** Mechtilde has quit IRC
16:46:20 <CDB-Man> 1. I am happy to supply narratives if you know where/how you want to document these things
16:46:20 <CDB-Man> 2. hmm, is there a setting somewher to make it that new reports open to the right of the currently selected tab, rather than at the far right as the last tab?
16:46:35 <CDB-Man> i find myself always moving tabs over. i have opver 0+ custom reports always open
16:46:41 <CDB-Man> over 30+*
16:47:56 <CDB-Man> jralls: as you suspected my trial balance does not balance even on average cost mode
16:49:46 <jralls> Have you considered putting the tabs down the side?
16:50:40 <jralls> Preferences>Windows
16:50:43 <CDB-Man> yes, but that still doesnt help when i have 30+ tabs
16:51:10 <CDB-Man> if it was scrollable with the scroll wheel it would be slightly more useful, but that's not the case
16:51:18 <CDB-Man> currently i always right click to navigate by context menu
16:51:46 <CDB-Man> the option to have new reports open next to the currently active tab woul dbe nice (rathe than always open as the last tab)
16:51:55 <CDB-Man> can submit a feature request if it's a feasible change
16:52:20 <CDB-Man> hmm, I actually have closer to 50+ tabs open on a permanent basis...
16:53:20 <jralls> Good grief.
16:54:02 <jralls> It's certainly feasible, though it would need a preference setting for users who want it on the end.
16:54:17 <CDB-Man> I run a lot of analytics! and yes, would be a preference setting for sure
16:56:12 <jralls> Anyway, how far out is the TB? Comparable to the new BS?
16:56:40 <CDB-Man> the TB is out $~2k, whereas the BS was out $~58
16:56:53 <jralls> Ugh.
16:57:09 <CDB-Man> this is average cost on the TB, vs nearest in time on the new BS
16:57:31 <jralls> How far out is the new BS on average cost?
16:58:13 <CDB-Man> with the new patch chirs posted before he went to bed......
16:58:20 <CDB-Man> $0.01!
16:58:30 <CDB-Man> time to run this with nearest in time....
16:59:02 <CDB-Man> exact balance on my problem date of 2019-10-31
16:59:20 <CDB-Man> chris did a good job -- i'll need to kick the tires a bit more to see if it holds up
17:00:01 <jralls> Planning to ignore the TB imbalance?
17:00:42 <CDB-Man> In my mind, I've written off the TB report ages ago, more specifically when I first asked you about it ~2+ years ago
17:00:55 <jralls> OK.
17:01:05 <CDB-Man> that my balance sheet balances, and I run several of my own closing entriy analysis... I'm pretty confident there's no actual issues
17:01:34 <jralls> You're better qualified to know that than I am.
17:01:42 <CDB-Man> I do several BS to IS reconciliations, along with a bunch of manipulated reports using account summary report, and several transaction reports
17:02:02 *** frakturfreak has quit IRC
17:02:10 <CDB-Man> if anything, the best way I find to ensure that you've closed all your accounts, is to run account summary, selecting only all the IS accounts
17:02:36 <CDB-Man> that's more precise, as all accounts ought to be nil if you've closed everything
17:03:07 <CDB-Man> old school, the TB was useful to catch clerical one-sided entries. with systematically enforced debit = credit, that's much less of a concern
17:04:15 <jralls> What it seems to be particularly helpful for in GnuCash is making sure that you've booked all of your capital gains and losses.
17:04:20 <CDB-Man> The TB report could perhaps be more sueful if it also printed all the TRADING accounts, using the exchange rate as at report end date, because that _ought_ to balance
17:04:54 <CDB-Man> hmm, regarding capital gains and losses, I have a much more sophisticated split structure to accurately capture that
17:05:33 <CDB-Man> let me pull up an example...
17:06:12 <jralls> Which may be what defeats the TB report. There's a lot of GnuCash that depends on the user doing things exactly one way... and that one way is often undocumented.
17:07:56 <CDB-Man> indeed -- I don't know precisely how GNUcash does it, so I cannot take to reliance on it, especially when geographical tax law diffferences throw further wrenches into it
17:08:29 <CDB-Man> I have a massive Canadain tax cost basis and gains accumulator spreadsheet to accurately track the cost basis, calculated using weighted average mechanics, the capital gain for me
17:08:57 <CDB-Man> I leverage reports from gnucash to help populate, but ultimately the gain/loss is computed outside and then just "keyed in"
17:09:34 <CDB-Man> https://i.imgur.com/FOoPzU2.png
17:09:54 <CDB-Man> this example is incidentally nice and simple, with 2 purchases, 2 sales, and 1 stock split
17:10:03 <CDB-Man> simple being a relative term
17:10:39 <CDB-Man> at one point the advanced portfolio report *almost* worked, until it didnt, so I've maintained my excel spreadsheet
17:12:01 <jralls> Yeah, I can't use the APR either, I don't book dividends the way it wants.
17:13:02 <CDB-Man> I have a solution to dividends as well
17:13:27 <CDB-Man> and I *think* it's compliant with APR
17:14:32 <CDB-Man> non-reinvested dividend: https://i.imgur.com/OaqI4sf.png
17:14:41 <CDB-Man> reinvested dividend: https://i.imgur.com/EpS8GZF.png
17:15:29 <CDB-Man> all you need is to have the Stock account in the split, with $0 balance, and the income credit split also flagged as "divdiend", and APR should pick it up
17:15:58 <CDB-Man> i'm pretty sure my div reinvestment structure also works with APR
17:16:05 <CDB-Man> I forget what exactly fails to work with APR
17:17:15 <CDB-Man> my way of doing the sales, in the 1st screenshot, both works with APR in terms of showing gain/loss and maintaining the correct cost basis in GNUcash, and also properly reports the net gain/loss into a P&L income account subledger
17:19:41 <CDB-Man> you effectively need to do 2 sets of entries. a cash entry, and an income accrual entry
17:20:03 <jralls> Those all look pretty conventional, I'd think the APR would be fine. I break it by not having the tracer split in dividend payouts and doing reinvestments as a separate transaction.
17:20:42 <CDB-Man> having the stock account in the split resolves the reinvestment part
17:22:01 <jralls> OK.
17:22:44 <CDB-Man> screenshot 2 with no reinvestment will allow it to trace
17:22:58 <CDB-Man> and screenshot 3 works for a split between reinvested portion and remainder cash deposits
17:23:36 <CDB-Man> it also relies on people religiously correctly setting the BUY, SELL, DIVIDEND, FEE flags
17:24:42 <jralls> Ah, another thing I don't do.
17:26:09 <CDB-Man> over the course of the past 5 years, I've lost track of the number of times I've reviewed all couple thousand journal entries of my investment account, and hand-edited all of them en-masse for some functional accounting change
17:26:21 <jralls> Actually two things: I don't use the action field at all and I don't separate commissions and SEC fees, I just post the gross amount.
17:26:23 <CDB-Man> to make it so that a certain report or a certain account asusmption worked proerly
17:26:54 <CDB-Man> I thihk at one point I (unsuccessfully) tried to modify the APR scheme to specifically pickup on the FEE flag
17:27:08 <CDB-Man> that was my gripe, it wasnt properly capitalizing fees into basis
17:28:17 <CDB-Man> yep, the dropdown "includede in basis" for brokerage fees doesnt use the FEE flag, i think you actually look for a split to an expense account
17:28:32 <CDB-Man> i remember this, as I tried to understand the scheme, and gave up
17:28:55 <CDB-Man> if the fees are capitalized, it should be debit to the asset, not to an expense, and that's where the report falls apart
17:29:22 <CDB-Man> "the asset" as in specifically the stock account, with 0 stock units, so it's a pure value transaction as illustrated in my screenshot
17:29:45 <CDB-Man> looking now at a run of my APR, the brokerage fees column shows nil, so it's not picking up on it
17:30:32 <CDB-Man> manually recalculating the "basis" column for a holding, it is indeed not capitalizing the brokerage fee, since my fee is debited to the asset itself, and not an expense as the report is looking for
17:30:56 <CDB-Man> in some jursidictions, brokerage fees on purchase are actually deducted in the year of occurrence
17:31:05 <CDB-Man> but in most places, it is added to your cost basis
17:31:17 <CDB-Man> so the report behaviour of searching for expense splits to accumulate is inaccurate
17:31:22 <CDB-Man> instead, it should search for the FEE flag
17:31:29 <CDB-Man> I could file a bug report to this extent
17:41:11 <CDB-Man> [2020.06.07 17:26:20] <jralls> Actually two things: I don't use the action field at all and I don't separate commissions and SEC fees, I just post the gross amount. <-- 1. I group SEC/SCN/echange fees in with commissions, that's fine, but even if I were to split them, they would both be flagged FEE, so it would still work. 2. if the APR report does not use them... does anything? do the lots use them? I don't use lots... because I don't have full faith
17:41:11 <CDB-Man> that it is accurate, and hence the giant spreadsheet
17:41:38 <CDB-Man> also in canada, since we don't have FIFO like you do in the US, it becomes a moot point
17:41:56 <CDB-Man> FIFO / specific identification
17:43:54 <CDB-Man> anyways, abck to kicking the tires on balance sheet
17:45:42 <CDB-Man> regardin trial balance, you'll be interested to know that when I run the report dated today, the out of balance on average cost vs nearest in time methods is the same
17:45:51 <CDB-Man> $2,714.02 in my case
17:46:23 <CDB-Man> the totals are quite different, $187k debit average cost vs 276k debit nearest in time
17:46:33 <CDB-Man> but that the differences are the same is interesting
17:46:37 <CDB-Man> not sure if that gives you any insight
17:49:00 <CDB-Man> the unrealized gains per TB on nearest in time is $88k, vs legacy BS trading gain $91k, the difference is exaclty $2,714.02 between the 2 reports
17:49:15 <CDB-Man> so your out of balance directly stems fomr sometihing different being done on the trading gains
17:49:32 <CDB-Man> weird though that this would also apply when average cost is used, as by definition there ought to be no trading gains there
17:50:00 <jralls> No, there ought to be no *unrealized* gains there.
17:50:45 <CDB-Man> to summarize:
17:50:45 <CDB-Man> 1. TB average cost out of balance (OOB) $2,714.02
17:50:45 <CDB-Man> 2. TB nearest in time OOB $2,714.02
17:50:45 <CDB-Man> 3. TB unrealized gain vs legacy BS unrealized gain, reports differ by $2,714.02
17:52:16 <jralls> The average-cost TB doesn't have an unrealized gain does it?
17:52:30 <CDB-Man> correct, there is no line item for unrealized gain
17:53:25 <CDB-Man> The new Chris BS that now accumulates trading accounts, computes the same unrealized gain as legacy BS, so that checks out now too. need to stress test it more, but dinner is coming up, so after that
17:53:52 <CDB-Man> (Chris is OOB by $0.01, but we can live with tha trounding error)
17:55:21 <jralls> I think that's telling you that you have 2714.02 in realized gains that didn't get booked. They're probably in currency exchange rather than investments.
17:56:09 <CDB-Man> Hmm, indeed, I do not have a P&L account for currency gain loss
17:56:20 <CDB-Man> There's simply too many transactions for that to be feasible
17:56:57 <jralls> Well, make one, put 2714.02 in it, and you're in balance! ;-)
17:57:01 <CDB-Man> However, I've only ever purchased USD with CAD, I don't recall ever selling USD back into CAD (might need to audit that claim)
17:57:28 <CDB-Man> Same with JPY, this one I can say for certain I've never sold it back into CAD
17:57:30 <jralls> IIRC there's a way to compute it from the trading account balances.
17:57:40 <CDB-Man> And HKD, and a few other currencies
17:58:18 <CDB-Man> How messy? My CAD trading account balance is negative $126k
17:59:03 <CDB-Man> Negative being debit balance
17:59:03 *** Hirppa has quit IRC
18:00:08 <jralls> Do you have $126K in foreign assets and expenses?
18:00:38 *** Hirppa has joined #gnucash
18:00:39 <CDB-Man> Cost basis or fair value?
18:00:45 <CDB-Man> The answer is probably yes to both
18:02:08 <jralls> Cost basis. "Probably" makes me wonder if it's $128,714.02 or $123285.98.
18:02:24 <CDB-Man> If that is the case though, and I debit/credit a currency fluctuation P&L account, I still lack an offsetting entry
18:03:09 <CDB-Man> The debit total is higher than the credit total on TB, so credit gain on currency, debit... Equity account cumulative currency adjustment
18:03:47 <CDB-Man> That would result in a net neutral, and the TB still out of balance? Or I need to rope in the trading accounts somehow?
18:04:23 <CDB-Man> If I need to write up in CAD terms my several USD cash accounts, that's quite the exercise
18:04:32 <CDB-Man> Assuming that is even the case
18:06:58 <jralls> I'm not sure about the trading account part, I don't use them. Income is equity so offsetting in an equity account won't affect the balance.
18:07:41 <CDB-Man> Well then, what could I possibly record, if I wanted to force a plug, to make the TB balance?
18:09:53 <jralls> Suppose you got 100 USD from the bank for 120 CAD and held if for a week then put it back in the bank at 130 CAD. To keep your book in balance you'd record that second transaction as 120 CAD from the USD account and 10 CAD from the Currency P/L account.
18:11:04 <jralls> Oh, duh! the other account now will be the CAD trading account.
18:11:40 <CDB-Man> That doesn't work, trading accounts enforce another trading account to offset, I believe
18:11:51 <CDB-Man> You can't DR trading account, CR income
18:12:06 <CDB-Man> Since they "aren't real accounts"
18:12:26 <CDB-Man> I think I need to credit income, and debit all my USD cash accounts
18:12:37 <CDB-Man> With units being 0
18:13:20 <CDB-Man> And since currency accounts don't track units, I would need to zero the balance and put it back in again, with a changed exchange rate
18:13:22 <jralls> Ah, that would work without trading accounts. It will be interesting to see what happens with them.
18:15:04 <jralls> Two numbers in each split: The amount in the account's commodity and the value in the transaction's currency. Account balances are the amounts.
18:15:33 <jralls> Doesn't matter if its a currency or not.
18:18:34 <CDB-Man> Well
18:18:52 <CDB-Man> Wouldn't that actually impact my USD cash balance, so that it no longer agrees to bank statement?
18:19:10 <CDB-Man> The "commodity" being USD
18:19:32 <CDB-Man> USD cash account does not track commodity units when trading accounts are enabled
18:19:52 <CDB-Man> I would actually end up with a wrong USD balance
18:20:19 <jralls> If the price is 0 then the USD amount is 0 and the CAD value is whatever you want. That's what you're doing in a stock account when you make a cap gains split.
18:20:40 <CDB-Man> There's no price column in the USD cash amounts
18:20:57 <CDB-Man> It doesn't have those columns like a stock account would
18:21:28 <jralls> Right-click, select edit exchange rate. Enter the CAD amount that you want to use.
18:23:11 <jralls> You'll need to create the transaction in the income account so that the transaction currency is CAD.
18:23:20 <CDB-Man> Hmm, will give that a try
18:23:46 <CDB-Man> Still, will be quite the exercise to allocate the gain across multiple USD currency accounts...
18:23:49 <CDB-Man> After dinner
18:24:27 <jralls> You don't have to if you don't want to. All you need is 2714 in the income account.
18:25:08 <CDB-Man> I'll still need a target debit about
18:25:12 <CDB-Man> Account*
18:26:53 <jralls> Right, but only one, and its amount is going to be 0.
18:27:25 <jralls> It's *value* will be CAD 2714, but that won't affect the balance.
18:27:29 <CDB-Man> This sounds like a recipe for an orphaned gain
18:27:42 <CDB-Man> Or division by zero
18:27:42 *** David has quit IRC
18:27:46 *** David has joined #gnucash
18:27:48 <CDB-Man> We'll see!
18:27:58 <jralls> You've already got the orphan gain.
18:28:19 <jralls> You're trying to give it a daddy. ;-)
18:32:39 <CDB-Man> I can probably still stick this into equity, I'll think about it over some Korean seafood pancakes
19:24:02 <chris-zzz> CDB-Man: $0.01 \o/ is obviously rounding error. I'll give another patch to try remove that.
19:24:29 *** chris-zzz is now known as chris
19:27:02 <chris> mmmm kimchi
19:29:39 <CDB-Man> No Kimchi in this case, just variety of seafood - I'll try out the rounding fix in a bit
19:29:49 *** mohave has joined #gnucash
19:30:00 <chris> CDB-Man: scheme is hard, and APR is written in a really really difficult way. I've been trying to simplify it in the last 2 years.
19:30:38 <chris> jralls: ofc I don't use Xcode. did the small patch work?
19:31:25 <mohave> jralls: Seems the download links on sourceforge haven't been updated for 3.904. Github seems to work fine.
19:32:35 <jralls> chris, just experimenting with it now. gjanssens new naming messed me up: new-aging and new-owner do (use-modules (gnucash report)) not (gnucash reports). So I had to add the latter to get it to build.
19:33:30 <chris> mohave: https://pastebin.com/raw/WZMDye3k is a candidate small patch to try fix compilation error
19:33:37 <jralls> So it (almost) does fix the problem in that reports.scm doesn't need the other two to build.
19:34:09 <chris> mohave: hold on...
19:36:34 <chris> CDB-man: I'll offer fix for RE to include closing-entries tomorrow
19:36:41 <chris> gtg work now
19:37:09 <CDB-Man> Sounds good
19:37:36 <jralls> So that makes me wonder if those two don't need scm-rpt-reports and can be in their own target that builds first instead of kluging around with set! gnc:create-new-owner.
19:38:05 <jralls> and its mates.
19:41:49 <jralls> chris, reports.scm exports 5 gnc:foo-report-create functions. I suppose that other reports depend on those 5. Why?
19:45:39 <chris> jralls: they're called from C.
19:46:13 <jralls> All reports are called from C at some point: The Reports menu is C.
19:47:05 <chris> these payable/receivable/owner reports have special hooks from plugin/invoice to run report
19:48:17 <jralls> Hmm.
19:53:16 *** mohave has quit IRC
19:54:18 <chris> these hooks are annoying
19:54:30 <chris> ok off now
19:57:21 <jralls> Bye. Pumpkin time for me too.
19:57:52 <jralls> I'll think about it more overnight. I'd rather unkink the dependencies than band-aid it.
20:09:15 <fell> On docs: The command "docker build -f util/ci/${BUILDENV}-docker -t ${BUILDENV}-gnucashbuild util/ci" failed and exited with 1 during .
20:10:50 <fell> Also wondering, why language: c++;compiler: gcc
20:17:07 <fell> But https://travis-ci.com/github/Gnucash/gnucash-docs/requests: #226 Build created successful
20:30:53 <CDB-Man> jralls: hmm, I think it's about time i start messing with saved report configurations, given the (ever growing) roster of custom reports that I use --- of the 50+ report tabs, all get used at least once every 2 weeks,if not more....
20:30:53 <CDB-Man> going to test out your suggested currency fix now, let's see what happens
20:33:04 <CDB-Man> hmm, something definitely went wrong with chris' suggested fix in https://bugs.gnucash.org/show_bug.cgi?id=797786#c18 --- i went from a 1 cent rounding diff to now a completely incorrect balance sheet.... that or I missed something up on modifying those 4 lines
20:34:25 <CDB-Man> probably some missing brackets somewhere....
20:41:57 <CDB-Man> okay, i don't think its brackets, but perhaps leaving out "gnc-commodity-get-fraction commodity" altogether wasn't the greatest idea?
20:44:28 <CDB-Man> hmm, I definitely broke something
20:49:31 <CDB-Man> when in doubt, reinstall the whole thing!
21:08:37 <CDB-Man> okay now that that issue is resolved-ish for now, time to try this trail balance currency realization thing
21:14:10 <CDB-Man> [2020.06.07 18:21:28] <jralls> Right-click, select edit exchange rate. Enter the CAD amount that you want to use. <-- "the split amount is zero, so no exchnage rate is needed"
21:18:14 <CDB-Man> [2020.06.07 18:23:11] <jralls> You'll need to create the transaction in the income account so that the transaction currency is CAD. <-- turns out you have that backwards, need to start in the USd account, so that I can se thte USD debit amount $0
21:18:54 <CDB-Man> honestly, ieven if this fixes the TB, i am expecting this to cause a balance sheet imbalance, refreshing report and here goews...
21:20:07 <CDB-Man> yep, the difference actuallt /increased/, from 2714.02 to 2783.19
21:23:32 <CDB-Man> reversing the signs in case it was a debit credit mismatch also did not work
21:26:32 *** storyjesse has joined #gnucash
21:35:51 <CDB-Man> jralls: i think by me manually trying to plug this difference... since it is averaging the entire register... it just bumps everything up.... i exported the pre and post TB with and without the $2714 added in, and I can see taht when the $2714 is added in, all of the USD accounts have had increased valuations
21:37:50 <CDB-Man> can't impact the USD with an exhcnage rate, as it will mess up everything else
21:38:06 <CDB-Man> so what's neede is a true transacton against trading CAD, but you cant actually do that...
21:38:15 <CDB-Man> since that would be creating money from thin air
21:47:54 *** jost has quit IRC
22:01:54 *** jost has joined #gnucash
22:03:31 *** Aussie_matt has joined #gnucash
22:31:28 *** lmat has quit IRC
22:57:28 *** Aussie_matt has quit IRC