I tried different reports and as far as I can see, the leading 0 works fine, even with the default setting of $accounts_alpha = 0. Not that I checked the code, but it seems like that setting is only affecting validation when entering new accounts / editing accounts?
In addition I would expect a problem like the one apmuthu described to appear when the account code is (by mistake) cast to integer - I don't know if there is a CoA with alphanumeric accounts, but in that case such a cast would fail anyways.

I will give it a try and propose myself as guinea pig - even though as far as I can see the only account in use by me is 0800 and that's equity capital, so not changing frequently.

I'll have an eye on that - in case I am facing problems I'll blame you... I mean I'll change it :-P

regarding the leading 0 - I am not yet convinced ;-)

I see your points, there could come bad to worse - on the other hand changing well known account numbers would be slapping in the faces of the (experienced) accountants, as well as would make interfacing more complicated (even though the 0-accounts are nothing that's usually in daily use).

.. I have to think about that

alright, I guess I might have to replace the DDL parts - the inserts should be fine as I purposely exported each one with field names...

Oh, I am surprised - do you speak german? :-o

What happens if accounts start with 0? I didn't see strange behaviour (even though I just checked config.php, there is $accounts_alpha = 0; ), but I edited most accounts via sql...

Alright, I'll put the user table back in.

Yes, they are expensive, even though e.g. Austria (21%) and Sweden (25%) have even higher rates. And you said "buy"... doesn't "buy" mean payers get something ;-) just kidding^^

First of all, the existing german CoA seems to be based on SKR04 (accounts are grouped by their position in the balance sheet), whereas I needed SKR03 (grouped by production process).

My findings:

- Current VAT in Germany is 19 % (§ 12 UStG. has been amended in 2009) - the CoA has no accounts for that VAT rate.
- For § 13b UStG. (reverse charge of VAT for inner-european trading), there are no accounts.
- In general, the CoA is missing many accounts (full SKR04 has roughly 1500 accounts).

These are the main things I could see at first sight...

Well, I have 2.4 installed, but not yet used very much - when 2.4 is released I think I have to migrate anyways.

I am no MySQL specialist - I was just wondering... ;-)

As promised, I just sent the .sql to the mailaddress given at the website.
Some info about it:
It is an SKR03 CoA with removed statistical accounts. I added some tax rates etc., but there will be some entries missing (in non-CoA tables). I also removed the users table, so users/passwords remain as set up previously.

By the way, is the mixture of DB-engines intended?

sounds good!

Let me finish the CoA - then I'll put it all together (as the other charts) and... then I guess I make it available to one of you guys?

Hi FA-community,

I needed a German chart of accounts and what I found was quite outdated.

So I decided to create a new one and am currently converting a German CoA from another open-source ERP to Frontaccounting. I basically did the following:
- installed CoA (under LGPL) in other ERP
- exported database table holding accounts
- did A LOT of editing (most work was matching and editing chart classes)

Maybe somebody here knows if the a.m. procedure is OK from legal point of view? AFAIK LGPL and GPL should be compatible, but I don't know, if that is important anyways, because I did not adjust the scripts under LGPL, but the results of the scripts...

In addition, I have some knowledge on accounting, but am (only) a software developer, so I would appreciate if somebody could check my work ;-)

Thanks in advance.