Dynamics GP Organization Structure or Implementing General Ledger in Large Corporation

Feb 28
07:54

2011

Andrew Karasev

Andrew Karasev

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

In large organization it might be practical to establish policies, where AP, AR and Accounting personnel has restriction on the GL accounts accessibility.

mediaimage

One of the reasons might be security,Dynamics GP Organization Structure or Implementing General Ledger in Large Corporation Articles however additional reasons are also possible, such as avoiding GL posting distribution mistakes; simplification in training and daily routines (where new hires do not have to come through tons of accounts to pick the one they need, etc.).  Of course, there is the way to restrict people via general security access: tasks, roles.  But, let’s say – if you would like accountant to have control over some accounts and see their balances, in order to restrict this person from accessing other accounts, you can consider implementing Organization Structure.  Let’s review the setup, procedures and FAQ:

1. Setup.  First of all, let’s abstract from your companies structures, as OS is about enabling accounts to User Class or to the specific user ID.  This is rather your internal structure of accounts, which is not necessary coinciding with your legal companies.  Even if you create Company on the Level 1 – it doesn’t mean that accounts are restricted to just the specified company.  In real life, when you are working in accounting department in multinational corporation, you may have substantial percent of your GL and AP transactions being classified as intercompany.  You can setup up to four levels and up to 256 entities.  OS is something that requires decision making and recommended starting point is to review corporate charts.  One of the popular examples is: Company for the first level, Product for the second, Department and Sector for the third and fourth respectively.  Please, note here, again – company is not necessary the legal entity, you may decide to have foreign branch to be the company in the Organization Structure, even when the it is legally the representative office or branch (part of your domestic company, not separate legal entity).  When you are done with the Levels and their possible values, you need to create Organization Tree (Cards -> System -> Organization Tree).  What you do here – you say, that Company A has Product X and Y, Product subdivisions have departments Consulting, Sales and Customer Service, then in turn each department has sectors: Engineers, Programmers, Receptionists, etc.

2. Assigning Users and User Classes.  This is done directly in User Security form and User Class form.  Both User and Class could be assigned to one position only.  Class in Great Plains security model crosses the company border and structure the users in all companies

3. Assign Accounts to the OS Entities.  In contrast to User or User Class – Account could be assigned to multiple entities (and this natural, as imagine Due To and Due From Accounts in intercompany transactions should be seen by both Purchasing and Sales departments in the respective companies).  You can do mass assignment in Administration -> Cards -> System -> Organization Assignments or for each individual account in Account Maintenance form (hierarchy resembling icon to the right from Account ID the one close to the Inactive Account checkbox)

4. Activating Account Level Security.  When you are done with Organization Structure, it’s Tree, Users, Classes and Accounts assignments, now it is time to activate Account Level Security.  It is done in Company Setup form, just below Security checkbox you should be able to find Account Security checkbox – mark it.  Here you need to take into consideration, that Organization Structure crosses company border and this is why you would need to enable it in all companies (their databases, meaning legal entities)

5. Users in the Organization Structure restrictions.  Account Security is definitely a good thing to implement in large organization.  Please, be aware about some side effects.  First of all, user doesn’t have a right to create new account (only SA, DYNSA and individual user or belonging to the class where Grand Access to All Accounts is market have now the ability to create new accounts, as before account is created there is no way to assign it to the entity in the Organization Structure).  Second, if user is creating something like Sales Order Processing Invoice, where accounts are defaulted from Posting Settings, Item, Customer or Customer Class – if the user is trying to open distribution window, where some of the accounts are not in her or his realm – the message “Access Denied/Account Missing” will be shown in the Description field.  The user can still post the batch in the originating module, but even if post through General Ledger is marked in Posting Setup, the transaction will not post in GP.  The user with enough privileges should take over, and open Batch Recovery form to unlock and post the Batch directly in General Ledger.  Additional restriction on the printing out reports – if you do not have the privilege to see the Account (due to Account Security restrictions via Organization Structure) – this doesn’t mean that your supervisor will get the same problem – he or she (assuming that that person have enough rights to see the account in the OS) should be able to print reports with full details

6. If you think that Organization Structure implementation cased more problems, than solutions.  If you are administrator it is simple to roll back security.  Open Setup -> Company -> Company and uncheck Account Security checkbox.  Here please think several times before unchecking Security checkbox (just above), as if you do so – all Great Plains Roles, Tasks would be available for all the users (as if all the users would be impersonated as PowerUser, except the ability to create new users)

7. Support domestically in the USA, Canada, Mexico and internationally.  This option is possible via Web Sessions, Skype or Phone conferences and direct visits onsite (in the case of the large scale project).  Our consulting team speaks English, Chinese, Portuguese, Spanish, Russian, Filipino.  Feel free to call us 1-866-304-3265, 1-269-605-4904, or email help@efaru.com