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
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
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:
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
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
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).
Just get local currency at a bank or from a bank’s (preferably indoor)
ATM--don’t forget to check it for a skimmer, even if it is in the bank’s lobby.
Make a “cash in wallet” account in the local currency. That will get you better
rates and only a few exchange transactions.
Regards,
John Ralls
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
I didn’t think of that one. Pondering that accounting nightmare makes me glad I
wasn’t concerned with accounting last time I was out of country and shopping in
just such a fashion. Most of the time even receipts weren’t available. I
probably paid a different exchange rate at each vendor. (It’s
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
> 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
I'll add a simple case that maybe does not happen often in real accounting but
happens to me all the time.
When traveling and exchanging cash at various small shops, the exchange rate
varies wildly. This, however, should not have the precedence compared to the
official central bank's rate.
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
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
14 matches
Mail list logo