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, <davidcousen...@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@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
