Access issues when including a new subsidiary

Access issues when including a new subsidiary

We are bringing a new subsidiary onto an existing SAP system. At this point, we believe that we will have one company code for each legal entity all pointing to a single controlling area. This being the case, our financial users are concerned with how we can restrict access per site; there will be multiple sites in each company code. The sites will be able to be broken out using the profit center hierarchy (one node for each site with multiple profit centers assigned). One argument that has been posed is to define each site as a company code because you can restrict access at the company code level. I believe there must be other alternatives.

    Requires Free Membership to View

    Login

    When you register, you will start receiving targeted emails from my award-winning team of editorial writers. Our goal is to keep you informed on the hottest topics and biggest challenges faced by SAP professionals today.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSAP.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSAP.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

There really aren't many options here. A best practice will be to use the company code to represent true legal entities, any decision to have multiple company codes with in the same country or fiscal company should be based on finacial reporting rules; not security objectives. Your options are limited here to using business areas as a rollup for financial security; although many companies prefer not to configure and maintain this type of master data (so it is a little unorthodox). The real answer is that you need to have effective job segregation at the functional level with appropriate security for well trained users; so you don't have to use security as a cultural control. The point of having an ERP is to provide greater visibility to business information to the users that need it for business decisions. (my high-horse statement) It is your job as the security administrator/leader to educate your process and business owners on the options available to them and attempt (as best you can) to steer them in the right direction from a security-risk perspective. In the info you have give me the risk appears to be that: 1) users will see corporate data, 2) users will mistakingly post data to the wrong company code (training issue) 3) you could have SOD issues at some of the smaller sites. All of these risks are functional and probably do not outweigh the cost and related business beaurocracy of implementing a company code for each physical site (unless their in different countries).

I once consulted at a company that created 20+ company codes for their Canadian operations, so they could segregate specifically what GL data could be viewed by specific users. This decision created significant problems for inter company posting, and created needless beaurocracy for their accounting organization to reconcile accounts (due to the significant security controls). Ultimately, they minimized their legal entities to a couple after a few mergers.

This was first published in June 2003