Re: File Format : XML v MySQL / postgres / sqllite

2018-01-27 Thread David T. via gnucash-user
Sebastien,

The problem isn’t with Python (I am told that Macs already have Python on 
them). The problem as I understand it (John will no doubt correct me when my 
statements prove ill-informed or flat out wrong) has to do with the fact that 
GnuCash requires a specific version of Python, which can only be guaranteed by 
compiling GnuCash with the current version of Python. Short of shipping GnuCash 
with a complete Python installation, the only way around this is for individual 
users to compile locally. Which, as I noted, is a painful process for me. But 
thanks for the information.

David


> On Jan 28, 2018, at 11:55 AM, Sébastien de Menten  wrote:
> 
> Hello David,
> 
> Regarding the use of python on windows and Mac, Anaconda has made a huge 
> difference in the last years providing all packages in an easy precompiled 
> version.
> You can have a look at https://conda.io/docs/user-guide/install/macos.html 
>  for the installation 
> (which is simple and does not require any compiler).
> 
> 
> On Jan 28, 2018 05:42, "D" mailto:sunfis...@yahoo.com>> 
> wrote:
> Ah, yes that was my incorrect reference. Sorry for the crossed reference.
> 
> I will note that my confusion stems in part from the fact that, as a Mac 
> user, I have never used anything to do with python and Gnucash, on account of 
> the high barrier to install the proper toolsets (i.e., compiling yourself). 
> My previous attempts at this process always ended in frustration and failure. 
> As a consequence, when I see anything that mentions python and Gnucash, my 
> eyes glaze over.
> 
> In the past, there hasn't been much to recommend beating my head against that 
> wall, but perhaps the time has come to see what happens at this time, since 
> there eh to be increasing numbers of ways to use python with Gnucash data.
> 
> David
> 
> On January 28, 2018, at 12:55 AM, John Ralls  > wrote:
> 
> I suspect David was thinking of CuteCash, Christian Stimming’s experimental 
> Qt GUI.
> 
> Regards,
> John Ralls
> 
> > On Jan 27, 2018, at 10:44 AM, Sébastien de Menten  > > wrote:
> >
> > Hello David,
> >
> > I saw you were mentioning piecash in your message. If you talk about
> > http://piecash.readthedocs.io/en/latest/ 
> > , it is not a proof of concept for
> > a frontend but an alternative to the gnucash python bindings to work with
> > gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> > MySQL) and is alive and maintained (last release on the 20th December 2017).
> >
> > The following article https://arachnoid.com/gnucash_utilities/ 
> >  shows some
> > interesting use cases for it.
> >
> > With gnucash 3.0, piecash will also allow you to write your own reports
> > using si python and jinja2 (work in progress).
> >
> > For people interested to contribute, https://github.com/sdementen/piecash 
> > .
> >
> >
> > On Jan 27, 2018 18:27, "D via gnucash-user"  > >
> > wrote:
> >
> > Mike,
> >
> > There is nothing new as far as I know about the file formats. You are right
> > that the primary benefit to using sql is being able to generate data sets
> > from sql that can used in reports. Processing a data file is no quicker in
> > sql, since it all gets loaded in at start up. Sql, moreover, adds a
> > database manager role to the mix; many users are not prepared to learn how
> > to manage a database platform to manage their financial accounts.
> >
> > I stick with the XML because it also can store the data compressed; when
> > dealing with the main data file and all its copies, the difference between
> > 3mb and 13mb adds up quickly.
> >
> > Piecash, as I understand it, was a proof-of-concept experiment to see
> > whether a python front end could be designed. It has not been maintained
> > for some years now, and I recall recent discussion about changing its
> > status with the project.
> >
> > As far as I know, there has been no change in recommendation to stay with
> > xml.
> >
> > David
> >
> > On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> > adrien.montele...@gmail.com > wrote:
> >
> > I switched from XML to SQLite about a year ago. I perceive a performance
> > improvement on loading, but that’s about it. (and I generally never shut
> > the app down anyway)
> >
> > I haven’t attempted any custom reporting yet, but I plan to.
> >
> > I could be mistaken, but I think PyCash is designed to parse the XML file
> > so you can still get the reporting you want.
> >
> > Regards,
> > Adrien
> >
> >> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
> > mikestillingfl...@fastmail.co.uk > 
> > wrote:
> >>
> >> Dear All,
> >>
> >> XML is the default when creating a new file.
> >>
> >> I have seen 

Re: File Format : XML v MySQL / postgres / sqllite

2018-01-27 Thread Sébastien de Menten
Hello David,

Regarding the use of python on windows and Mac, Anaconda has made a huge
difference in the last years providing all packages in an easy precompiled
version.
You can have a look at https://conda.io/docs/user-guide/install/macos.html
for the installation (which is simple and does not require any compiler).


On Jan 28, 2018 05:42, "D"  wrote:

> Ah, yes that was my incorrect reference. Sorry for the crossed reference.
>
> I will note that my confusion stems in part from the fact that, as a Mac
> user, I have never used anything to do with python and Gnucash, on account
> of the high barrier to install the proper toolsets (i.e., compiling
> yourself). My previous attempts at this process always ended in frustration
> and failure. As a consequence, when I see anything that mentions python and
> Gnucash, my eyes glaze over.
>
> In the past, there hasn't been much to recommend beating my head against
> that wall, but perhaps the time has come to see what happens at this time,
> since there eh to be increasing numbers of ways to use python with Gnucash
> data.
>
> David
>
> On January 28, 2018, at 12:55 AM, John Ralls  wrote:
>
> I suspect David was thinking of CuteCash, Christian Stimming’s
> experimental Qt GUI.
>
> Regards,
> John Ralls
>
> > On Jan 27, 2018, at 10:44 AM, Sébastien de Menten 
> wrote:
> >
> > Hello David,
> >
> > I saw you were mentioning piecash in your message. If you talk about
> > http://piecash.readthedocs.io/en/latest/, it is not a proof of concept
> for
> > a frontend but an alternative to the gnucash python bindings to work with
> > gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> > MySQL) and is alive and maintained (last release on the 20th December
> 2017).
> >
> > The following article https://arachnoid.com/gnucash_utilities/ shows
> some
> > interesting use cases for it.
> >
> > With gnucash 3.0, piecash will also allow you to write your own reports
> > using si python and jinja2 (work in progress).
> >
> > For people interested to contribute, https://github.com/sdementen/
> piecash.
> >
> >
> > On Jan 27, 2018 18:27, "D via gnucash-user" 
> > wrote:
> >
> > Mike,
> >
> > There is nothing new as far as I know about the file formats. You are
> right
> > that the primary benefit to using sql is being able to generate data sets
> > from sql that can used in reports. Processing a data file is no quicker
> in
> > sql, since it all gets loaded in at start up. Sql, moreover, adds a
> > database manager role to the mix; many users are not prepared to learn
> how
> > to manage a database platform to manage their financial accounts.
> >
> > I stick with the XML because it also can store the data compressed; when
> > dealing with the main data file and all its copies, the difference
> between
> > 3mb and 13mb adds up quickly.
> >
> > Piecash, as I understand it, was a proof-of-concept experiment to see
> > whether a python front end could be designed. It has not been maintained
> > for some years now, and I recall recent discussion about changing its
> > status with the project.
> >
> > As far as I know, there has been no change in recommendation to stay with
> > xml.
> >
> > David
> >
> > On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> > adrien.montele...@gmail.com> wrote:
> >
> > I switched from XML to SQLite about a year ago. I perceive a performance
> > improvement on loading, but that’s about it. (and I generally never shut
> > the app down anyway)
> >
> > I haven’t attempted any custom reporting yet, but I plan to.
> >
> > I could be mistaken, but I think PyCash is designed to parse the XML file
> > so you can still get the reporting you want.
> >
> > Regards,
> > Adrien
> >
> >> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
> > mikestillingfl...@fastmail.co.uk> wrote:
> >>
> >> Dear All,
> >>
> >> XML is the default when creating a new file.
> >>
> >> I have seen various quite dated questions about the decision process of
> > selecting which db to use.
> >>
> >> I think that the main advantage of using MySQL would be the ability to
> > generate custom reports.
> >>
> >> Are there any other advantages and are there any differences in the
> > interface between the various db's. Does the forum still recommend XML.
> >>
> >> Regards
> >>
> >> --
> >> Mike Stillingfleet
> >> mikestillingfl...@fastmail.co.uk
> >> ___
> >> gnucash-user mailing list
> >> gnucash-user@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> >> -
> >> 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
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> > __

Re: Reconcile unusable

2018-01-27 Thread Ronal B Morse

On 01/27/2018 11:26 PM, Mark Lawrence wrote:

On 28/01/18 05:50, Ronal B Morse wrote:

On 01/27/2018 07:20 AM, Mark Lawrence wrote:
With gnucash 2.6.17 on ubuntu 17.10 I cannot do anything with the 
reconcile screen.  Clicking anywhere to do anything always takes me 
back to the main screen, I can't even close it.  It doesn't make any 
difference whether or not I make changes on the "Reconcile 
information" screen.  I've tried restarting my laptop to no avail. 
Several searches have revealed nothing obvious.  Any ideas as this 
is very frustrating? Do I need to raise a bug report or is there one 
all ready that my searches missed?


Mark, I'm on Ubuntu 17.10 and I'm not seeing this issue...the 
reconcile screen and associated functions work fine.


Do you know if you are using the Wayland screen renderer or the old 
X-org. X11 renderer?  if you're not sure, restart Ubuntu and on the 
screen where you enter your user password there is a little gear icon 
near the password dialog box.  Click on that. One of the choices that 
appear will mention Wayland, another will mention X-org.  There may 
be others, depending upon the video in your computer.


Anyway, I believe that Ubuntu may default to using Wayland. That 
should be indicated in the dialog.  Select the X.org option and 
continue your normal login.  See if the problem with the reconcile 
screen persists.


Ron Morse



Problem solved by following the above, thanks for such a fast 
response, and over the weekend as well :)



Happy to be the one that helps, for a change.

n.b., the Wayland renderer has proven problematic for Ubuntu on a number 
of fronts (i.e., it's buggier than a rain forest). So much so that the 
next version, 18.4, due in April, will go back to using the X-Org. 
rendering system as the default.  Wayland will still be available, it 
just won't be automatically selected during the installation like it is 
for 17.10.


Ron Morse

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: Reconcile unusable

2018-01-27 Thread Mark Lawrence

On 28/01/18 05:50, Ronal B Morse wrote:

On 01/27/2018 07:20 AM, Mark Lawrence wrote:
With gnucash 2.6.17 on ubuntu 17.10 I cannot do anything with the 
reconcile screen.  Clicking anywhere to do anything always takes me 
back to the main screen, I can't even close it.  It doesn't make any 
difference whether or not I make changes on the "Reconcile 
information" screen.  I've tried restarting my laptop to no avail. 
Several searches have revealed nothing obvious.  Any ideas as this is 
very frustrating? Do I need to raise a bug report or is there one all 
ready that my searches missed?


Mark, I'm on Ubuntu 17.10 and I'm not seeing this issue...the reconcile 
screen and associated functions work fine.


Do you know if you are using the Wayland screen renderer or the old 
X-org. X11 renderer?  if you're not sure, restart Ubuntu and on the 
screen where you enter your user password there is a little gear icon 
near the password dialog box.  Click on that.  One of the choices that 
appear will mention Wayland, another will mention X-org.  There may be 
others, depending upon the video in your computer.


Anyway, I believe that Ubuntu may default to using Wayland. That should 
be indicated in the dialog.  Select the X.org option and continue your 
normal login.  See if the problem with the reconcile screen persists.


Ron Morse



Problem solved by following the above, thanks for such a fast response, 
and over the weekend as well :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: Reconcile unusable

2018-01-27 Thread Ronal B Morse

On 01/27/2018 07:20 AM, Mark Lawrence wrote:
With gnucash 2.6.17 on ubuntu 17.10 I cannot do anything with the 
reconcile screen.  Clicking anywhere to do anything always takes me 
back to the main screen, I can't even close it.  It doesn't make any 
difference whether or not I make changes on the "Reconcile 
information" screen.  I've tried restarting my laptop to no avail.  
Several searches have revealed nothing obvious.  Any ideas as this is 
very frustrating? Do I need to raise a bug report or is there one all 
ready that my searches missed?


Mark, I'm on Ubuntu 17.10 and I'm not seeing this issue...the reconcile 
screen and associated functions work fine.


Do you know if you are using the Wayland screen renderer or the old 
X-org. X11 renderer?  if you're not sure, restart Ubuntu and on the 
screen where you enter your user password there is a little gear icon 
near the password dialog box.  Click on that.  One of the choices that 
appear will mention Wayland, another will mention X-org.  There may be 
others, depending upon the video in your computer.


Anyway, I believe that Ubuntu may default to using Wayland. That should 
be indicated in the dialog.  Select the X.org option and continue your 
normal login.  See if the problem with the reconcile screen persists.


Ron Morse


___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Reconcile unusable

2018-01-27 Thread Mark Lawrence
With gnucash 2.6.17 on ubuntu 17.10 I cannot do anything with the 
reconcile screen.  Clicking anywhere to do anything always takes me back 
to the main screen, I can't even close it.  It doesn't make any 
difference whether or not I make changes on the "Reconcile information" 
screen.  I've tried restarting my laptop to no avail.  Several searches 
have revealed nothing obvious.  Any ideas as this is very frustrating? 
Do I need to raise a bug report or is there one all ready that my 
searches missed?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: Subaccounts [WAS Re: Future allocated money vs Budgets]

2018-01-27 Thread D via gnucash-user
I'm glad you're going to look at documenting your suggestions in the Tutorial. 
I imagine they would fit as a special section in the budgets chapter.

As for the idea of having formulas active in the register, I think that there 
are a number of issues that need consideration and addressing.

First, when entering transactions, you already can enter numeric formulas 
(35/57), and Gnucash will calculate these. If I am entering transactions for 
real accounting events, then that is all I really need, it seems to me. 
Calculations with variables would only arise for future, tentative 
transactions. But entering future, tentative transactions goes counter to the 
idea that an accounting package tracks real transactions--using real 
money--rather than potential transactions. This has been where such discussions 
have foundered in the past on these lists. The scheduled transactions module 
attempts to finesse this by allowing formulas which are processed separately, 
and which create real transactions at specified points in time.

I imagine also that activating variable-based calculations into the register 
itself would require some serious reprogramming, and I do not know how likely 
that is to happen. I have read here that the register code is challenging to 
work with, and that an attempt to update the register has stalled.

Personally, I have come to believe that budgeting is fundamentally different 
from accounting, and keep them separate. I use a spreadsheet to track the few 
areas I choose to budget, and have a report in Gnucash that gives me usage 
numbers for those areas, which I transfer over manually. Gnucash's budget tools 
always hurt too much for my brain.

David

On January 28, 2018, at 8:27 AM, Matt Graham  
wrote:

Nice! It seems like we are getting somewhere. I am convinced that the process 
we think of budgeting where we are saving up for something is really a case of 
segmenting money within a sub-account. And it looks like Gnucash is already 
happy with this kind of situation - with the include sub-accounts in the 
recociliation window.

I'm going to try this out over the next week or so and then try to contriubute 
to the Tutorial and concepts guide on it. It can get pretty complicated (for 
beginners) when you segment the money in your savings acount, and then want to 
spend out of cash/checking etc. Is a pretty common thing that people want out 
of Gnucash.

After trying it, I'll also be in a position to suggest any feature changes that 
would make it easier. Hinted already by others is the feature of "formula" 
based data entry - doing data entry a bit like a spreadsheet, where simple 
equations can be used often based on the values present in other 
accounts/transactions... I'll leave that for now and explore it in my next big 
discussion with you all!

Thanks again - greatly appreciate your time,
Matt


 Original message 
From: Adrien Monteleone 
Date: 27/1/18 18:15 (GMT+10:00)
To: GNU Cash User 
Subject: Re: Subaccounts [WAS Re: Future allocated money vs Budgets]

That’s an interesting use of future dated transactions. Thanks!


Regards,
Adrien

> On Jan 26, 2018, at 5:21 PM, Tommy Trussell  wrote:
>
> I was following the budget discussion, and I decided to split my comment
> into a different thread. I'm not responding to any particular comment, and
> this isn't quite germane to budgeting.
>
> But I want to clear up a few misunderstandings I'm seeing folks express
> about reconciling with sub-accounts. Subaccounts work very well, but they
> do take a little maintenance.
>
> WHEN TO USE SUBACCOUNTS
>
> You can use subaccounts for several purposes, including budgeting, holding
> onto money that isn't "yours" (a bond you're holding from a contractor for
> successful completion of a project, for instance), identifying earmarked
> funds, OR (as in the example below) simply stopping yourself from spending
> down the account more than you'd like.
>
> (If folks have additional suggested uses for subaccounts, bring em on!)
>
> EXAMPLE: MINIMUM BALANCE VIEW
>
> Here's a real-world (well it's real in MY world) example -- avoiding
> "minimum balance" fees. The bank name has been changed to protect the
> bookkeeper. ;-)
>
> I have a checking account at BigBank.
>
> Assets:Current Assets:BigBank Checking
>
> The terms on that bank account say it doesn't cost me anything UNLESS the
> balance drops below $2500, at which point I have to pay $8.50/month. (There
> are some other miscellaneous fees, all higher when the balance goes low.)
>
> SO to help avoid the $8.50/month expense, I created a sub account:
>
> Assets:Current Assets:BigBank Checking:Minimum Balance
>
> Then I created a transaction dated 2/15/2015, transferring $2500 from the
> account to its subaccount:
>
> (This is a representation of the BigBank Checking two-line auto-split
> register. Items in the right column are "cr" and items in the left column
> are "dr".)
>
>  2/15/2015 min Minimum Balance   2500.00cr
>Assets:C

Re: Accuracy / Rounding issues - Difference between gnucash and broker account

2018-01-27 Thread D via gnucash-user
Ah. The wonders of autocorrect. "the part three Mayers" really makes more sense 
if it were written as "the part that matters."

 David

On January 28, 2018, at 9:48 AM, D via gnucash-user  
wrote:

Yes. Fill in the amount and the shares, and let Gnucash calculate the price. It 
won't match the statement exactly (it never does, in my experience), but the 
price isn't really the part three Mayers; it's the other two that do.

David

On January 28, 2018, at 2:56 AM, Pawel Wocjan  wrote:

Hi,

I have selected dividend reinvestment for MSFT so I end up having fractional 
shares with my broker. For instance, in my account I see the following data for 
Microsoft:

Price: 94.060
Shares: 30.147
Current value: $2,835.62

I'm trying to reproduce all the data for all my individual stocks, mutual 
funds, ETFs with gnucash. However, gnucash pull the latest MSF price, which is 
94.060, has the same number of shares, but reports a different total value

$2,835.63

meaning there is a difference of 1 cent. It seems that the broker only keeps 
the first two fractional places and chops off the remaining ones. Gnucash 
rounds up (in this case) the second fractional place. 

Are there some general guidelines how to choose accuracy for fractional 
shares/price etc? Has anybody experience such minor discrepancies between 
his/her broker account and gnucash?

Thank you for your help,
Pawel 
  
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: Accuracy / Rounding issues - Difference between gnucash and broker account

2018-01-27 Thread D via gnucash-user
Yes. Fill in the amount and the shares, and let Gnucash calculate the price. It 
won't match the statement exactly (it never does, in my experience), but the 
price isn't really the part three Mayers; it's the other two that do.

David

On January 28, 2018, at 2:56 AM, Pawel Wocjan  wrote:

Hi,

I have selected dividend reinvestment for MSFT so I end up having fractional 
shares with my broker. For instance, in my account I see the following data for 
Microsoft:

Price: 94.060
Shares: 30.147
Current value: $2,835.62

I'm trying to reproduce all the data for all my individual stocks, mutual 
funds, ETFs with gnucash. However, gnucash pull the latest MSF price, which is 
94.060, has the same number of shares, but reports a different total value

$2,835.63

meaning there is a difference of 1 cent. It seems that the broker only keeps 
the first two fractional places and chops off the remaining ones. Gnucash 
rounds up (in this case) the second fractional place. 

Are there some general guidelines how to choose accuracy for fractional 
shares/price etc? Has anybody experience such minor discrepancies between 
his/her broker account and gnucash?

Thank you for your help,
Pawel 
  
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: File Format : XML v MySQL / postgres / sqllite

2018-01-27 Thread D via gnucash-user
Ah, yes that was my incorrect reference. Sorry for the crossed reference.

I will note that my confusion stems in part from the fact that, as a Mac user, 
I have never used anything to do with python and Gnucash, on account of the 
high barrier to install the proper toolsets (i.e., compiling yourself). My 
previous attempts at this process always ended in frustration and failure. As a 
consequence, when I see anything that mentions python and Gnucash, my eyes 
glaze over.

In the past, there hasn't been much to recommend beating my head against that 
wall, but perhaps the time has come to see what happens at this time, since 
there eh to be increasing numbers of ways to use python with Gnucash data.

David

On January 28, 2018, at 12:55 AM, John Ralls  wrote:

I suspect David was thinking of CuteCash, Christian Stimming’s experimental Qt 
GUI.

Regards,
John Ralls

> On Jan 27, 2018, at 10:44 AM, Sébastien de Menten  wrote:
> 
> Hello David,
> 
> I saw you were mentioning piecash in your message. If you talk about
> http://piecash.readthedocs.io/en/latest/, it is not a proof of concept for
> a frontend but an alternative to the gnucash python bindings to work with
> gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> MySQL) and is alive and maintained (last release on the 20th December 2017).
> 
> The following article https://arachnoid.com/gnucash_utilities/ shows some
> interesting use cases for it.
> 
> With gnucash 3.0, piecash will also allow you to write your own reports
> using si python and jinja2 (work in progress).
> 
> For people interested to contribute, https://github.com/sdementen/piecash.
> 
> 
> On Jan 27, 2018 18:27, "D via gnucash-user" 
> wrote:
> 
> Mike,
> 
> There is nothing new as far as I know about the file formats. You are right
> that the primary benefit to using sql is being able to generate data sets
> from sql that can used in reports. Processing a data file is no quicker in
> sql, since it all gets loaded in at start up. Sql, moreover, adds a
> database manager role to the mix; many users are not prepared to learn how
> to manage a database platform to manage their financial accounts.
> 
> I stick with the XML because it also can store the data compressed; when
> dealing with the main data file and all its copies, the difference between
> 3mb and 13mb adds up quickly.
> 
> Piecash, as I understand it, was a proof-of-concept experiment to see
> whether a python front end could be designed. It has not been maintained
> for some years now, and I recall recent discussion about changing its
> status with the project.
> 
> As far as I know, there has been no change in recommendation to stay with
> xml.
> 
> David
> 
> On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> adrien.montele...@gmail.com> wrote:
> 
> I switched from XML to SQLite about a year ago. I perceive a performance
> improvement on loading, but that’s about it. (and I generally never shut
> the app down anyway)
> 
> I haven’t attempted any custom reporting yet, but I plan to.
> 
> I could be mistaken, but I think PyCash is designed to parse the XML file
> so you can still get the reporting you want.
> 
> Regards,
> Adrien
> 
>> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
> mikestillingfl...@fastmail.co.uk> wrote:
>> 
>> Dear All,
>> 
>> XML is the default when creating a new file.
>> 
>> I have seen various quite dated questions about the decision process of
> selecting which db to use.
>> 
>> I think that the main advantage of using MySQL would be the ability to
> generate custom reports.
>> 
>> Are there any other advantages and are there any differences in the
> interface between the various db's. Does the forum still recommend XML.
>> 
>> Regards
>> 
>> --
>> Mike Stillingfleet
>> mikestillingfl...@fastmail.co.uk
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucas

Re: Subaccounts [WAS Re: Future allocated money vs Budgets]

2018-01-27 Thread Adrien Monteleone
You can already use formulas in scheduled transactions, I just don’t think you 
can use a present GC register value as a variable. (such as x% of the balance 
of Assets:Checking) I could be wrong. It should be possible though to use the 
value of one split as a variable so some auto-allocation might be possible.

There’s also the issue with triggering the transaction based on an event other 
than a date stamp. (such as triggering after you post a credit to income or a 
debit to an checking account)

What we really need there isn’t so much a Scheduled Transaction but a Template 
Transaction. (that can retain formulas)

As for keeping accounts straight, if someone in the real world wants to spend 
money from a savings account by writing a check on their checking account - 
that’s physically impossible. (barring auto adjusting as overdraft protection) 
I don’t see why GnuCash should be any different. Trying to make that possible I 
think would lead to all sorts of confusion as to where money came from or where 
it should be. To help reduce the tendency to do so, I suggested splitting up 
the sub-accounts based on where you are most likely to draw funds from for 
those particular purposes. Otherwise, you’d have to do a transfer from say 
‘Savings’ to ‘Checking’ in GnuCash first just like you would in the real world. 
But if you’re in the habit of spending from any ole’ source for any ole’ 
purpose then by all means, keep the sub-accounts separate, you’ll just have to 
include the transfer split in the expense transaction or else do a separate 
transfer transaction.

Regards,
Adrien

> On Jan 27, 2018, at 9:25 PM, Matt Graham  wrote:
> 
> Nice! It seems like we are getting somewhere. I am convinced that the process 
> we think of budgeting where we are saving up for something is really a case 
> of segmenting money within a sub-account. And it looks like Gnucash is 
> already happy with this kind of situation - with the include sub-accounts in 
> the recociliation window. 
> 
> I'm going to try this out over the next week or so and then try to 
> contriubute to the Tutorial and concepts guide on it. It can get pretty 
> complicated (for beginners) when you segment the money in your savings 
> acount, and then want to spend out of cash/checking etc. Is a pretty common 
> thing that people want out of Gnucash. 
> 
> After trying it, I'll also be in a position to suggest any feature changes 
> that would make it easier. Hinted already by others is the feature of 
> "formula" based data entry - doing data entry a bit like a spreadsheet, where 
> simple equations can be used often based on the values present in other 
> accounts/transactions... I'll leave that for now and explore it in my next 
> big discussion with you all!  
> 
> Thanks again - greatly appreciate your time,
> Matt
> 
> 
>  Original message 
> From: Adrien Monteleone  > 
> Date: 27/1/18 18:15 (GMT+10:00) 
> To: GNU Cash User  > 
> Subject: Re: Subaccounts [WAS Re: Future allocated money vs Budgets] 
> 
> That’s an interesting use of future dated transactions. Thanks!
> 
> 
> Regards,
> Adrien
> 
> > On Jan 26, 2018, at 5:21 PM, Tommy Trussell  > > wrote:
> > 
> > I was following the budget discussion, and I decided to split my comment
> > into a different thread. I'm not responding to any particular comment, and
> > this isn't quite germane to budgeting.
> > 
> > But I want to clear up a few misunderstandings I'm seeing folks express
> > about reconciling with sub-accounts. Subaccounts work very well, but they
> > do take a little maintenance.
> > 
> > WHEN TO USE SUBACCOUNTS
> > 
> > You can use subaccounts for several purposes, including budgeting, holding
> > onto money that isn't "yours" (a bond you're holding from a contractor for
> > successful completion of a project, for instance), identifying earmarked
> > funds, OR (as in the example below) simply stopping yourself from spending
> > down the account more than you'd like.
> > 
> > (If folks have additional suggested uses for subaccounts, bring em on!)
> > 
> > EXAMPLE: MINIMUM BALANCE VIEW
> > 
> > Here's a real-world (well it's real in MY world) example -- avoiding
> > "minimum balance" fees. The bank name has been changed to protect the
> > bookkeeper. ;-)
> > 
> > I have a checking account at BigBank.
> > 
> > Assets:Current Assets:BigBank Checking
> > 
> > The terms on that bank account say it doesn't cost me anything UNLESS the
> > balance drops below $2500, at which point I have to pay $8.50/month. (There
> > are some other miscellaneous fees, all higher when the balance goes low.)
> > 
> > SO to help avoid the $8.50/month expense, I created a sub account:
> > 
> > Assets:Current Assets:BigBank Checking:Minimum Balance
> > 
> > Then I created a transaction dated 2/15/2015, transferring $2500 from the
> > account to its subaccount:
> > 
> > (This is a representation of

Re: Subaccounts [WAS Re: Future allocated money vs Budgets]

2018-01-27 Thread Matt Graham
Nice! It seems like we are getting somewhere. I am convinced that the process 
we think of budgeting where we are saving up for something is really a case of 
segmenting money within a sub-account. And it looks like Gnucash is already 
happy with this kind of situation - with the include sub-accounts in the 
recociliation window.

I'm going to try this out over the next week or so and then try to contriubute 
to the Tutorial and concepts guide on it. It can get pretty complicated (for 
beginners) when you segment the money in your savings acount, and then want to 
spend out of cash/checking etc. Is a pretty common thing that people want out 
of Gnucash.

After trying it, I'll also be in a position to suggest any feature changes that 
would make it easier. Hinted already by others is the feature of "formula" 
based data entry - doing data entry a bit like a spreadsheet, where simple 
equations can be used often based on the values present in other 
accounts/transactions... I'll leave that for now and explore it in my next big 
discussion with you all!

Thanks again - greatly appreciate your time,
Matt


 Original message 
From: Adrien Monteleone 
Date: 27/1/18 18:15 (GMT+10:00)
To: GNU Cash User 
Subject: Re: Subaccounts [WAS Re: Future allocated money vs Budgets]

That’s an interesting use of future dated transactions. Thanks!


Regards,
Adrien

> On Jan 26, 2018, at 5:21 PM, Tommy Trussell  wrote:
>
> I was following the budget discussion, and I decided to split my comment
> into a different thread. I'm not responding to any particular comment, and
> this isn't quite germane to budgeting.
>
> But I want to clear up a few misunderstandings I'm seeing folks express
> about reconciling with sub-accounts. Subaccounts work very well, but they
> do take a little maintenance.
>
> WHEN TO USE SUBACCOUNTS
>
> You can use subaccounts for several purposes, including budgeting, holding
> onto money that isn't "yours" (a bond you're holding from a contractor for
> successful completion of a project, for instance), identifying earmarked
> funds, OR (as in the example below) simply stopping yourself from spending
> down the account more than you'd like.
>
> (If folks have additional suggested uses for subaccounts, bring em on!)
>
> EXAMPLE: MINIMUM BALANCE VIEW
>
> Here's a real-world (well it's real in MY world) example -- avoiding
> "minimum balance" fees. The bank name has been changed to protect the
> bookkeeper. ;-)
>
> I have a checking account at BigBank.
>
> Assets:Current Assets:BigBank Checking
>
> The terms on that bank account say it doesn't cost me anything UNLESS the
> balance drops below $2500, at which point I have to pay $8.50/month. (There
> are some other miscellaneous fees, all higher when the balance goes low.)
>
> SO to help avoid the $8.50/month expense, I created a sub account:
>
> Assets:Current Assets:BigBank Checking:Minimum Balance
>
> Then I created a transaction dated 2/15/2015, transferring $2500 from the
> account to its subaccount:
>
> (This is a representation of the BigBank Checking two-line auto-split
> register. Items in the right column are "cr" and items in the left column
> are "dr".)
>
>  2/15/2015 min Minimum Balance   2500.00cr
>Assets:Current Assets:BigBank Checking:Minimum Balance   $2500.00dr
>Assets:Current Assets:BigBank Checking   $2500.00cr
>
> When I reconciled my account the first time after creating this
> transaction, I made sure to tick the "Include Subaccounts" checkbox on the
> Reconcile Information dialog. I (as always) verified the ENDING balance
> information exactly as it was shown on the bank's statement.
>
> Also that first time I reconciled, I noticed TWO items to clear that
> weren't actually on the bank statement -- $2500 in the funds in side and
> $2500 in the funds out side of the reconcile window. I marked them BOTH as
> "cleared."
>
> From now on, I notice a few things have changed from before --
>
> o - My default balance when I reconcile AND the running balance in the
> BigBank Checking register will always show $2500 lower than I actually
> have.
>
> o - When I reconcile I always have to remember to override the default and
> enter the ENDING balance as it is shown on BigBank's statement.
>
> o - When I reconcile the "Include Subaccounts" checkbox is ticked and it
> needs to stay ticked. (It seems to "remember" the setting from session to
> session, as you would hope.)
>
> o - I also notice when I'm reconciling that when I "jump" to a transaction
> by double-clicking on an item in the funds in / funds out lists, the
> transaction opens into a different kind of "general ledger" style register
> that includes ALL transactions in the account and subaccounts. It exactly
> resembles the kind of register that appears when you search for
> transactions. It has a "plus" (+) mark in its tab and looks different from
> the "ordinary" register.
>
>
> Obviously at any time I can "overspend" and the primary account balance
> will go negat

Re: yahoo as json stock quotes pounds/pence

2018-01-27 Thread Dave H
Also if you go to
https://lists.gnucash.org/pipermail/gnucash-user/2017-November/thread.html#72946
there's a lot more info re the issue of changing quotes from Yahoo to
Alphavantage.

If you want to search the mailing list you need to specify the site in
google e.g. "site:gnucash-user@gnucash.org alphavantage" or similar as the
Gnucash search function doesn't work.

The actual release announcement for this change is at
https://lists.gnucash.org/pipermail/gnucash-user/2017-November/072859.html

And states among other things...

Finance-Quote 1.45 released!*Erik Colson* eco at ecocode.net

*Wed Nov 8 15:36:51 EST 2017*


   - Previous message (by thread): Asian Stocks and Multiple Currencies Not
   Updated
   
   - Next message (by thread): Finance-Quote 1.45 released!
   
   - *Messages sorted by:* [ date ]
   

[ thread ]
   

[ subject ]
   

[ author ]
   


--

New version 1.45 of Finance-Quote is available with the following changes:

* alphavantage
  * more suffix - currency pairs added
  * GBP and GBX divided by 100


Cheers Dave H.


On 28 January 2018 at 07:02, Dave H  wrote:

> This came about because of an issue reported in early November last year
> and is considered solved I believe 
>
> What version of Finance Quote are you running as it all changed about then
> ???
>
> > On 06/11/17 22:43, Erik Colson wrote:
> >> New version 1.43 of Finance-Quote is available with the following
> changes:
> >
> > All prices from AlphaVantage are being returned 100 times too big as
> > pence rather than pounds. For example, a price of £7.329 is being
> > returned as £732.90. This is making stock values 100 times too big in
> > gnucash.
>
> division by 100 will be added in F::Q v1.45
>
> Cheers Dave H.
>
>
> On 28 January 2018 at 02:18, ml enquirer  wrote:
>
>> OK, I guess this is not a solved problem, then? I don't see this on the
>> GnuCash FAQ page... and I figure these 2008/2009 threads are quite likely
>> to be outdated.
>>
>> I did the following:
>> - checkout financequote: "git clone
>> https://github.com/finance-quote/finance-quote.git
>> - edit lib/Finance/Quote/YahooJSON.pm to change:
>> <<
>>
>> $info{ $stocks, "last" }   = $json_price;
>> >>
>>
>> $info{ $stocks, "last" }   = $json_price/100.;
>> - edit the gnc-fq-helper script to add at the top the line:
>>
>> use lib '/lib';
>>
>>
>> This isn't a great/elegant solution. I'd be very interested to hear what
>> more experienced people have to say!
>>
>>
>> Thanks,
>>
>> Dan
>>
>>
>> On Thu, Jan 25, 2018 at 11:55 PM, ml enquirer 
>> wrote:
>>
>> > Hi,
>> >
>> > I'm aware this is not a new question:
>> > - https://lists.gnucash.org/pipermail/gnucash-user/2008-
>> > November/027224.html
>> > - https://lists.gnucash.org/pipermail/gnucash-user/2008-April/
>> 024688.html
>> > - https://lists.gnucash.org/pipermail/gnucash-user/2009-
>> > February/028602.html
>> >
>> > but I recently found the "get quotes" feature stopped working with a
>> very
>> > generic error message (more or less the same time as the change of
>> currency
>> > quotes from yahoo to alphaVantage). So I switched my "Type of quote
>> source"
>> > in the "Securities Editor" to "Yahoo as JSON" instead of "Yahoo Europe".
>> >
>> > However, now I see the returned values are in GBP *pence* not *pounds*,
>> so
>> > 100 times larger than GnuCash expects.
>> >
>> > Most previous fixes discussed here (as far as I can see all >2 years
>> old)
>> > involve various hacks at different levels in the source. Is this a
>> solved
>> > problem, or do I need to follow their lead and dig around in the code?
>> >
>> > Thanks in advance!
>> >
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> 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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Accuracy / Rounding issues - Difference between gnucash and broker account

2018-01-27 Thread Pawel Wocjan
Hi,

I have selected dividend reinvestment for MSFT so I end up having fractional 
shares with my broker. For instance, in my account I see the following data for 
Microsoft:

Price: 94.060
Shares: 30.147
Current value: $2,835.62

I'm trying to reproduce all the data for all my individual stocks, mutual 
funds, ETFs with gnucash. However, gnucash pull the latest MSF price, which is 
94.060, has the same number of shares, but reports a different total value

$2,835.63

meaning there is a difference of 1 cent. It seems that the broker only keeps 
the first two fractional places and chops off the remaining ones. Gnucash 
rounds up (in this case) the second fractional place. 

Are there some general guidelines how to choose accuracy for fractional 
shares/price etc? Has anybody experience such minor discrepancies between 
his/her broker account and gnucash?

Thank you for your help,
Pawel 
  
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: Reports very slow to open

2018-01-27 Thread John Ralls


> On Jan 25, 2018, at 10:00 PM, David Carlson  
> wrote:
> 
> Also, I think it is known that release 2.7.3 is unable to install F::Q, even 
> via the manual program link in the GnuCash program group of the Windows 7 
> start menu. 

If I knew that I'd forgotten. The new build scripts missed copying over the 
implementation file into the bundle. Thanks for bringing it up (again).

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: yahoo as json stock quotes pounds/pence

2018-01-27 Thread Dave H
This came about because of an issue reported in early November last year
and is considered solved I believe 

What version of Finance Quote are you running as it all changed about then
???

> On 06/11/17 22:43, Erik Colson wrote:
>> New version 1.43 of Finance-Quote is available with the following
changes:
>
> All prices from AlphaVantage are being returned 100 times too big as
> pence rather than pounds. For example, a price of £7.329 is being
> returned as £732.90. This is making stock values 100 times too big in
> gnucash.

division by 100 will be added in F::Q v1.45

Cheers Dave H.


On 28 January 2018 at 02:18, ml enquirer  wrote:

> OK, I guess this is not a solved problem, then? I don't see this on the
> GnuCash FAQ page... and I figure these 2008/2009 threads are quite likely
> to be outdated.
>
> I did the following:
> - checkout financequote: "git clone
> https://github.com/finance-quote/finance-quote.git
> - edit lib/Finance/Quote/YahooJSON.pm to change:
> <<
>
> $info{ $stocks, "last" }   = $json_price;
> >>
>
> $info{ $stocks, "last" }   = $json_price/100.;
> - edit the gnc-fq-helper script to add at the top the line:
>
> use lib '/lib';
>
>
> This isn't a great/elegant solution. I'd be very interested to hear what
> more experienced people have to say!
>
>
> Thanks,
>
> Dan
>
>
> On Thu, Jan 25, 2018 at 11:55 PM, ml enquirer 
> wrote:
>
> > Hi,
> >
> > I'm aware this is not a new question:
> > - https://lists.gnucash.org/pipermail/gnucash-user/2008-
> > November/027224.html
> > - https://lists.gnucash.org/pipermail/gnucash-user/2008-
> April/024688.html
> > - https://lists.gnucash.org/pipermail/gnucash-user/2009-
> > February/028602.html
> >
> > but I recently found the "get quotes" feature stopped working with a very
> > generic error message (more or less the same time as the change of
> currency
> > quotes from yahoo to alphaVantage). So I switched my "Type of quote
> source"
> > in the "Securities Editor" to "Yahoo as JSON" instead of "Yahoo Europe".
> >
> > However, now I see the returned values are in GBP *pence* not *pounds*,
> so
> > 100 times larger than GnuCash expects.
> >
> > Most previous fixes discussed here (as far as I can see all >2 years old)
> > involve various hacks at different levels in the source. Is this a solved
> > problem, or do I need to follow their lead and dig around in the code?
> >
> > Thanks in advance!
> >
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

2018-01-27 Thread John Ralls
I suspect David was thinking of CuteCash, Christian Stimming’s experimental Qt 
GUI.

Regards,
John Ralls

> On Jan 27, 2018, at 10:44 AM, Sébastien de Menten  wrote:
> 
> Hello David,
> 
> I saw you were mentioning piecash in your message. If you talk about
> http://piecash.readthedocs.io/en/latest/, it is not a proof of concept for
> a frontend but an alternative to the gnucash python bindings to work with
> gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> MySQL) and is alive and maintained (last release on the 20th December 2017).
> 
> The following article https://arachnoid.com/gnucash_utilities/ shows some
> interesting use cases for it.
> 
> With gnucash 3.0, piecash will also allow you to write your own reports
> using si python and jinja2 (work in progress).
> 
> For people interested to contribute, https://github.com/sdementen/piecash.
> 
> 
> On Jan 27, 2018 18:27, "D via gnucash-user" 
> wrote:
> 
> Mike,
> 
> There is nothing new as far as I know about the file formats. You are right
> that the primary benefit to using sql is being able to generate data sets
> from sql that can used in reports. Processing a data file is no quicker in
> sql, since it all gets loaded in at start up. Sql, moreover, adds a
> database manager role to the mix; many users are not prepared to learn how
> to manage a database platform to manage their financial accounts.
> 
> I stick with the XML because it also can store the data compressed; when
> dealing with the main data file and all its copies, the difference between
> 3mb and 13mb adds up quickly.
> 
> Piecash, as I understand it, was a proof-of-concept experiment to see
> whether a python front end could be designed. It has not been maintained
> for some years now, and I recall recent discussion about changing its
> status with the project.
> 
> As far as I know, there has been no change in recommendation to stay with
> xml.
> 
> David
> 
> On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> adrien.montele...@gmail.com> wrote:
> 
> I switched from XML to SQLite about a year ago. I perceive a performance
> improvement on loading, but that’s about it. (and I generally never shut
> the app down anyway)
> 
> I haven’t attempted any custom reporting yet, but I plan to.
> 
> I could be mistaken, but I think PyCash is designed to parse the XML file
> so you can still get the reporting you want.
> 
> Regards,
> Adrien
> 
>> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
> mikestillingfl...@fastmail.co.uk> wrote:
>> 
>> Dear All,
>> 
>> XML is the default when creating a new file.
>> 
>> I have seen various quite dated questions about the decision process of
> selecting which db to use.
>> 
>> I think that the main advantage of using MySQL would be the ability to
> generate custom reports.
>> 
>> Are there any other advantages and are there any differences in the
> interface between the various db's. Does the forum still recommend XML.
>> 
>> Regards
>> 
>> --
>> Mike Stillingfleet
>> mikestillingfl...@fastmail.co.uk
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

2018-01-27 Thread Sébastien de Menten
Hello David,

I saw you were mentioning piecash in your message. If you talk about
http://piecash.readthedocs.io/en/latest/, it is not a proof of concept for
a frontend but an alternative to the gnucash python bindings to work with
gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
MySQL) and is alive and maintained (last release on the 20th December 2017).

The following article https://arachnoid.com/gnucash_utilities/ shows some
interesting use cases for it.

With gnucash 3.0, piecash will also allow you to write your own reports
using si python and jinja2 (work in progress).

For people interested to contribute, https://github.com/sdementen/piecash.


On Jan 27, 2018 18:27, "D via gnucash-user" 
wrote:

Mike,

There is nothing new as far as I know about the file formats. You are right
that the primary benefit to using sql is being able to generate data sets
from sql that can used in reports. Processing a data file is no quicker in
sql, since it all gets loaded in at start up. Sql, moreover, adds a
database manager role to the mix; many users are not prepared to learn how
to manage a database platform to manage their financial accounts.

I stick with the XML because it also can store the data compressed; when
dealing with the main data file and all its copies, the difference between
3mb and 13mb adds up quickly.

Piecash, as I understand it, was a proof-of-concept experiment to see
whether a python front end could be designed. It has not been maintained
for some years now, and I recall recent discussion about changing its
status with the project.

As far as I know, there has been no change in recommendation to stay with
xml.

David

On January 27, 2018, at 12:13 PM, Adrien Monteleone <
adrien.montele...@gmail.com> wrote:

I switched from XML to SQLite about a year ago. I perceive a performance
improvement on loading, but that’s about it. (and I generally never shut
the app down anyway)

I haven’t attempted any custom reporting yet, but I plan to.

I could be mistaken, but I think PyCash is designed to parse the XML file
so you can still get the reporting you want.

Regards,
Adrien

> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
mikestillingfl...@fastmail.co.uk> wrote:
>
> Dear All,
>
> XML is the default when creating a new file.
>
> I have seen various quite dated questions about the decision process of
selecting which db to use.
>
> I think that the main advantage of using MySQL would be the ability to
generate custom reports.
>
> Are there any other advantages and are there any differences in the
interface between the various db's. Does the forum still recommend XML.
>
> Regards
>
> --
>  Mike Stillingfleet
>  mikestillingfl...@fastmail.co.uk
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

2018-01-27 Thread D via gnucash-user
Mike,

There is nothing new as far as I know about the file formats. You are right 
that the primary benefit to using sql is being able to generate data sets from 
sql that can used in reports. Processing a data file is no quicker in sql, 
since it all gets loaded in at start up. Sql, moreover, adds a database manager 
role to the mix; many users are not prepared to learn how to manage a database 
platform to manage their financial accounts.

I stick with the XML because it also can store the data compressed; when 
dealing with the main data file and all its copies, the difference between 3mb 
and 13mb adds up quickly.

Piecash, as I understand it, was a proof-of-concept experiment to see whether a 
python front end could be designed. It has not been maintained for some years 
now, and I recall recent discussion about changing its status with the project.

As far as I know, there has been no change in recommendation to stay with xml.

David

On January 27, 2018, at 12:13 PM, Adrien Monteleone 
 wrote:

I switched from XML to SQLite about a year ago. I perceive a performance 
improvement on loading, but that’s about it. (and I generally never shut the 
app down anyway)

I haven’t attempted any custom reporting yet, but I plan to.

I could be mistaken, but I think PyCash is designed to parse the XML file so 
you can still get the reporting you want.

Regards,
Adrien

> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet 
>  wrote:
> 
> Dear All,
> 
> XML is the default when creating a new file.
> 
> I have seen various quite dated questions about the decision process of 
> selecting which db to use.
> 
> I think that the main advantage of using MySQL would be the ability to 
> generate custom reports.
> 
> Are there any other advantages and are there any differences in the interface 
> between the various db's. Does the forum still recommend XML.
> 
> Regards
> 
> -- 
>  Mike Stillingfleet
>  mikestillingfl...@fastmail.co.uk
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: Reports very slow to open

2018-01-27 Thread David Reiser
I can’t time report loading on my macs in 2.7.3 — gnucash crashes whenever I 
try to create a report. No problems or slowdowns with 2.6.19
--
Dave Reiser
dbrei...@icloud.com





> On Jan 27, 2018, at 11:39 AM, R. Victor Klassen  wrote:
> 
> This is quite dramatic.  Probably my favourite thing to do in code is to make 
> it faster.  (Un)fortunately I don’t run Windows, so I have little to offer 
> here.  The sudden and dramatic change raises the question of what changed?   
> And I haven’t noticed this issue on the Mac, so I’m guessing the change was 
> only on Windows.  Which in itself supports the theory that the change 
> happened not within GnuCash but in one of its dependencies.  
> 
> But then, I try hard never to close GnuCash down, so I’m not sure I would 
> have noticed.   
> 
> The subject line refers to reports - the sample being tested has many large 
> reports open at startup, as I understand it.   But if “Loading User Data” 
> precedes the start of building reports, it wouldn’t seem that’s the issue - 
> unless building open reports is part of “Loading User Data”...
> 
> I’d be curious whether the startup time on an Sqlite3 file format would show 
> the same pattern.
> 
> 
>> On Jan 26, 2018, at 1:00 AM, David Carlson  
>> wrote:
>> 
>> Here are the times to fully open my data file on my Windows 7 laptop.
>> 
>> 2.6.18 to open 6,480 KB compressed XML file on C: drive
>> 3:14:21
>> 2.6.16 to open 82,605 KB uncompressed XML file on C: drive
>> 3:06:97
>> 2.6.18 to open 6,480 KB compressed XML file on LAN mapped to U:  3:54:00
>> 
>> 2.7.3 to open 6,484 KB compressed XML file on C: drive
>> 6:36:85
>> 2.7.3 to open 80,747 KB uncompressed XML file on C: drive
>> 6:41:29
>> 2.7.3 to open 6,484 KB compressed XML file on LAN mapped to U:7:25:00
>> 
>> For release 2.7.3 it takes just over 4 minutes to finish 'Loading User
>> Data" and start building register tabs in the main window.  Release 2.6.18
>> took about 1 minute 50 seconds to finish 'Loading User Data" and start
>> building register tabs in the main window.
>> It looks like that part of the process is the first place to look for ways
>> to speed it up.
>> 
>> I am not sure why the uncompressed file loaded more slowly with 2.7.3.  I
>> did change the date of one transaction to make the file 'dirty' to get it
>> saved in uncompressed format.
>> 
>> Also, I think it is known that release 2.7.3 is unable to install F::Q,
>> even via the manual program link in the GnuCash program group of the
>> Windows 7 start menu.
>> 
>> David C
>> 
>> On Thu, Jan 25, 2018 at 6:35 PM, John Ralls  wrote:
>> 
>>> David,
>>> 
>>> Maybe just to rule it out as an issue you could temporarily put it on a
>>> local drive.
>>> 
>>> How big is it? It's XML, right? See if turning compression on or off makes
>>> a difference.
>>> 
>>> Regards,
>>> John Ralls
>>> 
>>> 
 On Jan 25, 2018, at 3:15 PM, David Carlson 
>>> wrote:
 
 I failed to mention that my data file is not on my "C" drive, it is on a
 LAN file-server, but the entire path is via 100 MHz Ethernet, no Wi-Fi.
 
 David C
 
 On Thu, Jan 25, 2018 at 2:45 PM, David Carlson <
>>> david.carlson@gmail.com>
 wrote:
 
> Preliminary results comparing release 2.6.18-3 with 2.7.3 on a Dell
> Precision 7510 laptop running Windows 7 sp1 64 bit with a Intel(R)
>>> Core(TM)
> i7-6820HQ CPU @2.70Ghz and 24.0 GB installed RAM and all updates
>>> installed
> except a recent Dell display driver update and the Spectre patch update
>>> is
> not installed yet(?):
> 
> Opening a copy of my current data file with scads of tabs including
> several reports, and a read-only register tab.
> 
> In 2.6.18-3 it took 3 minutes 54 seconds to complete opening the file
>>> with
> no Since Last Run interruption.
> 
> In 2.7.3 first touch it took 8 minutes 25 seconds to the metadata
>>> migrated
> window.
> 
> Second opening 7 minutes 5 seconds.  I have many more details to share
> elsewhere.
> 
> David C
> 
> 
> On Thu, Jan 25, 2018 at 1:09 PM, Geert Janssens <
> geert.gnuc...@kobaltwit.be> wrote:
> 
>> Op donderdag 25 januari 2018 17:17:48 CET schreef David Carlson:
>>> About not seeing Geert's message in the Gmail instance in Firefox on
>>> my
>>> laptop, on that machine gmail put it into spam because it did not meet
>>> their lofty standards for authentication.  On the Gmail app on my
>> Samsung
>>> phone, it was in the Inbox.  Most of Geert's other messages this
>>> morning
>>> went to my inbox on the laptop.  Go figure!?!  🤔
>>> 
>>> David C
>>> 
>> Yeah, I don't know what I ever did to upset Google that much they want
>>> to
>> delegate me to the spam box... I tried to say I'm sorry but they didn't
>> want
>> to hear it ;)
>> 
>> Geert
>> 
>> 
>> 
> 
 ___
 gnucash-user ma

Re: Reports very slow to open

2018-01-27 Thread R. Victor Klassen
This is quite dramatic.  Probably my favourite thing to do in code is to make 
it faster.  (Un)fortunately I don’t run Windows, so I have little to offer 
here.  The sudden and dramatic change raises the question of what changed?   
And I haven’t noticed this issue on the Mac, so I’m guessing the change was 
only on Windows.  Which in itself supports the theory that the change happened 
not within GnuCash but in one of its dependencies.  

But then, I try hard never to close GnuCash down, so I’m not sure I would have 
noticed.   

The subject line refers to reports - the sample being tested has many large 
reports open at startup, as I understand it.   But if “Loading User Data” 
precedes the start of building reports, it wouldn’t seem that’s the issue - 
unless building open reports is part of “Loading User Data”...

I’d be curious whether the startup time on an Sqlite3 file format would show 
the same pattern.


> On Jan 26, 2018, at 1:00 AM, David Carlson  
> wrote:
> 
> Here are the times to fully open my data file on my Windows 7 laptop.
> 
> 2.6.18 to open 6,480 KB compressed XML file on C: drive
> 3:14:21
> 2.6.16 to open 82,605 KB uncompressed XML file on C: drive
> 3:06:97
> 2.6.18 to open 6,480 KB compressed XML file on LAN mapped to U:  3:54:00
> 
> 2.7.3 to open 6,484 KB compressed XML file on C: drive
> 6:36:85
> 2.7.3 to open 80,747 KB uncompressed XML file on C: drive
> 6:41:29
> 2.7.3 to open 6,484 KB compressed XML file on LAN mapped to U:7:25:00
> 
> For release 2.7.3 it takes just over 4 minutes to finish 'Loading User
> Data" and start building register tabs in the main window.  Release 2.6.18
> took about 1 minute 50 seconds to finish 'Loading User Data" and start
> building register tabs in the main window.
> It looks like that part of the process is the first place to look for ways
> to speed it up.
> 
> I am not sure why the uncompressed file loaded more slowly with 2.7.3.  I
> did change the date of one transaction to make the file 'dirty' to get it
> saved in uncompressed format.
> 
> Also, I think it is known that release 2.7.3 is unable to install F::Q,
> even via the manual program link in the GnuCash program group of the
> Windows 7 start menu.
> 
> David C
> 
> On Thu, Jan 25, 2018 at 6:35 PM, John Ralls  wrote:
> 
>> David,
>> 
>> Maybe just to rule it out as an issue you could temporarily put it on a
>> local drive.
>> 
>> How big is it? It's XML, right? See if turning compression on or off makes
>> a difference.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Jan 25, 2018, at 3:15 PM, David Carlson 
>> wrote:
>>> 
>>> I failed to mention that my data file is not on my "C" drive, it is on a
>>> LAN file-server, but the entire path is via 100 MHz Ethernet, no Wi-Fi.
>>> 
>>> David C
>>> 
>>> On Thu, Jan 25, 2018 at 2:45 PM, David Carlson <
>> david.carlson@gmail.com>
>>> wrote:
>>> 
 Preliminary results comparing release 2.6.18-3 with 2.7.3 on a Dell
 Precision 7510 laptop running Windows 7 sp1 64 bit with a Intel(R)
>> Core(TM)
 i7-6820HQ CPU @2.70Ghz and 24.0 GB installed RAM and all updates
>> installed
 except a recent Dell display driver update and the Spectre patch update
>> is
 not installed yet(?):
 
 Opening a copy of my current data file with scads of tabs including
 several reports, and a read-only register tab.
 
 In 2.6.18-3 it took 3 minutes 54 seconds to complete opening the file
>> with
 no Since Last Run interruption.
 
 In 2.7.3 first touch it took 8 minutes 25 seconds to the metadata
>> migrated
 window.
 
 Second opening 7 minutes 5 seconds.  I have many more details to share
 elsewhere.
 
 David C
 
 
 On Thu, Jan 25, 2018 at 1:09 PM, Geert Janssens <
 geert.gnuc...@kobaltwit.be> wrote:
 
> Op donderdag 25 januari 2018 17:17:48 CET schreef David Carlson:
>> About not seeing Geert's message in the Gmail instance in Firefox on
>> my
>> laptop, on that machine gmail put it into spam because it did not meet
>> their lofty standards for authentication.  On the Gmail app on my
> Samsung
>> phone, it was in the Inbox.  Most of Geert's other messages this
>> morning
>> went to my inbox on the laptop.  Go figure!?!  🤔
>> 
>> David C
>> 
> Yeah, I don't know what I ever did to upset Google that much they want
>> to
> delegate me to the spam box... I tried to say I'm sorry but they didn't
> want
> to hear it ;)
> 
> Geert
> 
> 
> 
 
>>> ___
>>> gnucash-user mailing list
>>> gnucash-user@gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> -
>>> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-us

Re: yahoo as json stock quotes pounds/pence

2018-01-27 Thread ml enquirer
OK, I guess this is not a solved problem, then? I don't see this on the
GnuCash FAQ page... and I figure these 2008/2009 threads are quite likely
to be outdated.

I did the following:
- checkout financequote: "git clone
https://github.com/finance-quote/finance-quote.git
- edit lib/Finance/Quote/YahooJSON.pm to change:
<<

$info{ $stocks, "last" }   = $json_price;
>>

$info{ $stocks, "last" }   = $json_price/100.;
- edit the gnc-fq-helper script to add at the top the line:

use lib '/lib';


This isn't a great/elegant solution. I'd be very interested to hear what
more experienced people have to say!


Thanks,

Dan


On Thu, Jan 25, 2018 at 11:55 PM, ml enquirer 
wrote:

> Hi,
>
> I'm aware this is not a new question:
> - https://lists.gnucash.org/pipermail/gnucash-user/2008-
> November/027224.html
> - https://lists.gnucash.org/pipermail/gnucash-user/2008-April/024688.html
> - https://lists.gnucash.org/pipermail/gnucash-user/2009-
> February/028602.html
>
> but I recently found the "get quotes" feature stopped working with a very
> generic error message (more or less the same time as the change of currency
> quotes from yahoo to alphaVantage). So I switched my "Type of quote source"
> in the "Securities Editor" to "Yahoo as JSON" instead of "Yahoo Europe".
>
> However, now I see the returned values are in GBP *pence* not *pounds*, so
> 100 times larger than GnuCash expects.
>
> Most previous fixes discussed here (as far as I can see all >2 years old)
> involve various hacks at different levels in the source. Is this a solved
> problem, or do I need to follow their lead and dig around in the code?
>
> Thanks in advance!
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: Please remove me from the mailing list

2018-01-27 Thread Frank H. Ellenberger
Hi,

Am 26.01.2018 um 23:53 schrieb Adrien Monteleone:
> I suppose you’re referring to this:
> 
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> 
> I would think altering this to say:
> 
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>>
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>
>> To do the same if you’re using Nabble:
>> (insert link here)

To do the same if you’re using Gmane:
(insert link here)
To do the same if you’re using whoever mirrors the list else:
(insert link here)

>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> 
> 
> would do the trick.
> 
> Regards,
> Adrien
:
 I think it should be more general.

Regards
Frank
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: Please remove me from the mailing list

2018-01-27 Thread Geert Janssens
Op vrijdag 26 januari 2018 23:53:29 CET schreef Adrien Monteleone:
> I suppose you’re referring to this:
> > ___
> > gnucash-user mailing list
> > gnucash-user@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> 
> I would think altering this to say:
> > ___
> > gnucash-user mailing list
> > gnucash-user@gnucash.org
> > 
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > 
> > To do the same if you’re using Nabble:
> > (insert link here)
> > -
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> 
> would do the trick.
> 
> Regards,
> Adrien
> 
I would prefer that the bit about nabble in addition would politely but 
clearly state the nabble interface to the lists is not managed by the gnucash 
project and that the user should contact nabble support for further help.

I just don't know how to express that in nice English with fewer words to keep 
the added footer more compact.

Geert


___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.