Updating the organizational units in a workflow under SOX compliance

Updating the organizational units in a workflow under SOX compliance

My company has implemented HR and we want to start using workflow and the organizational units that we have already defined. The problem is that the organizational units that are in our development environment have no relation to either our test or production environments, since the organization units are created/changed by the user in either environment.

How do I create a workflow in the development environment to use organizational units as the delivery device, and then send the workflow on to the test and production environments, without having to open the system for maintenance? Since these are SOX systems, opening up the data is a big headache.

    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.

You should definitely not be opening up any test/production system in order to update the organizational units in your workflow. What is normal practice is to put in the org units into your workflow (as you have been doing) and then transport the org units through to test/production along with your workflow. You can use transaction RE_RHMOVE30 to attach your org objects to a transport and send them through.

Your situation is a little different, as your users are the ones who are creating/changing the org units in production. If this can be avoided, then I would do so, but if this is an absolute requirement then you should change your workflows to call a responsibility rule in order to determine your agents. Then, once this is done, log into your production (or test) system and go to transaction OOCU_RESP. This will allow you to assign the org units to the responsibility for your workflow.

You should ensure that this does not in any way constitute a SOX compliance infringement.

This was first published in July 2005