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.