[GNC-dev] Further feedback

[Stephen M. Butler]

On 2/8/19 8:05 PM, Christopher Lam wrote:
>
> Well I've been schooled.
>
Mea Culpa.

This morning the in-house accountant gave me another lecture.  Seems
I've been using the term 'Journal Voucher' to be equivalent of GnC's
Transaction.  Just learned that JV is only for adjusting entries (such
as end-of-year cleanup, depreciation, etc) and the others are called
'Transaction' .  Could not obtain a name for the individual lines -- so
we'll use the GnC name of Split.

I should have been more technically precise in my terminology.

> Please refresh and try again.
>
I have your branch off in its own work area.  git pull complained that I
needed to specify the branch.  So ended up doing a git fetch -all. 
However, git describe seems to give me the same 3.4-85-g1dbec8566
identifier as before. 

How do I get a list of your branches so I can checkout the correct one?


> The headers should match the desired report *post* reconciliation.
>
> The transactions reported are: uncleared, cleared, and reconciliation
> whereby split-reconciliation-date = account's last-reconciliation-date.
>
> On 9/2/19 10:19 am, Steve Butler wrote:
>> Sorry for top posting.  Checked the transaction report items.  One is
>> Reconciled Date.   That date matches the bank statement date on which
>> it was reconciled.
>>
>> How does that report get that date per transaction if the field
>> doesn't exist?
>>
>> On Fri, Feb 8, 2019, 17:52 Christopher Lam <christopher.lck at gmail.com
>> <mailto:christopher.lck at gmail.com> wrote:
>>
>>     On 9/2/19 7:49 am, Stephen M. Butler wrote:
>>     > On 2/8/19 5:12 AM, Christopher Lam wrote:
>>     >> I've been experimenting and I think there's a logic error in your
>>     >> thinking -- *during* reconciliation, until it's complete, all
>>     >> 'reconciled' transactions are labelled 'cleared'. Reconciled
>>     >> transactions are, so to speak, gone and don't need to be shown
>>     on a
>>     >> reconciliation report.
>>     > The reconciliation report should run just after reconciliation has
>>     > finished.  Therefore, the just reconciled items will be marked as
>>     > reconciled.
>>
>>     I do agree in principle... however the internal logic of GnuCash
>>     dictates that there is no such thing as "just reconciled items".
>>
>>     Consider a very busy bank account needing regular
>>     reconciliation... on
>>     15-january you try reconcile but you've written and recorded a
>>     check for
>>     $53.50 on 20-december which is still not cleared. This $53.50 will
>>     remain unreconciled ("outstanding") causing a discrepancy of $53.50
>>     between your 15-January bank statement, and your book. You
>>     reconcile,
>>     skipping the $53.50 amount, and all's well.
>>
>>     On 15-february the bank statement arrives, and the $53.50 check has
>>     cleared on 19-january. The $53.50 status changes from
>>     (n)unreconciled to
>>     (c)cleared. Additionally all intermediate transactions are
>>     cleared. Your
>>     15-february bank statement now matches your books.
>>
>>     According to my suggestions above logic the $53.50 will be
>>     counted in
>>     the 'cleared' header, and be present in the reconciliation
>>     report. You
>>     will afterwards then complete the reconciliation, which converts all
>>     'c'leared to 'y'reconciled.
>>
>>     If we were to follow your logic, and if we run the reconciliation
>>     report
>>     on 15-february, and if we *aim* to look for the 'just-reconciled'
>>     items,
>>     we will definitely miss the $53.50 transaction dated 20-December
>>     because
>>     it's now reconciled/"archived". Remember the transactions do
>>     *NOT* have
>>     a 'reconciliation date' so we cannot look for them using a simple
>>     query.
>>     Only accounts have a last-reconciliation-date. We will *not* find
>>     them
>>     by querying 'reconciliation-date minus 1 day'.
>>
>>     Logically you're not wrong but GnuCash internal logic will
>>     dictate the
>>     above process must be followed.
>>

-- 
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