On 2023-02-19 05:32, m...@tgr66.me wrote:
The approach I’m taking in a migration app I’m writing will be conservative,
erring on the side of more general vice more specific. For example, ASSET,
LIABILITY, INCOME, EXPENSE, EQUITY are pretty easy to accurately apply based on
account names (for example, “assets:current assets:cash”). In an initial round
of type assignments, this account would get ASSET as its type. In a deeper
subsequent look, it should be reassigned with a type of CASH.
INCOME, EXPENSE and EQUITY types don’t have sub-types I see, so those will be
even easier. I don’t foresee any issues with those.
LIABILITY and CREDIT don’t appear too difficult as there just aren’t that many
options. First I’ll assign LIABILITY and if the words “credit card” or “credit
cards” exist in the rest of the account path, I’ll switch to CREDIT, otherwise,
leave it alone.
Assets and Investments will be the trickiest. Let me start with Assets first.
Assume an imported account has the path and name of “assets:savings:family
savings”. Getting this typed as an ASSET is pretty straightforward. Ideally,
however, it would be typed as BANK.
Or SHOULD it? Perhaps this family puts its savings in old coffee cans under the
back porch. So, I’d be inclined to leave this as ASSET. The user can change it,
but are there any negative implications of assigning too general of an account
type to an account?
However, if the name has the word “account” in it, well, then I’d be confident
assigning a type of BANK.
Investment accounts will be the trickiest I believe. Heck, I’m not sure I
understand the differences.
When I create a new account in GnuCash, I’m surprised at some of the
assignments made when creating the hierarchy. For example,
“Assets:Investments:Brokerage Account” is a placeholder with type of BANK. I
would be inclined to assign any placeholder accounts a more generic type. In
this case, ASSET. Again, are there any negative implications of me taking this
approach?
Regardless, I will direct the user to review all of them once created in
GnuCash to ensure they align with their exceptions, but are there consequences
if I get them wrong?
And finally, TRADING. I don’t see any of those in the initial account list
created when I make a new file. So, for now, I’ll ignore this. Is that okay?
It sounds like you are trying to answer two questions:
1. How do you extract meaning from account name strings in incoming
migration data, such that you can pick the appropriate GnuCash account type?
2. What are the GnuCash account types, and what are their meanings (or,
purposes, or semantics)?
I think question 1 is up to you. It is not a GnuCash question.
The place to start for question 2 is the GnuCash /Help/ documentation,
5.1. *Types of GnuCash Accounts*[1]. You might find it helpful to
consult the notes about what kinds of child account type each parent
account type accepts. Missing from this page is the Trading Account type.
Trading accounts are described in the GnuCash /Tutorial and Concepts
Guide/, 12.3. *Automatically Recording Currency Transactions using
Trading Accounts*[2], and at wiki page *Trading Accounts*[3].
You might have to resort to reading the GnuCash code[4] to answer more
detailed questions. I remember doing this once to clear up some of my
own questions.
Your subject: line asks, "what are the implications of getting [Account
Types] wrong?" I don't see you asking that in your message body. But as
far as I know, the implication can be unusability if you get the account
type very wrong (e.g. an Asset type for what should be an Expense type
account), or inconvenience if you get the account type a little wrong
(e.g. no option to add an interest payment during the reconciliation
process if you assign a Liability type for what should be a Credit type
account). Note that users can, within limits, change account types for a
book which is in use. That limits the negative implications of migration
software making the wrong choice of account type.
You are welcome to pose more specific questions to this list, if you like.
And, while reading the documentation you may come up with suggestions
for improved documentation wording. I encourage you to propose those as
pull requests, or to the gnucash-dev mailing list. Part of what makes
GnuCash so good is that many hands help to improve it.
Best regards,
—Jim DeLaHunt
[1] <https://www.gnucash.org/viewdoc.phtml?rev=4&lang=C&doc=help>,
temporarily hosted at
<https://code.gnucash.org/website/viewdoc.phtml?rev=4&lang=C&doc=help>
while www.gnucash.org's web server is offline.
[2]
<https://www.gnucash.org/docs/v4/C/gnucash-guide/currency_trading_accts.html>,
temporarily
<https://code.gnucash.org/website/docs/v4/C/gnucash-guide/currency_trading_accts.html>
[3] <https://wiki.gnucash.org/wiki/Trading_Accounts>
[4] <https://github.com/GnuCash/gnucash>
_______________________________________________
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.
