Re: [GNC] GnuCash 3.7 and Portfolio Report

[Ed Boivin]

Yup – that worked. Thanks John!

The actual path on Windows is C:\Program Files 
(x86)\gnucash\share\gnucash\scm\gnucash\report\standard-reports

Ed
From: John Ralls
Sent: Wednesday, October 2, 2019 8:41 PM
To: Ed Boivin
Cc: Ed Fields; Gnucash 
Users
Subject: Re: [GNC] GnuCash 3.7 and Portfolio Report


> On Oct 2, 2019, at 10:54 AM, Ed Boivin  wrote:
>
> I'm another Ed and am experiencing the same issue with the Investment 
> Portfolio report. Was working fine until the upgrade to V3.7.
>
> Here is what is in my trace file after trying to run the report:
> In procedure module-lookup: Unbound variable: report-currency
> * 13:35:47  WARN  [gnc_numeric_to_decimal()] Rounding required when 
> 'never round' specified.
> * 13:44:52  WARN  Could not locate file AUTHORS
> * 13:44:52  WARN  Could not locate file DOCUMENTERS
> * 13:44:52  WARN  Could not locate file LICENSE
> * 13:51:28  WARN14 (apply-smob/1 # e3cd160>)
> In c-interface.scm:
>  22:4 13 (gnc:call-with-error-handling _ _)
> In ice-9/boot-9.scm:
> 829:9 12 (catch #t # …)
> In c-interface.scm:
> 27:37 11 (_)
> In unknown file:
>   10 (eval-string "(gnc:report-run 10)" #)
> In ice-9/boot-9.scm:
>2312:4  9 (save-module-excursion #)
> In ice-9/eval-string.scm:
>  38:6  8 (read-and-eval # #:lang _)
> In report.scm:
> 776:4  7 (gnc:report-run _)
> In c-interface.scm:
> 64:23  6 (gnc:backtrace-if-exception _ . _)
>  22:4  5 (gnc:call-with-error-handling _ _)
> In ice-9/boot-9.scm:
> 829:9  4 (catch #t # …)
> In c-interface.scm:
> 26:40  3 (_)
> In report.scm:
>780:24  2 (_)
>756:25  1 (gnc:report-render-html #< type: 4a6b82e8678c4…> …)
> In portfolio.scm:
>198:32  0 (portfolio-renderer #< type: 4a6b82e8678c4f3d9e…>)
>
> In procedure module-lookup: Unbound variable: report-currency
>
> Any help is appreciated!
>
> Thanks,
> Ed (the other one)

Chris Lam explained that and offered a fix a week ago:


> On Sep 24, 2019, at 8:03 AM, Christopher Lam  
> wrote:
>
> There's an error in portfolio.scm -- modify the 'report-currency' to
> 'currency' and it should be fine
>
> modified   gnucash/report/standard-reports/portfolio.scm
> @@ -196,7 +196,7 @@
> (if (not (null? accounts))
> (let* ((commodity-list (gnc:accounts-get-commodities
> (gnc:accounts-and-all-descendants accounts)
> -report-currency))
> +currency))
>(pricedb (gnc-pricedb-get-db (gnc-get-current-book)))
>(exchange-fn (gnc:case-exchange-fn price-source currency to-date))
>


That part of GnuCash is interpreted so you can apply the fix (which is to 
replace "report-currency" with "currency" on line 199 of 
XXX/share/gnucash/scm/gnucash/reports/standard-reports/portfolio.scm. The XXX 
at the front is the install prefix for GnuCash: On Linux it's either /usr or 
/opt, on Windows by default it's C:/Program Files (x86)/gnucash/, and on MacOS 
the default is /Applications/Gnucash.app/Contents/Resources.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] GnuCash 3.7 and Portfolio Report

[John Ralls]

> On Oct 2, 2019, at 10:54 AM, Ed Boivin  wrote:
> 
> I'm another Ed and am experiencing the same issue with the Investment 
> Portfolio report. Was working fine until the upgrade to V3.7.
> 
> Here is what is in my trace file after trying to run the report:
> In procedure module-lookup: Unbound variable: report-currency
> * 13:35:47  WARN  [gnc_numeric_to_decimal()] Rounding required when 
> 'never round' specified.
> * 13:44:52  WARN  Could not locate file AUTHORS
> * 13:44:52  WARN  Could not locate file DOCUMENTERS
> * 13:44:52  WARN  Could not locate file LICENSE
> * 13:51:28  WARN14 (apply-smob/1 # e3cd160>)
> In c-interface.scm:
>  22:4 13 (gnc:call-with-error-handling _ _)
> In ice-9/boot-9.scm:
> 829:9 12 (catch #t # …)
> In c-interface.scm:
> 27:37 11 (_)
> In unknown file:
>   10 (eval-string "(gnc:report-run 10)" #)
> In ice-9/boot-9.scm:
>2312:4  9 (save-module-excursion #)
> In ice-9/eval-string.scm:
>  38:6  8 (read-and-eval # #:lang _)
> In report.scm:
> 776:4  7 (gnc:report-run _)
> In c-interface.scm:
> 64:23  6 (gnc:backtrace-if-exception _ . _)
>  22:4  5 (gnc:call-with-error-handling _ _)
> In ice-9/boot-9.scm:
> 829:9  4 (catch #t # …)
> In c-interface.scm:
> 26:40  3 (_)
> In report.scm:
>780:24  2 (_)
>756:25  1 (gnc:report-render-html #< type: 4a6b82e8678c4…> …)
> In portfolio.scm:
>198:32  0 (portfolio-renderer #< type: 4a6b82e8678c4f3d9e…>)
> 
> In procedure module-lookup: Unbound variable: report-currency
> 
> Any help is appreciated!
> 
> Thanks,
> Ed (the other one)

Chris Lam explained that and offered a fix a week ago:


> On Sep 24, 2019, at 8:03 AM, Christopher Lam  
> wrote:
> 
> There's an error in portfolio.scm -- modify the 'report-currency' to
> 'currency' and it should be fine
> 
> modified   gnucash/report/standard-reports/portfolio.scm
> @@ -196,7 +196,7 @@
> (if (not (null? accounts))
> (let* ((commodity-list (gnc:accounts-get-commodities
> (gnc:accounts-and-all-descendants accounts)
> -report-currency))
> +currency))
>(pricedb (gnc-pricedb-get-db (gnc-get-current-book)))
>(exchange-fn (gnc:case-exchange-fn price-source currency to-date))
> 


That part of GnuCash is interpreted so you can apply the fix (which is to 
replace "report-currency" with "currency" on line 199 of 
XXX/share/gnucash/scm/gnucash/reports/standard-reports/portfolio.scm. The XXX 
at the front is the install prefix for GnuCash: On Linux it's either /usr or 
/opt, on Windows by default it's C:/Program Files (x86)/gnucash/, and on MacOS 
the default is /Applications/Gnucash.app/Contents/Resources.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] GnuCash 3.7 and Portfolio Report

[Ed Boivin]

I'm another Ed and am experiencing the same issue with the Investment Portfolio 
report. Was working fine until the upgrade to V3.7.

Here is what is in my trace file after trying to run the report:
In procedure module-lookup: Unbound variable: report-currency
* 13:35:47  WARN  [gnc_numeric_to_decimal()] Rounding required when 'never 
round' specified.
* 13:44:52  WARN  Could not locate file AUTHORS
* 13:44:52  WARN  Could not locate file DOCUMENTERS
* 13:44:52  WARN  Could not locate file LICENSE
* 13:51:28  WARN14 (apply-smob/1 #)
In c-interface.scm:
 22:4 13 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9 12 (catch #t # …)
In c-interface.scm:
27:37 11 (_)
In unknown file:
  10 (eval-string "(gnc:report-run 10)" #)
In ice-9/boot-9.scm:
   2312:4  9 (save-module-excursion #)
In ice-9/eval-string.scm:
 38:6  8 (read-and-eval # #:lang _)
In report.scm:
776:4  7 (gnc:report-run _)
In c-interface.scm:
64:23  6 (gnc:backtrace-if-exception _ . _)
 22:4  5 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9  4 (catch #t # …)
In c-interface.scm:
26:40  3 (_)
In report.scm:
   780:24  2 (_)
   756:25  1 (gnc:report-render-html #< type: 4a6b82e8678c4…> …)
In portfolio.scm:
   198:32  0 (portfolio-renderer #< type: 4a6b82e8678c4f3d9e…>)

In procedure module-lookup: Unbound variable: report-currency

Any help is appreciated!

Thanks,
Ed (the other one)

From: John Ralls 
Sent: October 1, 2019 11:24 PM
To: Ed Fields 
Cc: Gnucash Users 
Subject: Re: [GNC] GnuCash 3.7 and Portfolio Report

You don't need perl unless you want to retrieve stock prices or currency 
exchange rates. It doesn't have anything to do with anything else.

The next two errors are unusual, but they also relate to setting up online 
quote retrieval and don't have anything to do with the report failing.

Was there anything more in the log after the gnc:call-with-error-handling line?

Regards,
John Ralls




> On Oct 1, 2019, at 2:50 PM, Ed Fields  wrote:
>
> checked the trace file,
>
> * 17:12:27  WARN  Could not spawn perl: Failed to execute
> child process (Bad file descriptor)
> * 17:12:27 ERROR  gnc_process_get_fd: assertion 'proc' failed
> * 17:12:27 ERROR  gnc_detach_process: assertion 'proc &&
> proc->pid' failed
> * 17:13:14  WARN14 (apply-smob/1 # df2e170>)
> In c-interface.scm:
> 22:4 13 (gnc:call-with-error-handling _ _)
>
> do I need to reinstall perl?
> if so which version is needed for Windows 10?
>
> thanks for your patience
> ed
>
>
> On Tue, Oct 1, 2019 at 5:31 PM Ed Fields  wrote:
>
>> Creating a portfolio report seems doesn't seem to work
>>
>> after selecting Reports / Assets and Liabilities / Investment Portfolio I
>> am presented with
>>
>> Report error
>> 
>> An error occurred while running the report.
>>
>> ordinarily I would expect to asked to set up the report
>> -
>>
>> I pressed on via selection of Edit / Report Options and selected an
>> investment account.  Then performed a reload.  Same error is displayed.
>>
>> This feature is sorely missed with v3.7, worked fine  before upgrade.
>> Please help
>>
>> thanks
>> ed
>>
>>
> ___
> gnucash-user mailing list
> gnucash-user@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@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.

Re: [GNC] Please suggest approach to track a category of disbursements

[Adrien Monteleone]

Sorry, my comment skipped over option 1. My point was, I think that was the 
correct method:

Dr. Taxable Fund$80
Dr. Exp:Tax $20
Cr. IRA $100

Could you describe in more detail what info you want to see? That is, are there 
certain totals or balances you want to track?

What you are doing above can show you how much went from one account (the IRA) 
to another account. (or multiple accounts)

This can be done with a Transaction Report or a Cash Flow Report. (which is 
misnamed, but does this particular job)

Since you mentioned tracking 20+ taxable funds, David and I mentioned possibly 
creating a single placeholder account and then put those individual funds as 
their own accounts as children of the placeholder —e.g.,

Assets:Investments:Taxable Funds
Assets:Investments:Taxable Funds:Fund A
Assets:Investments:Taxable Funds:Fund B
Assets:Investments:Taxable Funds:Fund C
Assets:Investments:Taxable Funds:Fund etc.

If you and your wife both invest in the same fund individually and you want to 
track that separately, you could ’tag’ each transaction with your names 
somewhere and filter reports based on that info. (see below) You could also 
create an intermediary placeholder for you and your wife, but I don’t think 
that is necessary and might get messy. But do what works for you. You might 
even leave out the ’Taxable Funds’ example above and just put the individual 
funds under ‘Investments’.

This would allow you to see all of the accounts aggregated if you wanted in a 
report, (or the CoA tab) or individually as desired. (or any mix of them since 
you can select individual accounts for a report)

The Transaction Report is likely the better vehicle here because it allows for 
filtering against accounts as well as filtering on info such as Description, 
Notes, or Memos of individual splits. This way, you could enter more detailed 
info there and run a report to see totals/balances based on that info. (what 
that info might be is up to you)

Get a handle on how you want to structure your account tree to track all of 
these funds, and then try a Transaction Report including only those accounts. 
Play with the options a bit to see how they work. Then feel free to come back 
with more questions on tweaking that. I too found the Report documentation a 
bit rough at first. I learned the most by running the reports and tweaking 
options.

Regards,
Adrien



> On Oct 2, 2019 w40d275, at 9:40 AM,  
>  wrote:
> 
> Adrien, thanks for responding. I hope I have some misconceptions that can be 
> easily rectified but a belief in a limited number of splits isn’t one of them.
> 
> In order for my notional “Disbursements” account to work the full 
> disbursement before taxes must be debited fully in Disbursements pre-tax in a 
> single transaction (or so I believe). Once it’s there, I have no choice but 
> to do the tax split from Disbursements (again, so I believe) in a second 
> transaction. Those two transactions then led me to the abstraction, 
> confusion, and self-zeroing problems I mentioned in the OP.
> 
> I’m not sure what you mean about making child accounts under disbursements - 
> Exp:Income Tax is already an account.
> 
> If I have misunderstood you, please tell me.
> 


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Adrien Monteleone]

I agree, that is a bug, and it is already filed! (there are several I can see 
which probably need to be marked as dupes)

I don’t think there has been a resolution on it or comment on them in some 
time, however. One bug (and associated thread) covered discussion of which 
fields should be protected.

I think the original case was changing a misspelling of a description.

Regards,
Adrien

> On Oct 2, 2019 w40d275, at 9:27 AM, Derek Atkins  wrote:
> 
> * I think it's a bug that modifying the Txn Desc unreconciled a
>  transaction.  That should not have affected it in any way.  Sure,
>  modifying the amounts should have caused a change, but description??
> 

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Adrien Monteleone]

No it does not exist.

Let’s consider this:

You are just starting out with GnuCash.
You are entering historical data.
You keep getting the warning.
You get fed up and dismiss it, intending to turn it back on later.
You forget to turn it back on.
Months later, you accidentally (as noted, hard to do) enter a transaction as 
really old.

The warning never fires...


Regards,
Adrien

> On Oct 2, 2019 w40d275, at 6:22 AM, Arman Schwarz  
> wrote:
> 
> All the issues I've highlighted really boil down to inserting transactions
> before already reconciled ones, so if we could prevent that it might make
> my concern moot.
> 
> So perhaps an easier route from a software design perspective would be just
> adding a warn dialog whenever you try to insert a transaction that comes
> before any reconciled transactions. You could also warn if the user tries
> to perform a reconciliation that leaves reonciled transactions _after_
> unreconciled transactions.
> 
> If you try to insert a transaction before a reconciled transaction, valid
> responses could be;
> 1) Go ahead anyway
> 2) Go ahead, but un-reconcile all transactions after the inserted
> transaction
> 3) Cancel, never warn again, etc.
> 
> Actually before I emberass myself here - does this already exist?


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Adrien Monteleone]

Also, how would GnuCash know you weren’t trying to correct a previously hasty 
reconciliation?

At best, perhaps a no-value transaction can be entered in the account register 
indicating that the balance listed was reconciled at that date. (and time 
perhaps)

I’m not sure what the other account should be or if it can even be the same 
account.

One could do this manually now, but maybe the reconciliation process could do 
it automatically. The user could elect to hide these if desired with a view 
filter.

These asserted balance entries should not be editable except by re-reconciling, 
but since that isn’t currently done by specific period, I’m not sure how that 
would work either.

Regards,
Adrien

> On Oct 2, 2019 w40d275, at 6:06 AM, Christopher Lam 
>  wrote:
> 
> FWIW I do think it's a nice feature to have.
> 
> It's not terribly difficult to implement either. Allow user to add a
> special entry with some metadata stating the balance should be X dollars,
> and if the user tries to input a transaction which will fail the balance
> assertion, pops a warning "Error - this transaction cannot be entered
> because it will invalidate balance on d/m/y which should be $amount.".
> 
> As always the devil is in the details: this will be a brand-new error
> condition that only triggers upon user input. Should this trigger when user
> imports transactions via CSV/OFX/QIF? What about with custom scripts
> whereby a book has been modified but the balance assertions are no longer
> valid? What about a book modified externally whereby the assertions now
> fail? Should GnuCash fail to open the book because it's now "invalid"?
> Should there be a framework/central mechanism to capture all these sanity
> checks?
> 
> It's really difficult. Software development is hard. For that matter I
> don't think any current developer has found this issue particularly high
> priority, so, it has never been done.
> 


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Adrien Monteleone]

> On Oct 2, 2019 w40d275, at 5:39 AM, Arman Schwarz  
> wrote:
> 
> Sorry for the wordy reply. The TLDR; I think we're on the same page that
> Balance Assertions are a "nice to have" but I feel I haven't really
> articulated the scenario/s that I think make this feature quite important,
> hence why I'm replying again.
> 
>> For example, if I enter a
>> transaction from July 10, 2019 with the incorrect date of July 10,
>> 2010,
> 
> This has actually happened to me before, where I'm backfilling some
> statements and I get the years mixed up, but you could imagine it might
> happen also if I'm punching in years on a number pad and write the wrong
> value, or if the user is prone to mixing up numbers (also very common).
> 
> Now imagine that at the time of this error reconciliation has been done for
> all months up to June 2019. 9 years worth of balances are now wrong, and
> GnuCash will quite happily ignore the fact that I've told it on multiple
> occassions what the balances should be at various dates (hence the missing
> feature of balance assertions that you should "get for free" with every
> reconciliation should you want it).

What ‘balances’ do you suppose are wrong?

The previous reconciliations were allegedly correct, else they should not have 
been completed in the first place. They involved matching paper (or pdf) 
statements to GnuCash. Either that matching was successful at the time it was 
done (each month for 9 years) or it wasn’t. Entering a transaction for 2010 in 
2019 when it should have been 2019, doesn’t magically make all of those 108 
reconciliations somehow flawed or ‘off’. You just end up with an unreconciled 
transaction dated 9 years ago. Yes, your running balance will be off by that 
amount, going back 9 years, but you’ll eventually catch this, at the very 
latest, when you do the next reconciliation and you see it at the top of the 
window to be cleared.


> 
> I think the premise of your responses is that I should now do a
> reconciliation to find this issue.

That should catch the error, sure. You might first notice it however looking at 
the running balance and noticing it doesn’t match what it should at some point 
in the past.

> 
>> WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t
> appear on *this month’s* statement?
> 
> (Remember that the transaction will appear on my reconciliation as well as
> my statement, it's just that the date will be wrong, but I'll try to
> respond to the core of the question - why would I sign off on something
> that's wrong?)

And you should notice that date is wrong. Checking dates is part of 
reconciliation. If you aren’t checking dates, you aren’t reconciling correctly. 
This is now starting to sound like you want the software to take over the 
manual process of auditing itself against another set of records. That is 
entirely the point of reconciliation - *manually* verifying the data, 
meticulously.

> 
> Firstly I'd say that I shouldn't have to, as GnuCash has at this point been
> given all the information it would need to point out to the user that there
> is a discrepency (via the many statement balances I would have given it to
> do the reconciliations up to this point).

GnuCash can’t presume you really didn’t need to enter that transaction in 2010 
and then re-reconcile it. Otherwise, the software would prevent any historical 
editing. Certainly there is a case for that, and some people would prefer it 
lock the past, but that isn’t what the devs want for the software.

> Secondly, most of the time I think you're right in that I would catch this
> issue in a reconciliation but I might not becuse:
> 
> - Many human errors are not random, but symptomatic of a cognitive bias.
> For example, I might mix up 9s and 0s, causing me to type "2010" instead of
> "2019". This would make me prone to missing this problem in reconiliation,
> or
> - I might be in a rush or might only check the balances. I might just
> _happen_ not to check the year because I've been staring at dates all day
> and I'm starting to get a bit frazzled.

Software can’t fix you. Only you can fix you. You shouldn’t do the 
reconciliation till you have time not to rush it. The software won’t explode if 
you don’t reconcile by a certain date.

> 
> Remember, I've already made the mistake by inputting the data incorrectly.
> There's a good chance I'm confused about the dates at this point, so the
> likelihood I'm going to stuff it up at reconciliation is larger than it
> would be for other transactions. In the above example I got the balance,
> day and month right, so there's literally only a single digit off!
> 
> But the worst part about this scenario is that there is no mechanism to
> catch this down the road. If I make a mistake on the date in
> reconciliation, that's it, it's there forever. Future balances will be
> correct because only the date is wrong, and I'm now stuck with this mistake
> forever, and can't know about it even though I've 

Re: [GNC] How can I add statement balances to my accounts as checks?

[David Carlson]

I do not recall the exact scenario but I believe that the other day in
release 2.6.19, while I was in a  credit card account register I changed
the amount assigned to a bank account which was already reconciled from
that bank account to a different bank account without unreconciling that
transaction line.  If I figure out how  I did that, I will ask if it can be
replicated in release 3.7.

David Carlson

On Wed, Oct 2, 2019 at 9:32 AM Derek Atkins  wrote:

> Arman Schwarz  writes:
>
> > Another complimentary feature might be to restrict the date range of
> > reconciliations - if I'm reconciling a July 2019 statement against my
> > accounts, why should I be given the option of using a July 1010
> transaction
> > to reconcile against? Maybe I should be able to specify the date range of
> > the statemetn I'm reconciling against?
>
> There may be a significant delay between when you initiate a transfer
> and when it clears the bank.  For example, some checks that I write (or
> get written on my behalf) only clear 60-90 days later.
>
> You're right that 10-year-old transactions are probably wrong.
>
> ON THE OTHER HAND, if you do wind up forcing un-reconciliation on a
> transaction (this happened to be the other day when I fixed a typo in
> the description of a transaction!*) then you *DO* need to re-reconcile it
> the next time around.
>
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> -derek
>
> * I think it's a bug that modifying the Txn Desc unreconciled a
>   transaction.  That should not have affected it in any way.  Sure,
>   modifying the amounts should have caused a change, but description??
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
> ___
> gnucash-user mailing list
> gnucash-user@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.
>


-- 
David Carlson
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] gnucash-user Digest, Vol 199, Issue 3

[ornd25]

Adrien, thanks for responding. I hope I have some misconceptions that can be 
easily rectified but a belief in a limited number of splits isn’t one of them.

In order for my notional “Disbursements” account to work the full disbursement 
before taxes must be debited fully in Disbursements pre-tax in a single 
transaction (or so I believe). Once it’s there, I have no choice but to do the 
tax split from Disbursements (again, so I believe) in a second transaction. 
Those two transactions then led me to the abstraction, confusion, and 
self-zeroing problems I mentioned in the OP.

I’m not sure what you mean about making child accounts under disbursements - 
Exp:Income Tax is already an account.

If I have misunderstood you, please tell me.

> I?m sure there are various methods but you can change IRA distributions to be 
> a parent account. Then make the necessary sub-accounts for the various 
> distributions.
>
> You can report on only the total distributions or the individual ones as 
> needed.
>
> You also don?t need to make a transaction include only 2 accounts. You can 
> have as many splits as you like.
>
> It looks like you?re adding layers and accounts simply by following a 2-split 
> per transaction artificial limitation. (which does not exist in GnuCash)
>
> That withholding split can be a part of the original transaction.
>
> Regards,
> Adrien
>
>> On Oct 1, 2019 w40d274, at 11:49 AM,  
>>  wrote:
>>
>> I would like to track IRA disbursements. (For those who don't know, an 
>> Individual Retirement Account is a US category of retirement investments in 
>> which taxes are not paid until the funds are withdrawn, i.e., "disbursed." 
>> In our case and these are disbursements from an IRA mutual fund and will be 
>> re-invested in a taxable mutual fund.
>>
>> 1. I'm currently using the simplest way - Cr losing IRA mutual fund $100, Dr 
>> gaining taxable fund $80, Dr withholding tax $20. I keep track of where the 
>> various distributions are by using the term "Distributions" in the GnuCash 
>> Description block. That way I can easily find them.
>>
>> 2. I tried setting up an "IRA Distributions" account but I found it 
>> unsatisfactory for various reasons, at least the way I set it up. It require 
>> two transactions instead of one. First, Cr losing IRA fund $100 and Dr IRA 
>> Distributions. Then, from the "IRA Distributions" account, Dr "IRA 
>> Distributions" $100, Cr "Withholding tax" $20, and Dr gaining taxable 
>> account $80.
>>
>> I had two problems I had with the second approach before I returned to the 
>> simple approach. It abstracted the re-investment and the withholding tax 
>> from the actual distribution and I found it confusing, even after I created 
>> it. Also, the "IRA Distributions" account was self-zeroing, as my debits and 
>> credits were equal - I was hoping for an approach that would clearly show my 
>> distributions over time.
>>
>> Between my wife's accounts and mine - different flavors of tax-benefitted 
>> and taxable accounts - I'm tracking 20+ accounts and I would like some 
>> suggestions as to a simple, clear way to do it.
>>

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Please suggest approach to track a category of disbursements

[ornd25]

> I would use placeholder accounts under some sort of Assets:Investments top
> level structure to record funds whose tax treatments was different.  You
> could use the description/memo fields to cross reference funds transferred
> between the different categories of investment as you suggest with a
> searchable keyword.  Using an intermediate account really doesn't add
> anything unless the taxation on exit status could be maintained for those
> funds on reinvestment. A transaction report where you specify the
> placeholder and subaccounts for your IRA accounts in the Accounts tab and
> also specify displaying the transfer account, sorted on transfer account,
> date etc should give you a record of the transactions to and from the IRA
> fund account(s). It can be saved as a custom  user report for reuse and
> exported and modified further as required.
>
> David Cousens
>
David, thanks, some of your comments were a little over my head, but I think I 
understand that you don’t believe I can accomplish what I want with an account 
- I have about come to that conclusion myself - and I should approach the 
problem with a Transaction Report. Unfortunately, when I reviewed the Help 
Manual on Reports I found it to be really heavy going. Is there somewhere I can 
read beginner-level Report documentation?

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Derek Atkins]

Arman Schwarz  writes:

> Another complimentary feature might be to restrict the date range of
> reconciliations - if I'm reconciling a July 2019 statement against my
> accounts, why should I be given the option of using a July 1010 transaction
> to reconcile against? Maybe I should be able to specify the date range of
> the statemetn I'm reconciling against?

There may be a significant delay between when you initiate a transfer
and when it clears the bank.  For example, some checks that I write (or
get written on my behalf) only clear 60-90 days later.

You're right that 10-year-old transactions are probably wrong.

ON THE OTHER HAND, if you do wind up forcing un-reconciliation on a
transaction (this happened to be the other day when I fixed a typo in
the description of a transaction!*) then you *DO* need to re-reconcile it
the next time around.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

* I think it's a bug that modifying the Txn Desc unreconciled a
  transaction.  That should not have affected it in any way.  Sure,
  modifying the amounts should have caused a change, but description??

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[David Carlson]

There is another scenario where the 'balance assertion' could be useful.  I
sometimes import credit card transactions that accidentally include
payments erroneously credited from the wrong bank account.  Then I wonder
why the bank account is suddenly out of balance.

I have been entering zero-valued transactions for years to accomplish the
'balance assertion' function, usually on the statement dates for some asset
or credit card accounts.

On Wed, Oct 2, 2019 at 6:32 AM Arman Schwarz  wrote:

> Another complimentary feature might be to restrict the date range of
> reconciliations - if I'm reconciling a July 2019 statement against my
> accounts, why should I be given the option of using a July 1010 transaction
> to reconcile against? Maybe I should be able to specify the date range of
> the statemetn I'm reconciling against?
>
> On Wed, 2 Oct 2019 at 21:22, Arman Schwarz  wrote:
>
> > All the issues I've highlighted really boil down to inserting
> transactions
> > before already reconciled ones, so if we could prevent that it might make
> > my concern moot.
> >
> > So perhaps an easier route from a software design perspective would be
> > just adding a warn dialog whenever you try to insert a transaction that
> > comes before any reconciled transactions. You could also warn if the user
> > tries to perform a reconciliation that leaves reonciled transactions
> > _after_ unreconciled transactions.
> >
> > If you try to insert a transaction before a reconciled transaction, valid
> > responses could be;
> > 1) Go ahead anyway
> > 2) Go ahead, but un-reconcile all transactions after the inserted
> > transaction
> > 3) Cancel, never warn again, etc.
> >
> > Actually before I emberass myself here - does this already exist?
> >
> > On Wed, 2 Oct 2019 at 21:06, Christopher Lam 
> > wrote:
> >
> >> FWIW I do think it's a nice feature to have.
> >>
> >> It's not terribly difficult to implement either. Allow user to add a
> >> special entry with some metadata stating the balance should be X
> dollars,
> >> and if the user tries to input a transaction which will fail the balance
> >> assertion, pops a warning "Error - this transaction cannot be entered
> >> because it will invalidate balance on d/m/y which should be $amount.".
> >>
> >> As always the devil is in the details: this will be a brand-new error
> >> condition that only triggers upon user input. Should this trigger when
> user
> >> imports transactions via CSV/OFX/QIF? What about with custom scripts
> >> whereby a book has been modified but the balance assertions are no
> longer
> >> valid? What about a book modified externally whereby the assertions now
> >> fail? Should GnuCash fail to open the book because it's now "invalid"?
> >> Should there be a framework/central mechanism to capture all these
> sanity
> >> checks?
> >>
> >> It's really difficult. Software development is hard. For that matter I
> >> don't think any current developer has found this issue particularly high
> >> priority, so, it has never been done.
> >>
> >> On Wed, 2 Oct 2019 at 10:41, Arman Schwarz 
> >> wrote:
> >>
> >>> Sorry for the wordy reply. The TLDR; I think we're on the same page
> that
> >>> Balance Assertions are a "nice to have" but I feel I haven't really
> >>> articulated the scenario/s that I think make this feature quite
> >>> important,
> >>> hence why I'm replying again.
> >>>
> >>> > For example, if I enter a
> >>> > transaction from July 10, 2019 with the incorrect date of July 10,
> >>> > 2010,
> >>>
> >>> This has actually happened to me before, where I'm backfilling some
> >>> statements and I get the years mixed up, but you could imagine it might
> >>> happen also if I'm punching in years on a number pad and write the
> wrong
> >>> value, or if the user is prone to mixing up numbers (also very common).
> >>>
> >>> Now imagine that at the time of this error reconciliation has been done
> >>> for
> >>> all months up to June 2019. 9 years worth of balances are now wrong,
> and
> >>> GnuCash will quite happily ignore the fact that I've told it on
> multiple
> >>> occassions what the balances should be at various dates (hence the
> >>> missing
> >>> feature of balance assertions that you should "get for free" with every
> >>> reconciliation should you want it).
> >>>
> >>> I think the premise of your responses is that I should now do a
> >>> reconciliation to find this issue.
> >>>
> >>> > WHY would you ‘clear’ a 9 year old transaction erroneously it it
> >>> doesn’t
> >>> appear on *this month’s* statement?
> >>>
> >>> (Remember that the transaction will appear on my reconciliation as well
> >>> as
> >>> my statement, it's just that the date will be wrong, but I'll try to
> >>> respond to the core of the question - why would I sign off on something
> >>> that's wrong?)
> >>>
> >>> Firstly I'd say that I shouldn't have to, as GnuCash has at this point
> >>> been
> >>> given all the information it would need to point out to the user that
> >>> there
> >>> is a 

Re: [GNC] How to run report on Paid Sales for a period? (Cash Accounting Method)

[Derek Atkins]

doncram  writes:

> GNUcash should include such a statement/report, but I think it does not.
> You should not have to try to cobble together something from bank
> statements;  it should simply be available.

GnuCash does include a Cash Flow report.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Arman Schwarz]

Another complimentary feature might be to restrict the date range of
reconciliations - if I'm reconciling a July 2019 statement against my
accounts, why should I be given the option of using a July 1010 transaction
to reconcile against? Maybe I should be able to specify the date range of
the statemetn I'm reconciling against?

On Wed, 2 Oct 2019 at 21:22, Arman Schwarz  wrote:

> All the issues I've highlighted really boil down to inserting transactions
> before already reconciled ones, so if we could prevent that it might make
> my concern moot.
>
> So perhaps an easier route from a software design perspective would be
> just adding a warn dialog whenever you try to insert a transaction that
> comes before any reconciled transactions. You could also warn if the user
> tries to perform a reconciliation that leaves reonciled transactions
> _after_ unreconciled transactions.
>
> If you try to insert a transaction before a reconciled transaction, valid
> responses could be;
> 1) Go ahead anyway
> 2) Go ahead, but un-reconcile all transactions after the inserted
> transaction
> 3) Cancel, never warn again, etc.
>
> Actually before I emberass myself here - does this already exist?
>
> On Wed, 2 Oct 2019 at 21:06, Christopher Lam 
> wrote:
>
>> FWIW I do think it's a nice feature to have.
>>
>> It's not terribly difficult to implement either. Allow user to add a
>> special entry with some metadata stating the balance should be X dollars,
>> and if the user tries to input a transaction which will fail the balance
>> assertion, pops a warning "Error - this transaction cannot be entered
>> because it will invalidate balance on d/m/y which should be $amount.".
>>
>> As always the devil is in the details: this will be a brand-new error
>> condition that only triggers upon user input. Should this trigger when user
>> imports transactions via CSV/OFX/QIF? What about with custom scripts
>> whereby a book has been modified but the balance assertions are no longer
>> valid? What about a book modified externally whereby the assertions now
>> fail? Should GnuCash fail to open the book because it's now "invalid"?
>> Should there be a framework/central mechanism to capture all these sanity
>> checks?
>>
>> It's really difficult. Software development is hard. For that matter I
>> don't think any current developer has found this issue particularly high
>> priority, so, it has never been done.
>>
>> On Wed, 2 Oct 2019 at 10:41, Arman Schwarz 
>> wrote:
>>
>>> Sorry for the wordy reply. The TLDR; I think we're on the same page that
>>> Balance Assertions are a "nice to have" but I feel I haven't really
>>> articulated the scenario/s that I think make this feature quite
>>> important,
>>> hence why I'm replying again.
>>>
>>> > For example, if I enter a
>>> > transaction from July 10, 2019 with the incorrect date of July 10,
>>> > 2010,
>>>
>>> This has actually happened to me before, where I'm backfilling some
>>> statements and I get the years mixed up, but you could imagine it might
>>> happen also if I'm punching in years on a number pad and write the wrong
>>> value, or if the user is prone to mixing up numbers (also very common).
>>>
>>> Now imagine that at the time of this error reconciliation has been done
>>> for
>>> all months up to June 2019. 9 years worth of balances are now wrong, and
>>> GnuCash will quite happily ignore the fact that I've told it on multiple
>>> occassions what the balances should be at various dates (hence the
>>> missing
>>> feature of balance assertions that you should "get for free" with every
>>> reconciliation should you want it).
>>>
>>> I think the premise of your responses is that I should now do a
>>> reconciliation to find this issue.
>>>
>>> > WHY would you ‘clear’ a 9 year old transaction erroneously it it
>>> doesn’t
>>> appear on *this month’s* statement?
>>>
>>> (Remember that the transaction will appear on my reconciliation as well
>>> as
>>> my statement, it's just that the date will be wrong, but I'll try to
>>> respond to the core of the question - why would I sign off on something
>>> that's wrong?)
>>>
>>> Firstly I'd say that I shouldn't have to, as GnuCash has at this point
>>> been
>>> given all the information it would need to point out to the user that
>>> there
>>> is a discrepency (via the many statement balances I would have given it
>>> to
>>> do the reconciliations up to this point).
>>>
>>> Secondly, most of the time I think you're right in that I would catch
>>> this
>>> issue in a reconciliation but I might not becuse:
>>>
>>> - Many human errors are not random, but symptomatic of a cognitive bias.
>>> For example, I might mix up 9s and 0s, causing me to type "2010" instead
>>> of
>>> "2019". This would make me prone to missing this problem in
>>> reconiliation,
>>> or
>>> - I might be in a rush or might only check the balances. I might just
>>> _happen_ not to check the year because I've been staring at dates all day
>>> and I'm starting to get a bit frazzled.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Arman Schwarz]

All the issues I've highlighted really boil down to inserting transactions
before already reconciled ones, so if we could prevent that it might make
my concern moot.

So perhaps an easier route from a software design perspective would be just
adding a warn dialog whenever you try to insert a transaction that comes
before any reconciled transactions. You could also warn if the user tries
to perform a reconciliation that leaves reonciled transactions _after_
unreconciled transactions.

If you try to insert a transaction before a reconciled transaction, valid
responses could be;
1) Go ahead anyway
2) Go ahead, but un-reconcile all transactions after the inserted
transaction
3) Cancel, never warn again, etc.

Actually before I emberass myself here - does this already exist?

On Wed, 2 Oct 2019 at 21:06, Christopher Lam 
wrote:

> FWIW I do think it's a nice feature to have.
>
> It's not terribly difficult to implement either. Allow user to add a
> special entry with some metadata stating the balance should be X dollars,
> and if the user tries to input a transaction which will fail the balance
> assertion, pops a warning "Error - this transaction cannot be entered
> because it will invalidate balance on d/m/y which should be $amount.".
>
> As always the devil is in the details: this will be a brand-new error
> condition that only triggers upon user input. Should this trigger when user
> imports transactions via CSV/OFX/QIF? What about with custom scripts
> whereby a book has been modified but the balance assertions are no longer
> valid? What about a book modified externally whereby the assertions now
> fail? Should GnuCash fail to open the book because it's now "invalid"?
> Should there be a framework/central mechanism to capture all these sanity
> checks?
>
> It's really difficult. Software development is hard. For that matter I
> don't think any current developer has found this issue particularly high
> priority, so, it has never been done.
>
> On Wed, 2 Oct 2019 at 10:41, Arman Schwarz  wrote:
>
>> Sorry for the wordy reply. The TLDR; I think we're on the same page that
>> Balance Assertions are a "nice to have" but I feel I haven't really
>> articulated the scenario/s that I think make this feature quite important,
>> hence why I'm replying again.
>>
>> > For example, if I enter a
>> > transaction from July 10, 2019 with the incorrect date of July 10,
>> > 2010,
>>
>> This has actually happened to me before, where I'm backfilling some
>> statements and I get the years mixed up, but you could imagine it might
>> happen also if I'm punching in years on a number pad and write the wrong
>> value, or if the user is prone to mixing up numbers (also very common).
>>
>> Now imagine that at the time of this error reconciliation has been done
>> for
>> all months up to June 2019. 9 years worth of balances are now wrong, and
>> GnuCash will quite happily ignore the fact that I've told it on multiple
>> occassions what the balances should be at various dates (hence the missing
>> feature of balance assertions that you should "get for free" with every
>> reconciliation should you want it).
>>
>> I think the premise of your responses is that I should now do a
>> reconciliation to find this issue.
>>
>> > WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t
>> appear on *this month’s* statement?
>>
>> (Remember that the transaction will appear on my reconciliation as well as
>> my statement, it's just that the date will be wrong, but I'll try to
>> respond to the core of the question - why would I sign off on something
>> that's wrong?)
>>
>> Firstly I'd say that I shouldn't have to, as GnuCash has at this point
>> been
>> given all the information it would need to point out to the user that
>> there
>> is a discrepency (via the many statement balances I would have given it to
>> do the reconciliations up to this point).
>>
>> Secondly, most of the time I think you're right in that I would catch this
>> issue in a reconciliation but I might not becuse:
>>
>> - Many human errors are not random, but symptomatic of a cognitive bias.
>> For example, I might mix up 9s and 0s, causing me to type "2010" instead
>> of
>> "2019". This would make me prone to missing this problem in reconiliation,
>> or
>> - I might be in a rush or might only check the balances. I might just
>> _happen_ not to check the year because I've been staring at dates all day
>> and I'm starting to get a bit frazzled.
>>
>> Remember, I've already made the mistake by inputting the data incorrectly.
>> There's a good chance I'm confused about the dates at this point, so the
>> likelihood I'm going to stuff it up at reconciliation is larger than it
>> would be for other transactions. In the above example I got the balance,
>> day and month right, so there's literally only a single digit off!
>>
>> But the worst part about this scenario is that there is no mechanism to
>> catch this down the road. If I make a mistake on the date in
>> 

Re: [GNC] How can I add statement balances to my accounts as checks?

[Christopher Lam]

FWIW I do think it's a nice feature to have.

It's not terribly difficult to implement either. Allow user to add a
special entry with some metadata stating the balance should be X dollars,
and if the user tries to input a transaction which will fail the balance
assertion, pops a warning "Error - this transaction cannot be entered
because it will invalidate balance on d/m/y which should be $amount.".

As always the devil is in the details: this will be a brand-new error
condition that only triggers upon user input. Should this trigger when user
imports transactions via CSV/OFX/QIF? What about with custom scripts
whereby a book has been modified but the balance assertions are no longer
valid? What about a book modified externally whereby the assertions now
fail? Should GnuCash fail to open the book because it's now "invalid"?
Should there be a framework/central mechanism to capture all these sanity
checks?

It's really difficult. Software development is hard. For that matter I
don't think any current developer has found this issue particularly high
priority, so, it has never been done.

On Wed, 2 Oct 2019 at 10:41, Arman Schwarz  wrote:

> Sorry for the wordy reply. The TLDR; I think we're on the same page that
> Balance Assertions are a "nice to have" but I feel I haven't really
> articulated the scenario/s that I think make this feature quite important,
> hence why I'm replying again.
>
> > For example, if I enter a
> > transaction from July 10, 2019 with the incorrect date of July 10,
> > 2010,
>
> This has actually happened to me before, where I'm backfilling some
> statements and I get the years mixed up, but you could imagine it might
> happen also if I'm punching in years on a number pad and write the wrong
> value, or if the user is prone to mixing up numbers (also very common).
>
> Now imagine that at the time of this error reconciliation has been done for
> all months up to June 2019. 9 years worth of balances are now wrong, and
> GnuCash will quite happily ignore the fact that I've told it on multiple
> occassions what the balances should be at various dates (hence the missing
> feature of balance assertions that you should "get for free" with every
> reconciliation should you want it).
>
> I think the premise of your responses is that I should now do a
> reconciliation to find this issue.
>
> > WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t
> appear on *this month’s* statement?
>
> (Remember that the transaction will appear on my reconciliation as well as
> my statement, it's just that the date will be wrong, but I'll try to
> respond to the core of the question - why would I sign off on something
> that's wrong?)
>
> Firstly I'd say that I shouldn't have to, as GnuCash has at this point been
> given all the information it would need to point out to the user that there
> is a discrepency (via the many statement balances I would have given it to
> do the reconciliations up to this point).
>
> Secondly, most of the time I think you're right in that I would catch this
> issue in a reconciliation but I might not becuse:
>
> - Many human errors are not random, but symptomatic of a cognitive bias.
> For example, I might mix up 9s and 0s, causing me to type "2010" instead of
> "2019". This would make me prone to missing this problem in reconiliation,
> or
> - I might be in a rush or might only check the balances. I might just
> _happen_ not to check the year because I've been staring at dates all day
> and I'm starting to get a bit frazzled.
>
> Remember, I've already made the mistake by inputting the data incorrectly.
> There's a good chance I'm confused about the dates at this point, so the
> likelihood I'm going to stuff it up at reconciliation is larger than it
> would be for other transactions. In the above example I got the balance,
> day and month right, so there's literally only a single digit off!
>
> But the worst part about this scenario is that there is no mechanism to
> catch this down the road. If I make a mistake on the date in
> reconciliation, that's it, it's there forever. Future balances will be
> correct because only the date is wrong, and I'm now stuck with this mistake
> forever, and can't know about it even though I've _told_ GnuCash the info
> it needs to find the mistake.
>
> It seems like there are several workarounds that reduce the likelihood of
> this happening, such as exercising more diligence as Adrien points out, or
> the various autocompletion features Liz mentioned. David's point about the
> order of entries might also help. But all of these seem to only partially
> reduce the likelihood of errors creeping in that really shouldn't be
> allowed to exist in the first place.
>
> I think as a software design philosophy the software really should be
> making it as easy as possible to get it right. I don't dispute that we
> should be diligent when reconciling values, but I think it's not ideal that
> the normal workflow could result in permanent 

Re: [GNC] How can I add statement balances to my accounts as checks?

[Arman Schwarz]

Sorry for the wordy reply. The TLDR; I think we're on the same page that
Balance Assertions are a "nice to have" but I feel I haven't really
articulated the scenario/s that I think make this feature quite important,
hence why I'm replying again.

> For example, if I enter a
> transaction from July 10, 2019 with the incorrect date of July 10,
> 2010,

This has actually happened to me before, where I'm backfilling some
statements and I get the years mixed up, but you could imagine it might
happen also if I'm punching in years on a number pad and write the wrong
value, or if the user is prone to mixing up numbers (also very common).

Now imagine that at the time of this error reconciliation has been done for
all months up to June 2019. 9 years worth of balances are now wrong, and
GnuCash will quite happily ignore the fact that I've told it on multiple
occassions what the balances should be at various dates (hence the missing
feature of balance assertions that you should "get for free" with every
reconciliation should you want it).

I think the premise of your responses is that I should now do a
reconciliation to find this issue.

> WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t
appear on *this month’s* statement?

(Remember that the transaction will appear on my reconciliation as well as
my statement, it's just that the date will be wrong, but I'll try to
respond to the core of the question - why would I sign off on something
that's wrong?)

Firstly I'd say that I shouldn't have to, as GnuCash has at this point been
given all the information it would need to point out to the user that there
is a discrepency (via the many statement balances I would have given it to
do the reconciliations up to this point).

Secondly, most of the time I think you're right in that I would catch this
issue in a reconciliation but I might not becuse:

- Many human errors are not random, but symptomatic of a cognitive bias.
For example, I might mix up 9s and 0s, causing me to type "2010" instead of
"2019". This would make me prone to missing this problem in reconiliation,
or
- I might be in a rush or might only check the balances. I might just
_happen_ not to check the year because I've been staring at dates all day
and I'm starting to get a bit frazzled.

Remember, I've already made the mistake by inputting the data incorrectly.
There's a good chance I'm confused about the dates at this point, so the
likelihood I'm going to stuff it up at reconciliation is larger than it
would be for other transactions. In the above example I got the balance,
day and month right, so there's literally only a single digit off!

But the worst part about this scenario is that there is no mechanism to
catch this down the road. If I make a mistake on the date in
reconciliation, that's it, it's there forever. Future balances will be
correct because only the date is wrong, and I'm now stuck with this mistake
forever, and can't know about it even though I've _told_ GnuCash the info
it needs to find the mistake.

It seems like there are several workarounds that reduce the likelihood of
this happening, such as exercising more diligence as Adrien points out, or
the various autocompletion features Liz mentioned. David's point about the
order of entries might also help. But all of these seem to only partially
reduce the likelihood of errors creeping in that really shouldn't be
allowed to exist in the first place.

I think as a software design philosophy the software really should be
making it as easy as possible to get it right. I don't dispute that we
should be diligent when reconciling values, but I think it's not ideal that
the normal workflow could result in permanent errors from a single mistake
(well, two mistakes I suppose, since you'd need to reconcile incorrectly,
but it's not out of the question as I've illustrated).

So it really wasn't my intention to come off as cynical, and I hope I
haven't done that - I'm actually hugely impressed by GnuCash and will
continue to use it regardless of whether it has balance assertions or note
(I'll just build it myself), but I'm hoping that I've succeeded in
articulating why I think it's a worthwhile feature (I know Adrien already
acknowledged this but I wanted to give a specific scenario).

On Wed, 2 Oct 2019 at 19:49, D via gnucash-user 
wrote:

> Moreover, when next you go to reconcile, that entry for 2010 will display
> up at the very top of the reconcile window, and one might wonder at that,
> see the incorrect date and fix it.
>
> [Technically, Gnucash doesn't store the reconciled amount, it calculates
> it at each reconcile for all transactions with the reconcile flag set.]
>
> David
>
> On October 2, 2019, at 10:17 AM, Liz  wrote:
>
> On Wed, 2 Oct 2019 16:19:10 +1000
> Arman Schwarz  wrote:
>
> > For example, if I enter a
> > transaction from July 10, 2019 with the incorrect date of July 10,
> > 2010,
>
>
> That is actually harder than you think.
> If you do not specify a date, 

Re: [GNC] How can I add statement balances to my accounts as checks?

[Liz]

On Wed, 2 Oct 2019 16:19:10 +1000
Arman Schwarz  wrote:

> For example, if I enter a
> transaction from July 10, 2019 with the incorrect date of July 10,
> 2010, 


That is actually harder than you think.
If you do not specify a date, you get today's date.
If you specify a number for the number of the day in the month you get
this month in this year (put in 2 and get 2nd October 2019
If you specify a number for the day, and a number for the month, you
get this year.

So the lazy entering of incomplete dates pulls you to the correct year.
(I know this can be changed in preferences, somewhere).


Nextly, the system does know the last balance at reconciliation. It
pulls that value in for the next reconciliation.

You can certainly type in transactions with no value, just a
description, and in that description put "Confirmed balance $123.45"

Liz
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Adrien Monteleone]

> On Oct 2, 2019 w40d275, at 1:19 AM, Arman Schwarz  
> wrote:
> 
> Thanks Adrien,
> 
> I think it's the "if you aren't careful" part of the reconciliation 
> philosophy that I don't like, but I think your message helped me understand 
> the intended workflow with GnuCash.
> 
> Just to explain my first comment; Reconciliation seems to depend on the user 
> checking that transactions are correct, and if a mistake is made, it's 
> unlikely that it will be caught in future. For example, if I enter a 
> transaction from July 10, 2019 with the incorrect date of July 10, 2010, then 
> I will just have thrown off 9 years worth of transactions. If I happen not to 
> notice this mistake during reconciliation (which is not unthinkable, since I 
> made the mistake in the first place) then I'll probably never catch it unless 
> I happen to reconcile old balances (which I'll never do).

No, you won’t throw off 9 years of transactions or 9 years of reconciliations.

Those are all correct. (presumably)

When you reconcile the *next time* you’ll see a 9 year old transaction that is 
listed as unreconciled. At that point, a mental red flag is supposed to be 
raised, and you should then pause the reconciliation and investigate.

*Note*, the reconciliation process is geared towards comparing a written bank 
statement with your electronic records.

WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t appear 
on *this month’s* statement?

That would be entirely against the intended process. (hence my admonition to be 
careful, some might not understand it isn’t about just clicking things, it is 
about CHECKING things)

If you do a reconciliation RIGHT at worst you’ll have a discrepancy you don’t 
have time to resolve and thus have to make a correcting transaction. (or the 
time needed to resolve it costs more than the transaction, in which case, the 
principle of ‘materiality’ suggests to just correct it and move on rather than 
solve the problem, such as spending more than a few seconds finding a lost 
penny or nickel.)


> 
> The issue with "be careful when reconciling" is that if I could be so careful 
> as not to make mistakes, I wouldn't need reconciliation in the first place. 
> Well, that's not entirely true, I suppose reconciliation would then still be 
> helpful in that it would catch mistakes made by the bank or some other third 
> party. Maybe that's what I'm missing - that reconciliation isn't intended to 
> catch user errors, just third party errors?

That is the entire point of reconciliation - to catch your earlier mistakes 
made in haste. (or otherwise, or someone else’s.) Reconciliation is NOT a 
rubber stamp process, quite the opposite.

> 
> Either way, balances are useful pieces of information that GnuCash is 
> throwing away. I may end up writing a bash/python script combined with 
> Christopher's suggestion to implement these assertions myself. If I do I'll 
> post the result but I don't really have enough (any) expertise with GnuCash 
> to know whether such a feature could be implemented in the software itself.
> 
> Anyway, thanks to both of you for clarifying for me.

Yes, noted asserted balances would be helpful as a feature. I’m not sure they 
should be enforced or trigger warnings, but it wouldn’t hurt to record them 
somewhere, especially since you’re inputting that info anyway.

Regards,
Adrien
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] How can I add statement balances to my accounts as checks?

[Arman Schwarz]

Thanks Adrien,

I think it's the "if you aren't careful" part of the reconciliation
philosophy that I don't like, but I think your message helped me understand
the intended workflow with GnuCash.

Just to explain my first comment; Reconciliation seems to depend on the
user checking that transactions are correct, and if a mistake is made, it's
unlikely that it will be caught in future. For example, if I enter a
transaction from July 10, 2019 with the incorrect date of July 10, 2010,
then I will just have thrown off 9 years worth of transactions. If I happen
not to notice this mistake during reconciliation (which is not unthinkable,
since I made the mistake in the first place) then I'll probably never catch
it unless I happen to reconcile old balances (which I'll never do).

The issue with "be careful when reconciling" is that if I could be so
careful as not to make mistakes, I wouldn't need reconciliation in the
first place. Well, that's not entirely true, I suppose reconciliation would
then still be helpful in that it would catch mistakes made by the bank or
some other third party. Maybe that's what I'm missing - that reconciliation
isn't intended to catch user errors, just third party errors?

Either way, balances are useful pieces of information that GnuCash is
throwing away. I may end up writing a bash/python script combined with
Christopher's suggestion to implement these assertions myself. If I do I'll
post the result but I don't really have enough (any) expertise with GnuCash
to know whether such a feature could be implemented in the software itself.

Anyway, thanks to both of you for clarifying for me.

On Wed, 2 Oct 2019 at 15:44, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> For now, the workflow is that if you alter a reconciled transaction,
> you’ll get a warning. (which is dismiss-able, and which you can elect to
> not be shown) There is at least one (though I think several) bug reports on
> what should trigger this warning when a reconciled transaction is edited,
> depending on what data edit causes the trigger.
>
> However, I know of no mechanism in GnuCash currently that checks to see
> that you’ve entered an historical transaction that *should* have been
> reconciled in the past, or even has an erroneous date and should be in the
> present but affects a reconciled period.
>
> Presumably, since it is required for the math to work out, if you are
> entering a real historical transaction, it should be part of the historical
> reconciliation. Which means if it were not already present, then either you
> have some serious errors in your current record, or, you made a correcting
> entry that needs to be erased/modified now that you have more accurate
> transaction data.
>
> Regardless of if you enter an old transaction that should have been
> included, or mis-enter a date in the past, the next time you reconcile,
> you’ll see that/those old transactions and notice something is amiss. While
> it would be nice to get such warning at the point of entry, there might be
> use cases where warnings are quite a pain, especially for someone
> intentionally entering historical data.
>
> Personally, I don’t have a problem with the current approach.
>
> If you successfully reconcile a period and don’t have to make an adjusting
> transaction, there should be no issue.
>
> If you reconcile but made errors and don’t feel like, or can’t at the
> moment track down why they are there and make an adjusting entry, then
> you’ll realize this at worst, at the next reconciliation.
>
> If you errantly enter an old date on a transaction, you’ll catch this at
> the next reconciliation. (unless you aren’t careful)
>
> Now, it would be nice if upon reconciliation, there were some way to
> indicate in a particular transaction (the last of the reconciled period)
> that the asserted balance was at a certain level. I do this from time to
> time if I happen to count a cash asset, but haven’t gotten around to
> reconciling it yet. I’ll note that at the point of the transaction I had a
> certain amount physically on hand. That way, when I do get around to formal
> reconciliation, I know my balance at that transaction needs to be a certain
> amount. And if it is off, I’ll have to either search for the error, or
> enter a miscellaneous transaction as a correction.
>
> If I ever have to make a balancing miscellaneous transaction to complete a
> reconciliation, I’ll indicate in it whatever that asserted balance was
> supposed to be. That way, if I ever get back to investigating or if I find
> a lost receipt for example, I can either edit that balancing transaction
> accordingly, or erase/reverse it entirely.
>
> But that doesn’t include the case of doing so automatically from an actual
> reconciliation. (rather than being not up to date in doing so, or manually
> noting the asserted balance.) Perhaps an RFE would be in order, however, I
> don’t know how much work would be involved or where that would even appear
> in