Thanks for inquiring. I've hinted at top-level concepts and ideas in my
thread "reconciliation concept from top view"
https://lists.gnucash.org/pipermail/gnucash-devel/2020-April/044863.html
and in particular the relationship between a "shared truth" and the GnuCash
"reconciliation" process. I am
Dale,
While that was the main thrust of the thread, it is inevitable that it will
bring attention to other issues so no real dramas. The advent of electronic
clearing almost immediately and OFX direct connect connections to at least
some banks (mine won't cooperate) is also changing the game. An
Oops, I misunderstood the turn this thread took. My mistake.
I don't have any particular comments on an autofix to clean XML files with
inconsistent reconciliation dates and the current approach GnuCash has for
reconciliation.
My comments were for some future many months->years away in a later
Geert
> From an implementation point of view I'd structure this slightly
> differently:
> 1. instead of adding an account property with a list of reconciliation
> history, I would introduce a
> new object, like a "statement" This object would have the fields you
> mention before (date of
>
Thanks John for clarifying that.
My take on that situation is that the statement start date is TODAY. The
statement end date is TODAY and the reconciliation date for any included
transactions is TODAY. That is obviously consistent with the manual
reconciliation process.
David
-
David
Adrien,
I am referring specifically to setting the reconciliation date for the split
you are reconciling. When a transaction is created in GnuCash both the date
it was entered into Gnucash and the date it was posted are recorded in the
transaction data structure and file. Only the posted date is
Dale,
I was referring specifically to the dates the bank puts on transactions
included in the statement for a specific period but not necessarily the
dates that may have been recorded by a user in GnuCash. The latter of course
may be different and the reconciliation process deals with that.
I
David,
No, Gunter meant what he said. If the bank's response to a FinTS or OFX
DirectConnect
query includes a balance, GnuCash will pop a dialog telling you that and allow
you
to reconcile. If you reconcile it will skip the reconcile info dialog and open
the reconcile window with the statement
+1 on your idea of the statement as a separate object.
If a closing date is later realized to be erroneous, it only needs to be
corrected in one place, not every transaction involved. And I hazard the guess
that the UI that allows a user to edit a statement object data would be simpler
and
I concur.
It is not unusual for a transaction to be made in one period and clear in the
next, even in modern times. This is highly probable with issuing a paper check.
Lower date bounds are going to be a problem.
While I don’t think there is much case (though one user reported so) for a
As an attempt for clarity, I don't globally agree with what David wrote
"The dates in a statement will all fall between the end date of the last
statement +1 (the start date of the current statement) and the end date of
the current statement as the statement dates are inclusive."
I believe in the
hi Geert
The first was really about directConnect OFX imports, not something I am all
that familiar with since banks here won't allow us access. Another user in
the discussion around Bug 797668 which I initially raised had mentioned
direct reconciliation in the import of OFX directly from the
Thanks for this overview. It matches mostly with how I understand
reconciliation.
I will add a few comments in between.
Op zondag 12 april 2020 07:14:22 CEST schreef David Cousens:
> I don't see any problem with the reconcile status at present as implemented
> in the QIF, OFX imports or even
Op zaterdag 11 april 2020 05:27:48 CEST schreef D. via gnucash-
devel:
> I will also add in here that the developers have muddied the waters
on this
> whole situation with the decision to de-reconcile transactions when
the
> user edits it later-- even if the changes are not related to an
David,
Am 12.04.20 um 07:25 schrieb David Cousens:
> if the bank process fails or does not supply the necessary required
> information I guess you would mark it as unreconciled but that assumes the
> user is gong to be able to do a manual reconciliation.
If the bank reports valid transactions,
Frank
Agreed. The other difficulty is that there is no control over a bank's
particular implementation unless they are strictly adhering to a well
defined standard and even then some countries adopt different standards. It
is moot for me in any case since Australia's major banks don't allow
David T, Christopher, Dale et al
In accounting terms a reconciliation is always a confirmation of the details
of the splits to an account against some external record independent of the
particular set of books records are kept in. This is generally done in a set
of contiguous periods over which
Hi David,
I have not looked in the sources, but try a theoretical abstrakt:
If all transmitted transactions are cleared by the bank
and the bank statement contains a closing balance
and this closing balance is equal the current (at that date) account
balance, the section can be marked as
Hi David,
Am 11.04.20 um 05:27 schrieb D. via gnucash-devel:
> Looking this over, it seems to me that your goals could only be achieved by
> adding a statement date data element to each transaction, which would tie
> that transaction to a specific statement. This field would have much more
>
T.
Original Message
From: Christopher Lam
Sent: Sat Apr 11 03:41:01 GMT+05:30 2020
Cc: gnucash-devel
Subject: Re: [GNC-dev] About 3.9 and reconciliation balances
The "purpose" for the "fix" was to allow future features:
1. allow manual reconciliation
I was not aware that AQbanking does a reconcile on the fly. I also use OFX,
CSV nad very occasionally QIF imports (but not from Quicken) but not that
heavily any more. I think it would be useful to have this information about
the reconcile marking process documented at least in the importing
The "purpose" for the "fix" was to allow future features:
1. allow manual reconciliation of an account, using past reconciled_date
and relevant past ending_balance. If my "fix" were applied, it would serve
*me* very well:
(a) If an account, properly reconciled, had an errant split hiding
Yes JR and DA
Nothing bad or sinister, rather a future opportunity to virtually
whiteboard the concepts and events surrounding "reconciliation", then
reviewing what gnucash currently does to see the gaps.
It's comforting to see that it works for so many scenarios, and the
discussion on this was
Dale,
On Fri, April 10, 2020 12:37 pm, John Ralls wrote:
>
>
>> On Apr 10, 2020, at 8:22 AM, Dale Phurrough via gnucash-devel
>> wrote:
>>
>> This feels like a separation of accounting logic -- separate from
>> storage
>> field -- has broken down. From what you wrote, it seems each of these
>>
> On Apr 10, 2020, at 8:22 AM, Dale Phurrough via gnucash-devel
> wrote:
>
> This feels like a separation of accounting logic -- separate from storage
> field -- has broken down. From what you wrote, it seems each of these
> sources have direct access to core fields without any
Wow...this mix-match of reconcile date behaviors are good to log somewhere
as an design/architecture aberration/bug. Good for discussion on...
1. what *does* the concept of "reconciliation date" mean?
2. does that meaning change with the source of reconciliation/truth (qif,
quicken, AQBanking,
Some further findings. I don't think the "fix" needs to come back.
The reconciled_date field is not well defined in code
- during manual reconciliation (which I use heavily) it sets
reconciled_date to statement_date.
- during QIF import from Quicken, it can also set reconcile_status to
mirror
Christopher
My remaining concern is that fixing any incorrect reconciliation dates is at
this stage a manual procedure requiring the editing of the XML file (SQL
database users?). In addition it requires sufficient knowledge of the XML
file structure to be able to correctly identify which
T.
Original Message
From: Christopher Lam
Sent: Thu Apr 09 12:55:18 GMT+05:30 2020
Cc: gnucash-devel
Subject: Re: [GNC-dev] About 3.9 and reconciliation balances
Regarding reverting:
It is too difficult to create a UI to modify reconciled dates. Options to
fix this are:
1
I don’t see #1 as ‘forever’ but ‘until a better option can be crafted’.
#2 gives flexibility. To reduce confusion, should it be selected by default?
(only those who intentionally need to reconcile future dates are the users
who’ll have to grok it)
How viable is:
3b. Add this to the Check &
Op dinsdag 7 april 2020 18:37:25 CEST schreef Derek Atkins:
> Hi,
>
> On Tue, April 7, 2020 11:47 am, Dale Phurrough wrote:
> > Cool use of cleared/reconciled for expenses. I can follow that general
> > approach.
> > I do have an inquiry regarding the need for the future when reconciling.
> >
Regarding reverting:
It is too difficult to create a UI to modify reconciled dates. Options to
fix this are:
1. roll back this change and tolerate the invalid data. This means any
progress on that matter is hindered forever.
2. allow this change depending on a user-selectable book property "Use
Thank you David.
Further work for tighter safeguards is planned in
https://github.com/Gnucash/gnucash/pull/685 -- no scrubbing is currently on
the table but a warning during reconciliation if future splits are detected.
On Thu, 9 Apr 2020, 9:59 am David Cousens, wrote:
> I am now happy that
I am now happy that there is no problem with the starting balance calculation
in 3.9 and the problem was caused by a previously undetected finger problem
on my part and withdraw my previous qualms about retaining it for the
future.
I still think it is excessive to restrict the reconciliation
A previous reconciliation on 31/12/2018 had had the statement date entered as
31/12/20 rather than 31/12/2018 which causes the entered date to be read as
31/12/2020 into GnuCash. I checked the entered dates on all transactions
which had 2020-12-31 as the recociliation date verified these were all
Typical very old transaction that has had its reconciliation date altered but
not by reconciling the period it is from (The date the transacion originally
occurred and the weird date 202-12-31 and the reconciliation date for the
other split of the transaction are highlighted. Only transaction
Chris,
1. I am concerned that the "new method of calculating starting balances"
introduced in GnuCash 3.9 may have a problem. I am still tracking down
exactly what happened in my case. I do have a future reconciliation date on
some transactions that had previously been imported in V 3.8. A
Hi,
On Tue, April 7, 2020 11:47 am, Dale Phurrough wrote:
> Cool use of cleared/reconciled for expenses. I can follow that general
> approach.
> I do have an inquiry regarding the need for the future when reconciling.
> (What am I missing...or is there a gnucash feature I'm assuming exists
> that
Cool use of cleared/reconciled for expenses. I can follow that general
approach.
I do have an inquiry regarding the need for the future when reconciling.
(What am I missing...or is there a gnucash feature I'm assuming exists that
doesn't?) 樂
In my mind, I see two accounts
1) bank account, e.g.
Hi,
On Tue, April 7, 2020 10:21 am, Dale Phurrough via gnucash-devel wrote:
> 1.
> This time period of one month is arbitrary and my experience suggests this
> is a symptom of a hack, incomplete solution, or partial workaround. Both
> (a) allowing future/advance reconciliation -and- (b)
Hi. I do have feedback on the 3.10 change suggestions. Meanwhile, I'll not
comment on the feature change "3.9 comes with a new method for calculating
reconciliation starting balances". I defer to others on this list for that.
1.
This time period of one month is arbitrary and my experience
.
Original Message
From: Christopher Lam
Sent: Tue Apr 07 13:00:55 GMT+05:30 2020
To: gnucash-devel
Subject: [GNC-dev] About 3.9 and reconciliation balances
Release 3.9 comes with a new method for calculating reconciliation starting
balances.
Previously, the account reconciled
Release 3.9 comes with a new method for calculating reconciliation starting
balances.
Previously, the account reconciled balance was considered the starting
balance. This includes any splits previously reconciled with an invalid
(e.g. future) reconciliation statement date.
>From 3.9 onwards, the
43 matches
Mail list logo
