I don't see any problem in the fact that taxation systems are
different in every country. Gnucash has guile as an extension
language, so the country dependent parts of it can be implemented as
scripts.
For example, no matter what coutry you are in, there will be a notion
of depreciation. The only thing that will differ is the depreciation
formula. The general depreciation mecanism can be implemented in
gnucash, with the depreciation formula being a guile script, dependent
on the taxation law in your country.
The same applies for reports, an income statement is an income
statement, and differs from country to country only in the
organisation of the accounts.
And in fact wouldn't be nice if gnucash will ask you on instalation
what country you are in, and automatically apply all the accounting
rules in that country? If you are an expert you could switch the
mecanism off, and use gnucash in whatever way you like...
Best Regards,
alex.
>>>>> "Jan" == Jan Schrage <[EMAIL PROTECTED]> writes:
Jan> --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii
Jan> Content-Transfer-Encoding: quoted-printable
Jan> In response to the mail on automated adjustment of accounts
Jan> and report generation, I would argue strongly against any
Jan> kind of automation in both account adjustment and report
Jan> generation. I am not against something like recurring
Jan> transactions, but that is a different matter. And now to the
Jan> details...
>> =20 =20 (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:
>>
Jan> [snip example] Yes, it's called depreciation. Actually, your
Jan> example is a case of linear depreciation, where in each
Jan> period of time the original asset is deprecated by the same
Jan> amount. This leaves the asset with a rest value of zero when
Jan> you're done.
Jan> Other models include degressive (is that the correct term in
Jan> english?) depreciation, where in each period of time the
Jan> original asset is deprecated by a fixed percentage of the
Jan> value it had in the previous period. This allows you to have
Jan> a large depreciation in the beginning, which is probably more
Jan> realistic for most assets. This leaves the asset with a rest
Jan> value larger than zero.
Jan> The third method coming to mind is digital (again I do not
Jan> know whether this is the correct english term)
Jan> depreciation. First you divide the asset value by the sum of
Jan> the years of use, e.g. for an asset worth $15.000 used over a
Jan> period of five years you get
Jan> 15.000/(1+2+3+4+5)=3D1000. Depreciation and asset value are
Jan> then calculated as follows: Year Depr. Rest Value 1
Jan> 1000*5=3D5000 10.000 2 1000*4=3D4000 6.000 3 1000*3=3D3000
Jan> 3.000 4 1000*2=3D2000 1.000 5 1000*1=3D1000 0
Jan> Not all the depreciation methods are relevant for taxation
Jan> purposes, though. In Germany, for example, digital
Jan> depreciation may not be used. Businesses may use both
Jan> degressive and linear depreciation (within certain bounds)
Jan> and individuals may use linear depreciation only. Again,
Jan> there are some restrictions.
Jan> The gist of this is that your use of depreciation will vary
Jan> with the country you are in, and possibly change when new
Jan> taxation laws apply (in Germany, e.g. some aspects of
Jan> taxation are being revised at the moment). Also the kind of
Jan> assets you may (or have to) write off over a couple of years
Jan> 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 =20
Jan> For the reasons above I would argue against any automated
Jan> depreciation in gnucash. The issues involved are too
Jan> complex. Myself, the thought of dialog boxes popping up
Jan> making me choose depreciation models I most likely will not
Jan> be able to use, and the use of which may not even be lawful
Jan> in my country, makes me shudder.
Jan> I agree with the notion that a lot of potential gnucash users
Jan> will not know much about these issues, but that can be solved
Jan> by documentation, which I hereby offer to write. That is, if
Jan> you guys out there are interested, I am going to knock up
Jan> something on matters of appreciation, depreciation and how to
Jan> use them properly in gnucash. If anybody's interested, I'll
Jan> also put together a short summary of German taxation issues
Jan> 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). =20
Jan> Again, this notion is erroneous. The kind of financial
Jan> reports - including grouping of assets and liabilities - you
Jan> need depend on your taxation laws. American methods of profit
Jan> calculation and German ones differ considerably, for
Jan> example. This used to be a major problem in US-German company
Jan> mergers. If you really want to make use of reports they must
Jan> fit your local taxation requirements, not vice versa.
Jan> Since there is already a perl interface suitable for report
Jan> generation I think it will be way more helpful if somebody
Jan> who knows his local requirements for taxation issues knocks
Jan> up a report generator suitable for his country and kind of
Jan> business for inclusion with the distribution. That way, we
Jan> get report models suitable for practical use. And they are
Jan> more flexible than click-interfaces, too.
Jan> Anyway, this is my two cents...
Jan> =2E..apart from one thing: Big compliments to all those who
Jan> have been involved in the project up to now. You've done an
Jan> excellent job so far.
Jan> Jan
Jan> =2E. . .. .... .. . ... .. . ... ... ... .. ... ...... ... .. .... ........
Jan> Jan Schrage [EMAIL PROTECTED]
Jan> http://www.unix-ag.uni-kl.de/~schrage/ PGP Public Key:
Jan> http://www.unix-ag.uni-kl.de/~schrage/pubkey.asc = =20
Jan> --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature
Jan> -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1
Jan> iQA/AwUBODVOsk4zcaruWWZFEQKgogCghCDbI0ybmXY7HOzBWJ+nqWr7mJcAoL5P
Jan> 3vmo6Fo2T1D5NGYrbbD1rO+Z =2WX5 -----END PGP SIGNATURE-----
Jan> --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=
Jan> -- Gnucash Developer's List To unsubscribe send empty email
Jan> to: [EMAIL PROTECTED]
Jan> --d6Gm4EdcadzBjdND--
--
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
