Hi All,
Can you let me know if there’s a way of producing a central chart of accounts?
I have multiple companies on the same database and the chart of accounts was copied from the G/L Account List of the original company during setup. However, there’s a tendancy for users to amend the chart. I would like a central chart of accounts to prevent this.
Has anyone done this before, and is there a tried and tested method?
Many Thanks,
Gemma
Hi gemma ,
with permission you can block modification of chart of account to some user.
To have automatically update of all the company you need to made a develop that update all the company chart of account when you update master, someone change property data per company but this is not recccomended solution.
Bye
Althogh there exists such thing as Tables (actually, data) common to all companies, the G/L Accounts table can not be common.
You can manage this through permissions, by limiting who can add new G/L Accounts to keep integrity between companies to few or even one superuser.
Hi Gemma,
Sound to me like you want to use the standard consolidations. Basically you create a consolation company and roll up the individual companies to the consolidation company. Have a read of the Consolidation section on the on-line help under General Ledger and see if it applies to you.
Hi Gemma,
How about that you create a “Master Data Company”. Then you limit the permissions to the G/L Account tables in the other companies, so that noone can change them. Finally you use the Data Migration tool to copy them to the other companies, and repeats that step every time you need to create or change a G/L Account.
Not super smart, but it does the job and doesn’t require any customizations.
Thanks everyone for your suggestions. I had considered using the consolidation functionality, but Erik, I like your idea of the ‘Master’ dater company. Thanks again.
Hi Erik,
Today I’ve been trying to work through your suggestion and I have drawn a blank at the data migration tool. Initially I thought you were referring to the copy tables function in the setup checklist (I am using V4 SP3), but this does not allow me to re-copy a table. Then I tried exporting and importing a fob in my test database, but this did not have the desired result.
Am I missing something? could you please point me in the right direction?
Many thanks,
Gemma
Hi Gemma,
I’m sorry you’re right. I’ve just checked. The database I was looking at actually had two small changes done in Codeunit 406, which allowed us to do this transfer multiple times.
First this code in the CopyData function was removed:
{CALCFIELDS("No. of Records","No. of Records (Source Table)");
IF "No. of Records" <> 0 THEN
ERROR(
Text007 +
Text008,
"Table Name",COMPANYNAME);
IF "No. of Records (Source Table)" = 0 THEN
ERROR(
Text009 +
Text010,
"Table Name",BaseCompanyName,COMPANYNAME);}And then in the TransferContents function:
INSERT(TRUE);
As changed to:
IF NOT INSERT(TRUE) THEN MODIFY(TRUE);
Gemma,
I have done this for several clients. The easiest way is to edit the G/L Account table and change the DataPerCompany from the default of ‘Yes’ to ‘No’. This will let all companies in the database share the same chart while keeping the posted entries separate. The trick will be whether or not any changes in the other companies will cause issues (i.e. new account in company A is a different account name/type than the same new number in company B). If they are all the same, you will need to make a full database backup, then through code delete the data in the G/L Account table for all companies except the “master” company. Doing the delete through code gets around the issue of not being able to delete an account that has posted entries. You can then change the DataPerCompany option and all companies will see the same chart.
Besides the fact that the copy function of the standard data transfer tool has to be modified, it has also to be assured that it is called every time when a change to the G/L table occured (one can forget it for example…) - So, I would suggest, too, to make the Table 15 (G/L Account) to be global (DataPerCompany=No), because I think this is the easiest and “cleanest” way to implement the desired behavior. But there are some troubles that might occur (as Modris Ivans warned before):
First of all, you have to assure that it is not possible to delete a G/L Account from a company where there are no G/L Entries (in closed periods) for that account, because when you press F4 to delete an account, it is only checked for G/L Entries in the current company, so it is possible that you can delete an account from one company that has (open) G/L Entries in another company and since the G/L Account table is global it is also deleted in all companies and that would be fatal… (so just extend the DELETE trigger function(s) to look in all companies instead of merely the active one).
There are some other places in the code (triggers) of table 15, where references are made to local tables (for example GLSetup) and you have to check carefully, if this might cause further troubles.
As a second point, there may be (and there are) fields in the G/L Account table with TableRelations to other tables that are not global, for example Global Dimension 1/2 - so one could draw into consideration to make also the dimension tables global (and get less maintenance effort), but this might cause more troubles… - on the other hand, if you are working with default dimensions and that table is not global, the default dimension will only be inserted in the active company and may have to be copied into the other ones…
Furthermore, if you want to use the fields “Gen. Business Posting Group”, “Gen. Prod. Posting Group”, “Tax Area Group”, “Tax Group Code”, “VAT Bus. Posting Group”, “VAT Prod. Posting Group”, “Default IC Partner G/L Acc. No.” and/or “Liquid Account No.”, be aware that the corresponding field codes are the same in all companies, and may be the corresponding tables should also be made global to make things easier and more consistent… - Fortunately in those “secondary” tables there are far less troubles, that might occur, if you make them global (except for the Dimension tables…)
The decision, if one of these secondary tables should be made global, too, should be come to by asking firstly if the corresponding field in the G/L table is used at all, and secondly if it leads to further, hardly predictable troubles (like in the case of the Dimension Value table, e. g.)
These troubles arising from table relations, may always occur, regardless of what method you are choosing to achieve something like a “global” G/L Account table.