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

[Alexander Damm]

Hello,

maybe we could a checkbox to the settings to use accruals.

false[Default]  -> for all users, who don't need to work with accruals
true -> for all users who need these account(s)/ account_types

In the Frontend there could be a dialog,  if the checkbox is true, that
every user has to enter, if a bill is payed directly or stays as an
Accounts Payable(liability) in the balance. The same goes for  Accounts
Receivable, if an asset is sold, but the cash/ bank didn't receive the
corresponding amount right away.

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
>