In response to the mail on automated adjustment of accounts and report
generation, I would argue strongly against any kind of automation in
both account adjustment and report generation. I am not against
something like recurring transactions, but that is a different matter.
And now to the details...
>
>
> (2) Adjusting the accounts means entering some transactions that are
> not really occured, to reflect some internal changes. I will
> ilustrate this by an example:
>
[snip example]
Yes, it's called depreciation. Actually, your example is a case of
linear depreciation, where in each period of time the original asset is
deprecated by the same amount. This leaves the asset with a rest value of
zero when you're done.
Other models include degressive (is that the correct term in english?)
depreciation, where in each period
of time the original asset is deprecated by a fixed percentage of the
value it had in the previous period. This allows you to have a large
depreciation in the beginning, which is probably more realistic for most
assets. This leaves the asset with a rest value larger than zero.
The third method coming to mind is digital (again I do not know whether
this is the correct english term) depreciation. First you divide the
asset value by the sum of the years of use, e.g. for an asset worth
$15.000 used over a period of five years you get
15.000/(1+2+3+4+5)=1000. Depreciation and asset value are then
calculated as follows:
Year Depr. Rest Value
1 1000*5=5000 10.000
2 1000*4=4000 6.000
3 1000*3=3000 3.000
4 1000*2=2000 1.000
5 1000*1=1000 0
Not all the depreciation methods are relevant for taxation purposes,
though. In Germany, for example, digital depreciation may not be used.
Businesses may use both degressive and linear depreciation (within
certain bounds) and individuals may use linear depreciation only. Again,
there are some restrictions.
The gist of this is that your use of depreciation will vary with the
country you are in, and possibly change when new taxation laws apply (in
Germany, e.g. some aspects of taxation are being revised at the moment).
Also the kind of assets you may (or have to) write off over a couple of
years and the minimum number of years depends on law.
> This kind of transactions can be automated, and it is important
> because the user that does not have accounting knowledge will find
> automatic transactions hard to understand/use
>
For the reasons above I would argue against any automated depreciation
in gnucash. The issues involved are too complex. Myself, the thought of
dialog boxes popping up making me choose depreciation models I most
likely will not be able to use, and the use of which may not even be
lawful in my country, makes me shudder.
I agree with the notion that a lot of potential gnucash users will not
know much about these issues, but that can be solved by documentation,
which I hereby offer to write. That is, if you guys out there are
interested, I am going to knock up something on matters of appreciation,
depreciation and how to use them properly in gnucash. If anybody's
interested, I'll also put together a short summary of German taxation
issues related to those depreciation models.
> (3) Financial reports are quite standard and their creation can be
> automated. However there are some points when the program has to
> ask the user for information. One such point would be the grouping
> of the acocunts (if you have a lot of asset accounts, you would
> prefer to report a single asset account showing the sum of all
> balances in the accounts).
>
Again, this notion is erroneous. The kind of financial reports -
including grouping of assets and liabilities - you need depend on your
taxation laws. American methods of profit calculation and German ones
differ considerably, for example. This used to be a major problem in
US-German company mergers. If you really want to make use of reports they
must fit your local taxation requirements, not vice versa.
Since there is already a perl interface suitable for report generation I
think it will be way more helpful if somebody who knows his local
requirements for taxation issues knocks up a report generator suitable
for his country and kind of business for inclusion with the
distribution. That way, we get report models suitable for practical use.
And they are more flexible than click-interfaces, too.
Anyway, this is my two cents...
...apart from one thing: Big compliments to all those who have been
involved in the project up to now. You've done an excellent job so far.
Jan
.. . .. .... .. . ... .. . ... ... ... .. ... ...... ... .. .... ........
Jan Schrage [EMAIL PROTECTED]
http://www.unix-ag.uni-kl.de/~schrage/
PGP Public Key: http://www.unix-ag.uni-kl.de/~schrage/pubkey.asc
PGP signature
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
