Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-22 Thread Kaligula

Please, calm down, Bruce :) That was just an idea.

If I knew Perl as much as I know JavaScript I'd submit a PR yesterday. 
(I know, I made a few modules for private use, they're on my GitHub – 
but it involved much much much more learning than actual writing, and it 
was long ago).


Nevermind. Have a nice day :)

Best regards,
Kaligula

W dniu 22.07.2023 o 19:53, Bruce Schuck pisze:

On 07/21/2023 at 18:34 EDT Kaligula wrote:

In general the suffix idea looks like a nice workaround – but I'd 
like to throw in my two cents.


So maybe a general solution in case of AV module pricing errors – a 
".???" suffix (to any ticker, not only LSE ones) where the "???" is 
the currency that the security is traded in? (Or even better with a 
":???" suffix, to avoid confusion with stock exchange suffixes). This

would allow the user to inform the AV module about changes in
default currency – e.g. "GBP.L:GPX" or "MVOL.L:USD".

Kaligula,

Please don't disturb the horse. It's well beyond deceased and we're 
not trying to make glue. At least I am not. I've made my decision on 
how it's going to be handled. I'm not going to waste any more time 
beyond writing this email on this issue.


My original question in this thread was asking how many of the users 
(at least GnuCash users on the email list) used AlphaVantage for 
non-US traded securities. *No one* responded answering that question, 
but John and I had a decent little discussion of the matter.


For a real solution, I would urge anybody using AlphaVantage for quote 
data to contact AV's support and request that the trade currency be 
added to the JSON returned from the GLOBAL_QUOTE API.


As always, F::Q is community supported software. So anyone is welcome 
to submit a pull request.


Bruce S

P.S. Likely any further responses with suggestions or ideas related to 
this issue will be ignored. Please let the Equus ferus caballus rest 
in peace.

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


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-21 Thread Kaligula

Hi,

(Sorry being late here, I'm not watching gnucash-user mailing list).

In general the suffix idea looks like a nice workaround – but I'd like 
to throw in my two cents.


1) There are securities like these ETFs: MVOL.L or ISLN.L – they are 
traded in USD.


2) If the suffix idea get implemented, wouldn't it be better to set the 
suffix to ".GBX" or ".GBp"? (or any?) It would give the idea of what it 
is for.


So maybe a general solution in case of AV module pricing errors – a 
".???" suffix (to any ticker, not only LSE ones) where the "???" is the 
currency that the security is traded in? (Or even better with a ":???" 
suffix, to avoid confusion with stock exchange suffixes). This would 
allow the user to inform the AV module about changes in default currency 
– e.g. "GBP.L:GPX" or "MVOL.L:USD".


Best regards,
Kaligula

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


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-19 Thread Bruce Schuck

On 7/18/23 10:34 AM, John Ralls wrote:


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.


Okay. I think it would be reasonable assumption that Finance::Quote
returns pricing in ISO-4217 currencies. But definitely a quagmire when
faced with an issue like this one.


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.


Which is why I posed the original question. Aside from the two of us
having this wonderful exchange of ideas, no one else stepped in to say
"Hey! I get some LSE traded stock data from AlphaVantage, and doubling
the time it takes to get quotes would annoy the heck out of me!". At
this point, the only one to raise an issue is someone that could deal
with it as is for all I care.



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.


Alright. At some point I'll have AlphaVantage look for symbols supplied 
with an additional '.X' suffix. If it's given, divide the pricing info 
by 100. If not, leave it be. Of course I'll add info on this to the 
manpage/POD. I'll also ping AV support again. I was told they would look 
into adding the currency to the JSON returned from the GLOBAL_QUOTE API 
which would make my job a zillion times easier.


Thanks again John.

Bruce S.
___
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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-18 Thread John Ralls



> On Jul 18, 2023, at 10:12 AM, Bruce Schuck  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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-18 Thread Bruce Schuck

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?

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.


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


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.


Bruce S.
___
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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-17 Thread john
Bruce forgot to copy the list on this and couldn't find it to resend, and then 
so did I on the reply!

> On Jul 17, 2023, at 18:57, Bruce Schuck  wrote:
> On 7/17/23 5:28 PM, John Ralls wrote:
> 
>> Sorry, I can't provide any examples of JSE or TASE stocks, I was
>> going completely off of looking at the code in the three modules.
> 
> No big deal. I did some searching, and I don't think AlphaVantage has data 
> for securities traded on the Johannesburg Stock Exchange. If someone else 
> reading this can supply an example, please post it.
> 
>> Yes, both of my suggestions transfer the responsibility for knowing
>> what currency a stock is traded in to the user. In GnuCash's case
>> that responsibility is already there. GnuCash doesn't use the
>> currency returned from F::Q, it assumes that the price is denominated
>> in the currency of the nearest parent account denominated in a
>> currency. We don't get that many users who miss that detail and it's
>> pretty easy for them to fix their books. I don't know about other
>> programs using F::Q.
> 
> Now here's where I am cloudy. Since GBX is *not* a standard ISO 4217 currency 
> code, a user cannot choose GBX as their default currency, or am I missing 
> something? Currently, without the AlphaVantage module modifying prices for 
> securities such as GBP.L, GnuCash would assume the price is GBP, and it would 
> be wrong. GnuCash would assume the price is 0.18 GBP, when it's 0.18 GBX or 
> 0.0018 GBP.
> 
> Which is likely why Erik added the "fix" back in 2017. Since all (or most?) 
> the LSE traded stocks have the ".L" suffix in AV, they all get mapped to GBP. 
> Erik may have tested with a GBp priced security and make the adjusting logic 
> match ".GBP" or ".GBX". Likely he also didn't realize that the suffix ".GBX" 
> was impossible, since it's not in the currency map in the module.
> 
> With this in mind, I think the currency check and extra API call needs to be 
> done so securities traded in GBX get adjusted to GBP and GBP priced 
> securities are left alone. To me, that's the simplest fix although for users 
> with a good amount of LSE traded securities, it will slow down the AV 
> throttling.

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.

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

I guess since YohooWeb *does* report the currency that simply documenting that 
it's a problem is an alternative, and users can be directed to use that instead 
when they have pricing problems.

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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-17 Thread John Ralls



> On Jul 17, 2023, at 11:11 AM, Bruce Schuck  wrote:
> 
> On 7/17/23 10:02 AM, john wrote:
> 
>> It's not all non-US securities. In AlphaVantage it appears to be only
>> LSE stocks; JSE stocks aren't supported and Tel Aviv stocks support
>> only ILS. The Yahoo JSON module adjusts prices for Zac (South Africa)
>> and ILA (Israel) as well as GBX, but Yahoo JSON apparently includes a
>> currency code to make that easy. That seems to be missing from
>> YahooWeb, perhaps an oversight on Vincent's part. The currency is
>> available on https://finance.yahoo.com/quote/GBP.L 
>>  prefixed by "Currency In" in
>> div id="quote-header-info".
> 
> The currency is being captured by YahooWeb. For GBP.L (traded in GBp/GBX) has 
> its price converted to GBP and currency reported as such. At the time of this 
> writing, GBP.L was 0.1850 GBp, F::Q v1.57 yahooweb returns 0.00185 GBP.
> 
> % gnc-fq-dump -v yahooweb GBP.L
> 
> stock   field  value
> -   -  -
> GBP.Lcurrency: GBP
> GBP.Ldate: 07/17/2023
> GBP.Lexchange: LSE - LSE Delayed Price
> GBP.L isodate: 2023-07-17
> GBP.Llast: 0.00185
> GBP.L  method: yahooweb
> GBP.Lname: Global Petroleum Limited
> GBP.L success: 1
> GBP.L  symbol: GBP.L
> 
> > So for AlphaVantage it seems only .L and .IL suffix securities would
> > need to be queried, and maybe only .L unless there are known
> > instances where .IL-suffixed symbols are priced in GBP.
> 
> I will change the AlphaVantage.pm fix I'm working on to only execute the 
> extra API call for securities ending with '.L'.
> 
>> Rather than spending an extra query maybe AlphaVantage.pm could
>> accept a special extra suffix indicating that the user wants quotes
>> to be multiplied by 100, perhaps X, so a request for GBP.L priced in
>> GBP would be GBP.L.X.
> 
> If I understand, this method assumes the user knows that the data from AV for 
> GBP.L is priced in GBp/GBX. Correct?
> 
>> Alternatively we could create a GBX, ZAX, and ILA pseudo-currencies
>> in GnuCash and users would create parent accounts in those currencies
>> for stocks quoted that way. That would take a little finessing on
>> users' part because using it would depend both on the currency the
>> stock is quoted in and whether F::Q converts it to the "real"
>> currency.
> 
> F::Q currently sets currency based on suffix. '.L' gets mapped to 'GBP'. I 
> just checked, currently no map in AV for ZAR. By chance, you don't have an 
> example for me? Thanks. Like the previous comment, this also expects users to 
> know what currencies the different securities are reports as coming from the 
> AV module, correct? While I like the idea on a high level, I think that is 
> asking for trouble reports from users having pricing issues.
> 

Bruce,

Sorry, I can't provide any examples of JSE or TASE stocks, I was going 
completely off of looking at the code in the three modules.

Yes, both of my suggestions transfer the responsibility for knowing what 
currency a stock is traded in to the user. In GnuCash's case that 
responsibility is already there. GnuCash doesn't use the currency returned from 
F::Q, it assumes that the price is denominated in the currency of the nearest 
parent account denominated in a currency. We don't get that many users who miss 
that detail and it's pretty easy for them to fix their books. I don't know 
about other programs using F::Q.

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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-17 Thread Bruce Schuck

On 7/17/23 10:02 AM, john wrote:


It's not all non-US securities. In AlphaVantage it appears to be only
 LSE stocks; JSE stocks aren't supported and Tel Aviv stocks support
only ILS. The Yahoo JSON module adjusts prices for Zac (South Africa)
and ILA (Israel) as well as GBX, but Yahoo JSON apparently includes a
currency code to make that easy. That seems to be missing from
YahooWeb, perhaps an oversight on Vincent's part. The currency is
available on https://finance.yahoo.com/quote/GBP.L 
 prefixed by "Currency In" in

div id="quote-header-info".


The currency is being captured by YahooWeb. For GBP.L (traded in 
GBp/GBX) has its price converted to GBP and currency reported as such. 
At the time of this writing, GBP.L was 0.1850 GBp, F::Q v1.57 yahooweb 
returns 0.00185 GBP.


% gnc-fq-dump -v yahooweb GBP.L

stock   field  value
-   -  -
GBP.Lcurrency: GBP
GBP.Ldate: 07/17/2023
GBP.Lexchange: LSE - LSE Delayed Price
GBP.L isodate: 2023-07-17
GBP.Llast: 0.00185
GBP.L  method: yahooweb
GBP.Lname: Global Petroleum Limited
GBP.L success: 1
GBP.L  symbol: GBP.L

> So for AlphaVantage it seems only .L and .IL suffix securities would
> need to be queried, and maybe only .L unless there are known
> instances where .IL-suffixed symbols are priced in GBP.

I will change the AlphaVantage.pm fix I'm working on to only execute the 
extra API call for securities ending with '.L'.



Rather than spending an extra query maybe AlphaVantage.pm could
accept a special extra suffix indicating that the user wants quotes
to be multiplied by 100, perhaps X, so a request for GBP.L priced in
GBP would be GBP.L.X.


If I understand, this method assumes the user knows that the data from 
AV for GBP.L is priced in GBp/GBX. Correct?



Alternatively we could create a GBX, ZAX, and ILA pseudo-currencies
in GnuCash and users would create parent accounts in those currencies
for stocks quoted that way. That would take a little finessing on
users' part because using it would depend both on the currency the
stock is quoted in and whether F::Q converts it to the "real"
currency.


F::Q currently sets currency based on suffix. '.L' gets mapped to 'GBP'. 
I just checked, currently no map in AV for ZAR. By chance, you don't 
have an example for me? Thanks. Like the previous comment, this also 
expects users to know what currencies the different securities are 
reports as coming from the AV module, correct? While I like the idea on 
a high level, I think that is asking for trouble reports from users 
having pricing issues.


Thanks again.

Bruce S.
___
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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-17 Thread john
> On Jul 16, 2023, at 15:52, Bruce Schuck  wrote:
> 
> Hello again,
> 
> At some point I am going to take a break from F::Q, I thought this weekend I 
> was going to escape.
> 
> ### For the question, skip to the next ###
> 
> Anyway, some time ago the issue was raised about prices from AlphaVantage for 
> LSE traded stocks (see 
> https://github.com/finance-quote/finance-quote/issues/281). While there is an 
> issue, the user's perceived solution was not the answer. Apparently my 
> attempt to explain that the root cause was that the data returned from the AV 
> "GLOBAL_QUOTE" API did *NOT* contain the currency used for the pricing 
> returned.
> 
> What the AV module does is assign a currency based on the suffix of the 
> lookup symbol. So stocks like GBP.L and GBPG.L get mapped to GBP. The problem 
> is that GBP.L (Global Petroleum Limited) is traded in GBX (aka GBp) and 
> GBPG.L (Goldman Sachs Access UK Gilts 1-10) is traded in GBP. But the AV 
> module as written cannot differentiate since the currency used is not part of 
> the data. Stocks from South Africa have a similar issue.
> 
> Needless to say, since I was not ready to dig into the root cause and not 
> wanting to remove the fix that was meant to convert GBp pricing to GBP 
> pricing based solely on the symbol's suffix, the user decided to go on a rant 
> and throw a tantrum in the comments and had to be blocked from the 
> Finance::Quote repository.
> 
> ### Question here ###
> 
> The currency for the trades can be gotten from AV, but an additional call 
> using the "SYMBOL_SEARCH" API is necessary. Obviously this would impact the 
> throttling limitation of AlphaVantage. For non-US stocks, this means that 
> including an additional currency lookup an average of 2.5 securities can be 
> fetched per minute. I am curious how many of you all use AV for non-US traded 
> securities? Has the pricing discrepancy affect you, and would you want it 
> corrected even though that means increasing retrieval time due to the extra 
> API usage?

It's not all non-US securities. In AlphaVantage it appears to be only LSE 
stocks; JSE stocks aren't supported and Tel Aviv stocks support only ILS. The 
Yahoo JSON module adjusts prices for Zac (South Africa) and ILA (Israel) as 
well as GBX, but Yahoo JSON apparently includes a currency code to make that 
easy. That seems to be missing from YahooWeb, perhaps an oversight on Vincent's 
part. The currency is available on https://finance.yahoo.com/quote/GBP.L 
prefixed by "Currency In" in div id="quote-header-info <>".

So for AlphaVantage it seems only .L and .IL suffix securities would need to be 
queried, and maybe only .L unless there are known instances where .IL-suffixed 
symbols are priced in GBP.

Rather than spending an extra query maybe AlphaVantage.pm could accept a 
special extra suffix indicating that the user wants quotes to be multiplied by 
100, perhaps X, so a request for GBP.L priced in GBP would be GBP.L.X.

Alternatively we could create a GBX, ZAX, and ILA pseudo-currencies in GnuCash 
and users would create parent accounts in those currencies for stocks quoted 
that way. That would take a little finessing on users' part because using it 
would depend both on the currency the stock is quoted in and whether F::Q 
converts it to the "real" currency.

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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-17 Thread Bruce Schuck

On 7/17/23 03:48 PDT AM, Brad Morrison wrote:


Does it also make sense to post this situation & question to the
other 6 GnuCash Mailman 2 mailing lists that are not in English? 
https://wiki.gnucash.org/wiki/Mailing_Lists  & 
https://lists.gnucash.org/mailman/listinfo


If someone cares to translate and cross-post, be my guest. I would think 
that those GnuCash users who can understand English may be subscribed to 
gnucash-user in addition to the gnucash-?? list of their native language.



2.5 securities per minute seems really slow!


Not a limitation of the module, a limitation of the AlphaVantage API for 
those using their free API key.


"We are pleased to provide free stock API service covering the majority 
of our datasets for up to 5 API requests per minute and 500 requests per 
day. If you would like to target a larger API call volume, please visit 
premium membership."


The currency is *not* supplied in the JSON returned when fetching the 
price data. So for securities such as GBP.L (GBX/GBp) or GBPG.L (GBP), a 
second API call is required to determine the currency. Otherwise that 
module maps '.L' to GBP which would be incorrect for GBP.L. So, for 
non-US stocks, 2 API calls are needed for one security.


Thanks.

Bruce S.
___
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.


Re: [GNC] Finance::Quote - AlphaVantage Trade Currencies

2023-07-17 Thread Brad Morrison

Hi Bruce/all,

Thank you for all your hard work with F::Q!

Does it also make sense to post this situation & question to the other 6 
GnuCash Mailman 2 mailing lists that are not in English? 
https://wiki.gnucash.org/wiki/Mailing_Lists & 
https://lists.gnucash.org/mailman/listinfo


I have never used F::Q in GnuCash (or at all), so maybe my point is 
useless or maybe you already are signed up for those other language 
lists. I was just thinking that there may be many more users of AV for 
non-US traded securities on the other language lists than English - ?


In my work for a tax & wealth management firm (on the tax side), I most 
frequently interact with non-US traded stocks when an IRS form 1099DIV 
(https://www.irs.gov/forms-pubs/about-form-1099-div) or 1099B 
(https://www.irs.gov/forms-pubs/about-form-1099-b) indicates that 
foreign taxes were paid and my role is account for those foreign taxes 
paid & to determine whether an IRS form 1116 
(https://www.irs.gov/forms-pubs/about-form-1116) is needed.


While I am mentioning the GnuCash mailing lists, does anyone know if 
there are plans to upgrade from Mailman 2 to Mailman 3? 
https://www.gnu.org/software/mailman/ & 
https://en.wikipedia.org/wiki/GNU_Mailman


2.5 securities per minute seems really slow!

Brad


On 7/16/23 15:52, Bruce Schuck wrote:

Hello again,

At some point I am going to take a break from F::Q, I thought this 
weekend I was going to escape.


### For the question, skip to the next ###

Anyway, some time ago the issue was raised about prices from 
AlphaVantage for LSE traded stocks (see 
https://github.com/finance-quote/finance-quote/issues/281). While 
there is an issue, the user's perceived solution was not the answer. 
Apparently my attempt to explain that the root cause was that the data 
returned from the AV "GLOBAL_QUOTE" API did *NOT* contain the currency 
used for the pricing returned.


What the AV module does is assign a currency based on the suffix of 
the lookup symbol. So stocks like GBP.L and GBPG.L get mapped to GBP. 
The problem is that GBP.L (Global Petroleum Limited) is traded in GBX 
(aka GBp) and GBPG.L (Goldman Sachs Access UK Gilts 1-10) is traded in 
GBP. But the AV module as written cannot differentiate since the 
currency used is not part of the data. Stocks from South Africa have a 
similar issue.


Needless to say, since I was not ready to dig into the root cause and 
not wanting to remove the fix that was meant to convert GBp pricing to 
GBP pricing based solely on the symbol's suffix, the user decided to 
go on a rant and throw a tantrum in the comments and had to be blocked 
from the Finance::Quote repository.


### Question here ###

The currency for the trades can be gotten from AV, but an additional 
call using the "SYMBOL_SEARCH" API is necessary. Obviously this would 
impact the throttling limitation of AlphaVantage. For non-US stocks, 
this means that including an additional currency lookup an average of 
2.5 securities can be fetched per minute. I am curious how many of you 
all use AV for non-US traded securities? Has the pricing discrepancy 
affect you, and would you want it corrected even though that means 
increasing retrieval time due to the extra API usage?


Bruce S.
___
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.


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