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

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

[GNC] Cannot alter Trading value

[Fred Tydeman]

I entered a purchase of stock (the dollar amount and the number of shares).
The system added two trading splits.  I saved the file.  I reopened the
file.
I now realize I typed the dollar amount wrong.  I open the transaction and
show the four splits.  I change the dollar amount in the purchase split and
I change the
dollar amount in the corresponding Trading split.  I click on Enter at the
top of the screen.  The Trading amount goes back to the old value and there
is now a split
for Imbalance.  Is this the expected behaviour?

I believe that the only way I have fixed this kind of issue in the past is
to
delete the entire transaction and reenter it.

OS:   Linux Fedora 37.
GC: 4.14
___
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

[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

[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

[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

[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] user groups that meet in person?

[Brad Morrison]

Hi Steve/all,

I have not seen anything posted to this Mailman 2 mailing list about in 
person user groups specific to GnuCash in the last 6 months...


You may have some luck/interest in GnuCash from the few Linux User 
Groups (https://en.wikipedia.org/wiki/Linux_user_group) that are still 
active, including NYLUG (http://nylug.org/), LILUG 
(http://www.lilug.org/), NJLUG (https://www.meetup.com/NJLinux/), and 
several others in the areas you listed.


I am on the "board" of the North Bay Linux Users Group 
(https://nblug.org/) and we have been meeting monthly for about the last 
1.5 years since the common pandemic hiatus. I also find it very helpful 
and enjoyable to meet others in person and discuss 
interests/questions/issues/etc.


One of my projects has been to scout out interest in forming a 
national/international umbrella organization of LUGs because so many of 
the local groups are scattered and not organized into a registered 501c3 
nonprofit organization. While that structure totally makes sense for 
smaller, all volunteer orgs, if all those independent LUGs had some 
organizational, financial, technical, marketing/PR, & legal structure & 
support, it would be a tremendous help and likely minimize the 
disruptions caused when a key member moves away or loses interest and 
the LUG falls apart. Even for the existing and ongoing LUGs like NBLUG, 
when we migrated our Mailman server from 2 to 3, no one in our group had 
done it before and it was a struggle. Having optional, central support 
for very occasional tasks like that makes updates/changes much easier 
and provides redundancy/backup for when something fails (like when the 
Texas storms took out the GnuCash website server and there was trouble 
with the host's ISP for weeks afterwards & the security/https 
certificates expiring/not redirecting correctly & some scrambling around 
trying to create and use workarounds for almost 2 months in early 2023 - 
https://lists.gnucash.org/pipermail/gnucash-user/2023-March/thread.html). 
The Linux Foundation (https://www.linuxfoundation.org/) offered some 
support & resources 
(https://lists.linuxfoundation.org/mailman/listinfo), but they are not a 
501c3. The Software Freedom Conservancy 
(https://sfconservancy.org/projects/services/) & Software in the Public 
Interest (https://www.spi-inc.org/membership/) are both 501c3 nonprofits 
and both fiscally sponsor nonprofit, open source projects, but SFC  has 
not been responsive (they seem overwhelmed with their current work) and 
I should check in with SPI...


GnuCash is also not a sponsored project of any 501c3 nonprofit org that 
I know of, so donations from US taxpayers are not deductible, but still 
greatly appreciated - https://gnucash.org/donate.phtml


Apologies for 'hijacking' your post, but you likely figured out that 
with no responses in 4 days, the basic answer was no.


Good luck!

Brad


On 7/13/23 14:38, Steve Freeman wrote:

Are there any user groups that meet in person? I'd really like to
occasionally work with others. Live in Connecticut, but travel to New York
(especially Westchester), New Jersey  and Philadelphia.

  


Steve Freeman

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

Re: [GNC] Migration and On-lind banking Manuals

[Brad Morrison]

Hi Chris/David/all,

While David covered some of the aspects of migrating your QuickBooks 
files into GnuCash, as far as online banking, I would suggest checking 
out https://wiki.gnucash.org/wiki/Setting_up_OFXDirectConnect & 
https://wiki.gnucash.org/wiki/OFX_Direct_Connect_Bank_Settings and 
seeing whether what you are hoping to do is possible with GnuCash and 
with the financial institution(s) that you use.


https://www.ofxhome.com/ - might also be helpful for determining the 
connection settings for the financial institutions listed there


https://financialdataexchange.org/ofx - I have heard from others on this 
GnuCash mailing list that OFX is not well maintained and further 
development is iffy. "Death by a thousand cuts" is how one person 
described OFX (https://en.wikipedia.org/wiki/Open_Financial_Exchange).


You also mentioned 'company files' in QuickBooks and while I am not 
exactly sure what you mean by that, if you have anything other than a 
very simple business, GnuCash may not work well for you:


https://github.com/Gnucash/gnucash/pull/1623#issuecomment-1583966278 - 
"But GnuCash isn't suitable for large—or even small;mdash;enterprises 
and never will be. GnuCash is for tiny and simple enterprises; we often 
say individuals and sole proprietorships. Even having employees makes 
using GnuCash a dubious proposition (no payroll module), as does 
carrying more than a very few line items of inventory (no inventory 
module) or performing any sort of manufacturing (no bill of materials or 
cost accounting modules).


Adding those modules is a non-starter: Consider that it's been 10 years 
since we began working on separating libgnucash from the application, 
converting from GObject to C++, and changing from a program that can 
load its data from a SQL database and put it back to one that is built 
around SQL queries. We haven't gotten very far.


Those seeking a F/LOSS accounting solution for larger enterprises should 
look to Odoo ." (https://www.odoo.com/ & 
https://www.odoo.com/accounting-firms)


I include that last part just to make any expectations you might have 
more grounded in the reality of GnuCash's current capabilities.


Good luck!

Brad


On 7/16/23 19:22, David Cousens wrote:

Chris,

If you will have ongoing access to Quickbooks then it is reasonable just to
start by transferring the balances. If for some reason (unable to run the
program in future due to platform change etc etc) you will not have access but
still have a need to access the previous records, then data migration.

When I first moved to GnuCash I had previous data from a business in MYOB.
Initially I just transferred the balances but eventually I transferred the data
for previous years using CSV export and import into GnuCash. I worked back wards
a year at a time resetting the opening balances. I produced balance sheets for
each year and Profit/Loss reports in MYOB before starting and ensured the
corresponding reports in GnuCash matched after completing the import of data for
a given year.  If the reconciliation was valid to some date (eg start of a
current period) before beginning the import and it still works on the major
accounts to the same date after import, you can be reasonably sure that you
haven't introduced too many major errors. If it doesn't agree use the usual
procedures to locate errors in the records until the reconciliation is in
agreement again. Gnucash will show any unreconciled transactions from past
periods in the reconciliation dialogue for a reconciliation to a dtae in the
current period and you can keep a reconciliation dialogue open while importing
the data.
  
Quickbboks IIF files seem to be tab separated CSV files so GNucash's importer

should be able to handle them.

With the importer it is usually good practice to initially import relatively
small batches until you work out the correct associations between columns in the
expoprted data and the corresponding headings within GnuCash. It is possibly a
good idea to initially do this on a dummy set of books to sort out the problems
and only import into your working books once you have it sorted and routine. I
imported data a month at a time going backwards when I initially did this (circa
2010) and gradually moved to 6 months and then a year at a time when I had a
reliable methodology worked out.

Make frequent backups of the data file as you work backwards.

Another approach that I didn't try was to enter the historical data into a
separate data file from the file for the current data going forward.

Good luck

David Cousens

On Sun, 2023-07-16 at 18:13 -0700, Chris Miller wrote:

Hi Folks,

I have a few Intuit QuickBooks "Company Files" that I will migrate to GnuCash.
I'm looking for migration advice.

It is not clear how much history I want to take with me. I may simply start
with exiting account balances, and live with QuickBooks for historical
reports. Or, it may be easy and worthwhile to move move more than 

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

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

Re: [GNC] Two Instances as opposed to two separate files

[Paul Feakins]

On 17/07/2023 10:48, David T. wrote:

That would be *OpenStacks* convention.


Most mailing lists follow those conventions.

Paul.

___
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] Two Instances as opposed to two separate files

[David T. via gnucash-user]

That would be *OpenStacks* convention.

By all means, impose their rules here!
⁣
David T.​

P.S. The amount of energy expended on this topic is amazing to me--and I note 
that NONE of you Authorities On Email Etiquette bothered to change the subject 
of this thread to reflect the completely new (and ultimately fruitless) 
discussion of a topic that left the barn, died, and was buried years ago.

On Jul 17, 2023, 11:37, at 11:37, Paul Feakins  wrote:
>On 15/07/2023 01:56, R Losey wrote:
>> Is there really a convention for replies?
>
>Indeed there is: 
>https://wiki.openstack.org/wiki/MailingListEtiquette#Replies
>
>Paul Feakins.
>
>___
>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.

Re: [GNC] Two Instances as opposed to two separate files

[Paul Feakins]

On 15/07/2023 01:56, R Losey wrote:

Is there really a convention for replies?


Indeed there is: 
https://wiki.openstack.org/wiki/MailingListEtiquette#Replies


Paul Feakins.

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