2022-05-01 GnuCash IRC logs
00:13:36 *** Aussie_matt has quit IRC
01:05:12 *** fell has quit IRC
01:06:31 *** fell has joined #gnucash
01:06:31 *** ChanServ sets mode: +o fell
01:13:50 *** sbluhm has joined #gnucash
02:12:20 *** sbluhm has quit IRC
02:37:29 *** raeburn has quit IRC
02:40:24 *** raeburn has joined #gnucash
02:40:24 *** ChanServ sets mode: +v raeburn
03:22:49 *** jmdaemon has quit IRC
03:34:04 *** Yotson has quit IRC
03:35:56 *** Yotson has joined #gnucash
03:48:53 *** Aussie_matt has joined #gnucash
06:09:04 *** sbluhm has joined #gnucash
07:46:34 *** sbluhm has quit IRC
07:49:04 *** David has quit IRC
07:49:14 *** David has joined #gnucash
07:57:37 *** sbluhm has joined #gnucash
08:18:42 *** lmat has quit IRC
08:26:49 *** lmat has joined #gnucash
09:44:52 *** sbluhm has quit IRC
10:07:09 *** Treasurer501c3 has joined #gnucash
10:09:54 *** Treasurer501c3 is now known as LoveGnuCash
10:10:32 *** LoveGnuCash is now known as Treasurer501c3
10:43:55 *** sbluhm has joined #gnucash
10:45:17 *** Aussie_matt has quit IRC
10:59:40 *** sbluhm has quit IRC
11:01:28 *** Treasurer501c3 has quit IRC
11:56:45 *** Treasurer501c3 has joined #gnucash
12:01:59 *** Treasurer501c31 has joined #gnucash
12:02:15 *** Treasurer501c3 has quit IRC
12:14:53 *** Treasurer501c31 has quit IRC
13:06:21 *** sbluhm has joined #gnucash
13:16:51 *** sbluhm has quit IRC
13:34:55 *** kcin has joined #gnucash
13:56:37 *** sbluhm has joined #gnucash
14:18:31 <fell> jralls: IMHO the assumtion in your last commit is wrong.
14:19:27 <fell> Valuta is the important date.
14:20:14 <jralls> Fell, not in the instance of the bug, where the bank was using value-date for an interest calculation instead of the posting date.
14:20:47 <fell> right
14:21:43 <jralls> Also we're importing for the *user's* book, not the bank. If the user charges a purchase on the 5th and that's the entry-date while the value-date is the 6th then the entry-date is the right date for the user's book.
14:22:52 <jralls> So under what circumstances do you think that the value date should take precedence if the entry date is supplied?
14:23:41 <fell> Example last friday I sent an order online and it was executed same date, but will will appear in the statement with enty date of tomorrow.
14:24:09 <jralls> And what will be the value date?
14:24:35 <fell> Same, when I used the atm on Friday evening.
14:25:19 <fell> value is Froiday, entry is Monday
14:26:23 <jralls> Interesting. So maybe we should use whichever is earlier?
14:26:54 <fell> Not always
14:27:43 <jralls> There are cases where the bank would set one of them to a date before the customer performed the transaction?
14:27:52 <fell> on 30.12. they usually enter already the value of 31.12.
14:28:12 <fell> as 31.12. is bank holyday.
14:29:16 *** jmdaemon has joined #gnucash
14:30:17 <fell> That are the end of the year intersts, fees, …
14:33:08 <jralls> What has that to do with anything? You do a transaction on the 30th, so that's the date you want in your book. If the bank puts the 31st in both fields then there's nothing GnuCash can do about it. If it puts 30 in one field and 31 in the other, 30 is the right one. The only problem would be if the bank puts 29 in one of the date fields.
14:33:14 <jralls> Does that happen?
14:34:11 <fell> If there is a weekend
14:36:00 <fell> The entry date is mostly relevant to control the bank.
14:37:01 <fell> As user I am interested in the value date —e.g. to control interest calculations.
14:37:40 <jralls> No you're not, especially if it's 30 February.
14:38:55 <fell> I never had a closer look in the 360 days bankers year.
14:39:25 <jralls> Your book should reflect the day that *you* recognize the expense. If you buy something on 27 February them that's what you should post in your book, regardless of whether the other account is cash-in-wallet, checking, credit card, or accounts payable.
14:39:37 *** superma has joined #gnucash
14:42:06 <fell> If I pay now thy my card they will record it value today, entry tomorrow
14:42:18 <fell> with
14:43:06 <jralls> OK, so we're back to using whichever is earlier.
14:43:54 <fell> No
14:43:57 *** superma has quit IRC
14:44:00 <jralls> Because?
14:45:00 <fell> Enty date only means the day they added it to the statement.
14:45:25 <fell> It can be before or after the value date.
14:46:18 <jralls> Right. When it's before the value date it's the date you want.
14:46:40 <fell> It is important for the closing saldo of the statemnt.
14:46:52 <jralls> Um, saldo? Balance?
14:47:04 <fell> right
14:47:33 <jralls> Well, again, the earlier one is the one that's going to be in the balance, right?
14:47:40 <fell> No
14:48:20 <jralls> How?
14:48:20 <fell> Assume end of month statements
14:49:17 <jralls> And they'd back date one or the other to the previous month? Seems very unlikely.
14:50:00 <fell> They calculate all their known movements.
14:50:46 <fell> for april. But last night I used the ATM
14:52:06 <fell> Then on they May statement appears it with valuta 30.4 and entry 2.5.
14:52:35 <fell> 2. because today is sonday
14:53:51 <jralls> Yup. 30.4 is the correct date for your book. It won't show up in the April statement. You'll leave it unchecked in the reconcile dialog. All good.
14:53:53 <fell> The other direction are events that they know in advance
14:54:20 <fell> like the end of abond
14:54:27 <fell> a bond
14:57:55 <jralls> Keep going.
14:58:13 <fell> They will enter them before bank holydays if no FX calculation is required..
15:01:30 <jralls> Ah, so an entry date of 29 April and a value date of 1 May.
15:02:19 <fell> Yep
15:02:59 <jralls> So there's no universal rule to follow.
15:04:19 <fell> I would always use the value date.
15:05:21 <jralls> Yes, but that's you. Warlord would say don't use either, always post everything by hand.
15:06:41 <jralls> And the OP on bug 798491 would prefer the entry date because apparently his bank works differently from yours.
15:07:00 <warlord> LOL.
15:07:13 <warlord> There is no universal right answer.
15:08:13 <jralls> Well, there is: Always post by hand. You can still import, the importer will pick up the hand entry and mark it cleared.
15:11:04 <jralls> For the somewhat lazy they can create an sx for the bond payout and still have the earlier date rule for everything else.
15:13:22 <warlord> Right, if you post by hand you'll get the date you want. There is no universal answer for the importer, and frankly I would close any bug report saying anything that isn't "use the date given by the bank".
15:13:32 <warlord> If you want another date, create by hand.
15:14:01 <jralls> The problem here is choosing between two dates given by the bank.
15:15:15 <fell> Ah, bankers year has inalid dates 29./30.2.
15:15:59 <jralls> fell, it does. But the real calendar doesn't and GnuCash uses the real calendar.
15:17:09 <jralls> So there's separate code that I accidentally committed as part of something else to convert an non-date back to the real last day of February.
15:17:18 <warlord> be right back..
15:17:26 *** warlord has quit IRC
15:17:38 <fell> IMHO they should get corrected to 1.3.
15:18:16 <fell> without reading the full article
15:23:36 *** warlord has joined #gnucash
15:23:45 <jralls> The purpose is apparently that (some?) German credit cards charge interest on a 30-day month regardless of how many days the month actually has, with accrual starting the day after the charge is made. So something charged on the 28th accrues interest starting on the (non-existent) 29th and accrues 2 days of interest before 1 March.
15:23:49 *** ChanServ sets mode: +qo warlord warlord
15:24:26 <jralls> A charge on 1 March starts accruing interest on 2 March.
15:24:49 *** kcin has quit IRC
15:26:26 <jralls> And of course that 28 February charge is going to show up on February
15:26:37 <jralls> sigh. February's statement.
15:32:45 <fell> I believe there are 2 different things: Internet/phone providers changed their contracts from monthly fee to 30-day fee.
15:34:16 <fell> That is not related to the different Day count conventions
15:34:29 <fell> for interests
15:40:46 <fell> In the german variant each month has 30 days, but if the contract ends on 28.02 they pay only 28 days
15:42:30 <fell> or in a leap year 29 days
15:42:59 <jralls> Would that show up as a weird value date in a swift download?
15:43:46 <fell> so they have to distinguisch it from 1.3. where they would have to pay 30 days for February
15:46:52 <fell> International Swaps and Derivatives Association collected that conventions.
15:48:02 <fell> The old SWIFT standards are members-only published.
15:48:19 <jralls> Swaps and derivatives are definitely out of scope for GnuCash. Phone bills aren't, but even if the phone bill says the billing period is 1-30 February the charge will show up at the bank on 1 March, right?
15:48:43 <jralls> Yeah, I had to join swift (it's free, they just want a confirmed email) to read the standard.
15:49:21 <fell> Cool!
15:51:51 <fell> I think for our purpose 1.3. is OK, perhaps an note in the docs about interest calculation.
15:52:23 <fell> with a link to https://en.wikipedia.org/wiki/Day_count_convention
15:58:02 <fell> The phone bill is different: Lets asume your contract starts on 1.1. Next invoices after 30 real days: 31.1, 2.3, 1.4, 1.5. …
16:00:10 <jralls> If they're really doing it for 30 *real* days instead of 30 banking days then that's only for the first year. The second year (assuming the first isn't a leap year) the bill will come on 26 January.
16:01:18 <jralls> The first bill, that is.
16:01:24 <fell> and you had a 13 payment in december.
16:01:52 <Simon> have these people not heard of weeks and billing every 28 days? :/
16:04:42 <fell> Psst! They could hear you! ;-)
16:06:22 *** sbluhm has quit IRC
16:06:38 <Simon> it even works for leap years!
16:07:55 <Simon> I can understand "overpaying" in February or being "underpaid" in 31-day months from the pov of the customer and provider, but 2 days extra interest in February - how do they get away with that?
16:08:34 <fell> They underpay you inmoth with 21 days.
16:08:49 <fell> 31
16:14:21 <warlord> Simon, they pay interest for 360 days (12 30-day months) in a 365-day year. So the bank is winning by 5 days / year.
16:58:12 *** field^Mop has joined #gnucash
16:59:19 *** bertbob has quit IRC
17:19:46 *** bertbob has joined #gnucash
17:19:46 *** ChanServ sets mode: +v bertbob
18:19:37 *** Treasurer501c3 has joined #gnucash
18:24:16 *** smartner__ has joined #gnucash
18:28:29 *** Piko has quit IRC
18:51:00 *** bertbob has quit IRC
18:55:20 *** CDB-Man has quit IRC
18:58:21 *** CDB-Man has joined #gnucash
18:58:21 *** ChanServ sets mode: +v CDB-Man
19:02:08 *** bertbob has joined #gnucash
19:02:09 *** ChanServ sets mode: +v bertbob
19:08:26 *** smartner__ has quit IRC
19:08:44 *** smartner__ has joined #gnucash
19:08:59 *** smartner__ is now known as register
19:09:06 *** register is now known as smartner
19:13:01 *** ChanServ sets mode: +v smartner
19:14:12 *** field^Mop has quit IRC
19:17:54 *** Treasurer501c3 has quit IRC
19:18:11 *** Treasurer501c3 has joined #gnucash
19:20:10 *** Treasurer501c3 has joined #gnucash
19:22:22 *** Treasurer501c3 has quit IRC
19:22:34 *** Treasurer501c3 has joined #gnucash
19:25:07 *** Treasurer501c3 has quit IRC
19:25:32 *** Treasurer501c3 has joined #gnucash
19:45:43 *** Treasurer501c3 has quit IRC
20:02:45 *** miklcct has quit IRC
20:03:11 *** miklcct has joined #gnucash
20:03:11 *** ChanServ sets mode: +v miklcct
21:57:36 <CDB-Man> chris: cap gains > 0 means a profit is realized, so price going up for long, and price going down for short
21:59:01 <CDB-Man> And unfortunately have not had time so far to do more specific stress testing. However I did use it for 2 real transactions in my actual book, for a purchase and sale, and that's been much smoother than my manual entries prior to the tool existing
22:47:19 *** storyjesse has joined #gnucash
23:02:50 *** smartner has quit IRC