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?

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?

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

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

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.

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

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

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 demo.frontaccounting.com, Banking and General Ledger. There are several accounts starting with zero, and the are presented in the Balance Sheet.

Joe

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.

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!

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