Re: [GNC-dev] pricedb policy

[Christopher Lam]

Thanks John... For some reason Gmail had classified all direct emails as
spam so I've effectively missed a lot of similar official replies 

On Mon, 14 May 2018, 11:01 John Ralls  wrote:

> The hierarchy is user:price/user:xfer-dialog<-F::Q<-user:price-editor for
> the reason I explained.
>
> One more time: No, the user:price entries in the pricedb should ***NOT***
> be considered a lookup table to the actual prices in transactions. If you
> want the actual prices in transactions (actually splits, transactions don’t
> have any amounts or values) then *go look at the splits*. If for some
> reason you need to cache the prices then cache the prices. Don’t overload
> the pricedb for a purpose for which it’s not designed.
>
> Regards,
> John Ralls
>
>
> > On May 13, 2018, at 6:19 PM, Christopher Lam 
> wrote:
> >
> > Thank you.
> >
> > Hence my RFC about whether "user:price" entries in pricedb should be
> > considered as a lookup-table to the actual prices achieved in
> transactions,
> > and should be subject to Check fixing. I'm sure the reports will
> > then fix themselves if they can rely on pricedb being accurate.
> >
> > IMHO if a transaction had documented an incorrect asset price, the
> > values/amounts should be amended. If I'd overvalued my house in
> > Equity:Opening Balances, I'd just go and amend the amounts.
> >
> > Perhaps I'll whip out a .scm to look at the prices and (optionally) offer
> > to fix any discrepancies.
> >
> > In future perhaps reports can offer use pricedb entries in a customizable
> > hierarchy - Finance::Quote prices, user:price, user:price-editor.
> >
> > On 14 May 2018 at 00:56, David T. via gnucash-devel <
> > gnucash-devel@gnucash.org> wrote:
> >
> >> The ONLY way to change the value in a transaction is to change it in the
> >> transaction itself—either by changing the number of shares, the actual
> >> price per share, or the total amount in the transaction (and note that
> the
> >> UI will ask you about this if you change one without changing the
> others).
> >> The price db doesn’t and shouldn’t push changes into existing real
> >> transactions.
> >>
> >> Changing the valuation in a transaction based on a price db change is
> the
> >> path to madness.
> >>
> >> The price db is for reporting on potential valuation. The transactions
> >> represent what actually happened. If I paid $100 for 10 shares of ABC
> >> stock, it doesn’t matter that the going price for ABC on the same day
> is $1
> >> per share—I’m still out $100 (and pretty gullible, too, I’d say).
> >>
> >> David T.
> >>
> >>
> >>> On May 13, 2018, at 7:20 PM, Adrien Monteleone <
> >> adrien.montele...@lusfiber.net> wrote:
> >>>
> >>> Christopher,
> >>>
> >>> I’ll add a complication for you.
> >>>
> >>> Suppose one enters a transaction and later realizes the price source
> was
> >> not correct.
> >>>
> >>> Does editing the originally generated user:price affect the
> transactions
> >> in the register? Are they in-sync or now unrelated?
> >>>
> >>> If editing user:price does not change the register, does that mean you
> >> have to edit the register entries (or use correcting entries) and if so,
> >> does this alter the original user:price? (or add another?)
> >>>
> >>> If the two get out of sync, how do you determine what is the true
> source
> >> to use to regenerate upon loading and Check?
> >>>
> >>> Regards,
> >>> Adrien
> >>>
>  On May 13, 2018, at 5:34 AM, Christopher Lam <
> christopher@gmail.com>
> >> wrote:
> 
>  Hi Devs
> 
>  I wish to enquire about policy on pricedb.
> 
>  As far as I can understand, pricedb receives entries from 3 different
>  sources:
> 
>  1. from entering transactions into the register, if the transaction
>  involves a foreign currency conversion or stock. e.g. originating
> >> account
>  is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
> >> (can't
>  determine which one is deemed to be the base currency). These pricedb
>  entries are tagged "user:price" or "user:xfer-dialog".
> 
>  2. from online sources eg alphavantage. This requires careful setup,
> and
>  seems to create price entries for all foreign currencies /
> commodities,
>  compared to the book currency (in my case AUD). These are tagged
>  "Finance::Quote".
> 
>  3. entries added by the user. These are tagged "user:price-editor".
> 
>  From my review of code so far, pricedb entries are rather important in
>  reports... an incorrect pricedb entry will lead to incorrect foreign
>  currency reporting, even if the transaction contains the exact
> transfer
>  amount.
> 
>  My concerns relate to (1) above. I believe these transactional prices
> >> are
>  always more accurate than online quotes, because they describe the
> exact
>  prices achieved.
> 
>  But it's buggy, e.g. if there are 2 transactions involving GBP/USD on
> >> the
> 

Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[John Ralls]

> On May 27, 2018, at 12:50 PM, Christian Stimming  
> wrote:
> 
> Dear John,
> 
> I did notice that the 2.6 branch was deleted (meaning: "maint" is now the 3.x 
> branch), but I didn't understand the reasons and didn't see any discussion of 
> this decision. I have some requirements which I can meet most easily by just 
> continuing the 2.6 version of gnucash, but this in turn needed some 
> occasional 
> commits there. For example, I'm still running Ubuntu 14.04 for reasons beyond 
> the scope of gnucash, and I haven't been able to build the 3.x branch on that 
> machine because of missing packages. At the same time the 2.6 branch met all 
> that I needed for everyday work, so I just stick to this.
> 
> Hence, I don't quite understand why there is such a strong requirement to 
> prohibit specifically any further existence of a 2.6 branch, and why you use 
> strong language to underline your point of view here. Also, it's a bit 
> puzzeling to me why you suggest me of all people to "change the name and 
> artwork" in case of a 2.6 branch - what have I missed here?? Where was the 
> discussion that led to this decision? Where was the decision process, if this 
> were the project's decision? Maybe some more liberality for other people and 
> their different requirements might be more suitable on your side, before 
> calling other people's requirements a "fantasy".
> 
> This particular pull request for the 2.6 branch showed up only one week after 
> I created that branch. To me, this looks like there are still more people 
> interested in such a branch. Of course, nothing new will happen there, but 
> the 
> interest still exists.
> 
> For this reason I propose to keep some old 2.6 branch still up and running in 
> the gnucash repository. I would volunteer to act as an owner of that branch, 
> in case this is needed, but on the other hand we didn't need any such 
> designated branch maintainers for the most part. Further voices? objections? 
> ideas? Thanks.
> 

Christian,

Sorry that I wasn't clear.

Geert and I decided after an IRC discussion that the simplest way to switch 
unstable to maint was to simply merge unstable onto maint and to remove the 
unstable branch, which is what we did. The 2.6.x releases are all tagged. Git 
isn't SVN, there's no need for a 2.6  branch to record what was in each 
release. The only reason for a separate branch is to develop a fork.

As you should be aware, we're very short of developer resources. We very simply 
cannot maintain two stable branches and still have time to also develop for the 
next major release. That's even more true now than it was 4 years ago after we 
stopped development on 2.4 because you and Phil Longstaff were regularly 
working on GnuCash then; both of you have left and no one has come forward at 
the same level of effort. 

As far as I can tell there have never been two stable branches maintained in 
parallel, so the question about a policy decision falls on you, not me. Where 
was the discussion to revive and maintain the 2.6.x branch after the release of 
3.0? I know the answer: There wasn't one. You *unilaterally* decided to impose 
your personal requirements on the rest of the team by creating a branch and 
implying on a bug report [1] that it was possible that we'd have future 
releases. Sorry, that's a fantasy. We don't have the resources. Your branch 
already caused someone to waste their time making a PR [2] in the mistaken 
belief that they were contributing to the project. 

You're of course free to have a 2.6 branch in your own repository and to 
continue that development if that's what you need. 

You can of course also distribute that work to the rest of the world, but 
there's a very practical problem with doing so if you call it GnuCash: You'd be 
delegating the support of your fork to the devs who are still working on 
GnuCash 3.x and towards GnuCash 4.x and they (we) don't have the resources to 
do that. The simple and obvious way to avoid that confusion would be for you to 
distribute your fork under a new name with its own "trade dress" and support 
mechanisms, hence my request.

As for building 3.x on Ubuntu 14.04, we run CI on Ubuntu 14.04 [3]. All of the 
needed packages are available except Googletest, for which you need only clone 
the source from GitHub and tell CMake where it is. You can use [3] as a setup 
script to quickly get a suitable build environment. If you need more help by 
all means ask.

Regards,
John Ralls



[1] https://bugzilla.gnome.org/show_bug.cgi?id=765846
[2] https://github.com/Gnucash/gnucash/pull/354
[3] https://github.com/Gnucash/gnucash/blob/maint/util/ci/ubuntu-14.04-docker
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[Christian Stimming]

Dear John,

I did notice that the 2.6 branch was deleted (meaning: "maint" is now the 3.x 
branch), but I didn't understand the reasons and didn't see any discussion of 
this decision. I have some requirements which I can meet most easily by just 
continuing the 2.6 version of gnucash, but this in turn needed some occasional 
commits there. For example, I'm still running Ubuntu 14.04 for reasons beyond 
the scope of gnucash, and I haven't been able to build the 3.x branch on that 
machine because of missing packages. At the same time the 2.6 branch met all 
that I needed for everyday work, so I just stick to this.

Hence, I don't quite understand why there is such a strong requirement to 
prohibit specifically any further existence of a 2.6 branch, and why you use 
strong language to underline your point of view here. Also, it's a bit 
puzzeling to me why you suggest me of all people to "change the name and 
artwork" in case of a 2.6 branch - what have I missed here?? Where was the 
discussion that led to this decision? Where was the decision process, if this 
were the project's decision? Maybe some more liberality for other people and 
their different requirements might be more suitable on your side, before 
calling other people's requirements a "fantasy".

This particular pull request for the 2.6 branch showed up only one week after 
I created that branch. To me, this looks like there are still more people 
interested in such a branch. Of course, nothing new will happen there, but the 
interest still exists.

For this reason I propose to keep some old 2.6 branch still up and running in 
the gnucash repository. I would volunteer to act as an owner of that branch, 
in case this is needed, but on the other hand we didn't need any such 
designated branch maintainers for the most part. Further voices? objections? 
ideas? Thanks.

Regards,

Christian


Am Samstag, 26. Mai 2018, 10:50:32 schrieb John Ralls:
> Christian,
> 
> Your "branch-2.6" drew its first PR today, so I've deleted it to avoid any
> further confusion. Please consult with the rest of the team before you do
> anything like that again. If you'd like to maintain a 2.6 branch yourself
> you are of course free to fork GnuCash, though you should change the name
> and artwork to avoid confusion with the main project.
> 
> Regards,
> John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Possible bug in Tax Schedule Report?

[Clint Redwood]

Hi,

I’ve been doing my taxes and have found a potential issue with the report. When 
calculating the transactions on an asset account, it appears to take the 
opening balance as at the opening of Report-Start-Date minus 1 day, and then 
process all the transactions during the reporting period, thus giving the final 
balance on the closing date. 

However, if there are any transactions on RSD-1, these are ignored, so the 
opening balance is prior to these transactions (which is what I think is wrong) 
and then the correct transactions are processed, and you are left with the 
ending balance being out by the value of the RSD-1 transactions.

So if you have transactions in an account:

DateDescValue   Balance
31/08/2016  Pay Someone 10009000
01/09/2016  Pay Someone Else500 8500
31/08/2017  Pay Another Person  300 8200

and run the report for 01/09/2016 to 31/08/2017, the result is:

opening balance (31/08/2016) 1
Pay Someone Else 500
Pay Another Person 300
closing balance (31/08/2017) 9200

whereas it should open at 9000 and close at 8200.

I’m using GnuCash 2.6.19 on MacOS (This copy was built from rev c1b5e6c8d+ on 
2017-12-17.) 

Is this a bug, or am I using the report wrongly? 

Thanks!

Yours,

Clint Redwood 

Screwtape Limited, Registered 06663232, Babington House, 26 College Road, 
Chilwell, Nottingham NG9 4AS

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel