date:20200727

Michael,

Exactly.  The QFX file only contains the information that the bank would
put on your monthly account statement along with the necessary
infrastructure to identify which bank created the file and which account
and the time frame which the file describes and sometimes some additional
information that GnuCash may or may not use.  GnuCash has to synthesize the
rest in order to create a list of full double-entry qualified
transactions.  That is why the import wizard is so difficult for users to
work with and even more difficult for developers to code.

Unfortunately most of us are very sloppy technically in talking of the file
as if it is a transaction list when it is really more like a bank
statement.

On Mon, Jul 27, 2020 at 8:57 PM Fross, Michael  wrote:

> Hello David,
>
> In looking at the QFX file, I only see one side of the transaction.  This
> file has 3 distinct transactions ( records) that are not related
> and only one account ID is listed.
>
> Michael
>
> On Mon, Jul 27, 2020 at 5:56 PM David Carlson 
> wrote:
>
>> There is another use case which GnuCash also needs to handle.  Some OFX
>> files may contain both sides of an inter-account transfer between two
>> accounts within the same bank because the OFX file can include multiple
>> accounts.  In fact, I do that on a regular basis at one of my banks.  I do
>> not test GnuCash's handling of these because I want to get the separate
>> notes associated with each side and merge them together into the same
>> transaction in my data file.  Thus I deliberately call both of them New
>> rather than try to match them within the import process.  I have not
>> checked to see if they have unique FITID's, but they would be under
>> different ACCOUNTID's  and both can be accepted as New in release 2.6.19
>> and prior, which is the latest version that I use.  I suppose ideally I
>> would like gnuCash to detect this case and automatically apply the
>> corresponding notes to both sides of the  transfer, so I don't have to do
>> it manually.
>>
>> David Carlson
>>
>> On Mon, Jul 27, 2020 at 5:23 PM Fross, Michael  wrote:
>>
>>> Got it. Thanks.  Now I understand why it used to work.  And I certainly
>>> wouldn't expect GnuCash to correct a bank's horrible behavior.  I'll keep
>>> an eye on the FITID and see if that's what they are doing.
>>>
>>> Thanks everyone for your help.  Much appreciated.
>>>
>>> Michael
>>>
>>> On Mon, Jul 27, 2020 at 5:13 PM Jean Laroche  wrote:
>>>
>>> > Ah, OK I get it now!
>>> > Yes, you should check that from one day to the next, the FTID returned
>>> > by citibank remains the same (for the same transaction). If not, then
>>> > that's going to be a problem.
>>> > What has changed recently with GC is that it not will not match a new
>>> > imported transaction with one from the register that has an online id.
>>> > Previous versions allowed that, so in your case, it's quite possible
>>> > that from one day to the next, the same transaction would be given a
>>> > different ID, but GC matched it to the same register transaction that
>>> > was previously matched.
>>> > So, on day 1, you'd match OFX1->Reg1, and on day two, you'd still match
>>> > OFX2 -> reg1, even though reg1 had already been matched to OFX1 the
>>> > previous day. So you'd see OFX2 appear as "match" and not "Add".
>>> >
>>> > The correct behavior is that OFX2 actually has the same ID as OFX1, and
>>> > it's entirely skipped by GC. But it seems that your bank is messing
>>> > their online ID, and this is what's causing the issue for you, along
>>> > with the new GC behavior.
>>> >
>>> > I'm not sure how to fix your problem. It's clearly a bank issue but
>>> > that's not terribly helpful as far as your problem goes. We should
>>> > probably add an option to defeat the new GC import behavior,
>>> > specifically for users like you whose bank send unreliable FTIDs/
>>> >
>>> > FYI, the new GC behavior was added because the old behavior was causing
>>> > issues with people who had recurring daily transactions: imagine buying
>>> > a cup of coffee every day: in that case GC will match all daily cups of
>>> > coffee to the same register transaction (within a date range, of
>>> course)
>>> > instead of adding the new one every day (which really is the correct
>>> way
>>> > to do it).
>>> >
>>> >
>>> >
>>> > Jean
>>> >
>>> >
>>> > On 7/27/20 2:45 PM, Fross, Michael wrote:
>>> > > Hi Jean.  Let me try to better explain my issue.
>>> > >
>>> > > On most days, I download QFX files from my Checking and Credit Card
>>> > > accounts and import them.  In this way I clear transactions and I can
>>> > > see what's going on.  The next day I'll do so again, and the importer
>>> > > skips those that have already been matched per your comment.s  I've
>>> been
>>> > > doing this for years and it's worked well.
>>> > >
>>> > > Since I updated to V4 the transactions that would have matched
>>> > > previously now come up with "Match Missing!" in the importer.  I
>>> don't
>>> > > want to add t

Re: [GNC] Import Transaction Matcher issue in v4

Hello David,

In looking at the QFX file, I only see one side of the transaction.  This
file has 3 distinct transactions ( records) that are not related
and only one account ID is listed.

Michael

On Mon, Jul 27, 2020 at 5:56 PM David Carlson 
wrote:

> There is another use case which GnuCash also needs to handle.  Some OFX
> files may contain both sides of an inter-account transfer between two
> accounts within the same bank because the OFX file can include multiple
> accounts.  In fact, I do that on a regular basis at one of my banks.  I do
> not test GnuCash's handling of these because I want to get the separate
> notes associated with each side and merge them together into the same
> transaction in my data file.  Thus I deliberately call both of them New
> rather than try to match them within the import process.  I have not
> checked to see if they have unique FITID's, but they would be under
> different ACCOUNTID's  and both can be accepted as New in release 2.6.19
> and prior, which is the latest version that I use.  I suppose ideally I
> would like gnuCash to detect this case and automatically apply the
> corresponding notes to both sides of the  transfer, so I don't have to do
> it manually.
>
> David Carlson
>
> On Mon, Jul 27, 2020 at 5:23 PM Fross, Michael  wrote:
>
>> Got it. Thanks.  Now I understand why it used to work.  And I certainly
>> wouldn't expect GnuCash to correct a bank's horrible behavior.  I'll keep
>> an eye on the FITID and see if that's what they are doing.
>>
>> Thanks everyone for your help.  Much appreciated.
>>
>> Michael
>>
>> On Mon, Jul 27, 2020 at 5:13 PM Jean Laroche  wrote:
>>
>> > Ah, OK I get it now!
>> > Yes, you should check that from one day to the next, the FTID returned
>> > by citibank remains the same (for the same transaction). If not, then
>> > that's going to be a problem.
>> > What has changed recently with GC is that it not will not match a new
>> > imported transaction with one from the register that has an online id.
>> > Previous versions allowed that, so in your case, it's quite possible
>> > that from one day to the next, the same transaction would be given a
>> > different ID, but GC matched it to the same register transaction that
>> > was previously matched.
>> > So, on day 1, you'd match OFX1->Reg1, and on day two, you'd still match
>> > OFX2 -> reg1, even though reg1 had already been matched to OFX1 the
>> > previous day. So you'd see OFX2 appear as "match" and not "Add".
>> >
>> > The correct behavior is that OFX2 actually has the same ID as OFX1, and
>> > it's entirely skipped by GC. But it seems that your bank is messing
>> > their online ID, and this is what's causing the issue for you, along
>> > with the new GC behavior.
>> >
>> > I'm not sure how to fix your problem. It's clearly a bank issue but
>> > that's not terribly helpful as far as your problem goes. We should
>> > probably add an option to defeat the new GC import behavior,
>> > specifically for users like you whose bank send unreliable FTIDs/
>> >
>> > FYI, the new GC behavior was added because the old behavior was causing
>> > issues with people who had recurring daily transactions: imagine buying
>> > a cup of coffee every day: in that case GC will match all daily cups of
>> > coffee to the same register transaction (within a date range, of course)
>> > instead of adding the new one every day (which really is the correct way
>> > to do it).
>> >
>> >
>> >
>> > Jean
>> >
>> >
>> > On 7/27/20 2:45 PM, Fross, Michael wrote:
>> > > Hi Jean.  Let me try to better explain my issue.
>> > >
>> > > On most days, I download QFX files from my Checking and Credit Card
>> > > accounts and import them.  In this way I clear transactions and I can
>> > > see what's going on.  The next day I'll do so again, and the importer
>> > > skips those that have already been matched per your comment.s  I've
>> been
>> > > doing this for years and it's worked well.
>> > >
>> > > Since I updated to V4 the transactions that would have matched
>> > > previously now come up with "Match Missing!" in the importer.  I don't
>> > > want to add them as they would create duplicates.  Transactions that
>> are
>> > > not cleared seem to be able to be matched.  But those that are
>> > > previously cleared get the "Match Missing!" issue.
>> > >
>> > > Now, based on what you told me, the QFX file for a problem transaction
>> > > has a FITID that is one higher than the ONLINE_ID in the gnucash file
>> > > for the same transaction.  So the Match Missing items seems to be
>> > correct.
>> > >
>> > > If I duplicate the transaction, delete the original, it matches which
>> I
>> > > assume is because there is not an ONLINE_ID associated with the new
>> one.
>> > >
>> > > What I don't understand is if there is an issue with GNUCash, which is
>> > > why I asked if others are having the same issue, or if it is/was an
>> > > issue with CITIBANK QFX files.  If they changed the FITID for some
>> > > reason that would cause this.

Re: [GNC] GTK CSS 4.0-4.1

I am not proficient in css  but the is a lot that has changed in the naming
of many of the tags. Attached is an example of some of the slight change in
names. Nowonder they did not work. The one you posted I had working for 3.91
but the tag names jhas been updated

If someone from the Dev team post the gtk.css file used in the 4.1
installation of Win 10


Thank You

Jimmy


 



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
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 to find un-posted invoices (was: Re: BotanyBayGardens nonprofit example, and why GnuCash does not suffice)

2020-07-27 Thread Bruce Irving via gnucash-user

Thanks, Adrien
I found that out yesterday when I created an invoice but didn't post it
I'll live with it until I can track them all down.  My goal is to eventually 
delete the AR module.
Bruce

Try Business > Customer > Find Invoice, then set criteria to `Is 
posted?` and uncheck the box. (without that criteria, others should show 
a `Posted` column anyway, 'un-posted' invoices will show "12/31/1969" as 
the date - a bug, but usable info still.)

You can of course add criteria, and/or run iterated searches to refine 
the list as needed.

Sadly, there is no way to get a report or even export this results list. 
(You can screenshot I suppose)

There is also no way to save the search criteria if they get complicated.

But from the Find window you can View, Edit, Pay, Print, etc. (the 
'Printable Report' button is an Invoice report, not a report of the 
results.)

Hope that helps.

Regards,
Adrien




Bruce
 Preach the Gospel wherever you go.
 If necessary, use words.
___
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] Report error: advanced-portfolio (Lipp F.)

2020-07-27 Thread John Bonnett


On 27/07/2020 11:56 pm, "Lipp F."  wrote:

Just installed 4.1 on Windows 10 and advanced portfolio report throws an

error. The report was working fine on 3.10. Here it is:

Report error

An error occurred while running the report.

In c-interface.scm:
 24:4 19 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9 18 (catch #t # …)
In c-interface.scm:
29:37 17 (_)
In unknown file:
  16 (eval-string "(gnc:report-run 9)" #)
In ice-9/boot-9.scm:
   2312:4 15 (save-module-excursion #)
In ice-9/eval-string.scm:
 38:6 14 (read-and-eval # #:lang _)
In report-core.scm:
689:4 13 (gnc:report-run _)
In c-interface.scm:
 66:2 12 (gnc:backtrace-if-exception _ . _)
 24:4 11 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9 10 (catch #t # …)
In c-interface.scm:
28:40  9 (_)
In report-core.scm:
   691:29  8 (_)
   673:25  7 (gnc:report-render-html #< type: "21d7cfc59fc7…> …)
In standard/advanced-portfolio.scm:
  1057:10  6 (advanced-portfolio-renderer _)
In ice-9/boot-9.scm:
829:9  5 (catch div/0 # …)
In standard/advanced-portfolio.scm:
   428:10  4 (table-add-stock-rows #< col-headers: (("A…> …)
In srfi/srfi-1.scm:
640:9  3 (for-each # …)
In standard/advanced-portfolio.scm:
   460:21  2 (_ _)
In srfi/srfi-1.scm:
640:9  1 (for-each # …)
In standard/advanced-portfolio.scm:
   515:41  0 (_ #)

In procedure module-lookup: Unbound variable: parent-or-sibling?

___

I also have a problem with the same report on Win10 after upgrading to GNC 4.1. 
My traceback is slightly different so, in case that matters, here it is.

Report error

An error occurred while running the report.

  18 (apply-smob/1 #)
In c-interface.scm:
 24:4 17 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9 16 (catch #t # …)
In c-interface.scm:
29:37 15 (_)
In unknown file:
  14 (eval-string "(gnc:report-run 2)" #)
In ice-9/boot-9.scm:
   2312:4 13 (save-module-excursion #)
In ice-9/eval-string.scm:
 38:6 12 (read-and-eval # #:lang _)
In report-core.scm:
689:4 11 (gnc:report-run _)
In c-interface.scm:
 66:2 10 (gnc:backtrace-if-exception _ . _)
 24:4  9 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9  8 (catch #t # …)
In c-interface.scm:
28:40  7 (_)
In report-core.scm:
   691:29  6 (_)
   673:25  5 (gnc:report-render-html #< type: "21d7cfc59fc7…> …)
In standard/advanced-portfolio.scm:
  1057:10  4 (advanced-portfolio-renderer _)
In ice-9/boot-9.scm:
829:9  3 (catch div/0 # …)
In standard/advanced-portfolio.scm:
   428:10  2 (table-add-stock-rows #< col-headers: (("A…> …)
In srfi/srfi-1.scm:
640:9  1 (for-each # …)
In standard/advanced-portfolio.scm:
   570:43  0 (_ _)

In procedure module-lookup: Unbound variable: parent-or-sibling?
 
Best Regards,


John Bonnett

___
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] Import Transaction Matcher issue in v4

There is another use case which GnuCash also needs to handle.  Some OFX
files may contain both sides of an inter-account transfer between two
accounts within the same bank because the OFX file can include multiple
accounts.  In fact, I do that on a regular basis at one of my banks.  I do
not test GnuCash's handling of these because I want to get the separate
notes associated with each side and merge them together into the same
transaction in my data file.  Thus I deliberately call both of them New
rather than try to match them within the import process.  I have not
checked to see if they have unique FITID's, but they would be under
different ACCOUNTID's  and both can be accepted as New in release 2.6.19
and prior, which is the latest version that I use.  I suppose ideally I
would like gnuCash to detect this case and automatically apply the
corresponding notes to both sides of the  transfer, so I don't have to do
it manually.

David Carlson

On Mon, Jul 27, 2020 at 5:23 PM Fross, Michael  wrote:

> Got it. Thanks.  Now I understand why it used to work.  And I certainly
> wouldn't expect GnuCash to correct a bank's horrible behavior.  I'll keep
> an eye on the FITID and see if that's what they are doing.
>
> Thanks everyone for your help.  Much appreciated.
>
> Michael
>
> On Mon, Jul 27, 2020 at 5:13 PM Jean Laroche  wrote:
>
> > Ah, OK I get it now!
> > Yes, you should check that from one day to the next, the FTID returned
> > by citibank remains the same (for the same transaction). If not, then
> > that's going to be a problem.
> > What has changed recently with GC is that it not will not match a new
> > imported transaction with one from the register that has an online id.
> > Previous versions allowed that, so in your case, it's quite possible
> > that from one day to the next, the same transaction would be given a
> > different ID, but GC matched it to the same register transaction that
> > was previously matched.
> > So, on day 1, you'd match OFX1->Reg1, and on day two, you'd still match
> > OFX2 -> reg1, even though reg1 had already been matched to OFX1 the
> > previous day. So you'd see OFX2 appear as "match" and not "Add".
> >
> > The correct behavior is that OFX2 actually has the same ID as OFX1, and
> > it's entirely skipped by GC. But it seems that your bank is messing
> > their online ID, and this is what's causing the issue for you, along
> > with the new GC behavior.
> >
> > I'm not sure how to fix your problem. It's clearly a bank issue but
> > that's not terribly helpful as far as your problem goes. We should
> > probably add an option to defeat the new GC import behavior,
> > specifically for users like you whose bank send unreliable FTIDs/
> >
> > FYI, the new GC behavior was added because the old behavior was causing
> > issues with people who had recurring daily transactions: imagine buying
> > a cup of coffee every day: in that case GC will match all daily cups of
> > coffee to the same register transaction (within a date range, of course)
> > instead of adding the new one every day (which really is the correct way
> > to do it).
> >
> >
> >
> > Jean
> >
> >
> > On 7/27/20 2:45 PM, Fross, Michael wrote:
> > > Hi Jean.  Let me try to better explain my issue.
> > >
> > > On most days, I download QFX files from my Checking and Credit Card
> > > accounts and import them.  In this way I clear transactions and I can
> > > see what's going on.  The next day I'll do so again, and the importer
> > > skips those that have already been matched per your comment.s  I've
> been
> > > doing this for years and it's worked well.
> > >
> > > Since I updated to V4 the transactions that would have matched
> > > previously now come up with "Match Missing!" in the importer.  I don't
> > > want to add them as they would create duplicates.  Transactions that
> are
> > > not cleared seem to be able to be matched.  But those that are
> > > previously cleared get the "Match Missing!" issue.
> > >
> > > Now, based on what you told me, the QFX file for a problem transaction
> > > has a FITID that is one higher than the ONLINE_ID in the gnucash file
> > > for the same transaction.  So the Match Missing items seems to be
> > correct.
> > >
> > > If I duplicate the transaction, delete the original, it matches which I
> > > assume is because there is not an ONLINE_ID associated with the new
> one.
> > >
> > > What I don't understand is if there is an issue with GNUCash, which is
> > > why I asked if others are having the same issue, or if it is/was an
> > > issue with CITIBANK QFX files.  If they changed the FITID for some
> > > reason that would cause this.  Since no one else has said they are
> > > having the issue, I'm assuming this is not a GNUCash issue.
> > >
> > > Does that better explain the issue?
> > >
> > > I really appreciate the time to respond and help me through this.
> > >
> > > Michael
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jul 27, 2020 at 3:50 PM Jean Laroche  > >

Re: [GNC] Import Transaction Matcher issue in v4

Fross, Michael,

Are you trying to match bank payments to credit card accounts from QFX/OFX
downloads from both sides?  If so, the FITID's might accidentally match but
the FID and/or BANKID and/or  ACCTID of the bank/credit card transaction
split line in the import file should be different from the corresponding
transaction split imported from the other financial institution.  Thus,
even if there is a FITID associated to a different split line in the same
transaction, it should not prevent matching to an incoming transaction,
and, hopefully, GnuCash would not choke on transactions imported from both
sides.

On Mon, Jul 27, 2020 at 4:53 PM Fross, Michael  wrote:

> Hi Christopher.  Alas I do not keep the QFX files.  I'll hang on to them
> for now and see if the FIDID does change.
>
> On Mon, Jul 27, 2020 at 4:20 PM Christopher Lam  >
> wrote:
>
> > As I understand the ofx spec*, the fitid should be an invariant for the
> > bank and account. By any chance do you have older qfx files to compare?
> >
> > * https://www.ofx.net/downloads.html
> >
> > On Tue, 28 Jul 2020, 4:34 am Fross, Michael,  wrote:
> >
> >> Thanks Jean / John for your thoughts.  There is a register entry that
> >> matches, IMHO, very closely.   I increased the Match Display Threshold
> >> from
> >> 1 to 3, and then to 6 (which appears to be the highest value allowed.)
> >> Every transaction from the import says "Match Missing."
> >>
> >> Digging around a bit, for the transaction in question, the QFX file
> >> contains the FITID of 202007210003:
> >>
> >> 
> >> CREDIT
> >> 2020072112
> >> 54.00
> >> 202007210003
> >> ACH Electronic Credit
> >> Expenses
> >> 
> >>
> >> My GNUCash file contains, for the same transaction has the online id
> being
> >> 202007210002
> >> 
> >>   
> >> online_id
> >> 202007210002
> >>   
> >>
> >> The online_ID is ...002 instead of ...003.  Changing the QFX file to
> match
> >> the online_id value seemed to work.  Now my question is why would this
> be
> >> different for *lots* of transactions.  Everything worked normally in v3,
> >> but this would not have changed as part of the release.  I'll check a
> few
> >> more problem transactions and see if I can detect a pattern.  Perhaps
> >> Citibank is paying games
> >>
> >> Michael
> >>
> >> On Sun, Jul 26, 2020 at 4:57 PM jean laroche  wrote:
> >>
> >> > To get a match you have to have a transaction in the register that's
> >> > sufficiently similar to the one you're importing, and that has not
> been
> >> > imported/matched before.
> >> > In your case, it could be one of these reasons (I can't see the
> image):
> >> > - There's no matching transaction in your register (no existing
> >> > transaction has amount close, and a date close to the imported one)
> >> > - There's a matching transaction but it's already been matched to an
> >> > imported transaction at some point so it's not available to be matched
> >> > to the new imported one.
> >> > - There's a matching transaction that's available, but the match score
> >> > is below the threshold that allows the transaction to be shown as a
> >> > potential match. Too large a date mismatch can cause that.
> >> >
> >> > Can you check whether you're in one of these 3 cases? If you're in
> case
> >> > 3, you can lower the minimum matching threshold in the preferences and
> >> > see if that helps.
> >> > J.
> >> >
> >> >
> >> > On 7/26/2020 2:44 PM, John Ralls wrote:
> >> > > If there's no matching transaction already in the account then
> there's
> >> > nothing to clear. In that case only adding or not makes sense.
> >> > >
> >> > > Regards,
> >> > > John Ralls
> >> > >
> >> > >
> >> > >> On Jul 26, 2020, at 1:56 PM, Fross, Michael 
> >> wrote:
> >> > >>
> >> > >> Hello all,
> >> > >>
> >> > >> I sent this earlier this month and didn't see any reply so I
> thought
> >> I
> >> > >> would try again.   Has anyone else seen these issues?  I use
> Citibank
> >> > and
> >> > >> perhaps it's a Citibank issue, but I did not have this problem on
> v2
> >> or
> >> > v3.
> >> > >>
> >> > >> Thanks all.  I appreciate the help.
> >> > >>
> >> > >> Michael
> >> > >>
> >> > >>
> >> > >> On Sat, Jul 4, 2020 at 9:48 AM Fross, Michael 
> >> > wrote:
> >> > >>
> >> > >>> Hello all,
> >> > >>>
> >> > >>> I typically download QFX files from my banks every day or two,
> >> import
> >> > them
> >> > >>> to clear them in Gnucash.  Worked great.  However, ever since
> >> > upgrading to
> >> > >>> v4, the importer seems to have trouble matching.  Most of the
> >> imported
> >> > >>> transactions are listed in the importer as (A)dd, but when I
> select
> >> > >>> (C)lear for them it says match missing.
> >> > >>>
> >> > >>> This has occurred for several accounts.  Here is a simple credit
> >> card
> >> > >>> example, although for my checking account, there are dozens like
> >> > this.  The
> >> > >>> top portion shows the register with the Sprint bill cleared.  The
> >> date,
> >> > >>> amount,

Re: [GNC] Import Transaction Matcher issue in v4

Got it. Thanks.  Now I understand why it used to work.  And I certainly
wouldn't expect GnuCash to correct a bank's horrible behavior.  I'll keep
an eye on the FITID and see if that's what they are doing.

Thanks everyone for your help.  Much appreciated.

Michael

On Mon, Jul 27, 2020 at 5:13 PM Jean Laroche  wrote:

> Ah, OK I get it now!
> Yes, you should check that from one day to the next, the FTID returned
> by citibank remains the same (for the same transaction). If not, then
> that's going to be a problem.
> What has changed recently with GC is that it not will not match a new
> imported transaction with one from the register that has an online id.
> Previous versions allowed that, so in your case, it's quite possible
> that from one day to the next, the same transaction would be given a
> different ID, but GC matched it to the same register transaction that
> was previously matched.
> So, on day 1, you'd match OFX1->Reg1, and on day two, you'd still match
> OFX2 -> reg1, even though reg1 had already been matched to OFX1 the
> previous day. So you'd see OFX2 appear as "match" and not "Add".
>
> The correct behavior is that OFX2 actually has the same ID as OFX1, and
> it's entirely skipped by GC. But it seems that your bank is messing
> their online ID, and this is what's causing the issue for you, along
> with the new GC behavior.
>
> I'm not sure how to fix your problem. It's clearly a bank issue but
> that's not terribly helpful as far as your problem goes. We should
> probably add an option to defeat the new GC import behavior,
> specifically for users like you whose bank send unreliable FTIDs/
>
> FYI, the new GC behavior was added because the old behavior was causing
> issues with people who had recurring daily transactions: imagine buying
> a cup of coffee every day: in that case GC will match all daily cups of
> coffee to the same register transaction (within a date range, of course)
> instead of adding the new one every day (which really is the correct way
> to do it).
>
>
>
> Jean
>
>
> On 7/27/20 2:45 PM, Fross, Michael wrote:
> > Hi Jean.  Let me try to better explain my issue.
> >
> > On most days, I download QFX files from my Checking and Credit Card
> > accounts and import them.  In this way I clear transactions and I can
> > see what's going on.  The next day I'll do so again, and the importer
> > skips those that have already been matched per your comment.s  I've been
> > doing this for years and it's worked well.
> >
> > Since I updated to V4 the transactions that would have matched
> > previously now come up with "Match Missing!" in the importer.  I don't
> > want to add them as they would create duplicates.  Transactions that are
> > not cleared seem to be able to be matched.  But those that are
> > previously cleared get the "Match Missing!" issue.
> >
> > Now, based on what you told me, the QFX file for a problem transaction
> > has a FITID that is one higher than the ONLINE_ID in the gnucash file
> > for the same transaction.  So the Match Missing items seems to be
> correct.
> >
> > If I duplicate the transaction, delete the original, it matches which I
> > assume is because there is not an ONLINE_ID associated with the new one.
> >
> > What I don't understand is if there is an issue with GNUCash, which is
> > why I asked if others are having the same issue, or if it is/was an
> > issue with CITIBANK QFX files.  If they changed the FITID for some
> > reason that would cause this.  Since no one else has said they are
> > having the issue, I'm assuming this is not a GNUCash issue.
> >
> > Does that better explain the issue?
> >
> > I really appreciate the time to respond and help me through this.
> >
> > Michael
> >
> >
> >
> >
> >
> >
> > On Mon, Jul 27, 2020 at 3:50 PM Jean Laroche  > > wrote:
> >
> > There's a misunderstanding here.
> > This is what GC does:
> > - It looks at the OFX transaction, which always has an FITID.
> > - IF GC sees this FITID in one of the register transactions, it skips
> > the OFX transaction, because it's already been imported (when a
> > transaction gets imported from the ofx, the online_id is copied into
> > the
> > register transaction, that's how GC remembers it's already imported
> the
> > transaction).
> > - If the FITID is not found in the register, GC assumes that this is
> a
> > new transaction and attempts to match it with existing transactions
> in
> > your register. BUT:
> >  . It only looks at register transactions that have NO FITID
> (i.e.,
> > register transactions that you entered manually, typically)
> >  . Among those, it looks for transactions that match pretty
> closely
> > for the date and the amount.
> >  . It picks the one with the highest matching score, if that
> > score is
> > above a user-adjustable threshold.
> >
> > So in the case you outline below, if the register transaction has the
> > same FITID

Re: [GNC] Import Transaction Matcher issue in v4

2020-07-27 Thread Jean Laroche

Ah, OK I get it now!
Yes, you should check that from one day to the next, the FTID returned 
by citibank remains the same (for the same transaction). If not, then 
that's going to be a problem.
What has changed recently with GC is that it not will not match a new 
imported transaction with one from the register that has an online id. 
Previous versions allowed that, so in your case, it's quite possible 
that from one day to the next, the same transaction would be given a 
different ID, but GC matched it to the same register transaction that 
was previously matched.
So, on day 1, you'd match OFX1->Reg1, and on day two, you'd still match 
OFX2 -> reg1, even though reg1 had already been matched to OFX1 the 
previous day. So you'd see OFX2 appear as "match" and not "Add".

The correct behavior is that OFX2 actually has the same ID as OFX1, and 
it's entirely skipped by GC. But it seems that your bank is messing 
their online ID, and this is what's causing the issue for you, along 
with the new GC behavior.

I'm not sure how to fix your problem. It's clearly a bank issue but 
that's not terribly helpful as far as your problem goes. We should 
probably add an option to defeat the new GC import behavior, 
specifically for users like you whose bank send unreliable FTIDs/

FYI, the new GC behavior was added because the old behavior was causing 
issues with people who had recurring daily transactions: imagine buying 
a cup of coffee every day: in that case GC will match all daily cups of 
coffee to the same register transaction (within a date range, of course) 
instead of adding the new one every day (which really is the correct way 
to do it).

Jean

On 7/27/20 2:45 PM, Fross, Michael wrote:

Hi Jean.  Let me try to better explain my issue.

On most days, I download QFX files from my Checking and Credit Card 
accounts and import them.  In this way I clear transactions and I can 
see what's going on.  The next day I'll do so again, and the importer 
skips those that have already been matched per your comment.s  I've been 
doing this for years and it's worked well.

Since I updated to V4 the transactions that would have matched 
previously now come up with "Match Missing!" in the importer.  I don't 
want to add them as they would create duplicates.  Transactions that are 
not cleared seem to be able to be matched.  But those that are 
previously cleared get the "Match Missing!" issue.

Now, based on what you told me, the QFX file for a problem transaction 
has a FITID that is one higher than the ONLINE_ID in the gnucash file 
for the same transaction.  So the Match Missing items seems to be correct.

If I duplicate the transaction, delete the original, it matches which I 
assume is because there is not an ONLINE_ID associated with the new one.

What I don't understand is if there is an issue with GNUCash, which is 
why I asked if others are having the same issue, or if it is/was an 
issue with CITIBANK QFX files.  If they changed the FITID for some 
reason that would cause this.  Since no one else has said they are 
having the issue, I'm assuming this is not a GNUCash issue.

Does that better explain the issue?

I really appreciate the time to respond and help me through this.

Michael

On Mon, Jul 27, 2020 at 3:50 PM Jean Laroche > wrote:

There's a misunderstanding here.
This is what GC does:
- It looks at the OFX transaction, which always has an FITID.
- IF GC sees this FITID in one of the register transactions, it skips
the OFX transaction, because it's already been imported (when a
transaction gets imported from the ofx, the online_id is copied into
the
register transaction, that's how GC remembers it's already imported the
transaction).
- If the FITID is not found in the register, GC assumes that this is a
new transaction and attempts to match it with existing transactions in
your register. BUT:
     . It only looks at register transactions that have NO FITID (i.e.,
register transactions that you entered manually, typically)
     . Among those, it looks for transactions that match pretty closely
for the date and the amount.
     . It picks the one with the highest matching score, if that
score is
above a user-adjustable threshold.

So in the case you outline below, if the register transaction has the
same FITID as your ofx transaction, the ofx transaction will NOT be
imported (it will be just skipped).

I think I don't quite understand the problem you're having. Is it that
you're importing OFX transaction and they're not matching register
transactions that you entered manually?
Or is it that they're being imported despite the fact they were
imported
previously?

J.

On 7/27/20 1:31 PM, Fross, Michael wrote:
 > Thanks Jean / John for your thoughts.  There is a register entry
that
 > matches, IMHO, very closely.   I increased the Match Disp

Re: [GNC] Import Transaction Matcher issue in v4

No. Section 3.2.3 of the OFX 1.6 spec:
"An FI (or its Service Provider) assigns an  to uniquely identify a 
financial transaction
that can appear in an account statement. Its primary purpose is to allow a 
client to detect
duplicate responses. Open Financial Exchange intends  for use in 
statement download
applications, where every transaction (not just those that are 
client-originated or serveroriginated)
requires a unique ID."

Regards,
John Ralls



> On Jul 27, 2020, at 2:20 PM, Christopher Lam  
> wrote:
> 
> As I understand the ofx spec*, the fitid should be an invariant for the
> bank and account. By any chance do you have older qfx files to compare?
> 
> * https://www.ofx.net/downloads.html
> 
> On Tue, 28 Jul 2020, 4:34 am Fross, Michael,  wrote:
> 
>> Thanks Jean / John for your thoughts.  There is a register entry that
>> matches, IMHO, very closely.   I increased the Match Display Threshold from
>> 1 to 3, and then to 6 (which appears to be the highest value allowed.)
>> Every transaction from the import says "Match Missing."
>> 
>> Digging around a bit, for the transaction in question, the QFX file
>> contains the FITID of 202007210003:
>> 
>> 
>> CREDIT
>> 2020072112
>> 54.00
>> 202007210003
>> ACH Electronic Credit
>> Expenses
>> 
>> 
>> My GNUCash file contains, for the same transaction has the online id being
>> 202007210002
>>
>>  
>>online_id
>>202007210002
>>  
>> 
>> The online_ID is ...002 instead of ...003.  Changing the QFX file to match
>> the online_id value seemed to work.  Now my question is why would this be
>> different for *lots* of transactions.  Everything worked normally in v3,
>> but this would not have changed as part of the release.  I'll check a few
>> more problem transactions and see if I can detect a pattern.  Perhaps
>> Citibank is paying games
>> 
>> Michael
>> 
>> On Sun, Jul 26, 2020 at 4:57 PM jean laroche  wrote:
>> 
>>> To get a match you have to have a transaction in the register that's
>>> sufficiently similar to the one you're importing, and that has not been
>>> imported/matched before.
>>> In your case, it could be one of these reasons (I can't see the image):
>>> - There's no matching transaction in your register (no existing
>>> transaction has amount close, and a date close to the imported one)
>>> - There's a matching transaction but it's already been matched to an
>>> imported transaction at some point so it's not available to be matched
>>> to the new imported one.
>>> - There's a matching transaction that's available, but the match score
>>> is below the threshold that allows the transaction to be shown as a
>>> potential match. Too large a date mismatch can cause that.
>>> 
>>> Can you check whether you're in one of these 3 cases? If you're in case
>>> 3, you can lower the minimum matching threshold in the preferences and
>>> see if that helps.
>>> J.
>>> 
>>> 
>>> On 7/26/2020 2:44 PM, John Ralls wrote:
 If there's no matching transaction already in the account then there's
>>> nothing to clear. In that case only adding or not makes sense.
 
 Regards,
 John Ralls
 
 
> On Jul 26, 2020, at 1:56 PM, Fross, Michael 
>> wrote:
> 
> Hello all,
> 
> I sent this earlier this month and didn't see any reply so I thought I
> would try again.   Has anyone else seen these issues?  I use Citibank
>>> and
> perhaps it's a Citibank issue, but I did not have this problem on v2
>> or
>>> v3.
> 
> Thanks all.  I appreciate the help.
> 
> Michael
> 
> 
> On Sat, Jul 4, 2020 at 9:48 AM Fross, Michael 
>>> wrote:
> 
>> Hello all,
>> 
>> I typically download QFX files from my banks every day or two, import
>>> them
>> to clear them in Gnucash.  Worked great.  However, ever since
>>> upgrading to
>> v4, the importer seems to have trouble matching.  Most of the
>> imported
>> transactions are listed in the importer as (A)dd, but when I select
>> (C)lear for them it says match missing.
>> 
>> This has occurred for several accounts.  Here is a simple credit card
>> example, although for my checking account, there are dozens like
>>> this.  The
>> top portion shows the register with the Sprint bill cleared.  The
>> date,
>> amount, and name (mostly) match.
>> 
>> [image: image.png]
>> 
>> Not sure if there is just something wrong with my setup or not.
>>> Perhaps a
>> bug?  Are others experiencing this?  Any ideas to get the matcher
>>> matching
>> again?  Something need to get cleared out?
>> 
>> For those of us in the US, happy Independence Day.  Thank you all for
>>> your
>> assistance.
>> 
>> Michael
>> 
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnuc

Re: [GNC] GTK CSS 4.0-4.1

2020-07-27 Thread Chris Graves

Here ya go.

/* This is an example GTK CSS file that can be used with Gnucash.
   Simply copy this file to the location specified below according
   to your platform and then restart gnucash.

  - Windows: CSIDL_APPDATA/GnuCash
(or the default is users\%USERNAME%\AppData\Roaming\GnuCash)

  - OS X: $HOME/Application Support/GnuCash

  - Linux: $XDG_CONFIG_HOME/gnucash
(or the default is $HOME/.config/gnucash)

  These settings are mainly to do with register colors and can be seen
  when the preference setting 'Register\Use GnuCash built-in color theme'
  is unset.

  Note: Widgets obtained from Glade files will not be addressable
  directly by name as these are not brought in when loaded, only
  the widget type can be configured unless they are named in code.
*/


/* Application wide font setting */
* {
  font: 12px arial;
}


/* Scollbar size */
scrollbar slider {
/* Size of the slider */
min-width: 20px;
min-height: 20px;
border-radius: 22px;

/* Padding around the slider */
border: 5px solid transparent;
}


/* Register sheet font setting */
gnc-id-sheet {
  font: 10px arial;
}


/* Register header font setting */
gnc-id-header {
  background-color: pink;
  color:blue;
}


/* Register cursor font setting */
gnc-id-cursor {
  background-color: #BDB76B;
  color: white;
}

gnc-id-cursor button {
  border-width: 1px;
  border-color: green;
}


/* Register sheet calendar */
gnc-id-sheet calendar {
  font: 13px arial;
  background-color:lightgreen;
  border-color: green;
  border-width: 1px;
}


/* Register User Colors, remove 'user' for builtin register values */
.gnc-class-user-register-header {
  background-color: seagreen;
  color: white;
}

.gnc-class-user-register-primary {
  background-color: pink;
}

.gnc-class-user-register-primary:disabled {
  background-color: plum;
}

.gnc-class-user-register-secondary {
  background-color: lightgreen;
}

.gnc-class-user-register-secondary:disabled {
  background-color: plum;
}

.gnc-class-user-register-split {
  background-color: lightblue;
}

.gnc-class-user-register-split:disabled {
  background-color: plum;
}

.gnc-class-user-register-cursor {
  background-color: #00BFFF;
  color: white;
  border-radius: 0px;
}


/* Toolbar Button size and spacing */
toolbar {
  background-color: darkgrey;
}

/* Toolbar font size, 0 to remove text */
toolbar toolbutton label {
  font-size: 0px;
}

toolbar toolbutton button {
  padding-left: 4px;
  padding-right: 4px;
}

toolbar toolbutton label {
  padding-left: 4px;
  padding-right: 4px;
}


/* Negative number color */
.gnc-class-negative-numbers {
  color: orange;
}


/* Gnucash Main Window, reduce size */
#gnc-id-main-window notebook tab {
  min-height: 0px;
  min-width: 0px;
  padding-top: 3px;
  padding-bottom: 3px;
  margin-top: 0px;
  margin-bottom: 0px;
  border-top: 0px;
  border-bottom: 0px;
}

#gnc-id-main-window notebook label {
  font: 14px arial, sans-serif;
}

#gnc-id-main-window notebook tab button {
  min-height: 0;
  min-width: 0;
  padding: 0px;
  margin-top: 0px;
  margin-bottom: 0px;
}


/* Dense Calendar Settings, use widget name gnc-id-dense-calendar
 * or gtk css name calendar which would also apply to other calendar
 * widgets */
#gnc-id-dense-calendar .frame {
  border-color: blue;
  border-width: 1px;
}

calendar .frame {
  border-color: blue;
  border-width: 1px;
}

#gnc-id-dense-calendar .header {
 background-color: lightgreen;
}

calendar .header {
 background-color: lightgreen;
}

#gnc-id-dense-calendar .primary {
  background-color: darksalmon;
}

#gnc-id-dense-calendar .secondary {
  background-color: darkseagreen;
}

#gnc-id-dense-calendar .markers {
  background-color: indianred;
}

#gnc-id-dense-calendar-popup {
  background-color: darksalmon;
  color: black;
}

#gnc-id-dense-calendar-popup treeview {
  background-color: lightcoral;
}


/* Progress bar */
progressbar progress {
  background-color: lime;
}


/* Status Bar */
statusbar frame {
  margin-top: 0px;
  margin-bottom: 0px;
}

statusbar label {
  font-size: 12px;
  color: red;
}


/* Reconcile Window */
#gnc-id-reconcile-totals * {
  background-color: darkgrey;
}

.gnc-class-credits treeview {
  background-color: pink;
}

.gnc-class-credits treeview:selected {
  background-color: cornflowerblue;
  color: white;
}

.gnc-class-debits treeview {
  background-color: lightblue;
}

.gnc-class-debits treeview:selected {
  background-color: cornflowerblue;
  color: white;
}


/* Highlight Text */
.gnc-class-highlight {
  color: blue;
}


/* Summary bar */
#gnc-id-summarybar {
  background-color:lightblue;
}

#gnc-id-summarybar .gnc-class-highlight {
  color: red;
}


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

Re: [GNC] GTK CSS 4.0-4.1

Chris can you upload a copy here

I want to compare with my GNC 3.91 custom CSS that I had and worked, maybe
they changed the css tags

I I have installed Flatpack GNC, cannot find a css for it

I spent weeks before customizing my own before

Having issues with the concept using the gtkinspector in plain english, I
don't have a free month

Thanks



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
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] Import Transaction Matcher issue in v4

Hi Christopher.  Alas I do not keep the QFX files.  I'll hang on to them
for now and see if the FIDID does change.

On Mon, Jul 27, 2020 at 4:20 PM Christopher Lam 
wrote:

> As I understand the ofx spec*, the fitid should be an invariant for the
> bank and account. By any chance do you have older qfx files to compare?
>
> * https://www.ofx.net/downloads.html
>
> On Tue, 28 Jul 2020, 4:34 am Fross, Michael,  wrote:
>
>> Thanks Jean / John for your thoughts.  There is a register entry that
>> matches, IMHO, very closely.   I increased the Match Display Threshold
>> from
>> 1 to 3, and then to 6 (which appears to be the highest value allowed.)
>> Every transaction from the import says "Match Missing."
>>
>> Digging around a bit, for the transaction in question, the QFX file
>> contains the FITID of 202007210003:
>>
>> 
>> CREDIT
>> 2020072112
>> 54.00
>> 202007210003
>> ACH Electronic Credit
>> Expenses
>> 
>>
>> My GNUCash file contains, for the same transaction has the online id being
>> 202007210002
>> 
>>   
>> online_id
>> 202007210002
>>   
>>
>> The online_ID is ...002 instead of ...003.  Changing the QFX file to match
>> the online_id value seemed to work.  Now my question is why would this be
>> different for *lots* of transactions.  Everything worked normally in v3,
>> but this would not have changed as part of the release.  I'll check a few
>> more problem transactions and see if I can detect a pattern.  Perhaps
>> Citibank is paying games
>>
>> Michael
>>
>> On Sun, Jul 26, 2020 at 4:57 PM jean laroche  wrote:
>>
>> > To get a match you have to have a transaction in the register that's
>> > sufficiently similar to the one you're importing, and that has not been
>> > imported/matched before.
>> > In your case, it could be one of these reasons (I can't see the image):
>> > - There's no matching transaction in your register (no existing
>> > transaction has amount close, and a date close to the imported one)
>> > - There's a matching transaction but it's already been matched to an
>> > imported transaction at some point so it's not available to be matched
>> > to the new imported one.
>> > - There's a matching transaction that's available, but the match score
>> > is below the threshold that allows the transaction to be shown as a
>> > potential match. Too large a date mismatch can cause that.
>> >
>> > Can you check whether you're in one of these 3 cases? If you're in case
>> > 3, you can lower the minimum matching threshold in the preferences and
>> > see if that helps.
>> > J.
>> >
>> >
>> > On 7/26/2020 2:44 PM, John Ralls wrote:
>> > > If there's no matching transaction already in the account then there's
>> > nothing to clear. In that case only adding or not makes sense.
>> > >
>> > > Regards,
>> > > John Ralls
>> > >
>> > >
>> > >> On Jul 26, 2020, at 1:56 PM, Fross, Michael 
>> wrote:
>> > >>
>> > >> Hello all,
>> > >>
>> > >> I sent this earlier this month and didn't see any reply so I thought
>> I
>> > >> would try again.   Has anyone else seen these issues?  I use Citibank
>> > and
>> > >> perhaps it's a Citibank issue, but I did not have this problem on v2
>> or
>> > v3.
>> > >>
>> > >> Thanks all.  I appreciate the help.
>> > >>
>> > >> Michael
>> > >>
>> > >>
>> > >> On Sat, Jul 4, 2020 at 9:48 AM Fross, Michael 
>> > wrote:
>> > >>
>> > >>> Hello all,
>> > >>>
>> > >>> I typically download QFX files from my banks every day or two,
>> import
>> > them
>> > >>> to clear them in Gnucash.  Worked great.  However, ever since
>> > upgrading to
>> > >>> v4, the importer seems to have trouble matching.  Most of the
>> imported
>> > >>> transactions are listed in the importer as (A)dd, but when I select
>> > >>> (C)lear for them it says match missing.
>> > >>>
>> > >>> This has occurred for several accounts.  Here is a simple credit
>> card
>> > >>> example, although for my checking account, there are dozens like
>> > this.  The
>> > >>> top portion shows the register with the Sprint bill cleared.  The
>> date,
>> > >>> amount, and name (mostly) match.
>> > >>>
>> > >>> [image: image.png]
>> > >>>
>> > >>> Not sure if there is just something wrong with my setup or not.
>> > Perhaps a
>> > >>> bug?  Are others experiencing this?  Any ideas to get the matcher
>> > matching
>> > >>> again?  Something need to get cleared out?
>> > >>>
>> > >>> For those of us in the US, happy Independence Day.  Thank you all
>> for
>> > your
>> > >>> assistance.
>> > >>>
>> > >>> Michael
>> > >>>
>> > >> ___
>> > >> 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

Re: [GNC] Import Transaction Matcher issue in v4

Hi Jean.  Let me try to better explain my issue.

On most days, I download QFX files from my Checking and Credit Card
accounts and import them.  In this way I clear transactions and I can see
what's going on.  The next day I'll do so again, and the importer skips
those that have already been matched per your comment.s  I've been doing
this for years and it's worked well.

Since I updated to V4 the transactions that would have matched previously
now come up with "Match Missing!" in the importer.  I don't want to add
them as they would create duplicates.  Transactions that are not cleared
seem to be able to be matched.  But those that are previously cleared get
the "Match Missing!" issue.

Now, based on what you told me, the QFX file for a problem transaction has
a FITID that is one higher than the ONLINE_ID in the gnucash file for the
same transaction.  So the Match Missing items seems to be correct.

If I duplicate the transaction, delete the original, it matches which I
assume is because there is not an ONLINE_ID associated with the new one.

What I don't understand is if there is an issue with GNUCash, which is why
I asked if others are having the same issue, or if it is/was an issue with
CITIBANK QFX files.  If they changed the FITID for some reason that would
cause this.  Since no one else has said they are having the issue, I'm
assuming this is not a GNUCash issue.

Does that better explain the issue?

I really appreciate the time to respond and help me through this.

Michael

On Mon, Jul 27, 2020 at 3:50 PM Jean Laroche  wrote:

> There's a misunderstanding here.
> This is what GC does:
> - It looks at the OFX transaction, which always has an FITID.
> - IF GC sees this FITID in one of the register transactions, it skips
> the OFX transaction, because it's already been imported (when a
> transaction gets imported from the ofx, the online_id is copied into the
> register transaction, that's how GC remembers it's already imported the
> transaction).
> - If the FITID is not found in the register, GC assumes that this is a
> new transaction and attempts to match it with existing transactions in
> your register. BUT:
> . It only looks at register transactions that have NO FITID (i.e.,
> register transactions that you entered manually, typically)
> . Among those, it looks for transactions that match pretty closely
> for the date and the amount.
> . It picks the one with the highest matching score, if that score is
> above a user-adjustable threshold.
>
> So in the case you outline below, if the register transaction has the
> same FITID as your ofx transaction, the ofx transaction will NOT be
> imported (it will be just skipped).
>
> I think I don't quite understand the problem you're having. Is it that
> you're importing OFX transaction and they're not matching register
> transactions that you entered manually?
> Or is it that they're being imported despite the fact they were imported
> previously?
>
> J.
>
> On 7/27/20 1:31 PM, Fross, Michael wrote:
> > Thanks Jean / John for your thoughts.  There is a register entry that
> > matches, IMHO, very closely.   I increased the Match Display Threshold
> > from 1 to 3, and then to 6 (which appears to be the highest value
> > allowed.)  Every transaction from the import says "Match Missing."
> >
> > Digging around a bit, for the transaction in question, the QFX file
> > contains the FITID of 202007210003:
> >
> > 
> > CREDIT
> > 2020072112
> > 54.00
> > 202007210003
> > ACH Electronic Credit
> > Expenses
> > 
> >
> > My GNUCash file contains, for the same transaction has the online id
> > being 202007210002
> >  
> >
> >  online_id
> >  202007210002
> >
> >
> > The online_ID is ...002 instead of ...003.  Changing the QFX file to
> > match the online_id value seemed to work.  Now my question is why would
> > this be different for *lots* of transactions.  Everything worked
> > normally in v3, but this would not have changed as part of the release.
> > I'll check a few more problem transactions and see if I can detect a
> > pattern.  Perhaps Citibank is paying games
> >
> > Michael
> >
> > On Sun, Jul 26, 2020 at 4:57 PM jean laroche  > > wrote:
> >
> > To get a match you have to have a transaction in the register that's
> > sufficiently similar to the one you're importing, and that has not
> been
> > imported/matched before.
> > In your case, it could be one of these reasons (I can't see the
> image):
> > - There's no matching transaction in your register (no existing
> > transaction has amount close, and a date close to the imported one)
> > - There's a matching transaction but it's already been matched to an
> > imported transaction at some point so it's not available to be
> matched
> > to the new imported one.
> > - There's a matching transaction that's available, but the match
> score
> > is below the threshold th

Re: [GNC] BotanyBayGardens nonprofit example, and why GnuCash does not suffice

I suppose mileage varies. In my experience, I've seen a case or two 
(different businesses) where the bank had another signatory appear in 
person to sign the check before they would honor it.


If your bank offers this protection, I'd certainly bring it to their 
attention when they aren't enforcing it. (which should also be audited 
internally, I agree)


Regards,
Adrien

On 7/27/20 3:50 PM, Dale Alspach wrote:

I would not put much faith in requiring two signatures. It is unlikely that
the bank is actually paying any attention to this requirement.  I learned
this from a former bank employee who was on the board of a nonprofit I work
with. In other words it is an internal control only.


___
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] Import Transaction Matcher issue in v4

2020-07-27 Thread Christopher Lam

As I understand the ofx spec*, the fitid should be an invariant for the
bank and account. By any chance do you have older qfx files to compare?

* https://www.ofx.net/downloads.html

On Tue, 28 Jul 2020, 4:34 am Fross, Michael,  wrote:

> Thanks Jean / John for your thoughts.  There is a register entry that
> matches, IMHO, very closely.   I increased the Match Display Threshold from
> 1 to 3, and then to 6 (which appears to be the highest value allowed.)
> Every transaction from the import says "Match Missing."
>
> Digging around a bit, for the transaction in question, the QFX file
> contains the FITID of 202007210003:
>
> 
> CREDIT
> 2020072112
> 54.00
> 202007210003
> ACH Electronic Credit
> Expenses
> 
>
> My GNUCash file contains, for the same transaction has the online id being
> 202007210002
> 
>   
> online_id
> 202007210002
>   
>
> The online_ID is ...002 instead of ...003.  Changing the QFX file to match
> the online_id value seemed to work.  Now my question is why would this be
> different for *lots* of transactions.  Everything worked normally in v3,
> but this would not have changed as part of the release.  I'll check a few
> more problem transactions and see if I can detect a pattern.  Perhaps
> Citibank is paying games
>
> Michael
>
> On Sun, Jul 26, 2020 at 4:57 PM jean laroche  wrote:
>
> > To get a match you have to have a transaction in the register that's
> > sufficiently similar to the one you're importing, and that has not been
> > imported/matched before.
> > In your case, it could be one of these reasons (I can't see the image):
> > - There's no matching transaction in your register (no existing
> > transaction has amount close, and a date close to the imported one)
> > - There's a matching transaction but it's already been matched to an
> > imported transaction at some point so it's not available to be matched
> > to the new imported one.
> > - There's a matching transaction that's available, but the match score
> > is below the threshold that allows the transaction to be shown as a
> > potential match. Too large a date mismatch can cause that.
> >
> > Can you check whether you're in one of these 3 cases? If you're in case
> > 3, you can lower the minimum matching threshold in the preferences and
> > see if that helps.
> > J.
> >
> >
> > On 7/26/2020 2:44 PM, John Ralls wrote:
> > > If there's no matching transaction already in the account then there's
> > nothing to clear. In that case only adding or not makes sense.
> > >
> > > Regards,
> > > John Ralls
> > >
> > >
> > >> On Jul 26, 2020, at 1:56 PM, Fross, Michael 
> wrote:
> > >>
> > >> Hello all,
> > >>
> > >> I sent this earlier this month and didn't see any reply so I thought I
> > >> would try again.   Has anyone else seen these issues?  I use Citibank
> > and
> > >> perhaps it's a Citibank issue, but I did not have this problem on v2
> or
> > v3.
> > >>
> > >> Thanks all.  I appreciate the help.
> > >>
> > >> Michael
> > >>
> > >>
> > >> On Sat, Jul 4, 2020 at 9:48 AM Fross, Michael 
> > wrote:
> > >>
> > >>> Hello all,
> > >>>
> > >>> I typically download QFX files from my banks every day or two, import
> > them
> > >>> to clear them in Gnucash.  Worked great.  However, ever since
> > upgrading to
> > >>> v4, the importer seems to have trouble matching.  Most of the
> imported
> > >>> transactions are listed in the importer as (A)dd, but when I select
> > >>> (C)lear for them it says match missing.
> > >>>
> > >>> This has occurred for several accounts.  Here is a simple credit card
> > >>> example, although for my checking account, there are dozens like
> > this.  The
> > >>> top portion shows the register with the Sprint bill cleared.  The
> date,
> > >>> amount, and name (mostly) match.
> > >>>
> > >>> [image: image.png]
> > >>>
> > >>> Not sure if there is just something wrong with my setup or not.
> > Perhaps a
> > >>> bug?  Are others experiencing this?  Any ideas to get the matcher
> > matching
> > >>> again?  Something need to get cleared out?
> > >>>
> > >>> For those of us in the US, happy Independence Day.  Thank you all for
> > your
> > >>> assistance.
> > >>>
> > >>> Michael
> > >>>
> > >> ___
> > >> 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 Gman

Re: [GNC] Import Transaction Matcher issue in v4

2020-07-27 Thread Jean Laroche


There's a misunderstanding here.
This is what GC does:
- It looks at the OFX transaction, which always has an FITID.
- IF GC sees this FITID in one of the register transactions, it skips 
the OFX transaction, because it's already been imported (when a 
transaction gets imported from the ofx, the online_id is copied into the 
register transaction, that's how GC remembers it's already imported the 
transaction).
- If the FITID is not found in the register, GC assumes that this is a 
new transaction and attempts to match it with existing transactions in 
your register. BUT:
   . It only looks at register transactions that have NO FITID (i.e., 
register transactions that you entered manually, typically)
   . Among those, it looks for transactions that match pretty closely 
for the date and the amount.
   . It picks the one with the highest matching score, if that score is 
above a user-adjustable threshold.


So in the case you outline below, if the register transaction has the 
same FITID as your ofx transaction, the ofx transaction will NOT be 
imported (it will be just skipped).


I think I don't quite understand the problem you're having. Is it that 
you're importing OFX transaction and they're not matching register 
transactions that you entered manually?
Or is it that they're being imported despite the fact they were imported 
previously?


J.

On 7/27/20 1:31 PM, Fross, Michael wrote:
Thanks Jean / John for your thoughts.  There is a register entry that 
matches, IMHO, very closely.   I increased the Match Display Threshold 
from 1 to 3, and then to 6 (which appears to be the highest value 
allowed.)  Every transaction from the import says "Match Missing."


Digging around a bit, for the transaction in question, the QFX file 
contains the FITID of 202007210003:



CREDIT
2020072112
54.00
202007210003
ACH Electronic Credit
Expenses


My GNUCash file contains, for the same transaction has the online id 
being 202007210002

         
           
             online_id
             202007210002
           

The online_ID is ...002 instead of ...003.  Changing the QFX file to 
match the online_id value seemed to work.  Now my question is why would 
this be different for *lots* of transactions.  Everything worked 
normally in v3, but this would not have changed as part of the release.  
I'll check a few more problem transactions and see if I can detect a 
pattern.  Perhaps Citibank is paying games


Michael

On Sun, Jul 26, 2020 at 4:57 PM jean laroche > wrote:


To get a match you have to have a transaction in the register that's
sufficiently similar to the one you're importing, and that has not been
imported/matched before.
In your case, it could be one of these reasons (I can't see the image):
- There's no matching transaction in your register (no existing
transaction has amount close, and a date close to the imported one)
- There's a matching transaction but it's already been matched to an
imported transaction at some point so it's not available to be matched
to the new imported one.
- There's a matching transaction that's available, but the match score
is below the threshold that allows the transaction to be shown as a
potential match. Too large a date mismatch can cause that.

Can you check whether you're in one of these 3 cases? If you're in case
3, you can lower the minimum matching threshold in the preferences and
see if that helps.
J.


On 7/26/2020 2:44 PM, John Ralls wrote:
 > If there's no matching transaction already in the account then
there's nothing to clear. In that case only adding or not makes sense.
 >
 > Regards,
 > John Ralls
 >
 >
 >> On Jul 26, 2020, at 1:56 PM, Fross, Michael mailto:mich...@fross.org>> wrote:
 >>
 >> Hello all,
 >>
 >> I sent this earlier this month and didn't see any reply so I
thought I
 >> would try again.   Has anyone else seen these issues?  I use
Citibank and
 >> perhaps it's a Citibank issue, but I did not have this problem
on v2 or v3.
 >>
 >> Thanks all.  I appreciate the help.
 >>
 >> Michael
 >>
 >>
 >> On Sat, Jul 4, 2020 at 9:48 AM Fross, Michael mailto:mich...@fross.org>> wrote:
 >>
 >>> Hello all,
 >>>
 >>> I typically download QFX files from my banks every day or two,
import them
 >>> to clear them in Gnucash.  Worked great.  However, ever since
upgrading to
 >>> v4, the importer seems to have trouble matching.  Most of the
imported
 >>> transactions are listed in the importer as (A)dd, but when I select
 >>> (C)lear for them it says match missing.
 >>>
 >>> This has occurred for several accounts.  Here is a simple
credit card
 >>> example, although for my checking account, there are dozens
like this.  The
 >>> top portion shows the register with the Sprint bill cleared. 
The date,

Re: [GNC] BotanyBayGardens nonprofit example, and why GnuCash does not suffice

2020-07-27 Thread Dale Alspach

I would not put much faith in requiring two signatures. It is unlikely that
the bank is actually paying any attention to this requirement.  I learned
this from a former bank employee who was on the board of a nonprofit I work
with. In other words it is an internal control only.

Dale

On Mon, Jul 27, 2020, 3:01 PM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> All but one business or non-profit I've worked for or with had a
> two-person signature rule. (over a certain small amount) One still
> writes paper checks to keep that standard. (not sure myself how that is
> handled electronically)
>
> For the one business that allowed only one signature for any amount, it
> was a mom & pop business, in a small town, with a small town bank, with
> signature images on file and all of the tellers personally know the
> business owners. (who are the only ones approved to sign checks) They
> did have a rule with the bank that if over a certain high amount, the
> bank had to speak to the other owner to confirm the check. *All* checks
> had to be made with an 'imprinter' and could not have their amounts hand
> written.
>
> Regards,
> Adrien
>
> On 7/26/20 10:39 AM, John Ralls wrote:
>
> >
> > Incidentally, the textbook also says that checks should ideally require
> two signatures. I don't know how to impose that control over electronic
> transfers but the local newspaper reports two or three cases of
> embezzlement a year where it's obvious that a two-person control would have
> prevented the crime.
>
> ___
> 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] GTK CSS 4.0-4.1

2020-07-27 Thread Chris Graves

There is an example .css file which ships with Gnucash.  On macOS, it’s located 
here:
/Applications/Gnucash.app/Contents/Resources/share/doc/gnucash/gtk-3.0.css

> On Jul 27, 2020, at 7:56 AM, GTI .H  wrote:
> 
> I would like it too. but for that we have to run the GtkInspector (
> https://wiki.gnome.org/action/show/Projects/GTK/Inspector?action=show&redirect=Projects%2FGTK%2B%2FInspector)
> and it doesn't run on Windows and nobody with an OS that runs GtkInspector
> so far hasn’t offered to help.
> 
> --
> Regards
> 
> Em seg., 27 de jul. de 2020 às 09:07, Jimmy R via gnucash-user <
> gnucash-user@gnucash.org> escreveu:
> 
>> Has anyone figured out yet if we can use our custom css.
>> Would like to get my font sizes and colors back if possible
>> 
>> 
>> 
>> --
>> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
>> ___
>> 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.
>> 
> 
> 
> -- 
> Regards
> GTI
> ___
> 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] Import Transaction Matcher issue in v4

Thanks Jean / John for your thoughts.  There is a register entry that
matches, IMHO, very closely.   I increased the Match Display Threshold from
1 to 3, and then to 6 (which appears to be the highest value allowed.)
Every transaction from the import says "Match Missing."

Digging around a bit, for the transaction in question, the QFX file
contains the FITID of 202007210003:


CREDIT
2020072112
54.00
202007210003
ACH Electronic Credit
Expenses


My GNUCash file contains, for the same transaction has the online id being
202007210002

  
online_id
202007210002
  

The online_ID is ...002 instead of ...003.  Changing the QFX file to match
the online_id value seemed to work.  Now my question is why would this be
different for *lots* of transactions.  Everything worked normally in v3,
but this would not have changed as part of the release.  I'll check a few
more problem transactions and see if I can detect a pattern.  Perhaps
Citibank is paying games

Michael

On Sun, Jul 26, 2020 at 4:57 PM jean laroche  wrote:

> To get a match you have to have a transaction in the register that's
> sufficiently similar to the one you're importing, and that has not been
> imported/matched before.
> In your case, it could be one of these reasons (I can't see the image):
> - There's no matching transaction in your register (no existing
> transaction has amount close, and a date close to the imported one)
> - There's a matching transaction but it's already been matched to an
> imported transaction at some point so it's not available to be matched
> to the new imported one.
> - There's a matching transaction that's available, but the match score
> is below the threshold that allows the transaction to be shown as a
> potential match. Too large a date mismatch can cause that.
>
> Can you check whether you're in one of these 3 cases? If you're in case
> 3, you can lower the minimum matching threshold in the preferences and
> see if that helps.
> J.
>
>
> On 7/26/2020 2:44 PM, John Ralls wrote:
> > If there's no matching transaction already in the account then there's
> nothing to clear. In that case only adding or not makes sense.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Jul 26, 2020, at 1:56 PM, Fross, Michael  wrote:
> >>
> >> Hello all,
> >>
> >> I sent this earlier this month and didn't see any reply so I thought I
> >> would try again.   Has anyone else seen these issues?  I use Citibank
> and
> >> perhaps it's a Citibank issue, but I did not have this problem on v2 or
> v3.
> >>
> >> Thanks all.  I appreciate the help.
> >>
> >> Michael
> >>
> >>
> >> On Sat, Jul 4, 2020 at 9:48 AM Fross, Michael 
> wrote:
> >>
> >>> Hello all,
> >>>
> >>> I typically download QFX files from my banks every day or two, import
> them
> >>> to clear them in Gnucash.  Worked great.  However, ever since
> upgrading to
> >>> v4, the importer seems to have trouble matching.  Most of the imported
> >>> transactions are listed in the importer as (A)dd, but when I select
> >>> (C)lear for them it says match missing.
> >>>
> >>> This has occurred for several accounts.  Here is a simple credit card
> >>> example, although for my checking account, there are dozens like
> this.  The
> >>> top portion shows the register with the Sprint bill cleared.  The date,
> >>> amount, and name (mostly) match.
> >>>
> >>> [image: image.png]
> >>>
> >>> Not sure if there is just something wrong with my setup or not.
> Perhaps a
> >>> bug?  Are others experiencing this?  Any ideas to get the matcher
> matching
> >>> again?  Something need to get cleared out?
> >>>
> >>> For those of us in the US, happy Independence Day.  Thank you all for
> your
> >>> assistance.
> >>>
> >>> Michael
> >>>
> >> ___
> >> 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.
>
> ___
> 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://wik

Re: [GNC] BotanyBayGardens nonprofit example, and why GnuCash does not suffice

All but one business or non-profit I've worked for or with had a 
two-person signature rule. (over a certain small amount) One still 
writes paper checks to keep that standard. (not sure myself how that is 
handled electronically)


For the one business that allowed only one signature for any amount, it 
was a mom & pop business, in a small town, with a small town bank, with 
signature images on file and all of the tellers personally know the 
business owners. (who are the only ones approved to sign checks) They 
did have a rule with the bank that if over a certain high amount, the 
bank had to speak to the other owner to confirm the check. *All* checks 
had to be made with an 'imprinter' and could not have their amounts hand 
written.


Regards,
Adrien

On 7/26/20 10:39 AM, John Ralls wrote:



Incidentally, the textbook also says that checks should ideally require two 
signatures. I don't know how to impose that control over electronic transfers 
but the local newspaper reports two or three cases of embezzlement a year where 
it's obvious that a two-person control would have prevented the crime.


___
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] BotanyBayGardens nonprofit example, and why GnuCash does not suffice


Will,

That's a basic tenet of access control. (part of accounting itself, and 
is in my text book too.)


The the person with access to funds (of any kind) should not be the 
person who accounts for those funds. (but should of course provide all 
the required documentation for what they do with them) Some 
organizations give access to cash to one person, and access to the 
checking account to another.


This can also help get more people involved and 'take interest' and 
develop a sense of ownership (and trust) in any organization. And it 
spreads the workload not just of the mundane tasks, but of holding each 
other accountable.


In my previous life in restaurant work, we had administrative assistants 
(trustworthy, long time employees who could do math) that handled the 
recording of daily deposits, made change orders, recorded sales 
receipts, etc. The managers had access to the cash. The admins turned 
over their documentation to the outside accounting firm.



Regards,
Adrien

On 7/25/20 3:04 PM, w...@theprescotts.com wrote:

Your suggestion about a second person to handle the cash is a good idea. One of 
my longstanding complaints has been that no one ever looks at any of the 
finances except me. We are a group of about 300 members with maybe 20 that take 
an active role in the organization. There is too much to do and no one wants to 
spend energy on something that isn't broken.


___
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] Petty Cash (was Re: BotanyBayGardens nonprofit example, and why GnuCash does not suffice)

Will, of course, get official advice, but I can speak to my prior 
experience dealing with Petty Cash and what were taught to me as 'best 
practices'.


1. All receipts of physical cash should be kept separate of Petty Cash 
and deposited in full, coins and all. Ideally, these should be placed in 
sealed, tamper-evident bags, designed for the purpose and placed in a 
'drop safe' that requires two keys to open, usually an armored pick-up 
service is employed that holds one key. That might be overkill for your 
use case, but you'd have to determine that based on cash receipt 
frequency and amount. This helps to match up cash receipt reporting and 
bank deposits for auditing.


2. All disbursements in physical cash come from Petty Cash and must have 
a receipt.


3. It is advisable to record a hand-written tally of Petty Cash 
regularly with an initial or signature, by denomination. (that part is 
important) 'Regularly' will vary with your needs. This could be daily, 
weekly, or in my experience with a restaurant, at each manager's shift 
change. (which was at least 3 times a day, open, mid, and close) At the 
least, the tally should be done both before and after access changes 
hands, one by the person transferring the access and again by the person 
receiving it to verify. (even with that in place, someone can still 
steal, but you have the info to catch them - I did.) Even better, each 
person should count and record in the presence of the other.


4. Petty Cash is *only* replenished with a 'Change Order' from the bank 
to 'par up' to whatever level is needed to be on hand. This level should 
be determined based on past receipts and can be increased or decreased 
seasonally or for special events as needed. You should have enough to 
reasonably meet small expenses and no more. If you have to provide 
change for individual registers, this will be considerably more based on 
their starting 'banks'. There are probably formulas for this somewhere, 
including the denomination breakdown.


There might be other 'best practices' (I'm sure I'm forgetting one or 
two, it has been over 15 years) and of course, seek professional advice.


Regards,
Adrien

On 7/25/20 1:02 PM, w...@theprescotts.com wrote:

As I said earlier, I am not an accountant just a volunteer keeping the books 
for a couple of groups. Michael comments:
"and NOT currency sitting around undeposited (of course don't do THAT)."

I do do that and wonder why it is a bad idea. I frequently get incoming cash, 
mostly from T-shirt sales. And I occasionally have to pay for minor expenses so 
I generally have some cash around. I fully account for the income and expenses 
out of this fund to the penny. If there is a major income or expense in cash, 
that is handled with a bank withdrawal or deposit with only the change going 
into the cash box. Generally I have about $1000 to $2000 mxn on hand ( = $50 to 
$100 usd).

Should I change my habits.

Will


___
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] Difficulty with online price retrieval

Samantha,

Regardless of the shell you must enclose paths with spaces in quotes, e.g.
  cd "c:\Program Files (86)\gnucash\bin"
You can use ' instead of " if you like. You can also start typing and use tab 
completion, for example type
  cd c:\prog
and the shell will change it to 
  cd 'C:\Program Files\'
You can then backspace out the \', type a space and  again and it will 
fill in the (x86)\' for you. 

Regards,
John Ralls
 

> On Jul 27, 2020, at 12:01 PM, Samantha Payn  
> wrote:
> 
> Sorry John (and everyone). I can't get it to accept (x86) now: 
> 
> C:\Users\User> cd C:\Program Files (x86)\gnucash\bin 
> x86 : The term 'x86' is not recognized as the name of a cmdlet, function, 
> script file, or operable program. 
> Check the spelling of the name, or if a path was included, verify that the 
> path is correct and try again. 
> At line:1 char:22 
> + cd C:\Program Files (x86)\gnucash\bin 
> + ~~~ 
> + CategoryInfo : ObjectNotFound: (x86:String) [], CommandNotFoundException 
> + FullyQualifiedErrorId : CommandNotFoundException
> 
> So sorry. Instead of bothering you guys should I try to get local help? 
> Best wishes and thanks again 
> Samantha 
>> On 27 July 2020 19:30 John Ralls < jra...@ceridwen.us> wrote:
>> 
>> 
>> Samantha,
>> 
>> Sorry I wasn't more explicit: Yes, each command is a line on its own, 
>> followed by . You need to use quotes around your API key, so
>> $Env:ALPHAVANTAGE_API_KEY = "[my API key]"
>> 
>> I see that I left off the second quote in the perl command line, it should be
>> perl 'c:\Program Files (x86)\gnucash\bin\gnc-fq-dump currency' USD GBP
>> 
>> The Powershell terminal color-codes errors in red on black, variables and 
>> special values (e.g. $true, $false) in green, and command names in yellow.
>> 
>> Regards,
>> John Ralls
>> 
>>> On Jul 27, 2020, at 2:30 AM, Samantha Payn < 
>>> saman...@boorertranslations.com> wrote:
>>> 
>>> Hi John
>>> I am sorry to have to come back to you for more support on this and thanks 
>>> again for your patience.
>>> After some fumbling (am I right that I should type each line you have typed 
>>> followed by the "Enter" key? I really am that much of a newb at this), I 
>>> got an error message in red type as follows:
>>> [my API key] : The term '[my API key]' is not recognized as the name of a 
>>> cmdlet, function,
>>> script file, or operable program. Check the spelling of the name, or if a 
>>> path was included, verify
>>> that the path is correct and try again.
>>> At line:1 char:29
>>> + $Env:ALPHAVANTAGE_API_KEY = [my API key]
>>> + ~~~
>>> + CategoryInfo : ObjectNotFound: ([my API key]:String) [], 
>>> CommandNotFoundException
>>> + FullyQualifiedErrorId : CommandNotFoundException
>>> 
>>> (In the text above I have switched out my 16 digit API key for the words 
>>> "[my API key]").
>>> 
>>> Please also explain what the significance of green and yellow text is in 
>>> this environment.
>>> Many thanks
>>> Samantha
>>> 
>>> 
 On 25 July 2020 20:04 John Ralls < jra...@ceridwen.us> wrote:
 
 
 Samantha,
 
 Powershell (Admin) just means Powershell with admin privilege. Starting it 
 will raise a User Authorization Escalation dialog box asking if you're 
 sure that you want Powershell to "make changes to your device". You don't 
 need it for this test, plain Powershell is fine. Yes, Powershell. I don't 
 think that there is a Poweshell, please excuse my hasty typing.
 
 Since you use only those 3 currencies try all three combinations, i.e. 
 USD->GBP, EUR->GBP, and EUR->USD with gnc-fq-dump.
 
 Regards,
 John Ralls
 
 
 
> On Jul 25, 2020, at 10:27 AM, Samantha Payn < 
> saman...@boorertranslations.com> wrote:
> 
> John, thank you for your continued support.
> Before I try this can I just clarify two points:
> I have a choice of Windows Powershell and Windows Powershell (Admin): 
> which should I choose?
> And in the middle of your email I presume you mean "Powershell" (not 
> Poweshell as typed)?
> Finally, in response to your question I have no securities in my Gnucash 
> accounts. I am a freelance translator with a home currency of GBP and 
> clients who pay me (and a very occasional purchase) in EUR and USD and 
> use Gnucash for my business accounts. These are the currency rates I am 
> trying to access.
> Best wishes
> Samantha
>> On 25 July 2020 17:12 John Ralls < jra...@ceridwen.us> wrote:
>> 
>> 
>> Samantha,
>> 
>> Next, some command-line testing. You can use CMD if you like, but I find 
>> Powershell to be a bit friendlier and easier to get to: Just right-click 
>> in the Start menu and it's in the middle. Once you have a shell, cd to 
>> C:\Program Files (x86)\gnucash\bin.
>> 
>> First you'll need to set your ALPHAVANTAGE_API_KEY in the environment:
>> CMD
>> set ALPHAVANTAGE_API_KEY xxx...
>> Poweshell
>> $Env:ALPH

Re: [GNC] Difficulty with online price retrieval

2020-07-27 Thread Samantha Payn

   Sorry John (and everyone). I can't get it to accept (x86) now:

   C:\Users\User> cd C:\Program Files (x86)\gnucash\bin
   x86 : The term 'x86' is not recognized as the name of a cmdlet,
   function, script file, or operable program.
   Check the spelling of the name, or if a path was included, verify that
   the path is correct and try again.
   At line:1 char:22
   + cd C:\Program Files (x86)\gnucash\bin
   + ~~~
   + CategoryInfo : ObjectNotFound: (x86:String) [],
   CommandNotFoundException
   + FullyQualifiedErrorId : CommandNotFoundException

   So sorry. Instead of bothering you guys should I try to get local help?

   Best wishes and thanks again

   Samantha

   On 27 July 2020 19:30 John Ralls < [1]jra...@ceridwen.us> wrote:

   Samantha,

   Sorry I wasn't more explicit: Yes, each command is a line on its own,
   followed by . You need to use quotes around your API key, so

   $Env:ALPHAVANTAGE_API_KEY = "[my API key]"

   I see that I left off the second quote in the perl command line, it
   should be

   perl 'c:\Program Files (x86)\gnucash\bin\gnc-fq-dump currency' USD GBP

   The Powershell terminal color-codes errors in red on black, variables
   and special values (e.g. $true, $false) in green, and command names in
   yellow.

   Regards,

   John Ralls

   On Jul 27, 2020, at 2:30 AM, Samantha Payn <
   [2]saman...@boorertranslations.com> wrote:

   Hi John

   I am sorry to have to come back to you for more support on this and
   thanks again for your patience.

   After some fumbling (am I right that I should type each line you have
   typed followed by the "Enter" key? I really am that much of a newb at
   this), I got an error message in red type as follows:

   [my API key] : The term '[my API key]' is not recognized as the name of
   a cmdlet, function,

   script file, or operable program. Check the spelling of the name, or if
   a path was included, verify

   that the path is correct and try again.

   At line:1 char:29

   + $Env:ALPHAVANTAGE_API_KEY = [my API key]

   + ~~~

   + CategoryInfo : ObjectNotFound: ([my API key]:String) [],
   CommandNotFoundException

   + FullyQualifiedErrorId : CommandNotFoundException

   (In the text above I have switched out my 16 digit API key for the
   words "[my API key]").

   Please also explain what the significance of green and yellow text is
   in this environment.

   Many thanks

   Samantha

   On 25 July 2020 20:04 John Ralls < [3]jra...@ceridwen.us> wrote:

   Samantha,

   Powershell (Admin) just means Powershell with admin privilege. Starting
   it will raise a User Authorization Escalation dialog box asking if
   you're sure that you want Powershell to "make changes to your device".
   You don't need it for this test, plain Powershell is fine. Yes,
   Powershell. I don't think that there is a Poweshell, please excuse my
   hasty typing.

   Since you use only those 3 currencies try all three combinations, i.e.
   USD->GBP, EUR->GBP, and EUR->USD with gnc-fq-dump.

   Regards,

   John Ralls

   On Jul 25, 2020, at 10:27 AM, Samantha Payn <
   [4]saman...@boorertranslations.com> wrote:

   John, thank you for your continued support.

   Before I try this can I just clarify two points:

   I have a choice of Windows Powershell and Windows Powershell (Admin):
   which should I choose?

   And in the middle of your email I presume you mean "Powershell" (not
   Poweshell as typed)?

   Finally, in response to your question I have no securities in my
   Gnucash accounts. I am a freelance translator with a home currency of
   GBP and clients who pay me (and a very occasional purchase) in EUR and
   USD and use Gnucash for my business accounts. These are the currency
   rates I am trying to access.

   Best wishes

   Samantha

   On 25 July 2020 17:12 John Ralls < [5]jra...@ceridwen.us> wrote:

   Samantha,

   Next, some command-line testing. You can use CMD if you like, but I
   find Powershell to be a bit friendlier and easier to get to: Just
   right-click in the Start menu and it's in the middle. Once you have a
   shell, cd to C:\Program Files (x86)\gnucash\bin.

   First you'll need to set your ALPHAVANTAGE_API_KEY in the environment:

   CMD

   set ALPHAVANTAGE_API_KEY xxx...

   Poweshell

   $Env:ALPHAVANTAGE_API_KEY = xxx...

   Now test that you can retrieve an arbitrary currency pair:

   perl 'c:\Program Files (x86)\gnucash\bin\gnc-fq-dump currency USD GBP

   If that works then Finance::Quote is working correctly and something
   else is going on. So far you've mentioned only currency rates, but the
   usual reason for a system error message from online price retrieval is
   trying to get a stock price from one of the dicontinued Yahoo! price
   sources. Do you have any securities in your book? If you're unsure use
   Tools>Security Editor to show a list of them.

   Regards,

   John Ralls

   On Jul 25, 2020, at 5:22 AM, Samantha Payn <
   [6]saman...@boorertranslations.com> wrote:

   Thank you for y

Re: [GNC] BotanyBayGardens nonprofit example, and why GnuCash does not suffice

I'm not an accountant or an attorney either. But I've been a manager and 
I've caught people stealing from various cash sources. I can attest, 
that if you don't track it tightly, even with access control, it will 
magically walk away at some point.


Not treating PayPal like an account in your books is asking for trouble. 
That's a pile of money that can flow back and forth from and to various 
sources and is 'invisible' to the books in that case. That is the very 
antithesis of 'accounting'.


For the issue of using cash for disbursements, that is the point of a 
petty cash account. (otherwise, it is just 'undeposited funds') Some 
organizations as part of their control and accounting mechanisms require 
disbursements over a certain amount ($5 is not unusual) to be by check. 
Some make it iron clad for any amount. This greatly simplifies cash 
handling, tracking and accounting and in such a case, the physical cash 
the organization receives is usually handled by a single person. (a good 
idea in general)


As for dating transactions, I wouldn't alter anything unless the law 
specifically allowed for it. Otherwise, I might reconsider using Accrual 
instead of Cash basis if it became a repeated issue.


Regards,
Adrien

On 7/25/20 12:03 AM, w...@theprescotts.com wrote:

I have a few comments on this long post. I will preface it by admitting that I 
am neither a tax attorney nor an accountant. I have kept my personal accounts 
in GnuCash for many years. I am the treasurer for two non-profits, or more 
accurately, two subsidiaries of one non-profit. But neither of them are legal 
entities nor in the US. Legally, they are probably more akin to informal 
associations.

The suggestions for falsifying the dates of transactions for convenience in 
accounting strike me as very bad advice. Is it even legal for an organization 
that has to abide by US tax laws.

Similarly, I don't understand the advice to just treat Paypal transactions as 
if they were directly on checking. This would make accounting for Paypal fees 
strange. For organizations outside the US, Paypal no longer holds funds; they 
transfer them immediately, so the Paypal balance is always zero except for 
immediately after a deposit to Paypal. Even so, it is much easier to track 
activity treating Paypal as a bank account.

Finally, I don't understand the suggestions about not having a cash account and 
immediately depositing all cash to checking. Perhaps it is partly because I 
live in a country where many transactions are still done with cash, where no 
one uses checks, just bank transfers. But I often accept donations in cash, and 
often pay bills in cash. Not accounting for those transactions directly would 
be neither accurate nor convenient.


___
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] BotanyBayGardens nonprofit example, and why GnuCash does not suffice


1. Job Costing

While not 'out of the box and in your face obvious' I think GnuCash can 
handle 'Job Costing' at least at a rudimentary level now. This sounds 
like a more specific request of the generic 'classes/categories' RFE 
that pops up frequently. (another is for revenue/profit centers used by 
managerial accounting)


I agree that advice to use the account hierarchy to do this only works 
for the simplest use cases, but otherwise turns into quite a mess.


User specified 'tags' are the ticket.

For cleanliness and sanity, these should probably be placed in the Notes 
and/or Memo fields and a standardized representation decided on by the 
user. (such as a preface of '#', '@', brackets, parenthesis, etc.)


The downside is GnuCash will not keep a list of these tags. That would 
have to be maintained separately as exact spelling makes reporting 
easier.(though some crafty regex can help)


Reporting is facilitated by using the Transaction Filter option on the 
tag text. Unfortunately the P&L/Income Statement Report and Balance 
Sheet Report, do not contain this option. The Transaction Report does, 
but massaging that into one of the other forms would still require 
spreadsheet editing.


So to achieve 'job costing' in the short term would require adding the 
Transaction Filter (and regex option if possible) to at least the P&L 
and/or Balance Sheet, but it should probably belong on several others as 
well.


Then a good wiki page can educate with screenshots and examples on how 
to accomplish the task.


If a tagging facility were officially added, this would be another piece 
of the puzzle. (I think it is already a filed RFE) But that might have 
to wait till GnuCash is a proper db-based app.


-
2. Statement of Cash Flows

I don't recall if this was heavily discussed in a thread or bug report 
(I think a bug report, maybe both) but I recall looking over this last 
year when trying to help a user with the current Cash Flow report.


Indeed it isn't anything at all like a 'Statement of Cash Flows'.

I theorized that it *might* be possible to get close if the Options > 
Accounts section were divided into 3, one for each of the three parts of 
the standard report form. John noted it is too difficult for GnuCash to 
know what accounts belong in each section, so like with other such 
questions for other reports (even this one as it is now), let the user 
select them.


The report code would then have to be altered to run through the 
selected accounts, subtotal and display for each of the three sections 
of the report.


I think it is doable in concept, but I don't know overall how tedious 
that might be to implement. I don't speak Scheme, but I suppose it is 
time to learn. Christopher might be able to advise more concretely where 
the difficulties lay.


In any case, the current report is misnamed if not a bit confusing to 
users looking for a 'Statement of Cash Flows', and this has been 
discussed in at least one bug report, but I don't think a suitable 
alternative has been agreed upon.



Regards,
Adrien

On 7/25/20 12:59 AM, jean laroche wrote:
Thanks for the very detailed analysis of Gnucash's shortcomings for 
nonprofits (and other businesses).

I'm not an accountant either, barely a computer scientist.
If I were to summarize the areas where GC falls short, it seems to me GC 
is missing:

- Support for Job Costing
- Cash Flow reporting isn't what it should be.

Could the original poster (Don) confirm that these two features, if 
fixed/implemented would go a long way toward making GC more suited for 
nonprofits?


Perhaps the developers (including me, in a  modest manner) could then 
discuss whether these would be easy to add/fix. Perhaps these features 
have been discussed in the past? Job costing, in particular, may not be 
that hard to implement? The Cash Flow reporting might also not be too 
hard to fix, once the OP specifies exactly how it should be done, ideally.


___
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] Difficulty with online price retrieval

Samantha,

Sorry I wasn't more explicit: Yes, each command is a line on its own, followed 
by . You need to use quotes around your API key, so
  $Env:ALPHAVANTAGE_API_KEY = "[my API key]"

I see that I left off the second quote in the perl command line, it should be 
  perl 'c:\Program Files (x86)\gnucash\bin\gnc-fq-dump currency' USD GBP

The Powershell terminal color-codes errors in red on black, variables and 
special values (e.g. $true, $false) in green, and command names in yellow. 

Regards,
John Ralls

> On Jul 27, 2020, at 2:30 AM, Samantha Payn  
> wrote:
> 
> Hi John 
> I am sorry to have to come back to you for more support on this and thanks 
> again for your patience. 
> After some fumbling (am I right that I should type each line you have typed 
> followed by the "Enter" key? I really am that much of a newb at this), I got 
> an error message in red type as follows: 
> [my API key] : The term '[my API key]' is not recognized as the name of a 
> cmdlet, function, 
> script file, or operable program. Check the spelling of the name, or if a 
> path was included, verify 
> that the path is correct and try again. 
> At line:1 char:29 
> + $Env:ALPHAVANTAGE_API_KEY = [my API key] 
> + ~~~ 
> + CategoryInfo : ObjectNotFound: ([my API key]:String) [], 
> CommandNotFoundException 
> + FullyQualifiedErrorId : CommandNotFoundException
> 
> (In the text above I have switched out my 16 digit API key for the words "[my 
> API key]"). 
> 
> Please also explain what the significance of green and yellow text is in this 
> environment. 
> Many thanks 
> Samantha 
> 
> 
>> On 25 July 2020 20:04 John Ralls < jra...@ceridwen.us> wrote:
>> 
>> 
>> Samantha,
>> 
>> Powershell (Admin) just means Powershell with admin privilege. Starting it 
>> will raise a User Authorization Escalation dialog box asking if you're sure 
>> that you want Powershell to "make changes to your device". You don't need it 
>> for this test, plain Powershell is fine. Yes, Powershell. I don't think that 
>> there is a Poweshell, please excuse my hasty typing.
>> 
>> Since you use only those 3 currencies try all three combinations, i.e. 
>> USD->GBP, EUR->GBP, and EUR->USD with gnc-fq-dump.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> 
>>> On Jul 25, 2020, at 10:27 AM, Samantha Payn < 
>>> saman...@boorertranslations.com> wrote:
>>> 
>>> John, thank you for your continued support.
>>> Before I try this can I just clarify two points:
>>> I have a choice of Windows Powershell and Windows Powershell (Admin): which 
>>> should I choose?
>>> And in the middle of your email I presume you mean "Powershell" (not 
>>> Poweshell as typed)?
>>> Finally, in response to your question I have no securities in my Gnucash 
>>> accounts. I am a freelance translator with a home currency of GBP and 
>>> clients who pay me (and a very occasional purchase) in EUR and USD and use 
>>> Gnucash for my business accounts. These are the currency rates I am trying 
>>> to access.
>>> Best wishes
>>> Samantha
 On 25 July 2020 17:12 John Ralls < jra...@ceridwen.us> wrote:
 
 
 Samantha,
 
 Next, some command-line testing. You can use CMD if you like, but I find 
 Powershell to be a bit friendlier and easier to get to: Just right-click 
 in the Start menu and it's in the middle. Once you have a shell, cd to 
 C:\Program Files (x86)\gnucash\bin.
 
 First you'll need to set your ALPHAVANTAGE_API_KEY in the environment:
 CMD
 set ALPHAVANTAGE_API_KEY xxx...
 Poweshell
 $Env:ALPHAVANTAGE_API_KEY = xxx...
 
 Now test that you can retrieve an arbitrary currency pair:
 perl 'c:\Program Files (x86)\gnucash\bin\gnc-fq-dump currency USD GBP
 
 If that works then Finance::Quote is working correctly and something else 
 is going on. So far you've mentioned only currency rates, but the usual 
 reason for a system error message from online price retrieval is trying to 
 get a stock price from one of the dicontinued Yahoo! price sources. Do you 
 have any securities in your book? If you're unsure use Tools>Security 
 Editor to show a list of them.
 
 Regards,
 John Ralls
 
 
> On Jul 25, 2020, at 5:22 AM, Samantha Payn < 
> saman...@boorertranslations.com> wrote:
> 
> Thank you for your help John.
> I have done as you instruct (including restarting Gnucash after the 
> install) but there is now a different problem.
> The Gnucash about info now does show version 1.49 for Finance::Quote
> The Get Quotes button does light up, but when I click it I get an error 
> window that says: "There was a system error while retrieving the price 
> quotes".
> I have tried restarting my computer to see if that helps but it made no 
> difference.
> The last two lines of the installing text in the CPAN window, before the 
> cpan prompt reappeared were *slightly* different to what you showed in 
> your email. As far as I can

Re: [GNC] $0 total balances wrongly appearing on Balance Sheet.

I'd go for the second. Account balances are on amounts (i.e. shares if that's 
what the account commodity is) and AFAIK nothing in the account code looks at 
split values.

Regards,
John Ralls


> On Jul 27, 2020, at 10:24 AM, David Carlson  
> wrote:
> 
> I am curious.  Is it possible for this behavior to occur if
> 
> 1) a commodity account has a balance of zero shares but a residual value
> because it has a unrealized gain or loss.
> 
> 2) a commodity account actually has a tiny share balance or residual value
> below the threshold visible at the account display resolution, likely due
> to rounding errors in transactions.
> 
> David Carlson
> 
> On Mon, Jul 27, 2020 at 12:12 PM Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> 
>> Sorry, the report appears to be working correctly for me on MacOS
>> (10.15.6) using GnuCash 4.1.
>> 
>> The 1st option should be the only one you need to toggle the zero
>> balanced accounts from appearing.
>> 
>> The 2nd option will remove just the zero figure but retain the account
>> name if the 1st option is checked.
>> 
>> Let's use an example where 'Cash' has a 0.00 balance,
>> 
>> 
>> If you uncheck both options you'll see:
>> 
>>Cash 0.00
>> 
>> If 1st option is unchecked, second option checked, you'll see:
>> 
>>Cash
>> 
>> If 1st option is checked, the second option is now irrelevant, and
>> you'll see nothing about 'Cash' at all.
>> 
>> Or at least that is the way I think it is supposed to work.
>> 
>> Regards,
>> Adrien
>> 
>> On 7/27/20 11:01 AM, peterb wrote:
>>> I've encountered a bit of a Scooby Doo mystery, and I'm hoping someone
>> can
>>> help me figure it out.
>>> 
>>> My Balance Sheet report consistently includes commodity accounts with 0
>>> balance figures for me, even when I've unchecked "Include accounts with
>>> zero total balances."  Trying to reproduce this with a brand-new book for
>>> demo purposes doesn't show this behavior, so I'm left assuming there's
>>> something about my file that is odd.
>>> 
>>> Specifically, there are two options under "Display" for Balance sheet, to
>>> wit:
>>> 
>>> • Include accounts with zero total balances
>>> • Omit zero balance figures
>>> 
>>> I would expect that having the first option UN-checked and the second
>>> option checked would result in my stock accounts with 0 shares in them
>>> appearing; sadly, they're all over the report.
>>> 
>>> In contrast, the "Balance Sheet using eguile-gnc" report has an option
>>> (under "Accounts", not "Display" this time) of "Exclude accounts with
>> zero
>>> total balances".  Checking this option achieves what I'd consider the
>> right
>>> result - no zero balance values are shown.
>>> 
>>> After further experimentation, there seems to be an interaction with the
>>> "Levels of Subaccounts" control on the Accounts tab of the report
>> options.
>>> If I increase the levels of subaccounts accordingly, or flatten the list
>> to
>>> the depth limit, the 0 balance figures don't appear - again, only (so
>> far)
>>> in this one file.
>>> 
>>> So I have two workarounds to the problem (either using the eguile report,
>>> or adjusting the depth limit/flattening options), but I am still
>> concerned
>>> that I don't understand why the behavior is happening in the first place.
>>> 
>>> My questions are:
>>> (1) Has anyone else seen this behavior?
>>> (2) If so, do you understand what's triggering 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.
>> 
> 
> 
> -- 
> 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.

___
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] Postgres SSL Solution?

GnuCash itself doesn't have SSL support, so there is indeed no clear way to do 
it. You might be able to set up a proxy of some sort.

Regards,
John Ralls


> On Jul 26, 2020, at 12:25 PM, Gregory Patricoski  
> wrote:
> 
> Hey team,
> 
> I am using a postgres database for my gnucash storage, but cannot seem to
> find a way to connect via SSL which is my preferred method. There does not
> seem to be a clear way to do this, does anyone have any suggestions as I
> may be missing something?
> 
> Thanks!
> 
> Greg
> 
> -- 
> 
> Gregory A. Patricoski
> 
> Patricoski Law Offices
> 
> Chicago Office
> 
> Mailing Address: 1755 S. Naperville Rd.
> 
> Suite 206, Wheaton, IL 60189
> 
> greg...@markpatlaw.com
> 
> ph. (312) 500-2020
> 
> fx. (630) 933-8000
> 
> Encrypted communications available.
> 
> *PGP*: C364 8552 E25C 90EF 3D0C  9584 BD40 656E 21EE 6653
> 
> The sender of this email is an attorney. The information contained in this
> communication is confidential, may be attorney-client privileged, may be
> attorney work product, and is intended only for the use of the addressee.
> It is the property of the sender. Unauthorized use, disclosure or copying
> of this communication or any part thereof is strictly prohibited and may be
> unlawful. If you have received this communication in error, please notify
> me immediately by return e-mail, and destroy this communication and all
> copies thereof, including all attachments. This language in this disclaimer
> is not intended to alter, waive, or in any way modify privilege as it
> exists under the law.
> ___
> 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] How to find un-posted invoices (was: Re: BotanyBayGardens nonprofit example, and why GnuCash does not suffice)

Try Business > Customer > Find Invoice, then set criteria to `Is 
posted?` and uncheck the box. (without that criteria, others should show 
a `Posted` column anyway, 'un-posted' invoices will show "12/31/1969" as 
the date - a bug, but usable info still.)


You can of course add criteria, and/or run iterated searches to refine 
the list as needed.


Sadly, there is no way to get a report or even export this results list. 
(You can screenshot I suppose)


There is also no way to save the search criteria if they get complicated.

But from the Find window you can View, Edit, Pay, Print, etc. (the 
'Printable Report' button is an Invoice report, not a report of the 
results.)


Hope that helps.

Regards,
Adrien

On 7/25/20 4:40 PM, Bruce Irving via gnucash-user wrote:


So far, only the provided reports.  We are at the beginning of our dues cycle 
so I haven't had much time to pursue this.


___
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] Import Transaction Matcher issue in v4

Ah, forgot about the ID, thanks.

Regards,
Adrien

On 7/27/20 12:31 PM, Jean Laroche wrote:

No,
 >> - There's a matching transaction but it's already been matched to an
 >> imported transaction at some point so it's not available to be matched
 >> to the new imported one.

This means, if you re-import the same file, the register transactions 
that were previously imported are marked as having been matched/imported 
(they have an online-id), and they're not available to be matched.
But more importantly, the ofx transaction is recognized as having been 
imported before because its online id is already in the register so the 
ofx transaction is skipped entirely.

Jean

___
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] Import Transaction Matcher issue in v4

2020-07-27 Thread Jean Laroche

No,
>> - There's a matching transaction but it's already been matched to an
>> imported transaction at some point so it's not available to be matched
>> to the new imported one.

This means, if you re-import the same file, the register transactions 
that were previously imported are marked as having been matched/imported 
(they have an online-id), and they're not available to be matched.
But more importantly, the ofx transaction is recognized as having been 
imported before because its online id is already in the register so the 
ofx transaction is skipped entirely.

Jean

On 7/27/20 9:52 AM, Adrien Monteleone wrote:
This appears to mean that if a subsequent import file contained a 
duplicate transaction for some reason, (or the user accidentally 
selected an already imported file) then duplicates would be imported. Or 
am I reading that wrong?

Regards,
Adrien

On 7/26/20 4:56 PM, jean laroche wrote:

- There's a matching transaction but it's already been matched to an 
imported transaction at some point so it's not available to be matched 
to the new imported one.

___
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] $0 total balances wrongly appearing on Balance Sheet.

I am curious.  Is it possible for this behavior to occur if

1) a commodity account has a balance of zero shares but a residual value
because it has a unrealized gain or loss.

2) a commodity account actually has a tiny share balance or residual value
below the threshold visible at the account display resolution, likely due
to rounding errors in transactions.

David Carlson

On Mon, Jul 27, 2020 at 12:12 PM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Sorry, the report appears to be working correctly for me on MacOS
> (10.15.6) using GnuCash 4.1.
>
> The 1st option should be the only one you need to toggle the zero
> balanced accounts from appearing.
>
> The 2nd option will remove just the zero figure but retain the account
> name if the 1st option is checked.
>
> Let's use an example where 'Cash' has a 0.00 balance,
>
>
> If you uncheck both options you'll see:
>
> Cash 0.00
>
> If 1st option is unchecked, second option checked, you'll see:
>
> Cash
>
> If 1st option is checked, the second option is now irrelevant, and
> you'll see nothing about 'Cash' at all.
>
> Or at least that is the way I think it is supposed to work.
>
> Regards,
> Adrien
>
> On 7/27/20 11:01 AM, peterb wrote:
> > I've encountered a bit of a Scooby Doo mystery, and I'm hoping someone
> can
> > help me figure it out.
> >
> > My Balance Sheet report consistently includes commodity accounts with 0
> > balance figures for me, even when I've unchecked "Include accounts with
> > zero total balances."  Trying to reproduce this with a brand-new book for
> > demo purposes doesn't show this behavior, so I'm left assuming there's
> > something about my file that is odd.
> >
> > Specifically, there are two options under "Display" for Balance sheet, to
> > wit:
> >
> > • Include accounts with zero total balances
> > • Omit zero balance figures
> >
> > I would expect that having the first option UN-checked and the second
> > option checked would result in my stock accounts with 0 shares in them
> > appearing; sadly, they're all over the report.
> >
> > In contrast, the "Balance Sheet using eguile-gnc" report has an option
> > (under "Accounts", not "Display" this time) of "Exclude accounts with
> zero
> > total balances".  Checking this option achieves what I'd consider the
> right
> > result - no zero balance values are shown.
> >
> > After further experimentation, there seems to be an interaction with the
> > "Levels of Subaccounts" control on the Accounts tab of the report
> options.
> > If I increase the levels of subaccounts accordingly, or flatten the list
> to
> > the depth limit, the 0 balance figures don't appear - again, only (so
> far)
> > in this one file.
> >
> > So I have two workarounds to the problem (either using the eguile report,
> > or adjusting the depth limit/flattening options), but I am still
> concerned
> > that I don't understand why the behavior is happening in the first place.
> >
> > My questions are:
> > (1) Has anyone else seen this behavior?
> > (2) If so, do you understand what's triggering 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.
>


-- 
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] BotanyBayGardens nonprofit example, and why GnuCash does not suffice

2020-07-27 Thread Michael or Penny Novack


On 7/27/2020 12:13 PM, Stephen M. Butler wrote:


I am able to send along an account ID or Invoice ID and then there is
the entire memo field on the check.  I also get an email from the CU (if
I request) stating that it has been sent.  I can forward that to the
recipient with additional notes.

Not convenient, but driving an hour to hand over coin is also very
inconvenient.


Handing over coin?

I meant as opposed to addressing and stamping an envelope, writing  a 
check, sticking that into the envelope along with a copy of the invoice 
(or copy of the receipts being reimbursed, etc.), walking to the end of 
the drive to stick it in the mailbox and put the flag up.


Things get lost in offices. I would never, for example send a check and 
its documentation in two separate envelopes. Any more than sending an 
electronic transfer and separate email. Electronic transfers are for 
when the recipient has asked for this and is assuming responsibility for 
crediting it to the correct transaction. If a business or government 
agency they may have set up a "draw" app for direct payment so already 
connected to the transaction.


Michael D Novack


--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

___
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] $0 total balances wrongly appearing on Balance Sheet.

Sorry, the report appears to be working correctly for me on MacOS 
(10.15.6) using GnuCash 4.1.


The 1st option should be the only one you need to toggle the zero 
balanced accounts from appearing.


The 2nd option will remove just the zero figure but retain the account 
name if the 1st option is checked.


Let's use an example where 'Cash' has a 0.00 balance,


If you uncheck both options you'll see:

Cash 0.00

If 1st option is unchecked, second option checked, you'll see:

Cash

If 1st option is checked, the second option is now irrelevant, and 
you'll see nothing about 'Cash' at all.


Or at least that is the way I think it is supposed to work.

Regards,
Adrien

On 7/27/20 11:01 AM, peterb wrote:

I've encountered a bit of a Scooby Doo mystery, and I'm hoping someone can
help me figure it out.

My Balance Sheet report consistently includes commodity accounts with 0
balance figures for me, even when I've unchecked "Include accounts with
zero total balances."  Trying to reproduce this with a brand-new book for
demo purposes doesn't show this behavior, so I'm left assuming there's
something about my file that is odd.

Specifically, there are two options under "Display" for Balance sheet, to
wit:

• Include accounts with zero total balances
• Omit zero balance figures

I would expect that having the first option UN-checked and the second
option checked would result in my stock accounts with 0 shares in them
appearing; sadly, they're all over the report.

In contrast, the "Balance Sheet using eguile-gnc" report has an option
(under "Accounts", not "Display" this time) of "Exclude accounts with zero
total balances".  Checking this option achieves what I'd consider the right
result - no zero balance values are shown.

After further experimentation, there seems to be an interaction with the
"Levels of Subaccounts" control on the Accounts tab of the report options.
If I increase the levels of subaccounts accordingly, or flatten the list to
the depth limit, the 0 balance figures don't appear - again, only (so far)
in this one file.

So I have two workarounds to the problem (either using the eguile report,
or adjusting the depth limit/flattening options), but I am still concerned
that I don't understand why the behavior is happening in the first place.

My questions are:
(1) Has anyone else seen this behavior?
(2) If so, do you understand what's triggering 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] Import Transaction Matcher issue in v4

This appears to mean that if a subsequent import file contained a 
duplicate transaction for some reason, (or the user accidentally 
selected an already imported file) then duplicates would be imported. Or 
am I reading that wrong?


Regards,
Adrien

On 7/26/20 4:56 PM, jean laroche wrote:

- There's a matching transaction but it's already been matched to an 
imported transaction at some point so it's not available to be matched 
to the new imported one.


___
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] GTK CSS 4.0-4.1

Without more info on what isn't working, there's not much to help with.
(a copy of your custom file would help)

But you can still do this on your own. (probably best if there are lots
of things to tweak)

1. Install Virtualbox
2. Create a new VirtualMachine and install a linux distribution in it.
(the more recent the better, probably Ubuntu or Fedora in that case)
3. Install GnuCash 4.x in the linux virtual machine, either build it or
use the Flatpak.

4. Run GnuCash with the Inspector turned on.
5. Find your CSS target(s), test and update your file as needed.

Steps 1 & 2 should take less than 10 minutes with reasonable download speed.

If you build GnuCash in step 3, that could take 60-90 minutes if you've
never done it before. (about 30-45 minutes setup, and maybe same for the
build) CPU and memory of the host machine (and how much you allocated to
the Virtual Machine) effects this as well, so mileage will vary.

Setting up Flatpak and installing GnuCash should take about 10 minutes
tops. (so much faster and far less technical than building)

Steps 4 & 5 will involve some learning the Inspector and some trial and
error. Thankfully, the inspector includes a live CSS editing tab for
more rapid testing, but you'll still want to test your actual file
changes in Windows as the two GTK versions (between Linux and Windows)
are likely to be different.

Sadly, there is no easier way if the Inspector won't run on Windows
directly.

Regards,
Adrien

On 7/27/20 9:56 AM, GTI .H wrote:

I would like it too. but for that we have to run the GtkInspector (
https://wiki.gnome.org/action/show/Projects/GTK/Inspector?action=show&redirect=Projects%2FGTK%2B%2FInspector)
and it doesn't run on Windows and nobody with an OS that runs GtkInspector
so far hasn’t offered to help.

--
Regards

Em seg., 27 de jul. de 2020 às 09:07, Jimmy R via gnucash-user <
gnucash-user@gnucash.org> escreveu:

Has anyone figured out yet if we can use our custom css.
Would like to get my font sizes and colors back if possible

___
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] BotanyBayGardens nonprofit example, and why GnuCash does not suffice

2020-07-27 Thread Stephen M. Butler

On 7/27/20 2:07 AM, Liz Dodd wrote:
> On Sun, 26 Jul 2020 17:40:19 -0400
> Michael or Penny Novack  wrote:
>
>> Having the bank mail a check? When I mail a check, there is always
>> going to be supporting documentation in the envelope along with it.
>> Are you receiving checks with no indication what for? What do you do
>> then?
>>
> There's about 250 characters for that data available on Osko, the
> Aussie system.
> You mention real problems, but they are already solved in some places.
>
> https://osko.com.au/faqs
>
> Liz

I am able to send along an account ID or Invoice ID and then there is
the entire memo field on the check.  I also get an email from the CU (if
I request) stating that it has been sent.  I can forward that to the
recipient with additional notes.

Not convenient, but driving an hour to hand over coin is also very
inconvenient.

-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

[GNC] $0 total balances wrongly appearing on Balance Sheet.

2020-07-27 Thread peterb

I've encountered a bit of a Scooby Doo mystery, and I'm hoping someone can
help me figure it out.

My Balance Sheet report consistently includes commodity accounts with 0
balance figures for me, even when I've unchecked "Include accounts with
zero total balances."  Trying to reproduce this with a brand-new book for
demo purposes doesn't show this behavior, so I'm left assuming there's
something about my file that is odd.

Specifically, there are two options under "Display" for Balance sheet, to
wit:

• Include accounts with zero total balances
• Omit zero balance figures

I would expect that having the first option UN-checked and the second
option checked would result in my stock accounts with 0 shares in them
appearing; sadly, they're all over the report.

In contrast, the "Balance Sheet using eguile-gnc" report has an option
(under "Accounts", not "Display" this time) of "Exclude accounts with zero
total balances".  Checking this option achieves what I'd consider the right
result - no zero balance values are shown.

After further experimentation, there seems to be an interaction with the
"Levels of Subaccounts" control on the Accounts tab of the report options.
If I increase the levels of subaccounts accordingly, or flatten the list to
the depth limit, the 0 balance figures don't appear - again, only (so far)
in this one file.

So I have two workarounds to the problem (either using the eguile report,
or adjusting the depth limit/flattening options), but I am still concerned
that I don't understand why the behavior is happening in the first place.

My questions are:
(1) Has anyone else seen this behavior?
(2) If so, do you understand what's triggering it?

Thanks,

Peter
___
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] GTK CSS 4.0-4.1

2020-07-27 Thread GTI .H

I would like it too. but for that we have to run the GtkInspector (
https://wiki.gnome.org/action/show/Projects/GTK/Inspector?action=show&redirect=Projects%2FGTK%2B%2FInspector)
and it doesn't run on Windows and nobody with an OS that runs GtkInspector
so far hasn’t offered to help.

--
Regards

Em seg., 27 de jul. de 2020 às 09:07, Jimmy R via gnucash-user <
gnucash-user@gnucash.org> escreveu:

> Has anyone figured out yet if we can use our custom css.
> Would like to get my font sizes and colors back if possible
>
>
>
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
> ___
> 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.
>


-- 
Regards
GTI
___
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.

[GNC] Report error: advanced-portfolio

2020-07-27 Thread Lipp F.

Just installed 4.1 on Windows 10 and advanced portfolio report throws an
error. The report was working fine on 3.10. Here it is:

Report error

An error occurred while running the report.

In c-interface.scm:
 24:4 19 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9 18 (catch #t # …)
In c-interface.scm:
29:37 17 (_)
In unknown file:
  16 (eval-string "(gnc:report-run 9)" #)
In ice-9/boot-9.scm:
   2312:4 15 (save-module-excursion #)
In ice-9/eval-string.scm:
 38:6 14 (read-and-eval # #:lang _)
In report-core.scm:
689:4 13 (gnc:report-run _)
In c-interface.scm:
 66:2 12 (gnc:backtrace-if-exception _ . _)
 24:4 11 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
829:9 10 (catch #t # …)
In c-interface.scm:
28:40  9 (_)
In report-core.scm:
   691:29  8 (_)
   673:25  7 (gnc:report-render-html #< type: "21d7cfc59fc7…> …)
In standard/advanced-portfolio.scm:
  1057:10  6 (advanced-portfolio-renderer _)
In ice-9/boot-9.scm:
829:9  5 (catch div/0 # …)
In standard/advanced-portfolio.scm:
   428:10  4 (table-add-stock-rows #< col-headers: (("A…> …)
In srfi/srfi-1.scm:
640:9  3 (for-each # …)
In standard/advanced-portfolio.scm:
   460:21  2 (_ _)
In srfi/srfi-1.scm:
640:9  1 (for-each # …)
In standard/advanced-portfolio.scm:
   515:41  0 (_ #)

In procedure module-lookup: Unbound variable: parent-or-sibling?
___
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] GTK CSS 4.0-4.1

CSS for Windows 10



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
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.

[GNC] GTK CSS 4.0-4.1