> On Jul 18, 2023, at 10:12 AM, Bruce Schuck <bsch...@asgard-systems.com> wrote:
>
> On 7/17/23 9:06 PM, john wrote:
>
>> Well, a user wouldn't want to set GBX as their default currency,
>> just to create an account in their tree denominated in it to be a
>> parent for stock accounts that are priced in GBX. But you're right
>> that it's not something that a user can do now because GBX isn't an
>> ISO4217 currency and that's historically how we decide what's a
>> currency. Implementing it would require making an exception to that
>> policy and adding an entry to our currency file.
>
> Probably why AlphaVantage and YahooJSON convert GBX quotes to GBP. I
> started to get involved with Finance::Quote after AV was added because a
> Google finance API was discontinued.
>
>> To be pure it would also require F::Q to leave the GBX->GBP conversion to
>> the client program, because while it's reasonable to expect a user who owns
>> GBP.L shares to know that they trade in GBX it's not reasonable to expect
>> them to know that it's one of the exceptions that doesn't get adjusted
>> automatically when getting the price from AlphaVantage, but *does* get
>> adjusted automatically when retrieved from Yahoo!.
>
> YahooJSON and now YahooWeb are already doing the GBX->GBP conversion
> (not my doing). Easy because both of those sources have the pricing
> currency in the data returned. I hope you are not suggesting that the
> conversion is removed from both of those modules?
I'm not. I'm pointing out the disadvantages of handling the pricing issue on
the client side.
>
> There-in lies why I figure the additional lookup to get the correct
> currency is needed. So the user doesn't need to worry about what modules
> may or may not be doing GBX->GBP or ZAc->ZAR conversion. Consistent with
> two Yahoo modules, AV would return the ISO currency. At least that was
> my thinking.
Roger, but slowing AV down to 5 quotes/2 minutes will make it pretty useless
for anyone with even a small number of LSE stocks. Users already gripe about
the 5/sec throttling.
>
>> And repeating myself for emphasis, that's how GnuCash could handle it
>> but I have no idea if it's reasonable for other programs. From that
>> standpoint the extra suffix is more straightforward: Just add it and
>> F::Q will unconditionally multiply the price by 100. That will work
>> for any client and is pretty easy to explain to users.
> To clarify, are you suggesting have AlphaVantage check for the additional
> (let's say ".X") suffix? Or any quote source? Much easier to accomplish on a
> per module basis, than F::Q in general. But as stated, that means the user
> needs to know to use GBP.L.X (Global Petroleum) for AV to return GBP, but
> YahooJSON does not need the extra ".X". Then again, that's what man pages are
> for... ;)
Yes, I think that's the best alternative to asking AV for the currency. Another
that we haven't discussed would be caching the results somewhere, but that
conflicts with F::Q's stateless design.
>
> Definitely validates what I tried to explain in the F::Q issue, where the
> solution is *not* just a simple "remove the adjustment".
>
> I may just shelve this for a while longer. Thanks for the discussion and
> insight.
Regards,
John Ralls
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
