Options

Common G/L account for all companies

santoshmkcetsantoshmkcet Member Posts: 229
Dear all

i want to create a G/L account in one company. How to set up so that when i create a G/L account in one company it gets updated in another company also.
Thanks & Regards
Santosh
Where Stones can be transformed to Gold

Answers

  • Options
    jglathejglathe Member Posts: 639
    Hi,

    that's not a standard NAV feature. I assume it's a feature you can get in an add-on, or you have to program it for the customer.

    with best regards

    Jens
  • Options
    manisharma31manisharma31 Member Posts: 285
    You need to change the property DataPerCompany from yes to no of table 15-G/L Account.
    But this can only be possible if there are no. ledger entry for any of the accounts in any company.
    Regards,
    Manish
  • Options
    jglathejglathe Member Posts: 639
    Hi,

    I strongly recommend not to change the G/L Account table into a global table. You would get far more problems than you would solve. I would recommend thinking about a master company with all alowed G/L accounts, and syncing from there.

    with best regards

    Jens
  • Options
    Alex_ChowAlex_Chow Member Posts: 5,063
    Dear all

    i want to create a G/L account in one company. How to set up so that when i create a G/L account in one company it gets updated in another company also.

    Take a look at the CHANGECOMPANY command on the OnInsert, OnModify, and OnDelete triggers.
  • Options
    manisharma31manisharma31 Member Posts: 285
    Hi jglathe
    Can you please give a good reason to believe it.

    I don't get it if i am marking Chart of Account comman to all companies would create a problem which cannot be solved.
    I personally had implemented 5 NAV projects & in that 4 have set comman to all companies (i.e Chart of Account / Vendor / Customer) and its been 3 yrs they are running smooth.

    If that was the case then why microsoft has given that property. :?:
    Regards,
    Manish
  • Options
    Alex_ChowAlex_Chow Member Posts: 5,063
    By changing that property, you can delete a G/L account from one company that has G/L Entries in another company.
  • Options
    DenSterDenSter Member Posts: 8,304
    Not to mention data in related tables that exist in one company but not in others, and when someone wants to make a change in one company that is not desired in another company. Lots of reasons why you can't just set that property.
  • Options
    jglathejglathe Member Posts: 639
    Alex Chow wrote:
    By changing that property, you can delete a G/L account from one company that has G/L Entries in another company.

    Hi manisharma31,

    Alex' remark is one reason, but not the only one. One other reason for example would be Posting Groups and Tax Codes, they are only the same as long as your companies are in the same tax (VAT) jurisdiction. In effect the posting groups would be too weak to be trusted or useful, when different countries (subsidiaries) are different companies (not unusual here).
    When it comes to customers/vendors, other fields like payment terms also come into play. We have the same "problem" at my employer.
    You are right: These problems can be solved, however it requires some coding and understanding of the data structure. Once started, you have a lot of things to change until you have a reliable system again. And you lose flexibility, which can be a problem when the application grows with the company.

    with best regards

    Jens
  • Options
    S0918423470S0918423470 Member Posts: 159
    I agree with Jens, we should not change that property because of safety and stable data. I think that the best way is using code to synchronize common data . It's easy and not much risk. We can create a button call "Synchronize data" and give options to synchronize common data for specific company or all companies.
    HN
  • Options
    manisharma31manisharma31 Member Posts: 285
    Agreed with the reason guys.
    Thanks.

    But there are always advantages and dis-advantages for every thing.
    Regards,
    Manish
Sign In or Register to comment.