John,
I have to agree. Changing the date on the offending $150 transaction is
really just a workaround, not a fix. But the root cause seems to be
something wrong in the code that transfers the user-entered data (the
date and amount) from the Reconcile Info window to the Main Reconcile
window. Basically, the code logic when calculating the Ending Balance
for the Main Reconcile window seems to be something like this:
IF (TransDate = StatementDate) THEN (MainEndingBal = InfoEndingBal +
TransAmt)
I realize that's a very simplistic way of putting it; but that seems to
be how the logic is working for calculating what Ending Balance amount
ends up in the Main Reconcile window. Of course, then there's the weird
complication where changing the Info Ending Balance by a penny seems to
invalidate this simple If-Then formula. And it also doesn't explain why
other folks aren't able to reproduce the same problem on other systems.
Anyway, I'm more than happy to do additional testing or provide added
info if any wants to look into this further. If I don't hear back
though, I'll just go ahead and use the workaround, and move on.
Tom
On 08/05/2026 09:21 PM, John Ralls wrote:
Tom.
I’d say that date manipulation—changing the date of the added
transaction—works around the problem you’re reporting rather than
fixing anything unless you left out that you also advanced the date
passed to reconcile info (that’s the real name of the little dialog
that collects the reconcile date and ending balance before the main
reconcile window comes up) to 7/28: The 7/27 default ending balance
will be the $800 you want.
FWIW (and at this point I’m not sure it’s worth much) that’s not what
I meant about the date being irrelevant. I was referring to the
remarks about the date really being 7/26 because at 00:00:01 7/27 the
balance was still $800.
Regards,
John Ralls
On Aug 5, 2026, at 19:41, Tom Route36 <[email protected]> wrote:
Hi John,
I managed to get back to the system here tonight. I have some
important new info; but before I get into that let me go and provide
the Preference settings you asked for. Here they are:
=====
Reverse Balanced Accounts: Credit accounts
Reconciling: Check cleared transactions - checked
Reconciling: Automatic credit card payment - unchecked
Reconciling: Always reconcile to today - unchecked
Reconciling: Enable autoclear tools in reconciliation - unchecked
=====
Also, I can confirm that none of the splits are cleared. All of the
transactions that are part of this statement period / reconciliation
operation all still have 'n' in the Reconcile column.
Now, on to the new info. One of the things you said yesterday was
that the date stuff was irrelevant. But based on my additional
testing today, I'm going to have to disagree with you. It seems to
be a key factor here.
I first repeated the same test of reconciling with the 7/27 Statement
Date and the $800.00 Ending Balance using every conceivable sequence
of tabbing around and mousing around and hitting enter that I could
come up with. Nothing changed the result. The $800 entry in the
Reconcile popup window always ended up getting overwritten with the
$950 amount after hitting OK.
But then I made one change. In the register, I edited the offending
$150 transaction that had the 7/27 date. And I simply changed the
transaction date to 7/28 -- the day *after* the Statement Ending
Date. Then I did the Reconcile operation. And when I hit OK? Now
my $800 Ending Balance carried thru to the Funds In vs Funds Out
window as $800. Problem solved!
There may be some additional factors playing into this that's causing
the issue to only show up on this particular account on my system.
And I'm not really sure what those other factors might be. But the
key factor appears to be when you're doing a Reconcile operation on
an account in which there's a non-zero transaction in the register
with a date *equal* to the Statement Date that the user is entering
in the Reconcile popup window. When those conditions occur, that
seems to cause the user-entered Ending Balance to get overwritten.
At least, that's what appears to be happening on my system here.
I'm still not following thru with the reconciliation of this credit
card account just yet. I'm keep things as they are in case you'd
like me to run some additional tests or need other info first. Just
let me know what you need.
Tom
On 08/05/2026 10:58 AM, John Ralls wrote:
Tom,
No rush, respond when you have time and are with your machine.
That’s an interesting behavior that I still can’t reproduce, but
maybe I need to set up a test book with the right conditions to be
able to duplicate it exactly.
Please do provide the preferences you have set to help with
replication efforts.
Regards,
John Ralls
On Aug 5, 2026, at 01:24, Tom Route36 <[email protected]> wrote:
John,
A correction to my availability for testing. It's Wednesday
(today) that I won't have my test system. So if you have other
questions for me, I'll be back Thursday. Sorry for the confusion.
(It's been a really long day for me ... whatever day this is now.)
Tom
On 08/05/2026 01:57 AM, Tom Route36 wrote:
Hi John,
I can go and provide you with all the settings you asked about
here; but before I do that I have an important -- and weird --
update I think you might want to hear about first. Bear with me
while I explain step-by-step the additional testing I just did.
First, in this credit card account where I'm doing the testing, I
have deliberately *not* actually completed any reconciliation. So
all of the past month's transactions are all staying in their
un-reconciled state. All I'm doing is bringing up the Reconcile
popup window repeatedly and trying different dates and amounts
there to see what happens in the resulting Reconciliation summary
box after I click OK in the popup window. In other words, I'm
trying to maintain the same testing baseline.
Having said that, here's the exact routine that I'm following.
With the credit card account open, I click the Reconcile button at
the upper right corner of the GnuCash window. That opens the
Reconcile popup window. The Statement Date field has the 7/25
date. And the Ending Balance field, which is highlighted by the
current cursor position, shows the $800 amount. I click in the
Statement Date field to put the cursor there. And I tap the plus
key (+) on my numeric keypad twice to advance the date to 7/27.
As soon as I do that the $800 amount in the Ending Balance field
changes to $950.
Once the Ending Balance field changes to $950, I hit the Tab key
twice to move the cursor to the Ending Balance Field, which
highlights the $950 amount. Then I type in my correct Ending
Balance amount, which is the $800 amount from my credit card
statement. Then I use the mouse to click the OK button. That
closes the Reconcile popup window; and takes me to the Funds In
vs. Funds Out window where I see the Reconcile summary box in the
lower right corner. And that's where I see that the Ending
Balance in that summary box is $950 instead of the $800 that I
just entered previously.
Okay. So the above description is what I'm doing step-by-step.
Now, brace yourself for the weird part.
Like I said above, when I put $800 as the Ending Balance in that
popup window and click OK, the summary box then lists the Ending
Balance as $950. So my entry got overridden, just as I've been
reporting all along. So for my testing now, I decided to change
the value that I entered in that popup window -- still setting the
Statement Date to 7/27. For the Ending Balance I typed in
$799.99. And to my surprise, when I clicked the OK button, the
Reconcile summary box kept and displayed the Ending Balance as
$799.99, exactly as I entered it.
So since the Reconcile popup seemed to like one cent less than the
actual ending balance, I figured why not try one cent more? Next
go round in the popup window I entered $800.01. And once again,
when I clicked the OK button, the summary box kept and displayed
the Ending Balance as $800.01, again exactly as I entered it. No
more overriding of my entered values.
Problem solved?? Nope! I went back again to enter the proper
value of $800.00 exactly. And once again, when I clicked OK, the
summary box insisted on showing the $950 value again. Like I said
... weird!
I can still provide those other details if you think it will
help. But unfortunately, I'm going to be away from my test system
here all day Thursday. If there's any other info or testing you'd
like though, just let me know; and I'll try to get to it on Friday.
Tom
On 08/04/2026 09:59 PM, John Ralls wrote:
Tom,
Yes, all the date stuff is irrelevant. The problem you describe
is that the entry isn’t getting read before the dialog is closed
and the ending balance is copied to the reconcile window. This
seems closely related to
https://bugs.gnucash.org/show_bug.cgi?id=799650, which reported
that under some circumstances using the enter key to complete the
reconcile info dialog after editing the ending balance field
didn’t read the new value in that field. As Sherlock said he
fixed it a year ago.
Since none of us can reproduce the problem—and while nobody yet
has tried on Windows it’s pretty unlikely to be OS related—you
may have found a new corner case. Please record carefully, step
by step, exactly what you type and click to reproduce the behavior.
There are also some preferences that might be germane: What are
your settings for Reverse Balanced Accounts in the Accounts page
and all of the Reconcile options in the Register tab?
One more possible difference: Are any of the splits cleared (the
Reconcile column between the account and debit columns is ‘c’
instead ’n’?
Regards,
John Ralls
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
