Re: [GNC-dev] pricedb policy

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

Re: [GNC-dev] pricedb policy

Here you go, a prices-report.scm which can be dropped into standard-reports folder and adds a rudimentary forex analysis. If rebuilding you'll need to add onto CMakeLists.txt as well. It scans *only* transactions which involve 2 different commodities. eg GBP<->EUR or AAPL<->USD. It calculates

Re: [GNC-dev] pricedb policy

He he, just to make things a bit more complicated and realistic: > Sent: Sunday, May 13, 2018 at 6:42 PM > From: "John Ralls" <jra...@ceridwen.us> > To: "Adrien Monteleone" <adrien.montele...@lusfiber.net> > Cc: gnucash-devel@gnucash.org > Subject:

Re: [GNC-dev] pricedb policy

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

Re: [GNC-dev] pricedb policy

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

Re: [GNC-dev] pricedb policy

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

Re: [GNC-dev] pricedb policy

;> publishes the official exchange rates for the tax year and I would really >> need to be able to use that rate for all my tax reports, irrespective of >> what the other entered prices may be. >> >>> Sent: Sunday, May 13, 2018 at 12:34 PM >>> From: "C

Re: [GNC-dev] pricedb policy

There are two use cases that will be more common. One is the general end-of-period valuation that is usually driven by publicly reported prices. The other would be a book value which could be a cost basis. That might be driven by transactions or average costs. There needs to be a way for

Re: [GNC-dev] pricedb policy

Sunday, May 13, 2018 at 12:34 PM >> From: "Christopher Lam" <christopher@gmail.com> >> To: gnucash-devel@gnucash.org >> Subject: [GNC-dev] pricedb policy >> >> My concerns relate to (1) above. I believe these transactional prices are >> always more

Re: [GNC-dev] pricedb policy

On the contrary, there is such a thing. Certainly, in near real-time, as you describe, no there isn’t. But when booking an existing asset at current market prices when starting a book, there is. There might be various reasons for this approach, not the least of which is that the original

Re: [GNC-dev] pricedb policy

> On May 13, 2018, at 3:34 AM, Christopher Lam > 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

Re: [GNC-dev] pricedb policy

stopher Lam" <christopher@gmail.com> > To: gnucash-devel@gnucash.org > Subject: [GNC-dev] pricedb policy > > My concerns relate to (1) above. I believe these transactional prices are > always more accurate than online quotes, because they describe the exact > p

Re: [GNC-dev] pricedb policy

I'm sorry there's no complication. There's no such thing as "price source was not correct" while entering a transaction. Let's say I transfer 100 GBP to 150 USD, currently generating a pricedb entry of GBP/USD=1.5, later "realize" the price source was incorrect and should have been

Re: [GNC-dev] pricedb policy

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