[GNC-dev] pricedb policy
jralls at ceridwen.us
Sun May 13 22:59:19 EDT 2018
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.
> On May 13, 2018, at 6:19 PM, Christopher Lam <christopher.lck at gmail.com> 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&Repair 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 at 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
>> 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.monteleone at lusfiber.net> wrote:
>>> 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&Repair?
>>>> On May 13, 2018, at 5:34 AM, Christopher Lam <christopher.lck at gmail.com>
>>>> Hi Devs
>>>> I wish to enquire about policy on pricedb.
>>>> As far as I can understand, pricedb receives entries from 3 different
>>>> 1. from entering transactions into the register, if the transaction
>>>> involves a foreign currency conversion or stock. e.g. originating
>>>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
>>>> 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
>>>> 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
>>>> My concerns relate to (1) above. I believe these transactional prices
>>>> 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
>>>> same day, the second entered price will overwrite the first. (<-
>>>> to my last test)
>>>> I'd think it would be important for accuracy that, upon book opening,
>>>> Check&Repair, the user:price data should be *overwritten* by the actual
>>>> prices obtained from the transactions. Moreover if there are several
>>>> transactions involving commodities, Check&Repair should **add** relevant
>>>> amounts to ensure accurate pricing.
>>>> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
>>>> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
>>>> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
>>>> Unfortunately I don't do C so cannot help with coding, but would think
>>>> the "user:price" prices should *always* be regenerated from the
>>>> amounts during Check & Repair and upon loading datafile.*
>>>> gnucash-devel mailing list
>>>> gnucash-devel at gnucash.org
>>> gnucash-devel mailing list
>>> gnucash-devel at gnucash.org
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel