[GNC-dev] „Accruals are potentially missing as account_types in the db scheme
Alexander Damm
alex.damm.m1 at gmail.com
Wed Apr 13 10:02:07 EDT 2022
Hello David, hello all,
first of all gnucash is a very cool program for me and I really like to use
it for my little company. Many thanks to the developers.
I'm sorry for my first description on the mailing list, I'm very sure that
maybe the E-Bilanz part was misleading. Furthermore I'm a project lead and
amateur python developer and not an accountant, so any statement needs to
be double checked ;)
First I'd like to say that I totally understand that gnucash focuses more
on the enduser then the professional user and changes would have major
implications on the code.
Especially on the Frontend, if a new account_type would be implemented
Furthermore there would be not much benefits for a regular End User of
gnucash to have new account_types such as "accruals".
Still in my option the choice of account_types doesn't match the same level
and maybe there is a chance to harmonize the need of the end/ soho users:
My suggestion would be the following:
Active:
[standard account_types]
[taxonomie] [current account_type in
gnucash] [ change requests ]
1. Fixed Assets:
bs.ass.fixAss --
none
1.1. "Intangible assets"
bs.ass.fixAss.intan --
pls implement or just
"Fixed Assets"
1.2. "Tangible Assets"
bs.ass.fixAss.tan Asset
pls specify or just "Fixed
Assets"
1.3. Financial Assets
bs.ass.fixAss.fin Stock/ Mutual Fund
pls specify or just "Fixed Assets"
2. Current Assets:
bs.ass.fixAss --
none
2.1. Inventory
bs.ass.currAss.inventory --
pls implement or just
"Current Assets"
2.2. Accounts Receivable
bs.ass.currAss.receiv Accounts Receivable
none
2.3. Stock/ Mutual Fund
bs.ass.currAss.securities Stock/ Mutual Fund
pls specify or just "Current Assets"
2.4. Cash
bs.ass.currAss.cashEquiv.cash Cash
none
2.4. Bank/ Credit Card
bs.ass.currAss.cashEquiv.bank Bank
none
2.4. --
--
Currency
none
Passiv:
[standard account_types]
[taxonomie] [current account_type in
gnucash] [change requests]
1.Equity
bs.eqLiab.equity Equity
none
1.1. --
bs.eqLiab.equity.subscribed --
Equity is fine
1.2. --
bs.eqLiab.equity.capRes --
Equity is fine
1.3. --
bs.eqLiab.equity.revenueRes --
Equity is fine
1.4. --
bs.eqLiab.equity.retainedEarnings --
Equity is fine
1.5. --
bs.eqLiab.equity.netIncome --
Equity is fine
2. --
bs.eqLiab.accruals --
pls implement
3. Liability
bs.eqLiab.liab Liability/
Accounts Payable accounts payable is a
subaccount from liability or just liability
PNL:
1. Income
2. Expense
The accounting structure from the taxonomie is in my humble opinion not set
mindless and follows a clear structure, which is not only vaild in germany
but in whole europe and could help gnucash to attract even more users.
regards alex
On Wed, 13 Apr 2022 at 12:06, <davidcousens49 at gmail.com> wrote:
> Alex,
>
> My understanding of the use of accrual accounts in Germany is very
> limited. but
> my understanding that the e-Bilanz requires a mapping of the general ledger
> accounts in GnuCash onto a taxonomy which defines the format of the
> E-Bilanz (
> presumably theDiFin - the digital financial reports in XBRL format and
> that this
> taxonomy can be changed annually by the Ministry of Finance.
>
> Given this it seems that it would make much more sense to construct this
> mapping
> externally using the python interface to construct the required mapping
> and to
> produce the XBRL document required for submission from a stock standard
> GnuCash
> data file/database. Others may be able to answer whether the python
> bindings
> provide sufficient database/datafile access to be able to produce this
> mapping
> as I have no experience using them. A shift to accrual accounting proper,
> while
> it will primarily affect the business features accounts in GnuCash,
> involves a
> change primarily in the timing of when transactions including income and
> expenses are recorded not a particular positioning of accounts in the
> Accounts
> heirarchy. The timing or recording an event in accrual accounting is
> determined,
> not by the exchange of monies, but by the time of entering into the
> contractual
> commitment to receive or expend funds.
>
> Standard accounting practice for accruals accounting (the default in most
> jurisdictions in any case - GnuCash has no special requirements to
> implement it
> other than the user entering the appropriate date/time for a specific
> transactions and the business features and accounts implement it
> implicitly) has
> no requirement for a separate category of Accruals accounts and doing so
> would
> complicate even further the programming of the application of the
> accounting
> equation which is fundamental to accounting practice. Some of these
> accounts are
> classifiable as Assets and some as Liabilities and having both Asset and
> Liability accounts in a single class of Accruals is a mess.
>
> As usual when governments implement these sort of things what you actually
> have
> to do is hidden deeply in multiple layers of gobbledegook so neither they
> nor
> anyone else can really be clear on what is actually required. This is
> usually
> because they outsource this development to private companies who have a
> vested
> interest in the obscurity to ensure you are required to use their
> particular
> proprietary software to successfully submit electronically. This seems to
> be the
> case both in the UK and Australia with the implementation of digital
> submission
> using XRBL which is really what the e-Bilanz seems to be really about.
>
> Heiling's 2020 paper (has some perspectives on the transition to accrual
> accounting in Germany although not directly relevant to the e_Bilanz
> question
>
>
> David Cousens
>
> On Wed, 2022-04-13 at 07:58 +0200, Alex Ritzer wrote:
> > Hello,
> >
> > I'm currently using GnuCash 4.1. on Windows with a mysql Backend
> >
> > Every year I have to create a so called "e-Bilanz" for the german finance
> > department after the annual statement of accounts .
> >
> > Due to the mandatory Taxonomie I have to use among other things the
> > following acoounts:
> >
> > Activ:
> > (Fixed Assets) de-gaap-ci:bs.ass.fixAss
> > (Current Assets) de-gaap-ci:bs.ass.currAss
> >
> > Passiv:
> > (Equity) de-gaap-ci:bs.eqLiab.equity
> > (Accurals)de-gaap-ci:bs.eqLiab.accruals
> > (Liability) de-gaap-ci:bs.eqLiab.liab
> >
> > [image: image.png]
> >
> > Currently I programmed a workaround in python to get all the liabilities
> > from the db.
> > Still it would be nicer, if we would have an account_type "accurals" or
> > another field in the table accounts to distinguish between liability and
> > accurals.
> >
> >
> > From a short check on the db model I would estimate that there would be
> no
> > harm on the db
> > Scheme, if a new account type or another field would be added.
> >
> > Regards
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
More information about the gnucash-devel
mailing list