[GNC-dev] „Accruals are potentially missing as account_types in the db scheme

davidcousens49 at gmail.com davidcousens49 at gmail.com
Thu Apr 14 06:44:18 EDT 2022



Alex 

I don't really think there is any need to do this inside GnuCash and I think it
would certainly not be correct to do so inside GNuCash.  These are all primarily
accounts in equity to meet future anticipated costs, mainly relevant to a
company, where you would make such provisions for future costs from the Retained
earnings, other than the aset and lability acounts.  I feel you are
misuderstanding the intention of the eBilanz  classifications. The y will
contain a lot of detail that may not be relevant for a small company but may be
for much larger companies

The problem is that GNuCash is not used in Germany alone and different
jurisdictions can have very different financial reporting requirements and these
change over time whereas the current accounting practices built into GnuCash are
relatively stable and generally reasonably compliant with the international IFRS
standards for accounting if you follow the jurisdictions standard practices.

You can't really expect to impose Germany's specific financial reporting
requirements on the rest of the world. Commercial packages like SAP and similar
have the resources to do this (and I suspect they do not alter the accounting
package component of the system but tack on an additional system to handle the
mapping of their accounting accounts to the taxonomy and produce the XBRL file.

The Ministry of Finance in Germany have provided the capacity to do this through
the use of an Excel file which can map the accounts internal to GnuCash onto the
account classifications eBilanz requires separately from another file containing
the Balance sheets, profit and Loss reports from GnuCash using the internal
GnuCash account names in a suitable form (e.g. Excel).





On Thu, 2022-04-14 at 11:19 +0200, Alexander Damm wrote:
> Thanks for the reply.
> 
> 
> This is exactly how it is. In my last mail showed some accounts on the
> highest level.
> 
> "The classes all appear to be subclasses of either Equity and/or
> Liabilities and
> not specific classes of accounts in their own right. I tried to have a look
> at
> the eBilanz online submission site (
> https://www.ebilanzonline.de/digitaler-finanzbericht/#c424) to see if I
> could
> find out what the required input was and how to present it but that is not
> possible without registration."
> 
> Of course I can program a workaround in python to link all accounts from
> gnucash to the xbrl notation. But my question was, if it would not make
> sense according to my lineup to change the account_type to match a greater
> standard and as a benefit reduce the effort to convert the annual statement
> of accounts for small business owners.
> 
> 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 links for further information would be:
> https://cloud.amana.de/TaxonomyVersion/
> 
> Regards Alex
> 
> 
> On Wed, 13 Apr 2022 at 23:03, <davidcousens49 at gmail.com> wrote:
> 
> > Alex,
> > 
> > I've been able to find out a bit more about the eBilanz format from this
> > site
> > 
> > http://www.fractalexperience.com/xbrl/web/?h=be50b430c57f45244ba9e9a5.c8e28feef1a872188bcc479a
> > The bs.eqLiab.accruals descriptor appears to apply to accounts in equity
> > for
> > Provisions for future liabilities where the liability accrues on a periodic
> > basis, e.g. pensions which accrue with length of service.
> > 
> > Similarly the bs.eqLiab.equity represents similar accounts in equity
> > which are
> > intended to cover certain other contingencies, retained earnings , profit
> > and
> > loss etc.
> > 
> > The bs.eqLiab.liab class applies to the general class of liabilities which
> > the
> > eBilanz seems to report as a general class under equity which is OK as both
> > liabilities and Equity have the same deit/credit meanings.
> > 
> > The classes all appear to be subclasses of either Equity and/or
> > Liabilities and
> > not specific classes of accounts in their own right. I tried to have a
> > look at
> > the eBilanz online submission site (
> > https://www.ebilanzonline.de/digitaler-finanzbericht/#c424) to see if I
> > could
> > find out what the required input was and how to present it but that is not
> > possible without registration.
> > 
> > It would appear their site (see FAQs on it) can import data from an Excel
> > spreadsheet interface and the mapping of your accounts onto the classes can
> > similarly be constructed in an Excel spreadsheet and imported in that
> > format.
> > Since LibreOffice can export spreadsheets in the Excel 2003 format so it
> > should
> > be possible to get data in even if you are not a Microsoft user.
> > 
> > I went through a similar effort with the Australian system when they
> > introduced
> > digital business reporting and found it equally confusing. I gave up there
> > as it
> > has not yet been applied to individuals tax reporting and I am no longer
> > operating a business, but that will no doubt happen in the future.
> > 
> > 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
> > 
> _______________________________________________
> 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