2023-02-23 GnuCash IRC logs
00:22:11 *** Aussie_matt has joined #gnucash
00:37:51 *** Aussie_matt has quit IRC
01:11:42 *** fell has quit IRC
01:13:01 *** fell has joined #gnucash
01:13:01 *** ChanServ sets mode: +o fell
01:49:38 *** Aussie_matt has joined #gnucash
02:04:35 *** gandalf has joined #gnucash
02:38:24 *** NoobAlice has quit IRC
03:05:29 *** gjanssens has joined #gnucash
03:05:29 *** ChanServ sets mode: +o gjanssens
03:13:16 <Simon> it sounds like what you're actually looking for is to say "no new splits prior to *date* in this account"?
03:14:06 <Simon> requiring a specific balance on that date is more complicated to enforce
03:15:58 <Simon> if you're already using the "reconciled transactions are read-only" flag then it should be simple enough to find the last reconciled transaction in a continuous sequence from the beginning, and then disallow splits to be added/moved before that
04:37:00 *** gjanssens has quit IRC
04:43:39 *** chf has quit IRC
05:09:07 <chris> Simon: Not 100% sure yet of goals... It may be idea to create a gncBankStatement object with 1 account and many splits, and those splits are somewhat protected from deletion/modification if they're attached to gncBankStatement
05:09:46 <chris> 1 gncBankStatement = 1 account, many splits, 1 date, 1 ending balance, (?)1 starting balance, 1 free-text note
05:16:35 *** ns12 has quit IRC
05:17:08 *** ns12 has joined #gnucash
05:18:00 <chris> it'll feed some OCD type folks
05:26:25 <chris> "somewhat protected" would mean: split's date and amount are not modifiable unless it's detached from a bank statement
05:27:50 *** gjanssens has joined #gnucash
05:27:50 *** ChanServ sets mode: +o gjanssens
05:31:00 <Simon> I don't mean what the code should do
05:31:18 <Simon> I mean you should figure out what you want as a user
05:32:29 <Simon> Because associating all the splits with a reconcile object doesn't in itself stop you accidentally adding another split from another register in a way that alters your historic balances
05:32:48 <Simon> Neither do date+balance pairs
05:32:48 <chris> true
05:33:16 <Simon> Which is why I suggested read-only *date* periods
05:34:14 <Simon> Also having to reverify every reconciliation start/end balance when making changes is going to be computationally expensive
05:35:44 <chris> I think I started with the idea of "Balance Assertions" i.e. on 31-12-2020 my balance was $1234.56, and if this is no longer true then something has added an earlier transaction in error
05:36:49 <chris> then gjanssens suggested a BankStatement object which will also protect splits' details, and would also be useful
05:38:01 <Simon> Yes but you can't fix the start/end balances easily. The bank may also have transactions clearing late so that it can't possibly match what's on the statement.
05:39:07 <Simon> It would be nice to have a prompt when I modify something that's in the (reconciled) past for an account
05:39:36 <chris> no cannot fix the balances, but the BankStatement object would just keep a record of successful reconciliations. nothing difficult about that.
05:40:23 <Simon> Right but the scenarios are mostly accidents involving other splits than the ones that were reconciled
05:41:34 <Simon> So you can't do anything useful with the bank statement object except perhaps see what the balance was then, but even that may never match a balance row in the register
05:42:28 <Simon> My credit card statement balance does this a lot. Stuff can be delayed settling for 1-2 days so it ends up on the next statement.
05:44:35 * chris has tried to debug a book in the past using xaccSplitGetDateReconciled -- it was not funny
05:44:50 <chris> I guess it was a bad reconciliation done in the past
05:57:15 <Simon> Either my importing script duplicates stuff because the description changed or I've accidentally moved something and changed its amount. Suddenly an account that should be going to 0 every month no longer does.
06:01:35 <Simon> Having a "read-only time period" from 0 to the last reconciled transaction would probably be useful as long as I don't run into problems when I do want to edit those.
06:02:23 <Simon> Although I can also think of problems with that immediately.
06:04:03 <Simon> If I have a USD to GBP account transaction and I reconcile the USD side (because I've just made a payment) but then the GBP account gets settled later I will need to change the previously estimated GBP amount to the actual amount.
06:04:50 <Simon> What usually happens there is that editing the GBP amount automatically changes the USD amount and I then have to correct the exchange rate.
06:05:27 <Simon> (one account is a USD prepaid account for a service and the other account is a GBP credit card)
06:14:01 <chris> in my idea the sanity checks would not necessarily be performed in real time-- it could be the upgraded "Reconciliation Report"
06:14:31 <chris> gjanssens: not sure how to fix the master build errors... no amount of extern "C" {} seems to fix it
06:33:59 <gjanssens> chris: thanks for the heads up. It needed some tweaking of the mocking code.
06:33:59 <gncbot> gjanssens: Sent 10 hours and 1 minute ago: <chris> I'm thinking about the Reconciliation object... it could formally set the relevant splits as ReadOnly...
06:35:47 <gjanssens> I currently have little input for you on the reconciliation. I can't wrap my head around that ATM...
07:28:24 <warlord> Simon, "if you're already using the "reconciled transactions are read-only" flag then it should be simple enough to find the last reconciled transaction in a continuous sequence from the beginning, and then disallow splits to be added/moved before that" -- this doesn't work, because there is overlap between dates and reconciliation.
07:29:13 <warlord> For example, I can write a check on Feb 23, period can end on Feb 28, and then the check is only deposited on March 3rd. I want the check dated Feb 23 even though it is "not reconciled" in the Feb 28 reconciliation.
07:31:06 <warlord> Your example of a credit card is also accurate. I can make a purchase on Feb 23 which doesn't post until Feb 25, but another dated Feb 24 could post Feb 24.. And if the statement date is Feb 24, the Feb 24 charge will be on it, but the Feb 23 will not.
07:31:20 <Simon> warlord: that's fine assuming you enter it before reconciling, it will remain unreconciled and the time-based readonly state would end at the cheque
07:31:43 <warlord> But you cannot assume that it will be entered before you reconcile
07:32:05 <warlord> I often reconcile my wife's CC well before I enter the "next month" of receipts.
07:33:04 <Simon> Then such a feature wouldn't work for you, but it can't work for you anyway if the goal is "stop modifications inside a reconciled period" and you want to do that.
07:33:17 <Simon> Not everyone can use every feature which is why they're optional
07:34:33 <warlord> I think there needs to be some leeway.
07:34:45 <warlord> I'm not sure I agree with "no modification before last reconcile date"
07:35:08 <Simon> There could be a configurable time delay applied too
07:35:13 <warlord> reconciling is making sure your books "match" someone else's -- but that does not mean your books are EQUAL to theirs.
07:36:27 <Simon> The point is that almost everything before a reconciliation should remain the same. If something new is added 6 months ago it messes up the balance for today and is probably a mistake.
07:36:35 <warlord> Now, if we separated out "date" and "reconcile period" (or statement period), then I would agree that making sure you cannot add or modify transactions within the statement period is a reasonable feature. But that cannot be done by date alone.
07:37:17 <warlord> Sure, if you are going by date, reasonable people can argue about where that date-line should be.
07:37:40 <warlord> (I think I agree that 6 months is beyond where that date-line should be)
08:24:04 *** gandalf1 has joined #gnucash
08:24:31 *** gandalf has quit IRC
08:24:31 *** gandalf1 is now known as gandalf
09:06:51 *** gjanssens has quit IRC
10:03:01 *** Aussie_matt has quit IRC
11:07:41 *** gandalf1 has joined #gnucash
11:08:08 *** gandalf has quit IRC
11:08:08 *** gandalf1 is now known as gandalf
11:22:44 *** palerider has joined #gnucash
11:24:32 *** palerider has left #gnucash
11:37:22 *** ChanServ sets mode: +v Milou[m]
11:45:12 *** gandalf1 has joined #gnucash
11:45:40 *** gandalf has quit IRC
11:45:40 *** gandalf1 is now known as gandalf
12:09:47 *** gandalf1 has joined #gnucash
12:10:15 *** gandalf has quit IRC
12:10:16 *** gandalf1 is now known as gandalf
12:10:58 *** NoobAlice has joined #gnucash
12:44:30 *** gjanssens has joined #gnucash
12:44:30 *** ChanServ sets mode: +o gjanssens
13:07:01 *** gandalf1 has joined #gnucash
13:07:28 *** gandalf has quit IRC
13:07:28 *** gandalf1 is now known as gandalf
13:18:44 *** gandalf has quit IRC
13:19:38 *** gandalf has joined #gnucash
13:25:28 <jralls> chris, gjanssens, and I have been down this "balance assertion" path before: https://github.com/Gnucash/gnucash/pull/667. It gets very complicated very quickly.
13:48:02 *** ArtGravity has joined #gnucash
13:48:02 *** ChanServ sets mode: +v ArtGravity
13:56:07 <gjanssens> jralls: I'm looking at Bug 798572 - Parse numbers with two minus signs as a positive numbers (https://bugs.gnucash.org/show_bug.cgi?id=798572)
13:56:38 <gjanssens> I'm tempted to just close that as too unusual to cater for. Do you have thoughts on that ?
14:00:05 <gjanssens> As I'm about to leave, feel free to leave me a note. I'll read it tomorrow then... Or just proceed with closing the report is you agree with my suggestion.
14:02:51 <jralls> That's my inclination too, but I found https://infinitekind.tenderapp.com/discussions/switching-from-another-personal-finance-program/8232-csv-data-download-from-bank and https://manpages.ubuntu.com/manpages/impish/man5/hledger_csv.5.html that suggest that maybe it's more common than we think.
14:05:12 <gjanssens> Hmm, ok. In that case we may have to figure out a way. I can strip double minus signs with a regex, just as I'm stripping off currency symbols and (as of today) whitespace from number fields.
14:09:02 <jralls> That seems the simplest way.
14:09:43 <gjanssens> Right. For one of the next days :)
14:09:55 <gjanssens> See you later!
14:09:58 <jralls> OK. Enjoy your evening!
14:49:44 *** chf has joined #gnucash
15:04:33 *** gjanssens has quit IRC
15:48:09 *** gandalf1 has joined #gnucash
15:48:38 *** gandalf has quit IRC
15:48:38 *** gandalf1 is now known as gandalf
15:52:38 *** gandalf has quit IRC
16:07:40 *** chf has quit IRC
19:33:36 *** ArtGravity has quit IRC
20:13:33 *** Aussie_matt has joined #gnucash