Indeed, my apologies David. I got lost in the thread, which it seems has
now broken again (2 new messages I see are threaded separately as a new
topic) and one reply from Chris Good concerning OFX import having the
auto-creation option somehow ended up in a thread "Due Invoices Reminder
form"! So please accept my apologies for the noise.
I'm not sure why threads get broken, though I suspect that is a digest
thing. It may not even look that way to everyone. It could be
Thunderbird (my reader of choice using Gmane) could be the culprit.
(though Mail.app on my Mac did the same)
To the topic, it seems OFX *might* or should be able to autocreate
missing securities, but Jim noticed there were problems. (and his file
is CSV anyway)
I think there is some agreement here, that it would be really, really
nice if both importers could offer and properly create new securities
when importing transactions from a broker and such.
That is an interesting approach you offer. And I agree, after that much
work, it just might be saner to add them manually. If the # of
securities were really high, then maybe it would be worth the outside
effort.
Regards,
Adrien
On 8/16/22 1:48 PM, David T. via gnucash-user wrote:
Adrien,
It has been complicated, I agree. However, this thread originated with
https://lists.gnucash.org/pipermail/gnucash-user/2022-August/102395.html
written by Jim. Flywire has added a number of good comments related
generally to importing investment transactions on the thread, but is
misunderstanding Jim's specific problem regarding mitigating the burden
of creating a large number of securities in the securities database.
I will admit, as I re-read Jim's original post, he buried the primary
problem midway through the second paragraph, making it easy to think his
problem had mostly to do with importing investment transactions.
However, a closer reading of the post, along with his explanations later
in the thread, make it clear that his primary problem is the creation of
130 entries in the Securities database.
Your final comment summarizes the conundrum.
If I were in that situation, I'd might go the latter route, fraught with
danger though it is.
NOTE: THE FOLLOWING STEPS ARE NOT RECOMMENDED BECAUSE YOU RUN THE RISK
OF RUINING YOUR DATA FILE ENTIRELY. MY WORDS HERE ARE MEANT ONLY AS A
SPECULATIVE SET OF OPERATIONS WITH RISKS THAT NO SANE ACCOUNTANT WOULD
ACCEPT. DON'T DO THIS. I KNOW I WOULDN'T!
First, I'd create a new GC test file (test.gnucash) and add one account
and one security to it (the account is necessary to force GnuCash to
save the commodity entry, apparently) and save the file. Then I'd save
it as an SQLite3 file. Then, I'd use an online GUID generator (e.g.,
https://www.uuidgenerator.net/guid) to create a bunch of GUIDs for my
new securities records. Next, I'd merge the GUIDs with the list of
commodities into a single list (containing: GUID, namespace, mnemonic,
fullname, fraction, quote_flag, quote_source), open test.gnucash in a
database app and insert the entries into the Commodities table. Then I'd
save the whole content to XML and paste the commodities content into a
***copy*** of my real data file (I don't know whether you need to fix
<gnc:count-data cd:type="commodity">, but I imagine you would). Then I'd
open the new Frankenstein file and confirm that the new commodities are
there and add a transaction or two to verify that it was functional.
Having confirmed all this, I'd begin importing actual transactions.
Of course, I might just find all this unsupported hacking too stressful
and just bite the bullet and enter things through the UI.
_______________________________________________
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.
