Topic: License compatiblity for CoA from other ERP

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.


Re: License compatiblity for CoA from other ERP

There is nothing proprietary in heads of accounts and classifications - suit yourself. FA has it's own table structure anyway.

Re: License compatiblity for CoA from other ERP

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?

Re: License compatiblity for CoA from other ERP

If you model it on the en_US-new.sql then changes will be comparable.

Re: License compatiblity for CoA from other ERP

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?

6 (edited by apmuthu 11/13/2015 02:37:26 pm)

Re: License compatiblity for CoA from other ERP

Since FA 2.3 stable is not being ordinarily updated and will receive only critical updates, your CoA probably will not see the light of day.

It may however be modified and get offered as a FA 2.4 pkg.

Should you wish to make it available to the community, you can upload it somewhere and paste the link here or alternatively fork my FA GitHub repo (which has the extensions as well) and include it therein and send in a pull request.

The dev team is busy with getting FA 2.4 out the door.

Could you please state what was outdated in the existing German CoA?

The Mixed table types is intended in FA 2.3 whilst in FA 2.4 all tables have become InnoDB even though CASCADEs are not implemented as yet. IMHO it is better to retain all non-transaction tables as MyISAM as it is easier to recover from corruption for those tables.

Re: License compatiblity for CoA from other ERP

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... ;-)

8 (edited by apmuthu 11/13/2015 05:14:38 pm)

Re: License compatiblity for CoA from other ERP

Thanks for the differences between SKR 3 and 4. If you are following this SKR03 chart, then beware that FA does not like account numbers starting with "0" (zero).

This article was useful - SKR 03 und SKR 04 für die Buchführung von Unternehmen. (SKR 03 and SKR 04 for the accounting of business).

For the user table, keep the default username and password fields the same as in the en_US-new.sql file.

UStG (Deutscheland) == Value Added Tax Act (Germany)

The graph in the Wikipedia article proves that the Government is becoming expensive and soon people should discard it - why "buy" / "tolerate" expensive politicians and bureaucrats wink

Re: License compatiblity for CoA from other ERP

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^^

Re: License compatiblity for CoA from other ERP


Just curious. Why can't the accounts start with zero, if they are alphanumeric? I see no problems in that.


11 (edited by apmuthu 11/13/2015 06:38:20 pm)

Re: License compatiblity for CoA from other ERP

Google Translate. Worked on disease classifications for care2x project.....

There is one post where there was some comparison of account codes and some errors crept in. In fact the UK CoA had to be modified to start with 1 instead of 0. Better safe than sorry. Also please check the order of the fields if they match the en_US-new.sql - the UK CoA had to be corrected to comply - the official UK CoA pkg still has these errors but my repo has it corrected.

You might want to use my version of the en_US-new.sql - basically make for dynamic fiscal year, removal of redundant indices and inclusion of speed up indices besides currency symbols.

Probably @joe is right if alphanumeric account codes are enabled and used but most users will not bother to change the defaults in the config file! Also URL GET parameters are safer handled with numeric codes when interfacing with third party applications.

Re: License compatiblity for CoA from other ERP

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...

Re: License compatiblity for CoA from other ERP

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

Re: License compatiblity for CoA from other ERP

The account are per default set to be alphanumeric. So there are absolutely no problem using accounts with leading zeroes.

Certain EU countries uses leading zeroes for alternative reporting. I guess some French COA are using this.

Never mind it is probably not that necessary to use leading zero accounts.


Re: License compatiblity for CoA from other ERP

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

16 (edited by apmuthu 11/13/2015 07:10:06 pm)

Re: License compatiblity for CoA from other ERP

Lines 129-130 from config.default.php in FA 2.3:

    /* allow alpha characters in accounts. 0 = numeric, 1 = alpha numeric, 2 = uppercase alpha numeric */
    $accounts_alpha = 0;

The account are per default set to be numeric.

chart_master.account_code2 can hold the alternate alphanumeric account code if necessary to interface with other applications. It is used in rep701.php other than when primary record is added/updated.

Re: License compatiblity for CoA from other ERP

Yes, but they are alphanumeric (varchar in database) only allowing 0-9 numeric character values. It will also allow a point sign.

So therefore they can start with a zero character.

Look at the, Banking and General Ledger. There are several accounts starting with zero, and the are presented in the Balance Sheet.


Re: License compatiblity for CoA from other ERP

Sorry, I meant this url.


Re: License compatiblity for CoA from other ERP

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.

Re: License compatiblity for CoA from other ERP

In FA there are no cast to integer for accounts. So you can safely use the default account setting

It would be rather inconvenient to treat an account number as an integer.

You are right. The account settings are either Numeric (which mean that only numeric characters are allowed to enter) =0, alphanumeric, where you can enter alpha characters also (Aa to Zz) =1 and last the alpha characters can only be uppercase = 2.

Re: License compatiblity for CoA from other ERP

The demo url has decimal point and differing no. of digits as well in Account code. I only hope that the "+" and "-" signs are not allowed as range choice would go haywire in reports. Also 1200 and 12001 are different as also 790 is different from 0790 - all sorted as strings..... Therefore say in rep 704 (GL Account Transactions) for a range of Account Codes from 700 to 800, 790 will be included but not 0790. Happy confusion with leading zeroes and decimal points!

Re: License compatiblity for CoA from other ERP

Please, think about this as an accountant. The COA is presented as


This is a normal presentation, where 5 or more digits are treated as subaccounts.
Can you see the disaster if we would sort these as integers?

This is the way COAs are setup, despite using digits or a combination of digits and characters.

No accountants are confused about this!


Re: License compatiblity for CoA from other ERP

@joe: Whilst the selection of codes presented are actually accountant friendly, consider for a moment an inadvertant prefix of one or more zeroes to a regular account say: 790, as 0790, 00790, etc.

Hence use varying multi digit / character account codes with care to be accountant friendly.

Re: License compatiblity for CoA from other ERP

We are removing ourselves from the original topic.
What we could discuss in another topic is if we shouldd prevent entering non digits in the so called Numeric accounts.
F.i. Only digits 0-9.

Let us close this topic now.