[GNC] Redo account reconciliations
john
jralls at ceridwen.us
Sat Sep 4 10:59:20 EDT 2021
He said the February reconcile.
So tell the reconcile info dialog 28 Feb and type in the balance from the February statement as usual. Click OK. As long as you haven't messed up anything else you'll be able to check the one unreconciled split from February and the finish button and you're done.
Regards,
John Ralls
> On Sep 4, 2021, at 7:18 AM, Derek Atkins <derek at ihtfp.com> wrote:
>
> Ah... But that's NOT how you are supposed to recover from that.
> If you reconciled up for 31 Aug 2021, and you un-reconcile a transaction,
> it doesn't matter what date the transaction has -- you should re-reconcile
> 31 August! You just need to re-check the February transaction.
>
> -derek
>
> On Sat, September 4, 2021 9:10 am, Christopher Lam wrote:
>> Derek,
>> Consider a well-used bank account. You reconcile every end of the month
>> successfully up to 31 Aug 2021.
>> Accidentally you unreconcile a Feb 2021 split.
>> You retrieve your 28 Feb 2021 bank statement, try to re-reconcile and fail
>> because the reconciliation end balance also tallies splits from March 2021
>> onwards.
>> C
>>
>> On Sat, 4 Sept 2021 at 13:01, Derek Atkins <derek at ihtfp.com> wrote:
>>
>>> Chris,
>>>
>>> On Sat, September 4, 2021 8:36 am, Christopher Lam wrote:
>>>> I agree that if an account reconciliation is done periodically
>>> correctly
>>>> every time, then it works well. If an old reconciled split is
>>> unreconciled
>>>> and we need to re-reconcile a previous reconciliation date, then the
>>> code
>>>> falls apart.
>>>
>>> I'm curious why you say it falls apart?
>>>
>>>> It may be an idea to allow batch unreconciliation of all splits whose
>>>> reconcile date is after the reconciliation date in the Reconciliation
>>>> dialog, thereby allowing the user to re-do reconciles.
>>>
>>> That could be a good idea.
>>>
>>> -derek
>>>
>>>> On Sat, 4 Sept 2021 at 06:34, Borden via gnucash-user <
>>>> gnucash-user at gnucash.org> wrote:
>>>>
>>>>>
>>>>>
>>>>>> The starting balance is computed from all the reconciled
>>> transactions
>>>>> "to
>>>>>> date". It *can* be safe to ignore the starting balance if, for
>>>>> example,
>>>>> a
>>>>>> transaction became unreconciled. For example, let's say you
>>> reconcile
>>>>>> from some starting balance X to a final balance of $1000. Then you
>>>>>> accidentally unreconcile a $100 transactions. If you try to
>>>>> re-reconcile
>>>>>> that same statement/date/ending-balance of $1000, it won't show X
>>> as
>>>>> the
>>>>>> starting balance, but something else (PROBABLY $900, but I'm not
>>> 100%
>>>>>> sure). But that's okay -- just ensure the ending balance is
>>> correct
>>>>> and
>>>>>> all the transactions that SHOULD be reconciled ARE reconciled.
>>>>>>
>>>>>> There is no way to get a transaction to reconciled status (y)
>>> manually
>>>>> --
>>>>>> the only way is through a reconcile process. So if you have
>>>>> reconciled
>>>>>> transactions, that must've happened through a reconcile.
>>>>>>
>>>>>> I would recommend you just go ahead with March, ignore the starting
>>>>>> balance, enter the correct March ending balance, and see if the
>>>>>> reconciliation works (ensure you re-reconcile anything from earlier
>>>>> that
>>>>>> might have become unreconciled).
>>>>>>
>>>>> So I just want to build a bit on this answer. GNUCash doesn't have
>>> QBs
>>>>> reconciliation system - so don't equate the two. As an accountant who
>>>>> doesn't need to be handheld or leashed, I find GNUCash's system
>>> better
>>>>> than QBs - albeit there is room for improvement. However, I wouldn't
>>>>> recommend GNUCash to someone less comfortable with bare-ledger
>>>>> accounting -
>>>>> controls exist for a reason.
>>>>>
>>>>> I don't know how the backend works, but my experience is that the
>>>>> "Opening
>>>>> balance" is basically a running total of all the transactions marked
>>>>> "Reconciled" in that account. Whereas QB will _prevent_ you from
>>>>> attempting
>>>>> to reconcile August if July's reconciled balance differs from what it
>>>>> previously reconciled, GNUCash doesn't care - it just says "The
>>>>> transactions marked 'Reconciled' for this account total to $X." And
>>>>> that's
>>>>> good for when you have to go back and fix things... and know what
>>> you're
>>>>> doing.
>>>>>
>>>>> When you reconcile a transaction, again based on my experience,
>>> GNUCash
>>>>> toggles the "Reconciled" flag on the account _and_ inserts the
>>>>> reconciliation date. I personally like this because I can, say,
>>> start a
>>>>> fresh reconciliation for March having reconciled through August to
>>> pick
>>>>> up
>>>>> the transactions that _should_ have been in the March reconciliation
>>> but
>>>>> weren't because I readded them (or whatever). However, I need my
>>>>> calculator with me because I need to adjust the "closing balance" to
>>>>> reflect not the statement balance but what GNUCash's "running total"
>>>>> balance should be. Contrast this to having to undo every rec in QB
>>> back
>>>>> to
>>>>> March and redo every rec again.
>>>>>
>>>>> Still, as I said, there's room for improvement in GNUCash:1) Since
>>> the
>>>>> rec
>>>>> date gets stored with the Rec flag, GNUCash can have a function that
>>>>> unreconciles every transaction before a given rec date. This would be
>>>>> analogous to QB's batch rec undo.
>>>>> 2) One should be able to rec from the ledger as QB lets you do - and
>>>>> prompt for a rec date. Yes it's dangerous, poor practice, etc., but
>>> the
>>>>> GNU
>>>>> philosophy is not to leash the user. If a user wants to sudo rm -rf /
>>>>> their
>>>>> installation, GNU warns them first, but ultimately lets them. User
>>> knows
>>>>> best. If you want your computer to dictate what you're allowed to do
>>>>> with
>>>>> it, that's what Apple's for.
>>>>>
>>>>> I hope that helps a bit
>>>>> _______________________________________________
>>>>> gnucash-user mailing list
>>>>> 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
>>>> 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 www.ihtfp.com
>>> Computer and Internet Security Consultant
>>>
>>>
>> _______________________________________________
>> gnucash-user mailing list
>> 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 www.ihtfp.com
> Computer and Internet Security Consultant
>
> _______________________________________________
> gnucash-user mailing list
> 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.
More information about the gnucash-user
mailing list