[GNC] editing reconciled transactions changes reconcile status

[Stephen M. Butler]

On 1/10/19 2:43 PM, Adrien Monteleone wrote:
> Thanks for the clarification Geert,
>
> I’m going to follow your approach and say, “Let’s take a step back.”
>
> What exactly is a bank statement telling you? What are they tracking in their books? Why do you need a statement at all?
>
> As I noted in a previous reply (though that example was decades ago) some banks don’t always have or include payee information for every transaction, even for written checks. (and some transactions are ATM withdrawals or other means of account interaction)
>
> I would say the bank is informing you that your balance changed from x to y over the period and the evidence are the individual transactions for specific amounts on specific dates.
>
> WHO the money was paid to, or in what form, and arguably even the transaction number assigned to it, are not relevant to the question of “Why did my balance change and by how much?”
>
> (I can see transaction numbers being useful to verify a specific transaction which may be duplicated in short order has specifically cleared the bank)
>
> Thus I would make the case that as payee (description) isn’t relevant to answering these questions, they are technically *not* part of the reconciliation process. They are extra information to assist with the process, but not crucial to it. You could reconcile a statement if the bank didn’t provide that info at all. (as noted, lack of transaction numbers might make this more questionable)
>
> But taking the opposite position still leaves a use case for not un-reconciling an edited description, and that is “spelling”. It is quite possible, a spelling error was made, not noticed upon entry, and not noticed upon reconciliation. (or even learned of until later) It might also be an incomplete or slightly incorrect name for the payee. Correcting this information does not ‘un-reconcile’ the transaction against the bank statement. Everything would still reconcile had this info been correct at the time of the reconciliation. And it is for that reason, by that test, I would make the case that #3, the description, should not unset the flag if changed.
>
> So the test to answer the question of what data unsets the flag should be in my opinion, “If this data was in its changed state at the time of the reconciliation, would the user still have been able to reconcile?” If the answer is yes, then the flag should be left alone. If the answer is no, then the flag should be unset. If the answer is “unsure” or “depends” then the flag should be unset.
>
> Regards,
> Adrien

My business account recently showed two different transactions with the
same check #.  Found out my partner had gone to the bank since they rand
out of checks.  They guessed at the "correct" next number.  Both
transactions were valid and the bank paid both out.  Now I have two
different transactions with the same check #.

Makes me wonder if check # (transaction #) is truly a reconciliation
requirement.

--Steve


>
>
>> On Jan 10, 2019, at 5:13 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>>
>> Op dinsdag 8 januari 2019 07:23:47 CET schreef Liz:
>>> I was going to say "irrelevant, I have all warnings set"
>>> but on checking I find that "change contents of reconciled split" was
>>> unset.
>>>
>>> However, there is no sane reason for changing the Payee or description
>>> of a reconciled split and unreconciling the transaction.
>>> Yes, it is an Asset account.
>> Let's take a step back.
>>
>> The idea behind the current reconcile behavior is that you check off the data 
>> you have in GnuCash against what's on the statement you receive from your 
>> bank. It follows that only data that's actually on your statement can be 
>> verified and hence only that data should be "protected" once a transaction is 
>> reconciled.
>>
>> This has been discussed a couple of months back and back then it was decided 
>> the following information is typically found on a statement to be protected:
>> 1. Transaction date
>> 2. Transaction number
>> 3. Transaction description
>> 4. Transaction amount (which translates in the split amount for the split in 
>> the account for which the statement is created).
>>
>> So these fields can be verified and are hence protected by reconciliation.
>>
>> I'll note past discussions on this topic seem to go in all directions. Some 
>> people believe more fields should be protected others believe some fields 
>> should not be.
>>
>> The above is the current state. I'm open to further discussion on this with a 
>> broader audience to get to something that's more generally accepted.
>>
>> Regards,
>>
>> Geert
>>
>>
>> _______________________________________________
>> 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.


-- 
Stephen M Butler, PMP, PSM
Stephen.M.Butler51 at gmail.com
kg7je at arrl.net
253-350-0166
-------------------------------------------
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8