[GNC] Reconciliation Changes
Chris Good
goodchris96 at gmail.com
Fri Oct 15 03:57:43 EDT 2021
Hi David,
I don’t believe the way the transactions are loaded into the reconcile screen has changed.
I remember there was a problem with the calculated reconciled balance some time ago which was something to do with the reconciled date,
but I don’t think that has anything to do with Lisa’s problem.
Re the user who is having problems with postponing a reconciliation. It has yet to be proven this isn’t a user error.
I would think that if there was a problem like that, many people would have reported it by now.
The code that was reverted for 3.11 was to do with propagating the reconcile status to other splits. It is very unlikely this has anything to do with postponing a reconciliation.
Regards,
Chris Good
From: David Carlson <david.carlson.417 at gmail.com>
Sent: Friday, 15 October 2021 5:27 PM
To: Chris Good <goodchris96 at gmail.com>
Cc: Derek Atkins <derek at ihtfp.com>; D. <sunfish62 at yahoo.com>; Steve Welch via gnucash-user <gnucash-user at gnucash.org>
Subject: Re: [GNC] Reconciliation Changes
For completeness I should have mentioned that for accounts which have sub-accounts like those that envelope budgeters will probably have, the user should view the account in a 'with sub-accounts view' to see everything that is happening in the 'with sub-acconts' reconciliation window.
On Fri, Oct 15, 2021 at 12:57 AM David Carlson <david.carlson.417 at gmail.com <mailto:david.carlson.417 at gmail.com> > wrote:
No, Chris. In release 3.8 and earlier when the user first clicks on the Reconcile icon and the pop-up appears to set the date, balance, etc., then clicks OK, the Reconcile window opens with every transaction that is dated before the reconciliation date and marked "c" in the Reconcile box is automatically checked to be reconciled. Thus the user normally will only need to check or uncheck any transactions that do not match the bank statement. If the user was importing transactions so they were marked "c" when they were imported or marking existing transactions "c" if they think they saw them in their smartphone banking app, those transactions are already applied to the target balance calculation and do not need to be manually checked.for reconciliation. That is how it worked in release 3.8 and earlier.
There is another thread that apparently indicates that in the current release if some transactions were manually marked as reconciled and the user chooses Postpone, when he returns he will find his previous markings lost. In release 3.8 those manually marked transactions will still be marked when returning to the reconciliation. It appears that the code was not reverted exactly to the way it was in release 3.8.
On Thu, Oct 14, 2021 at 10:45 PM Chris Good <goodchris96 at gmail.com <mailto:goodchris96 at gmail.com> > wrote:
Hi David (Carlson),
Not sure what you mean by “automatic marking that happens when the reconciliation process is initiated”?
Perhaps you mean the marking of transactions as cleared when they are imported?
Regards,
Chris Good
From: David Carlson <david.carlson.417 at gmail.com <mailto:david.carlson.417 at gmail.com> >
Sent: Friday, 15 October 2021 3:00 AM
To: Derek Atkins <derek at ihtfp.com <mailto:derek at ihtfp.com> >
Cc: D. <sunfish62 at yahoo.com <mailto:sunfish62 at yahoo.com> >; Steve Welch via gnucash-user <gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org> >; Chris Good <goodchris96 at gmail.com <mailto:goodchris96 at gmail.com> >
Subject: Re: [GNC] Reconciliation Changes
I wonder if there is some confusion here between manually marking (or un-marking) account and sub-account transactions as reconciled (or not) vs the automatic marking that happens when the reconciliation process is initiated. The purpose of the pause before committing the reconciliation is to allow the user to uncheck the items that have not cleared to bring the cleared balance to match the outside bank statement or the user's desired result. I hope that GnuCash still pre-marks all un-reconciled account transactions (and sub-account transactions if they exist and the appropriate box is checked) dated before the reconciliation date when the reconciliation is started, as manually marking possibly hundreds of transactions at the beginning of the process would definitely be a pain. I do agree that each sub-account transaction line should be separately manually changeable.
Because I am still running release 3.8 I cannot observe for myself how it works now, but release 3.8 does at least pre-mark all un-reconciled account transactions before the reconciliation date. I do not have sub-accounts in my data.
On Thu, Oct 14, 2021 at 6:53 AM Derek Atkins <derek at ihtfp.com <mailto:derek at ihtfp.com> > wrote:
Chris, Lisa,
Yes, I agree with David here. It is absolutely quite common (and for
DECADES has been the suggested way to do "envelope budgeting" in GnuCash)
-- to have subaccounts of your Bank (or other Asset) account for your
budget items.
I realize that I did instigate your change in PR-713, however to reiterate
my original message, "I do not agree with this change AND think it will
introduce another bug" (emphasis added here). I still think the original
change you made in PR-670 was wrong. But regardless, here we are now.
In your particular case in bug #797648 I (still) don't understand why this
is a single transaction. If you are using two payment methods to two
expense accounts, that to me is two transactions. They could be processed
at different times, post at different times, and they are absolutely for
different items. I don't even know how you can place such an order (well,
except, I guess, if you're at a restaurant and order separate checks --
but even in that case I don't see why you need to enter it as a single
transaction).
The use-case of envelope budgeting is definitely more common than your use
case, so we should definitely support that. Perhaps I can propose some
additional logic:
If *ALL* the splits in a transaction are within the Reconciliation account
(sub)tree, then when you click on one, it should be as if you click on all
of them. That would help Lisa's use-case of moving money from one
envelope into another, or from the main account into an envelope.
However, this (new?) logic will not help in the case of a purchase where
you're buying things from different envelope budgets in a single
transaction (e.g. you're buying toothpaste and gas in the same
transaction). I'm not sure how to get this and Chris' desire (and my
desire) together, because I feel they are all mutually exclusive
processes.
I will just point out that in the reconcile window, all the splits of the
same transaction will be next to each other, so if you're buying
toothpaste and gas together, the splits for
Assets:Bank:Checking:Toothpaste and Assets:Bank:Checking:Gas will be next
to each other and should be easy enough to check manually (because they
would both be credits in the same transaction).
-derek
On Thu, October 14, 2021 7:26 am, D. via gnucash-user wrote:
> Chris,
>
> I believe she's implementing envelope budgeting
> (https://www.thebalance.com/what-is-envelope-budgeting-1293682) using sub
> accounts. A fair number of users of Gnucash do this, which has been
> discussed on the lists over the years.
>
> David T.
>
>
> -------- Original Message --------
> From: Chris Good <goodchris96 at gmail.com <mailto:goodchris96 at gmail.com> >
> Sent: Thu Oct 14 03:11:57 EDT 2021
> To: gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org>
> Subject: Re: [GNC] Reconciliation Changes
>
> Hi Lisa,
>
> This change was done under https://bugs.gnucash.org/show_bug.cgi?id=797648
> for reasons explained in the bug.
> The first fix went live in 3.9 which forced all splits in a transaction to
> the new selected reconciled state when one of them was changed, rather
> than
> just toggling the reconciliation status of all the splits for the account
> being reconciled.
> This was deemed incorrect, so a change was made in 3.11 where changing the
> reconciliation status of a split in a transaction had no effect of other
> splits in the transaction for the account being reconciled.
>
> I wouldn't recommend running an old version like 3.10. Never upgrading
> until
> you have to greatly increases your risk of falling foul of a security
> issue
> (or just a bug) that may have already been fixed.
>
> I don't upgrade immediately a new version is available, but I do after a
> little while so it is likely that any major problems with a new release
> will
> have been found and probably fixed.
>
> It seems unusual to create different subaccounts in a bank account for
> different types of expenses.
> I believe it is more usual to split your income and expenses into
> different
> income and expense accounts, and do your budgeting based on the totals of
> those accounts.
>
> Regards,
> Chris Good
>
> Message: 6
> Date: Tue, 12 Oct 2021 20:31:44 -0700
> From: Lisa Reynoso <mrs.reynoso at gmail.com <mailto:mrs.reynoso at gmail.com> >
> To: David Carlson <david.carlson.417 at gmail.com <mailto:david.carlson.417 at gmail.com> >
> Cc: DaveC49 <davidcousens49 at gmail.com <mailto:davidcousens49 at gmail.com> >, Gnucash Users
> <gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org> >
> Subject: Re: [GNC] Reconciliation Changes
> Message-ID: <916D45E4-A319-4AB9-BFB9-FD7A6557F4C8 at gmail.com <mailto:916D45E4-A319-4AB9-BFB9-FD7A6557F4C8 at gmail.com> >
> Content-Type: text/plain; charset=utf-8
>
> Well, my computer reformatted, so I had to start over. But in almost two
> decades, I started over several times, and this last time is the only time
> this problem occurred. I can?t imagine that had anything to do with it.
>
> I?m going to look at an old hard drive I saved from a couple computers
> back
> and see if I have an old installation file and see what it does if I do.
> Or
> what happens if I import old files from years back (if they are still
> there). I?ll let you know how it goes.
>
> Lisa
>
> Sent from my iPhone
>
>> On Oct 12, 2021, at 5:35 PM, David Carlson <david.carlson.417 at gmail.com <mailto:david.carlson.417 at gmail.com> >
> wrote:
>>
>> ?
>> Sub accounts under the same bank account are not the same as transfer s
>> to
> outside accounts.
>>
>> If I recall correctly, they must be of the same type as the parent
> account. I think that should still work as before in reconciliations.
> Were
> you able to import your table of accounts from an old file or did you
> start
> over, possibly different somehow this time?
>>
>>
>>
>>> On Tue, Oct 12, 2021, 7:18 PM Lisa Reynoso <mrs.reynoso at gmail.com <mailto:mrs.reynoso at gmail.com> >
>>> wrote:
>>> Okay, first, I don?t know what version I had before. It was about 2
>>> years
> ago that I downloaded it, and my hard drive was wiped, so I have no idea.
>>>
>>> Second, you completely misunderstood my problem. I understand the
> reconciliation process intricately; I?ve been using it for a decade and a
> half. I understand about clicking the ?include sub accounts? box; it?s the
> sub account feature that turned me on to the program, since I was doing
> that
> on paper as my mother did; a computer was so much faster, since it did
> most
> of the math for me. I like math, but it gets tedious entering numbers in a
> calculator. But I digress.
>>>
>>> There are two basic examples to illustrate. I have a checking account,
> divided into various sub accounts, such as gas, groceries, clothing,
> school
> bill, etc. When I deposit a paycheck, I split the deposit into various
> accounts. Likewise when i purchase both food and toothpaste at the grocery
> store; toothpaste doesn?t come from the food budget. When I want to
> reconcile the checking, I used to be able to check one of those splits and
> have them all highlight. So if I checked the toothpaste transaction, the
> grocery charge would check as well. Of course the expense account wouldn?t
> reconcile; I wasn?t referring to that.
>>>
>>> But the other example is when I transfer money within the checking
> account from one sub account to another. Like my original gas to groceries
> (or vice versa) analogy. In that case, when I would check the credit, the
> debit would check automatically as well, and the balance on the
> reconciliation would not change, because no money actually entered or left
> the checking. It was just moved around within it. Now I have to check one
> and then scroll down to find the other. I make several dozen of these
> transactions every month, and it is tedious to have to check them both.
>>>
>>> I downloaded version 4.4 when this problem first made itself felt. I
> downloaded 3.11 today, and it still doesn?t do what it used to. I have
> Windows 10; I don?t know if an earlier version will work or not.
>>>
>>> Lisa
>>>
>>> Sent from my iPhone
>>>
>>> > On Oct 12, 2021, at 2:09 PM, davidcousens49 at gmail.com <mailto:davidcousens49 at gmail.com> wrote:
>>> >
>>> > ?Lisa
>>> >
>>> > It may help if you can tell us what the previous version was and
>>> > which version you have now upgraded to.
>>> >
>>> > On the reconciliation setup dialog under the Ending Balance entry
>>> > there is a checkbox "Include subaccounts" which AFAIK by default is
>>> > not checked. Try selecting that when starting the reconciliation
>>> > and see if that restores some of the functionality you are used to.
>>> > As far as I can tell once you have selected that option in the
>>> > dialog for a given account it remains in force for subsequent
>>> > reconciliations until you unselect it again but I am not completely
> sure how sticky that option is and whether it does set a flag in the
> account
> structure.
>>> >
>>> > Any reconciliation process only acts on a single account and as
>>> > such only marks the splits of a transaction into that that account.
>>> > You do not reconcile a whole transaction unless you have
>>> > individually reconciled all accounts that the transaction has
>>> > splits to. Splits to an account which has not been reconciled will
>>> > generally be marked with a "n" ( and maybe a "c" in some cases) and
>>> > splits to a reconciled account with a "y". If a previous version of
>>> > GNuCash did do this then that behaviour was incorrect. I have been
>>> > using GnuCash for a similar period of time and I can't recall any
> version in which a whole transaction not just the split was reconciled.
>>> >
>>> > David Cousens
>>> >
>>> >> On Tue, 2021-10-12 at 12:29 -0700, Lisa Reynoso wrote:
>>> >> I've used GNU cash for years. Like, over 15 years. I used it
>>> >> before I was married, so it's definitely been more than 15 years.
>>> >>
>>> >> Anyway, I never upgrade except when I get a new computer, and then
>>> >> I install whatever is the latest, and transfer the files from the
>>> >> old version (or in my most recent case, I just started over,
>>> >> because the computer reformatted without my permission--yeah, that
>>> >> was a nightmare!). When this latest install happened, something
>>> >> had changed about how the reconciliation works. Always before when
>>> >> I had a transfer from one subaccount within an account to another,
>>> >> or if it was a split transaction, when I would check one box in
>>> >> the reconciliation window, all boxes pertaining to that
>>> >> transaction would check. For example, suppose I had extra gas
>>> >> money at the end of the month, but had overspent my grocery fund.
>>> >> I could transfer from the gas to the grocery subaccounts, and when
>>> >> I reconciled, I could check one box and it would mark them on both
>>> >> the credit and debit sides, without me having to hunt for the
>>> >> opposite transaction. Likewise, when I deposit a check, I usually
>>> >> divide it among various accounts, and all I had to do was click
>>> >> one of the subaccount deposits, and all the other deposits from
>>> >> the same check would be marked as well. Now, that's not the case.
>>> >> And I can't find an old enough version for Windows 10 that does
>>> >> that anymore. Anyone have any ideas? It now takes almost twice as
>>> long
> for me to reconcile, since I have a lot of subaccounts and do a lot of
> internal transferring within my checking account that doesn't show up on
> my
> bank statement.
>>> >> Having to look for the parallel transactions or figuring out which
>>> >> split transactions go together takes more time. I'm almost ready
>>> >> to try to find some other software, but I've used this for so long
>>> >> I really don't want to switch.
>>> >>
>>> >> Lisa
>>> >>
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org>
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org>
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
--
Derek Atkins 617-623-3745
derek at ihtfp.com <mailto:derek at ihtfp.com> www.ihtfp.com <http://www.ihtfp.com>
Computer and Internet Security Consultant
_______________________________________________
gnucash-user mailing list
gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org>
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
--
David Carlson
--
David Carlson
--
David Carlson
More information about the gnucash-user
mailing list