SOX Compliance Improving Control and Security in Oracle Erp

SOX COMPLIANCE:
IMPROVING CONTROL & SECURITY IN ORACLE ERP
A White Paper prepared by IT Convergence
Authors
The IT Convergence Consulting Services team
Editor
Keith Thomas
Copyright
IT Convergence 2008

SOX COMPLIANCE: IMPROVING CONTROL & SECURITY IN ORACLE ERP
TABLE OF CONTENTS
INTRODUCTION ..........................................................................................................................................................3
OVERVIEW ..................................................................................................................................................................3
SCOPE .........................................................................................................................................................................3
METHODOLGY ............................................................................................................................................................3
STRATEGY ..................................................................................................................................................................4
ADDITIONAL CONSIDERATIONS...............................................................................................................................5
SOX SECURITY PROJECT PHASES .........................................................................................................................5

Requirements Phase.................................................................................................................................................5
Technical Design Phase ...........................................................................................................................................5
Implementation Phase ..............................................................................................................................................7
Testing Phase .........................................................................................................................................................18
Production Deployment Phase ...............................................................................................................................19
Maintenance and Monitoring Phase .......................................................................................................................19
ADDITIONAL GUIDELINES TO ENSURE A SUCCESSFUL SOX SECURITY PROJECT ......................................20
CONCLUSION............................................................................................................................................................20
IT Convergence White Paper 2 / 21

Introduction
Enacted in 2002, the Sarbanes-Oxley Act (SOX) mandated significant changes in corporate governance and financial
practice with the aim of protecting investors by improving the accuracy and reliability of corporate disclosures. While
SOX compliance can be a significant burden for business, with an estimated 15 billion dollars spent on SOX compliance
in 2005 alone, complying with the Acts regulations also gives companies an opportunity to improve access security,
data integrity, and to streamline business processes. This white paper outlines how to leverage an Oracle ERP solution
to take advantage of these opportunities while ensuring SOX compliance.
Overview
The information presented here is based on the experience of recent Sox security projects completed by IT
Convergence. This white paper provides the methodology, strategy, considerations, and work steps necessary to
address SOX security, business control, and data integrity requirements. Also presented are examples of Oracle setups
and configurations that illustrate how to increase overall control and security access in an Oracle ERP environment.
Most businesses can adhere to both industry best practices and SOX regulations by properly exploiting standard Oracle
configurations and security controls.
Scope
The scope of this white paper focuses on following Oracle configurations and security controls:
Menus
Sub-Menus
Functions
Responsibilities
Report Groups
Profile Settings
User Setups
Methodology
The methodology outlined here incorporates both the standard project life cycle phases and the SOX life cycle phases.
This methodology has been outlined to account for each element of the project.
Designing Business and Audit Requirements

Reviewing of Business and Audit Requirements
Identifying essential Oracle Configuration and Setups
Creating SOX security Technical Design
Obtaining Business and Audit signoff on Technical Design
Implementing security in a test environment
Audit Testing and signoff

End-User Testing and signoff

Production Deployment
Maintenance and Monitoring
Strategy
The strategy outlined here details the approach taken to execute each element encompassed by the project
methodology.
The Requirements Phase includes reviewing the internal audit recommendations and business requirements.
The requirements phase covers the following areas:
General Security Definitions
Cross Module Access
Segregation of Duties
Sensitive Data
Recommendations to remedy security conflicts
The Technical Design Phase includes the identification of Oracle setups for the following areas:
Menu Setups
Sub-Menu Setups
Function Setups
Responsibility Setups
System Profile Setups
The Implementation Phase includes implementing the Sox security setups in the test environment according to
technical design
The Testing Phase includes the following steps:

Create Test Scripts
Review Test Scripts with the business team and audit and obtain signoff
Unit Testing
Audit Testing
End-User testing
Remediate Issues until Audit and End-User signoff is obtained.
The Production Deployment Phase includes the following:

Create Loader Script including all setup information
Load setups into Oracle
Validate all setups in Oracle
End-User Validation of functionality
The Monitoring and Maintenance Phase:

Create monitoring scripts to detect any changes in setups
Maintain security setups as changes occur with Oracle users, roles, or responsibilities
Adhere to SOX standards that the business has adopted
Establish a consistent schedule for monitoring scripts

Run monitoring scripts on schedule and report any security breaches

Establish and adhere to a SOX maintenance and approval process
Additional considerations for an effective implementation
Make sure that the end-users are aware of the changes that will be coming with the SOX security upgrade.
Plan for enough time to handle testing and remediation.
Identify and use consistent naming standards for all setups to establish or maintain standards.
Manually enter setups data into the test instance, and once signoff is obtained, use a migration or loader tool to
electronically move setups to the production environment. This further enhances security and adheres to SOX
recommended controls.
SOX security project phases
REQUIREMENTS PHASE
The first phase in this kind of project is the requirements phase and, as the name implies, this is the phase where all
business and the SOX audit team requirements are identified. The SOX security requirements can be identified by
focusing on business security controls, past audit testing, audit recommendations, current end-user functionality, and
current security access. The next step would be to identify security gaps by reviewing the SOX security
recommendations provided by the audit team. These recommendations then need to be compared to data that details
the relationship between current user access profiles and Oracle functionality. The security access requirements need to
include not only what needs to be removed or excluded from certain Oracle responsibilities and roles, but these
requirements also must ensure that the end-users have access to the functionality they need to do their jobs.
The goal is to design a solution that reduces as many security risks as possible. In some cases, however, there may not
be enough end-users to handle all the segregation of duty roles and, in that event, a company may have to hire more
resources or accept some risk to the Oracle Applications security controls. When a company does decide to accept
some level of risk with its security controls, the business is required to write-up a risk justification paper and to provide
this information to the internal and external audit teams as requested.
The last step in the requirements phase is to have a review of the requirements design with the end-users, technical
team, business owners, and the audit team. All should agree to the requirements design with key stakeholders of the
project, and all parties should provide sign-off on the requirements design.
TECHNICAL DESIGN PHASE
Before starting the technical review, the technical SOX team should make sure they have a clear understanding of the
requirements design. The technical design phase will involve research to identify technical solutions to meet the
functional design. The technical solutions for a typical Sox security project should include: Oracle Menu Setups, Sub-

Menu Setups, Function Setups, Responsibility Setups, Reporting Group Setups, System Profile Setups and User
Setups. All setups should also be included in the technical design.
Menu and Sub-Menu Setup allow for addition or exclusion of functionality included in a menu that is associated with a
specific responsibility, which in turn is associated with a specific user. Menu Setups can include Sub-Menus. All menu
and sub-menu functionality is tied to a specific function.
Function Setups allow for access to functionality developed for Oracle. The Function Setup refers to the functionality
related to an Oracle Form, not functionality that is incorporated into a specific form. An example of Oracle Form
functionality is Enter Journal Entries in GL. Enter Journal Entries is form-functionality in Oracle. However, workflow or
functionality available to the form itself, like Post Journal Entry on the Enter Journal Entries form, is not controlled
within the Function Setups screen. Functionality that exists on the form itself can be excluded to a specific Oracle Form
through the setup Responsibility screen.
Report Group Setups allows for a specific report group to be created. The report group is then set up with specific
Oracle or custom reports and processes. The report group is then associated with a responsibility group which dictates
what reports and processes a specific responsibility is allowed to execute. For example, if there is a business
requirement that only an Accounts Payable (AP) Manager can run the AP Trial Balance, then the AP Trial Balance
report would need to be removed from all report groups associated with all AP responsibilities, except for the AP
Manager responsibility.
Responsibility Setups allow for a specific responsibility to be set up and associated with specific menus. Thus, specific
functionality can be associated with specific report groups, and with modified Form functionality access through the
Menu Exclusion, Excluded Items, and Securing Attribute options on the responsibility form.
System Profile Setups are needed when creating new responsibilities. Responsibilities must be associated with a
specific Operating Unit and this setup is done through the System Profile Setup. The profile option is called: MU
Operating Unit. Profile options can be set up at various levels, including: Site Level, Application Level, Responsibility
Level, User Level, Server Level, or Organization Level. In this case, the profile option: MU Operating Unit would be set
up at the Responsibility level.
User Setups are used to set up a specific user who will have access to the Oracle ERP environment. The user must be
assigned certain responsibilities in order to use any Oracle functionality. There is usually a business justification to set
up a user or change a user along with a list of Responsibilities the user should be given access to.

Here is a diagram of the security discussed above:
Function
Menu Sub-Menu
System Profile Responsability Report-Group
User
IMPLEMENTATION PHASE
The screenshots displayed in the next section illustrate how to set up security controls in the Oracle Application
environment. The illustration is based on a typical business scenario of a business that wants to segregate the duties of
its finance department. The specific example that is illustrated here involves creating an AP Processor, who is allowed to
enter invoices, but is not allowed to validate the invoices, which is a requirement for AP payments. The AP Processor
is also not allowed to disburse payments for invoices. The AP Processor is allowed to view suppliers, invoice setups,
and to run and review reports in order to help in the creation and management of invoice entry. Based on this business
scenario, the Oracle security setups are based on the following requirements:
1. Create a role in Oracle for an AP Processor. (See step one on page eight.)
2. The AP Processor should be able to do the following:
a. Create invoices, but not validate, place holds or pay the invoices (See steps two and five on pages
nine and thirteen.)
b. Run reports and view the report output (See step one on page eight.)
c. Reports should include only reports and not processes (See step four on page twelve.)
d. Reports should only pertain to Suppliers and Invoices (See step four on page twelve.)
e. View Distribution Sets and Payment Terms Setups (See steps one, two, and three on pages eight,
nine, and eleven.)

f. View Suppliers (See step one on page eight.)
3. The AP Processor should only be able to see and work with the Vision Operations Operating Unit. (See step
six on page fifteen.)
Step One: Create the Menu, ITC_AP_PROCESSOR_NAVIGATE, and assign the appropriate sub-menus and required
functionality according to the requirements provided.
Instructions for Step One
1. Login as Responsibility: System Administrator
2. Navigate to \Application\Menu
3. Enter the Menu Name using approved naming standards.
4. Enter the User Menu Name, which will be the key field that is used when assigning the Menu to a
Responsibility or to another Menu.
5. Enter the Menu Type. Standard is used when the forms are accessed through the Oracle Navigator.

6. Enter the Sequence number to identify the numerical order in which the menu prompts should be displayed in
the Navigator window.
7. Enter a user-friendly, Menu Prompt name, which will be displayed to the user in the Navigator window.
8. Enter the Sub-Menu name if applicable. Note that the Sub-Menu name must have already been created in the
Menu Form.
9. Enter the Function name if applicable. Note that the Function must have already been created in the Function
Form.
10. Enter a description that best describes the functionality of this menu prompt.
11. Make sure that the Grant box is checked. The Grant box is usually checked as a default.
12. Press Ctrl-S to save your work.
Step Two: Create a Sub-Menu to support the primary Menu. In this case, the functionality includes functionality with
view only access, so the custom Sub-Menu has been created: ITC_AP_INVOICE_SETUP

Instructions for Step Two
1. Login as Responsibility: System Administrator
2. Navigate to \Application\Menu
3. Enter the Menu Name using approved naming standards.
4. Enter the User Menu Name, which will be the key field that is used when assigning the Menu to a
Responsibility or to another Menu.
5. Enter the Menu Type. Standard is used when the forms are accessed through the Oracle Navigator.
6. Enter the Sequence number to identify the numerical order in which the menu prompts should be displayed in
the Navigator window.
7. Enter a user-friendly, Menu Prompt name, which will be displayed to the user in the Navigator window.
8. Enter the Sub-Menu name if applicable. Note that the Sub-Menu name must have already been created in the
Menu Form.
9. Enter the Function name if applicable. Note that the Function must have already been created in the Function
Form.
10. Enter a description that best describes the functionality of this menu prompt.
11. Make sure that the Grant box is checked. The Grant box is usually checked as a default.

Step Three: Create a function that allows for View-Only access for the distribution and payment terms forms. The
functions below were created by copying the original functions and renaming them to a custom function name. This way
the custom functions adopt all characteristics of the original function except that the custom functions will be updated
with the parameter Query Only. The functions that were copied were: Maintain Distribution Sets and Define Payment
Terms. View-Only access is obtained by updating the parameters to include: QUERY_ONLY=YES
Instructions for Step Three
1. Login to Responsibility: System Administrator
2. Navigate to: \Application\Function
3. Copy the standard Form Maintain Distribution Sets to a new row.
4. Update the Function name to a custom name using approved naming standards.
5. Dont change the Form Name Maintain Distribution Sets. The custom form needs to use the Oracle
Standard Form.
6. Dont change the Application Payables.
7. Update the parameters to include, QUERY_ONLY=YES. This parameter makes the form, View-Only.

8. Leave all other setups for this form untouched.
10. Repeat the same steps to set up the custom form: Define Payment Terms.
Step Four: Create a report request for the AP Processor user and assign only Supplier and Invoice related reports. The
actual list of reports should be signed-off by the project business owner.
Instructions for Step Four
2. Navigate to: \Security\Responsibility\Request
3. Enter the name of the Request Group. Use approved naming standards. This is the name that will be used to
tie this report group to a responsibility.
4. Enter Application name: Payables.

5. Leave the Request Group Code blank, as this is used as a parameter that identifies to the requests that a
customized standard submission form can be selected.
6. Enter a description that best describes this request group.
7. Enter Program as the Type of Request. Program is used when reports and processes are being added to
the request group.
8. Enter the Name of the Request. The requested program must have already been created and set up in
Oracle. Programs are entered through the \Concurrent\Program\Define and Executable forms.
9. The application name of Payables is defaulted and does not need to be changed.
10. Press Crtl-S to save your work.
Step Five: Create the AP Processor Responsibility: ITC US AP PROCESSOR. Assign to ITC US AP PROCESSOR the
menu: ITC_AP_PROCESSOR_NAVIGATE. This controls the functionality this responsibility will have. Assign ITC US AP
PROCESSOR to the report group: ITC US AP PROCESSOR REPORTS. This will control what reports the responsibility
will have access to. Remove the users ability to validate, pay or place holds on invoices from the invoice screen using
Menu Exclusions.

Instructions for Step Five
2. Navigate to \Responsibility\Define
3. Enter a Responsibility name using approved naming standards. This is the name that will be assigned to a
user in the user define form, and will be displayed to the user as a Responsibility.
4. Enter a unique Responsibility Key name. The Responsibility Key name will be used by Oracle loader
programs.
5. Application should be set to Payables.
6. Enter where the Responsibility Forms will be available. In this case the Forms will be available from Oracle
Applications.
7. Enter Standard for the Data Group name. The Data Group identifies the grouping of the Oracle Application
and the Oracle User Name.
8. Enter Payables for the Data Group Application.
9. Enter the Menu that this Responsibility will use. The Menu was created in Step 1 of this illustration. The Menu
dictates what functionality is available to this Responsibility.
10. Enter the Request Group for this Responsibility. The Request Group was created in Step 4 of this illustration.
11. Enter Payables for the Request Group Application.
12. Move cursor to the Menu Exclusions zone.
13. Enter Function in the Type field. This identifies what functionality will be excluded from a form for this
Responsibility.
14. Enter Invoice Actions for the Menu Name. This will prevent the responsibility from having access to the
Actions pop-up window on the Invoice form.

Step Six: Setup Profile Settings to ensure the new responsibility: ITC US AP PROCESSOR can access the appropriate
organization. This setup includes setting the MU Operating Unit to the appropriate operating unit, in this case: Vision
Operations. The Operating Unit setup needs to be assigned at the Responsibility level so that this only affects the ITC
US AP PROCESSOR.
Instructions for Step Six
2. Navigate to: \Profile\System
3. Under Display check the Responsibility check-box.
4. Enter the Responsibility, ITC US AP PROCESSOR for the responsibility name.
5. Enter the profile option: MO:% to see the Multi-Org profile settings.
6. Enter Vision Operations under the heading of Responsibility for the profile option, MO: Operating Unit.

Update the User to include the new responsibility, ITC US AP PROCESSOR. Disable any responsibilities that the user
should not have. In this case, MMOUSE is a new user and ITC US AP PROCESSOR is the only responsibility to be
assigned to this user.
Instructions for updating user responsibilities
2. Navigate to: \Security\User\Define
3. Enter the appropriate User Name, using consistent naming standards.
4. Enter a password once, and then the form will prompt you to enter the password a second time to verify the
password.
5. Enter an appropriate description of the user. System Administrators frequently spell the user name out
completely as a reference.
6. Check Day for the Password Expiration rule. Best practices for SOX compliance controls recommend having
the password for a user expire every 60 to 90 days.
7. Move cursor to the Responsibility zone.

8. Enter the Responsibility name for the user. This dictates what Responsibility the user has access to when the
user logs into Oracle. Note: The user can have more than one Responsibility assigned.
9. Enter the application name, Payables.
10. The security group type is defaulted as Standard and should not be changed.
11. The Oracle System Date is defaulted to the Starting Effective Date, but can be changed as appropriate.
The screen below shows the responsibility, ITC US AP PROCESSOR, and the functionality or Menu items available to
this responsibility.

The screen below demonstrates how the functionality Actions has been removed from the responsibility: ITC US AP
PROCESSOR. Note on the screen below, there is not an Actions Button, so the AP Processor cannot pay invoices,
place holds or validate invoices.
TESTING PHASE
The testing phase should include technical validation testing, audit testing, and end-user testing. The testing phase
should include an approved testing plan that can be used by all team members. Technical testing should ensure two
equally important goals have been fulfilled. First, technical testing should verify that the technical design and
implementation meet the intended goals of the business and audit team. Second, this testing should also verify that
users are still able to complete necessary business processes in Oracle. The test plans should test every responsibility
that has been created or updated and ensure all the functionalities that correspond to these responsibilities are correct.
The end-users should test all assigned responsibilities and functionality as thoroughly as possible.
It is imperative that project SOX security plans include ample time for testing. This is because resolution of problematic
issues will require approval from both business stakeholders and the audit team. These changes will need to be
redeveloped, and the solution will be retested. Finally, project planners must take into account the fact that this entire
process might need to be repeated several times. Technical testing is considered to be successful once the business
owners, the audit team, and end-users have all signed-off on all SOX security setups.

PRODUCTION DEPLOYMENT PHASE
Once testing has concluded and all stakeholders have signed-off on the Sox security setups, the setups can be
deployed into the production environment. A good control is to move the SOX setups from the test environment into the
production environment using an electronic tool, like FND Loader or Generic Loader, so that there is no manual entry of
the SOX setups in the production environment. Manual entry of setups into the production environment should be
avoided. This method is quite similar to the method used to move source code into production and it is in line with
industry best practices as well as SOX controls. This control is also in line with the segregation of duties, in which source
code is moved into a test environment, tested and then, once end-user approval is granted, a person other than the
developer, such as the source control administrator, moves the source code into the production environment. Ultimately,
developers and support analysts should not have update access in the production environment. Once the SOX setups
have been moved into the production environment, validation of the setups should occur by the end-users. The process
of remediation, testing, production deployment, and validation should be repeated until all SOX setups have been moved
into the production environment successfully.
MAINTENANCE AND MONITORING PHASE
Once all SOX setups have been deployed into production, ongoing monitoring of Oracle security and maintenance is
needed on a regular basis to keep Oracle security SOX compliant. SOX auditors usually require frequent monitoring,
and this frequency varies according to circumstance but can be required on a monthly or even a daily basis. In an effort
to stay current on SOX compliance reporting, internal audit teams usually require quarterly SOX compliance reports to
ensure monitoring and maintenance is working effectively.
Usually, the UNIX administrator and DBAs monitor direct server and UNIX level access and direct database access. The
Oracle App System Administrator should monitor all application security access. There are standard Oracle reports that
can be run to monitor application security access and controls, such as: the Active Responsibility Report, the Active
User Report, the Sign-on User Report and other security reports as well. The Oracle System Administration Security
manual has a listing of all Oracle Security Reports.
Other methods of monitoring include writing custom SQL queries to monitor secured tables to document who has made
essential changes on the table and when those changes were made. Also, setting-up alerts to notify the appropriate
people when a security breach has occurred is a very effective monitoring measure.
Maintenance policies should include a process in which any Oracle Application security changes are documented and
approved by the business stakeholders. These changes will include any security changes that become necessary as
users access needs change, new users are added to the Oracle Application system, or users are disabled in the Oracle
Application.

Additional guidelines to ensure a successful SOX security project
Based on previous experience gained from completing Sox security projects, here are some additional issues to keep in
mind.
All standard Oracle responsibilities should be end dated as they have inherent Segregation of Duty conflict.
Oracle Applications functionality changes between versions. Therefore, it is important to consider how this fact
will impact on a decision to use or not to use standard Oracle menus and responsibilities.
Project implementers must develop and enforce uniform naming conventions for custom Oracle
responsibilities, menus, and report groups, as this enforces and strengthens security through consistency and
ease of maintenance.
A Security Steering Group should be established to monitor additions or changes to any Oracle or custom
responsibility, menu, report group, user definition, or profile setting.
Analysts and developers should only have VIEW access to the Oracle ERP Production instance.
Eliminate all setup menu access for custom responsibilities in the Oracle production instance and limit setup
menu access in the Oracle test instance. This enhances security controls, and forces developers and other
setup administrators to follow a proper change control process.
End date all generic user names as they hide any audit trail.
Use alerts to notify appropriate individuals when a security breach has occurred.
Conclusion
While SOX has increased the demand for overall security, which of course is good for the business, it has also brought
the demand for documentation and education on SOX requirements. Many SOX auditors require documentation that
shows the following:
1. How is security being handled for Oracle Applications?
2. What processes have been put in place to implement Sox security?
3. Instructions on how to implement security, how to monitor security, and how to maintain security.
4. Examples of monitoring reports over time, mainly to see that monitoring and maintenance are being done on
a regular basis.
In addition to the required documentation, auditors also like real-time, on-line walkthroughs of security audit trails. A
thorough SOX security solution should provide documentation that adequately addresses each of these issues, and key
stakeholders should be prepared to offer SOX auditors these types of on-line walkthroughs. As this demonstrates, an

effective SOX compliance project does not end when Oracle ERP applications are configured to comply with SOX
regulations. End-users, stakeholders, and decision makers will all require education on SOX controls, SOX Audit
readiness, and documentation standards. 1 Therefore, end-user education should be considered as a fundamental part
of any SOX compliance solution.
While SOX standards may have increased the level of work required for some companies to meet new security and
controls required by SOX, they also benefit companies by building integrity, enhancing relationships with stockholders,
partners, customers, and suppliers. In addition, an effective SOX security solution will help companies avoid SOX fines
and penalties, improve efficiency of business operations, and keep policies, documentation, security settings and
controls current. This paper has outlined several of the key steps an organization must take to implement an effective
Sox security solution that will help your company achieve these goals.
Obviously there are a host of SOX compliance-related considerations that go beyond the scope of what has been
discussed here. Individuals or organizations that need additional information, assistance, or education relating to SOX
compliance are welcome to contact IT Convergence at 1-800-675-0032 or 1-415-675-7935.
IT Convergence White Paper: IT Convergence World Worldwide Inquiries: www.itconvergence.com

SOX Compliance: Improving Control Headquarters: Tel: 1 (415) 675-7935 Copyright 2008
& Security in Oracle ERP 450 Sansome Street, 13th Floor, Fax: 1 (415) 675-7940 IT Convergence.
February, 2006 San Francisco, CA 94111, USA All rights reserved.
1
Oracle Tutor is an excellent tool that companies can use to strengthen their SOX compliance documentation. For more
information, please see the white paper Oracles Documentation Solution: Oracle Tutor.

SOX Compliance Improving Control and Security in Oracle Erp

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SOX Compliance Improving Control and Security in Oracle Erp

Caricato da

Copyright:

Formati disponibili

SOX COMPLIANCE:

IMPROVING CONTROL & SECURITY IN ORACLE ERP

A White Paper prepared by IT Convergence

SOX SECURITY PROJECT PHASES .........................................................................................................................5

ADDITIONAL GUIDELINES TO ENSURE A SUCCESSFUL SOX SECURITY PROJECT ......................................20

IT Convergence White Paper 2 / 21

Designing Business and Audit Requirements

IT Convergence White Paper 3 / 21

End-User Testing and signoff

The Testing Phase includes the following steps:

The Production Deployment Phase includes the following:

The Monitoring and Maintenance Phase:

IT Convergence White Paper 4 / 21

Run monitoring scripts on schedule and report any security breaches

Additional considerations for an effective implementation

SOX security project phases

TECHNICAL DESIGN PHASE

IT Convergence White Paper 5 / 21

IT Convergence White Paper 6 / 21

Here is a diagram of the security discussed above:

System Profile Responsability Report-Group

2. The AP Processor should be able to do the following:

IT Convergence White Paper 7 / 21

f. View Suppliers (See step one on page eight.)

Instructions for Step One

1. Login as Responsibility: System Administrator

3. Enter the Menu Name using approved naming standards.

IT Convergence White Paper 8 / 21

12. Press Ctrl-S to save your work.

IT Convergence White Paper 9 / 21

Instructions for Step Two

1. Login as Responsibility: System Administrator

3. Enter the Menu Name using approved naming standards.

12. Press Ctrl-S to save your work.

IT Convergence White Paper 10 / 21

Instructions for Step Three

1. Login to Responsibility: System Administrator

2. Navigate to: \Application\Function

3. Copy the standard Form Maintain Distribution Sets to a new row.

6. Dont change the Application Payables.

IT Convergence White Paper 11 / 21

8. Leave all other setups for this form untouched.

9. Press Ctrl-S to save your work.

Instructions for Step Four

1. Login to Responsibility: System Administrator

2. Navigate to: \Security\Responsibility\Request

4. Enter Application name: Payables.

IT Convergence White Paper 12 / 21

6. Enter a description that best describes this request group.

10. Press Crtl-S to save your work.

IT Convergence White Paper 13 / 21

Instructions for Step Five

1. Login to Responsibility: System Administrator

5. Application should be set to Payables.

8. Enter Payables for the Data Group Application.

11. Enter Payables for the Request Group Application.

12. Move cursor to the Menu Exclusions zone.

15. Press Ctrl-S to save your work.

IT Convergence White Paper 14 / 21

Instructions for Step Six

1. Login to Responsibility: System Administrator

2. Navigate to: \Profile\System

3. Under Display check the Responsibility check-box.

4. Enter the Responsibility, ITC US AP PROCESSOR for the responsibility name.