Subsystem Functional Security

General Ledger

From the General Ledger object "tree" on the Manage Security Roles plugin, a number of process switches can be set for Budgeting, FTE Budgeting, and Journal Entry Functions.

Budgeting

Budget Date Override: The Execute object check box is the only attribute that is validated. With this box checked, the operator has the authority to override the Budget Date.
Budget Transfer Limit: The budget transfer limit is set from the screen display seen below. This screen is used to set the Ledger, Part/Group, and Message for one or a number of ledger and Part/Group combinations.

• Enter the Ledger to be validated.
• Enter the Part/Group to be validated.
• Select the level of action indicator from the pull down.
• When the proper information has been entered, click the Save Changes icon to save the current filter record.

FTE Budgeting

Amount Override: The Execute object check box is the only attribute that is validated. With this box checked, the operator has the authority to override the Amount.
FTE Override: The Execute object check box is the only attribute that is validated. With this box checked, the operator has the authority to override the FTE.

Journal Entry Functions

Batch Proof Budget Suppress: The Execute object check box is the only attribute that is validated. With this box checked, the operator has the authority to suppress the batch proof budget checking.
Data Entry Budget Override: The Execute object check box is the only attribute that is validated. With this box checked, the operator has the authority to override the budget checking on the journal entry page.

Purchasing

Security settings for Purchasing is handled in four areas:

1. Purchasing (PO) Security Codes (POUPSC)
2. Manage Security Roles
3. Manage Users
4. Workflow

Security Codes

The Purchasing (PO) Security Codes (POUPSC) page is used to define security codes used by the Purchasing subsystem and enforced through security definitions for role, user, or vendor identities.

If security codes are defined, a Workflow model can be designed that will automatically create the required approvals for each invoice. The codes are used to enforce approvals and restrict access to records. They may or may not be used in the approval routing process. In 7.9, the GL account background parts are what typically drive approvals.

For example, if the POUPPR page does not have a security code entered, approvals are not required in order to print the PO. If there is a security code on the record, then it will not print until an approval code of APRV is on the record. The GL account number (background part of Key or Object code), the PO or item total, and PE ID are commonly used to determine approval routing. User security roles identify which PR/POs a user can see based on which PO security codes they are given access to in the Common Security for PO in their role.

Security Code: Enter a code of up to four characters. These codes will appear in the drop-down list on purchasing data entry pages that contain a Security Code field.
Description: Enter up to 30 characters that describe the security code.

Manage Security Roles

Security settings for Purchasing can be defined in Common Security Settings and Purchasing.

Common Security

For any given role, access can be restricted in the Common Security Settings for Purchase Order Numbers and Purchasing Security Codes that are referenced/linked throughout the Purchasing subsystem.

Special consideration should be given to creating Where clauses. It may be necessary to include checks for blank or null values depending on the columns being interrogated in the Where clause.

Applying Where clauses to any of the attributes will restrict access to those attributes based on the Where clause. Whenever a column that is referenced in the pop_pv_dtl or the pos_sec_mstr Where clause is being read, the Where clause will apply.

A variety of combinations of security can be developed based on Where clauses written for the POP_PV_DTL and the POS_SEC_MSTR. Within each of the tables listed above, access can be granted for any combination of Read, Write, Update, Delete, and Execute.

The most common uses of Where clauses would be to limit access based on security code, being able to read and/or write information containing a given security code(s) and restricting access to a specific purchase order(s) by PO number.

Click the Pencil icon to access the Edit Where Clause window.

Purchasing Security

Purchasing Functions

Note the POI_ITEM_DTL has a value of Filtered and a check in the Read column. This setting will allow a read of the POI_ITEM_DTL table if the value of the Where clause is satisfied.

Note the POI_ITEM_DTL has a value of Filtered and a check in the Delete column. This setting will allow a deletion of a POI_ITEM_DTL table record if the value of the Where clause is satisfied.

PO – Purchasing Menu

Note that if the Execute box for "PO – Print Purchase Orders" is not checked, the mask POPO will not be available to users assigned this role.

Manage Users

The NU Manage Users plugin can be used to set default PO security codes for users. When "Workflow Enable" is set to Y, the user is allowed to approve PRs in Workflow.

Workflow

Workflow handles the approval process for Purchasing. An example Workflow model name is PR_APRV. The model can be configured to narrow down the number of users that can approve PRs. Users that have Workflow Enable set in their security record in NU Manage Users can be integrated into the Workflow approval process.