[GNC-dev] About 3.9 and reconciliation balances

[Dale Phurrough]

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. Bank of America Checking
2) the expenses, for simplicity lets put them all into a single
"Reimbursable Expenses" account

As I think through this, I would hope you can following a workflow similar
the following:
1. Enter multiple transactions into "Reimbursable Expenses" account for all
such expenses
2. Submit expense reports and mark those expenses in "Reimbursable
Expenses" account as cleared
3. Wait for check
4. Receive reimbursement check on 1 May 2020
5. On 2 May 2020, use GnuCash to reconcile the "Reimbursable Expenses"
account
6. Mark the splits in the "Reimbursable Expenses" that are included with
this reimbursement check as reconciled. The reconcile date on those
specific splits will be 2 May 2020.
7. Now the "Reimbursable Expenses" account is reconciled.
8. On 4 May 2020, deposit the reimbursement check.
9. On 8 May 2020, you see that check's cash was deposited into your bank
account. You mark the credit split in the "Bank of America Checking"
account as cleared.
10. On 2 *June* 2020, you use your May bank account statement to reconcile
the "Bank of America Checking" account
11. You mark the splits in "Bank of America Checking" account that match
those in the bank statement as reconciled.  The reconcile date on those
specific splits will be 2 *June* 2020
12. Now the " Bank of America Checking" account is reconciled.

In the above workflow, there is no future-reconcile handling needed.
Reconciling the expenses is separate form reconciling the bank account.
Reconciles always happen now or in the past.

--Dale

On Tue, Apr 7, 2020 at 4:37 PM Derek Atkins <derek at ihtfp.com> wrote:

> 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) disallowing
> something
> > "too far ahead" is again arbitrary and is forcing an arbitrary accounting
> > policy rather than conservative double-book rules and math.
> > Features with rules which are defined by the computer clock
> > are troublesome. It makes sense when one needs to transfer money via an
> > online API. It doesn't make sense when one is doing core accounting
> tasks.
> > Also this seems (in my shallow understanding of the 3.9 change) to not
> > work
> > with that 3.9 change. How could someone future reconcile if future-date
> > splits wouldn't be valid with respect to the future-target-reconcile
> > balance? This suggests a cascade of more workarounds.
>
> I will comment on this, because this came directly from a conversation
> that Chris and I had.  Chris originally wanted to ensure that reconciles
> could never happen in the future *at all*.  I.e., it would not allow you
> to future-reconcile.
>
> I said that I do often future-reconcile.  My use-case is that I keep track
> of my reimbursable expenses using cleared/reconciled flags to denote that
> I expensed them (cleared), and the expense was reimburned (reconciled).
> So when I file my expense report I mark those items as cleared.  Then when
> the reimbursement check comes in, I reconcile down to $0.  My issue is
> that I want to do this (enter the reimbursement check and reconcile) on
> the day I receive the check, however the check only gets deposited the
> next day, so I need to be able to reconcile 1-2 days into the future.
>
> When I proposed this use-case to Chris, he suggested a month leeway, and I
> didn't push back saying "that is too much."
>
> If you have an ACTUAL use-case of future-reconciling I would like to hear
> it, because this is the only future-reconcile use case I have come across.
>  Everything else in my experience is reconciling in the past.
>
> > 2.
> > I highly discourage altering any data without explicit disclosure and
> > acceptance of each change occurrence. This is not in alignment with the
> > ideas of data integrity, data persistence, trust and disclosure, etc.
> > Also a similar arbitrary accounting policy with the suggested date>1month
> > logic and 1/1/1970.
>
> GnuCash already has several places where is will correct (read: alter)
> data entries on the fly, when it Scrubs the accounts.  It does this with
> bad strings and invalid dates, among other corrections.  It will already
> do these corrections silently when the data file is loaded.  Having said
> that, it probably still makes sense to pop up a dialog to warn the user if
> it finds this kind of "invalid" data.
>
> > --Dale
>
> -derek
> --
>        Derek Atkins                 617-623-3745
>        derek at ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
>
>