[This bug report s a copy of https://gnucash.uservoice.com/admin/v3/suggestions/37860628/] Once a week I download the week ending prices of all the stocks that I have owned to a csv file. Almost all of them import well. 2 do not. Those two are COP and ADP, because GnuCash assumes both are currencies. i.e. My CSV file has Conoco Phillips (COP) price and GnuCash assigns the value to Columbian Peso (COP) I would like an option to say that all of the imported prices are stocks, or to ignore currencies. Maybe a pop-up window asking what the individual price is associated with when there are multiple commodities with the same ticker. Mostly I would like something more convenient than opening the editor every time to correct both of those entries.
If you are no uservoice admin use the link in URL instead. The OP was crater21_98@yahoo.com. I just did a test: In the Commodity_From List are both: in the currencies COP (Columbian Peso) and at the end COP (Conoco Phillips) after I created it, but the data columns are missing a namespace column.
Well I never thought of that... So I could add a tick box under 'Allow existing prices...' with the text "Imported commodity prices are non currencies" and with this ticked by default the existing columns could be used. Then add another property column of "Commodity Is Currency" which would have CSV values of translated "Yes/No" These new options would be mutually exclusive so selecting one would deselect the other. Looking at the code it does a unique table lookup, then a currency table lookup and then tries in all namespaces so I think this would fit in well. Any thoughts?
Or add another column "namespace" which would align well with the pricedb model.
(In reply to John Ralls from comment #3) > Or add another column "namespace" which would align well with the pricedb > model. +1
I think I am getting confused with the namespace for currency that I would match on. Is it "CURRENCY" or translated "Currencies"
It's either CURRENCY or ISO4217.
That's an implementation detail really. Rather use gboolean gnc_commodity_namespace_is_iso(const char *name_space)
I have change the 'Commodity from' CSV import to require two populated columns, they are 'Namespace' and 'Symbol' that match the columns available in the 'Security Editor'. As long as the namespace / symbol combination matches the price database the 'Commodity from' will be valid. This will be available in 3.6, please test when available and report back so that this bug can be closed.
Are both Namespace and Symbol required for each commodity separately? I cannot test this yet.
Requiring 'namespace' for each import entry is not an ideal solution because it requires that an internal GnuCash element be supplied. Yeah, it aligns with the pricedb model, but it can't readily be derived from an external source. I've been importing a mix of mutual fund, ETF, and stock prices from a source with an unpredictable order, and no way to infer the 'namespace' except eyeballs. Providing 'namespace' requires about the same effort needed to enter prices manually using the price tool editor. In my view, this "fix" breaks the general case to solve a rather rare one.
Could the 'namespace' field be set up to act roughly the same way that the 'account' field does while editing transactions? ie, a drop down list appears, but it is still possible to enter free form text?
(In reply to John Layman from comment #10) > Requiring 'namespace' for each import entry is not an ideal solution because > it requires that an internal GnuCash element be supplied. Yeah, it aligns > with the pricedb model, but it can't readily be derived from an external > source. I've been importing a mix of mutual fund, ETF, and stock prices > from a source with an unpredictable order, and no way to infer the > 'namespace' except eyeballs. Providing 'namespace' requires about the same > effort needed to enter prices manually using the price tool editor. In my > view, this "fix" breaks the general case to solve a rather rare one. I believe this is a valid point. Perhaps we should limit this to require a namespace in case of ambiguity only. Or adjust the importer to ask for clarification in case it detects ambiguity. When going that route an additional challenge is to write that in such a way that it doesn't *require* a gui. It should remain possible to run the importers from say a python script in which the script script should be able to do most of the importer tweaking as the gui would allow.
Since the actual issue is currencies vs. securities perhaps a simple currency yes/no would be better than requiring the user to remember in what namespace he configured the security. We might go so far as to default it to non-currency.
