[GNC-dev] pricedb policy

[Christopher Lam]

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 GBP/USD=1.6, it would mean that the USD expense or 
account would not have received $150USD in the first place, causing all 
sorts of USD imbalances or incomplete funds for purchase.

My view is that "user:price"-type pricedb entries are usually directly 
generated from transactional transfers, therefore can be considered a 
lookup-table for existing transfers, and should not be user-editable.


On 13/05/18 22:20, Adrien Monteleone 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&Repair?
>
> Regards,
> Adrien
>
>> On May 13, 2018, at 5:34 AM, Christopher Lam <christopher.lck at 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
>> same day, the second entered price will overwrite the first. (<- according
>> to my last test)
>>
>> I'd think it would be important for accuracy that, upon book opening, and
>> 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.
>>
>> e.g.
>> 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 that*
>> the "user:price" prices should *always* be regenerated from the transaction
>> amounts during Check & Repair and upon loading datafile.*
>>
>> Thoughts?
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel