Managing access to Oracle Financials - Maintaining access

Reviewing access

Departments should regularly (at least quarterly) review the user access reports to ensure that staff have access and are assigned responsibilities in Oracle Financials appropriate for their role. 

To obtain a full picture of access, there are five reports available. These are brought together in the User Access Dashboard. This should be run and reviewed at least quarterly – it can be run more regularly and this is good practice for departments with frequent access changes. It is recommended that evidence of review is retained e.g. in the comments box.

To aid review you can request an up to date schematic drawing of your purchasing hierarchy and/or general ledger (GL) approval hierarchy from FSSC.

Note: the team have to put these diagrams together manually so please do allow sufficient time when requesting them.

When reviewing access authorised signatories for Oracle access should consider whether:

• the responsibilities held are all necessary for the user’s job
• the purchasing approval limit (if any) is appropriate to the user’s job and the department’s budget
• potential breaches of segregation of duties can be reduced or eliminated
• higher risk access (e.g. Buyer Work Centre and Payables) is limited to only those staff who specifically need it and cannot use alternative read only access
• the journal approval limits and supervisors (GL) are appropriate
• staff who have left the University or the department do not appear on the department’s report
• the department’s delegation of authority register is up to date

Please refer to the Working with the User Access Dashboard document for more information.

Key issues that can impact workflow

Authorised signatories for Oracle access should also be aware of key issues that can have a major impact on workflow, such as:

• General ledger (GL) supervisors (approves other users’ journals) – ensure all GL users have a supervisor and that supervisor is in post; gaps in the GL hierarchy (missing GL supervisors) can lead to journals getting stuck;
• Project requisition approvers (approves other users’ requisitions when coded to projects) – ensure there are users in the delegated approval positions in the PO hierarchy; delegations to empty hierarchy positions will not flow through the PO hierarchy as normal leading to orders getting stuck;
• Radiation protection supervisors (a role that exists in some departments for monitoring purposes, where a nominated person is notified when hazardous items are purchased)

The Guide to the Position Hierarchy may help in determining whether users are in the correct position in the purchasing hierarchy.

Making changes to access

If any changes to access are required, either following this review or due to changes in a user’s role, then the online service request for Oracle R12 Department User Access, or Central User Access should be completed, authorised by the department’s authorised signatory and submitted to the FSSC.

1. Increasing access

Where additional access is being requested on a change in role the same principles and process as for New Users applies. In addition the user's current access should be reviewed via the User Access Dashboard or by running the UO User Access (New) report, in order to review whether any other adjustments are required to keep access to the minimum required for their role.

Please note it is easy to overlook a change in role – changes to access may be needed to ensure it remains the minimum required.

2. Decreasing access - See Removing access

3. Mass changes to access

If you need to make changes to a number of users' access in one go and these changes only affect their:

• Approval limits
• Position in the purchasing (PO) hierarchy
• Reduce the users' access only

You can email details of the changes to be made along with authorised signatory for Oracle access approval to the FSM team to be processed.

Where changes relate to new responsibilities or changing the type of access (e.g. general ledger enquiry to general ledger sal) then separate online access requests will be required for each user.

Making temporary changes to your own access - Vacation rules

Vacation rules can be set via the vacation rules link on the main Oracle screen under Worklist.

It is recommended that you delegate upwards, however if you set the rules yourself, you can delegate to colleagues who normally have a lower limit. For example, an Head of Administration and Finance (HAF) may delegate to their finance manager, noting that you are delegating your higher limit to them. 

You can send all approval notifications to one person or set separate rules for specific types of approval notifications to be sent to different colleagues to ensure the most appropriate person covers different tasks. For example, you can set one rule for "Requisition Approval" and a separate rule for "Journal Batch".