Pricing Security

This chapter covers the following topics:

Overview of Oracle Pricing Security

In Oracle Applications, a basic level of security called functional security is used to manage users' access to each application and control their access to windows, functions, and reports within an application.

Typically, the system administrator administers functional security and assigns operating unit, responsibility, and system access to users. See the Oracle E-Business Suite System Administrator's Guide - Security for more information about functional security.

In addition to the existing functional security, Oracle Advanced Pricing provides an additional level of security called pricing security. Pricing security enables you to restrict pricing activities such as updating and viewing pricing entities to users who are granted specific access privileges. Pricing entities include price lists, pricing agreements, and modifiers.

Pricing security can be set up and maintained in the HTML user interface by a user who is assigned the Oracle Pricing Administrator responsibility. The Oracle Pricing Administrator has the authorization to access and update all pricing entities for all functional users. With pricing security, you can implement a higher level of control by:

Warning: Before turning on pricing security, you must create privileges for existing pricing entities.

Advanced Pricing Responsibilities

A responsibility defines a level of authority in an application. Each responsibility lets you access a specific set of Oracle Applications windows, menus, reports, and data to fulfill your role in an organization. Several users can share the same responsibility, and a single user can have multiple responsibilities.

You can assign users the following seeded responsibilities to enable access to pricing windows, menus, reports, and data:

Pricing Security Terms

The following terms are used in Oracle pricing security:

Pricing Security and Operating Units

Pricing Security allows you to create pricing data that is specific to an operating unit. The multi-organization access control (MOAC) feature further enables users to access multiple operating units within one responsibility, and to create multiple pricing entities (price lists, modifiers) for different operating units without changing responsibility. This feature is controlled by the profile option MO: Security Profile. When MOAC is enabled, you can enable pricing security to provide centralized control of pricing entities for use by operating unit or across all operating units for pricing orders. Pricing security is still used to assign access roles at Global, Organization, Responsibility, or User levels with roles of View Only or Maintain. However, when MOAC is enabled, you should review the following changes in pricing security action:

Note: See the Oracle Applications Multiple Organizations Implementation Guide for information about setting the profiles MO: Security Profile and MO: Default Operating Unit.

Multi-Organization Access Control

Profile option MO: Default Operating Unit automatically creates pricing security privileges

When you create a price list or modifier list, the default pricing security privileges are created for the operating unit that is set in the MO: Default Operating Unit regardless of whether the price list or modifier list is created as Global or for a different operating unit. This occurs when:

For example, suppose you are assigned the Pricing Manager responsibility with access to the following operating units - OU1, OU2, and OU3 - and the following conditions exist:

If you then create a global price list (PL1) or price list for OU2 (PL2), the view and maintain privileges will be created for OU1 because the operating unit defaults from the MO: Default Operating Unit profile (the default operating unit that is set for the responsibility) for both PL1 and PL2.

Update to Operating Unit field allowed if users have Maintain access

In Oracle Advanced Pricing, the operating unit on the price list or modifier list must match the operating unit of the transaction (for example, a sales order) that is being priced. If pricing security is ON, any user who is granted maintain access to the price list or modifier list can update the Operating Unit field of the modifier or price list.

For example, suppose you have a price list PL1 from operating unit OU1 that is assigned a maintain privilege of Global, but you log into a responsibility with access to only OU2, OU3 as assigned by the MO: Security Profile. You could update the price list PL1 due to Global security privilege and update it from OU1 to OU2; however, you cannot change it back to OU1 through the same responsibility because the security profile does not provide access to OU1.

Setup Steps for Implementing Pricing Security

After you upgrade to pricing security, pricing security is not switched on automatically. Pricing users with functional access can still fully view and maintain existing price lists and modifiers as before the upgrade.

Before turning security on, you should review and complete the following setup steps for implementing pricing security, otherwise, pricing users may be unable to query any price lists or modifiers in the pricing windows. After you have completed the security setup steps, you can run the concurrent program QP: Security Control with Views Conversion to turn on pricing security.

Note: The profile option QP: Security Control (read-only) displays the current setting of the security option for your entire installation (either on or off).

You must be assigned the Oracle Pricing Administrator responsibility to set up and maintain the pricing security features for all functional pricing users.

Step 1: Map security access requirements

Identify and map all price lists, modifiers, and agreement price lists to:

Step 2: Assign ownership of pricing entities (Entity Usage page)

The next step is to assign preexisting price lists and modifiers to an operating unit. Use Global Usage settings to restrict the entity to a specific operating unit or make it available across all operating units.

Step 3: Create privileges (Privileges page)

The next step is to create access privileges for all users in all operating units. You can assign view or maintain access to a pricing entity.

Optionally, you may want to create entity sets that enable you to group multiple entities of the same entity type, and then grant access to the entity set. For example, you may want to create a set called Summer Set that contains all active modifiers with Summer Promotion in the modifier name. Then you can assign privileges to the entity set rather than to each entity separately.

Note: You must have a license for Advanced Pricing to use entity sets.

Step 4: Set security profile options

Use the following security profile options to set the default security privileges for pricing entities that are newly-created:

These profile options are delivered in default settings that maintain the existing functional security features of Oracle Pricing. Before you can change these profile settings, the Oracle Pricing Administrator must map the complete security access requirements for each pricing entity. No security profile option should be changed until these steps have been completed.

Step 5: Turn on pricing security

To activate pricing security, set the concurrent program QP: Security Control with Views Conversion to ON. This is the "switch" that turns security on or off for your installation. Before setting the program to ON, ensure you have completed all the preceding implementation steps.

Related Topics

Assigning Pricing Entity Usage (Entity Usage page)

Creating Pricing Entity Sets

Creating Privileges

Setting Security Profile Options

Changes to Pricing User Interfaces (UI) after Upgrading and Turning On Security

This section summarizes the changes that occur to pricing entities after you upgrade to pricing security and turn on security. Some of the changes, such as the new Global check box on price lists and modifiers, are visible only to users after pricing security is turned on.

Entity Usage

After the upgrade to security, all existing price lists and modifiers are assigned the default entity usage of Global Usage. Global usage enables the pricing entity to be used across all operating units. When security is turned on, a Global box is added to the header of all modifiers and price lists to indicate the global usage status for the entity. If the Global check box is:

The Global check box is not visible to users until the concurrent program Security Control is turned ON. When the check box is visible, a user with Maintain access privileges can select or clear the Global check box. However, users with view-only privileges cannot change the Global check box. If a user creates a new pricing entity (such as a price list) and clears the Global check box, then an operating unit must be assigned to that entity. If MOAC is not enabled, the operating unit defaults to the value of the profile MO: Operating Unit.

With MOAC, this operating unit will default to the value in the MO: Default Operating Unit profile. You can override this default and select from any operating unit that is assigned to the MO: Security Profile option. If the Global check box is left selected (the default value), then the entity can be used across all operating units when transactions are priced.

Alternatively, the Pricing Administrator can also update the Global check box for one entity at a time or in bulk using the Bulk Update Entity Usage page, which is available from the Entity Usage page.

Changes to Price Lists

After the upgrade, you can review the operating unit and global usage settings for an entity on the Entity Usage page. An example of the information that appears for a selected entity is outlined in the following table:

Entity Name Type Global Usage Owned by Operating Unit
Name of the entity (for example, Summer Pricelist) Type of entity (for example, Standard Pricelist) Yes Blank (not assigned to an operating unit)

The following price list changes occur after the upgrade to pricing security:

Changes to Modifier windows

The following modifier changes occur after the upgrade to pricing security:

Changes to Calling Applications

All calling applications that display a list of values for price lists can use the pricing view QP_PRICELISTS_LOV_V to display the valid global and operating unit (OU) price lists that are specific to their transaction. This view displays the either the global price lists and price lists that are specific to the OU on the transaction or all price lists depending on whether the pricing security feature is turned ON or OFF.

Changes to Other Pricing windows

The following table outlines the impact of pricing security and security privileges on various windows in Advanced Pricing:

For the following: Security Privileges are enforced:
Copy Price Lists Yes. You need at least view-only access.
Copy Modifier Yes. You need at least view-only access.
Modifier Incompatibility setup Yes, can be updated if you have maintain access.
Pricing Organizer Yes. You can view and access the modifier if it appears.
Pricing Mass Maintenance Yes. You need maintain access.
Adjust Price List Yes. You need maintain access.
Add Items to Price Lists Yes. You need maintain access.
Multi-currency conversion No security at present.
Formulas No security at present.
Agreement Header Agreement inherits security rules of attached price list.
Price List report Yes. You must have at least view-only access.
Modifier Detail report Yes. You must have at least view-only access.
Archive and Purge Yes, you must have maintain access.

Assigning Pricing Entity Usage

By default, a new price list or modifier is assigned Global usage. If the Global check box is deselected for a pricing entity such as a modifier, the Operating Unit field is enabled. The operating unit defaults from the profile option MO: Default Operating Unit if MOAC is enabled. If MOAC is not enabled, the value defaults from the profile option MO: Operating Unit.

This operating unit field value appears in the Owned by Operating Unit field on Pricing Entity Usage user interfaces. A pricing entity that is assigned to an operating unit can be used only for that operating unit and not across all your operating units. However, pre-existing price lists and modifiers are not assigned a default operating unit, so you can use the entity usage feature to:

When assigning pricing entity usage to a pricing entity such as a price list or modifier, you should consider the following:

Warning: The Oracle Pricing Administrator should assign ownership to all price lists and modifiers prior to upgrading or implementing Oracle Pricing Security. This can also be done using the Bulk Update Entity Usage feature on the Entity Usage page.

To assign pricing entity usage

On the Entity Usage page, search for the entities and assign the following entity usage values:

Note: For fresh upgrades or new installations, the Global Usage check box is Yes (selected) and the Owned by Operating Unit field is blank.

To make bulk changes to multiple pricing entities, click Bulk Update Entity Usage.

To use bulk update entity usage

Use the Bulk Update Entity Usage page to quickly apply settings for global usage and operating unit assignment across multiple pricing entities; for example, to assign the same operating unit across all price lists.

From the Entity Usage page, find the pricing entities to be updated. Alternatively, to select all pricing entities on a page, click Select All. If additional entities are listed on subsequent pages, click the Next link, and then click Select All. Repeat this process until all the entities to be updated are selected. Click Bulk Entity Usage to update the following settings:

Notes

Implementation Suggestions for Privileges

Complete the following planning and implementation steps before turning on pricing security. This mapping should be completed by someone with complete knowledge about the following: the pricing users and their operating units; all price lists; modifier lists; and any specific business requirements for granting access to any of the many pricing entities.

  1. Identify and list all users with functional access to Advanced Pricing menu.

    Identify all responsibilities within your installation that have functional access to the Oracle pricing menus. This helps to determine whether a pricing entity can be granted access by users with these responsibilities. When an access privilege is granted by responsibility, then all users with this responsibility will have this privilege.

    Add to the listing of all responsibilities with access to pricing menus, all individual users, by name. Some users may not require Maintain privileges to any pricing entities, but may actually require view-only access. These users should be identified and associated with the pricing entities to which they require view access.

    This mapping assists in granting an access privilege to a specific user. A user may have access privileges by virtue of their responsibility. If the user, whose responsibility has been granted an access privilege of ViewOnly to a pricing entity, needs to have Maintain access, a privilege may be granted to the user for Maintain that is a higher privilege than that granted to his or her Responsibility.

  2. List all users by new access privileges.

    A listing of all users and their access privileges should be maintained by the Pricing Administrator. Once mapping has been completed and access privileges granted, you can query the privileges that are granted in a variety of ways using the Privileges page of the Security pages. A search by entity type such as Standard Price List displays all standard price lists by entity name, grantee type, grantee name, access level (ViewOnly or Maintain), and effective dates. Your listing of new access privileges can be checked against the results.

Creating Privileges

Security privileges enable you to define who can access each pricing entity and the level of access that is permitted: View Only or Maintain. You can grant the following access privileges:

Note: You must be assigned the Oracle Pricing Administrator responsibility to grant privileges.

You can assign privileges using the following pages:

To assign default security privileges for newly-created pricing entities, see Setting Default Security Profile Options.

Precedence Levels for Multiple Privileges

A user belonging to a responsibility classification such as Pricing User will typically have the access privileges that are associated with that responsibility. However, if a user has only View Only access to a pricing entity by virtue of his or her responsibility, but requires Maintain access, you can assign a Maintain access privilege to the user. A Maintain access privilege is a higher privilege than View Only, and therefore, the higher Maintain privilege prevails for the named user.

If a user has a Maintain access privilege to a given entity at any level of his or her user hierarchy (Responsibility, Operating Unit, and Global), the user will have Maintain access regardless of any other privileges. For example, if a user has Maintain access at his operating unit level but a view-only access at his user level, his Maintain access privilege will have precedence.

To create privileges (directly in Privileges page)

In the Search region, search by Entity Type to view and assign privileges directly on the Privileges page:

Note: If the message No data exists appears in the Results: Privilege(s) region then no privileges exist for the entity.

Alternatively, select the entities and click either Express Create Privilege or Bulk Create Privileges.

To create a privilege for one specific pricing entity (Express Create Privilege)

  1. To create a privilege for one specific pricing entity, select the entity and click Express Create Privilege.

  2. Select the entity type and entity name of the pricing entity to be granted privileges.

  3. Select from the following Grantee Types and, if applicable, select a Grantee Name:

    • Responsibility: Grants the privilege to a specific responsibility such as Pricing User, Guest User (the specific Grantee Names depend on the setup for your specific business).

    • User: Grants the privilege to a specific user such as John Smith in the Pricing Department.

    • Global: If Grantee Type is Global, leave Grantee Name blank. This makes the privilege available to all users with functional access to pricing menus.

    • Operating Unit: Grants the privilege to a specific operating unit. For example, select Vision1 to give a privilege to all users who have Vision 1 as the default operating unit.

  4. Access Level: Select the access level to be granted to the grantee:

    • Maintain: Enables users to delete, view, and update pricing entities.

    • View Only: Enables users to view but not update the pricing entity.

  5. Start and End Dates: Select the start and end dates. For example, to provide temporary access to a temporary employee, you could enter a start date of 02-Jul-2007 and an end date of 31-Aug-2007. Alternatively, accept the system dates.

To create privileges to multiple pricing entities (Bulk Create Privileges)

Use the Bulk Create Privileges page to quickly create and assign privileges to multiple entities such as price lists or modifiers. For example, you could search for all price lists belonging to the operating unit of Vision France and then use the bulk create privileges feature to grant them all Maintain access. Alternatively, as a shortcut, you could create an entity set for the entities to be changed, and use the bulk update to update the entity set. The changes are then applied to all entities within that entity set.

  1. Do a search by entity type, then select the pricing entity or entities to be granted privileges.

  2. Click Next to display the Bulk Create Privileges: Provide Additional Privileges Information page, and complete your entries:

    • Entity Type and Entity Name: Select the Entity Type and Entity Name of the pricing entity to be granted privileges.

    • Grantee Types/Grantee Name: Select one of the following:

      • Responsibility: Grants the privilege to a specific responsibility such as Pricing User, Guest User (the specific Grantee Names depend on the setup for your specific business).

      • User: Grants the privilege to a specific user such as John Smith in the Pricing Department.

      • Global: If Grantee Type is Global, leave Grantee Name blank. This makes the privilege available to all users with functional access to pricing menus.

      • Operating Unit: Grants the privilege to a specific operating unit. For example, select Vision1 to give a privilege to all users that have Vision1 as the default operating unit.

    • Access Level: Select the access level to be granted to the grantee:

      • Maintain: Enables users to delete, view, and update pricing entities.

      • View Only: Enables users to view but not update the pricing entity.

    • Start and End Dates: Select the start and end dates. For example, to provide temporary access to a temporary employee, you could enter a start date of 02-Jul-2007 and an end date of 31-Aug-2007. Alternatively, accept the system dates.

Creating Entity Sets

You can create a set of pricing entities that contain multiple pricing entities of the same entity type; for example, an entity set for price lists and an entity set for modifiers. This facilitates assigning privileges to the entire entity set rather than to each separate entity. Here are some examples of entity set usage:

To use entity sets, you need to:

  1. Create an entity set using the Create Entity Set page. On this page, you can select only header level criteria to create the set.

  2. Use the entity set as the grant object (with object type as ENTITY SET) and grant access roles to any grantee type and grantee.

You should identify the selected criteria in the description of the entity set. Once an entity set is created, you cannot copy or update it. If changes are required, a new entity set must be created.

Note: You can revoke or add privileges as needed. However, the entity set cannot be deleted if any existing privileges are on that entity set. The Entity Set feature is available only to licensed users of Oracle Advanced Pricing.

For entity sets, consider the following guidelines:

If this entity set is used in an access privilege, the newly created entity will be included in the set and will have those privileges.

Example of Entity Set Usage

You create a new entity set named SET1 for all active modifiers for USD currency containing Wireless in the customer name. Next you query on the set name SET1 on the Entity Sets page. After clicking the Go button, no records are displayed in the Results region. This occurs because there are no records that currently exist meeting these criteria.

Next, you create a privilege for entity set SET1 and assign view-only access for the Vision Operating Unit. Next, a user creates a new modifier - MOD 1 in the USD currency for the customer Totally Wireless - and makes the modifier active.

The MOD 1 modifier will automatically be assigned to the SET1 entity set and will inherit view-only access.

To create an entity set

  1. In the Create Entity Set page, define your set criteria:

    • Set Name and Description: Enter a name that uniquely identifies the entity set that you are creating, and a description that is simple, meaningful, and includes all the criteria that is selected for this entity set. The criteria to define the set should be included in the description for the set.

    • Pricing Entity Types: Select a pricing entity type to be included in the entity set. Only one pricing entity type can be included in an entity set.

      Note: An entity set can contain only one unique pricing entity type. For example, Entity Set1 cannot contain entity types of both Standard Price List and Modifier.

    • Pricing Entity Name: Select an operator - is, is not, contains, starts with, ends with - and then enter specific details about the pricing entity name to be included in the set. For example, if you select Pricing Entity Name is Summer Price List, then the price list that is named Summer Price List will be included in the entity set. (Assuming Standard Price List was selected as the pricing entity type.)

  2. Optional Qualifier Criteria: Select criteria from the Add Criteria field to add additional criteria, and click the Add button. Add only the criteria that you need for your new entity set. Remember to add the additional criteria to the Set Description. Your entity set will include only those pricing entities exactly matching your criteria.

To delete an entity set

To delete an entity set, you must first revoke all privileges on this set and then delete it.

  1. Navigate to the Entity Sets page and do a search for an existing entity set.

  2. In the Results: Entity Set(s) region, click the Delete icon to delete a specific entity set.

  3. If the Delete icon is grayed out, the entity set still has privileges assigned to it. Before the entity set can be deleted, you must first revoke the privileges, and then delete the entity set.

Setting Security Profile Options

You can set security profile options to define the default security privileges that are assigned to newly-created price lists and modifiers. These profiles should be left in default setting (maintaining current functionality) and not be changed until you have decided which users should have automatic privileges of View Only or Maintain whenever a pricing entity is newly created. These privileges are automatically created as soon as the creating user saves the new entity. Security access for existing pricing entities is set by the Oracle Pricing Administrator using pricing security.

The two security profile options, QP: Security Default Maintain Privilege and QP: Security Default ViewOnly Privilege, control the default access privileges that are assigned to newly-created price lists or modifiers only:

Before setting the security profile options and changing the defaulting privilege profiles, complete all security setup requirements. To change the access privileges for pre-existing price lists and modifiers, use the Security Privileges window.

Additional Implementation Considerations

The following discussion will assist you in choosing the combination of profile option settings to meet your security policy.

Resolving conflicts between multiple access levels

If the user has two different access privileges to the same pricing entity, the access level of Maintain always prevails. For example, if a pricing user has Maintain access at the User level to certain price lists, and view-only access at the Responsibility level, the user has Maintain privileges to those price lists.

In all cases, the highest access level (the Maintain access privilege) prevails over the View-Only privilege. This rule applies regardless of what operating unit ID the user is in.

Security profile option settings compared

The following section lists possible combinations of security profile option settings that define the default view and maintain access privileges for newly created pricing entities. Review the combinations of profile option settings and select the combination that suits the requirements for your installation. When security is turned on, a price list and modifier that is newly created will be assigned the default view and maintain security privileges from the profile option settings.

Security Profile ON: Behavior when you are creating a new pricing entity

The following table shows behavior by combinations of profile settings when you are setting up new price lists and modifiers. Available values are None, User, Responsibility, Operating Unit, and Global.

QP: Default View Only Privilege QP: Default Maintain Privilege Behavior while being created After saving and exiting the Entity's (Price list or Modifier) setup windows
None None Entity can be viewed and updated while being created. 1. The new entity cannot be viewed or updated by anyone.
None User Entity can be viewed and updated while being created. 2. The new entity can be viewed and updated only by the user who created it only.
None Responsibility Entity can be viewed and updated while being created. 3. The new entity can be viewed and updated only by users with the same responsibility as the user who created it only.
None Operating Unit Entity can be viewed/updated while being created. 4. The new entity can be viewed and updated by all users with the same default operating unit as the user who created the entity only.
None Global Entity can be viewed and updated while being created. 5. The new entity can be viewed and updated by all users.

Security Profile ON: Behavior when you are creating a new pricing entity for combination: values for User

The following table shows behavior by combinations of profile settings when you are setting up new price lists and modifiers. Available values are: None, User, Responsibility, Operating Unit, and Global.

QP: Default View Only privilege QP: Default Maintain Privilege Behavior while being created After saving and exiting the Entity's (Price list or Modifier) setup windows
User None Entity can be viewed and updated while being created. The user who created it can view the new entity. Nobody can update it.
User User Entity can be viewed and maintained by user who created it. The new entity can be viewed and updated only by the user who created it only.
User Responsibility Entity can be viewed and maintained by user who created it. Similar to the None/Responsibility settings, except that the user can still view the entity even if he or she is exempted from the responsibility.
User OU Entity can be viewed and maintained by user who created it. Similar to None/Operating Unit settings, except that, the user can still view the entity even if he or she has a different default operating unit.
User Global Entity can be viewed and maintained by user who created it. Same as None/Global settings. The new entity can be viewed and updated by all users.

Security Profile ON: Behavior when you are creating a new pricing entity for combination: values for Responsibility

The following table shows behavior by combinations of profile settings when you are setting up new price lists and modifiers. Available values are: None, User, Responsibility, Operating Unit, and Global.

QP: Default View Only Privilege QP: Default Maintain Privilege Behavior while being created After saving and exiting the Entity's (Price list or Modifier) setup windows
Responsibility None Entity can be viewed and maintained by user who created it. All the users can view the new entity with the same responsibility as the user who created it. Nobody can update it.
Responsibility User Entity can be viewed and maintained by user who created it. All the users can view the new entity with the same responsibility as the user who created it. And, only the user who created it can update it.
Responsibility Responsibility Entity can be viewed and maintained by user who created it. Same as None/Responsibility settings. The new entity can be viewed and updated only by users with the same responsibility as the user who created it only.
Responsibility Operating Unit Entity can be viewed and maintained by user who created it. All the users can view the new entity with the same responsibility as the user who created it. And, all the users with the same default operating unit as the user who create it can also update it.
Responsibility Global Entity can be viewed and maintained by user who created it. Same as None/Global. The new entity can be viewed and updated by all users.

Security Profile ON: Behavior when you are creating a new pricing entity for combination: values for Operating Unit

The following table shows behavior by combinations of profile settings when you are setting up new price lists and modifiers. Available values are: None, User, Responsibility, Operating Unit, and Global.

QP: Default View Only Privilege QP: Default Maintain Privilege Behavior while being created After saving and exiting the Entity's (Price list or Modifier) setup windows
Operating Unit None Entity can be viewed and maintained by user who created it. All the users with the same default operating unit as the user who created it can view the new entity. Nobody can update it.
Operating Unit User Entity can be viewed and maintained by user who created it. All the users with the same default operating unit as the user who created it can view the new entity. Only the user who created it can update it.
Operating Unit Responsibility Entity can be viewed and maintained by user who created it. All the users with the same default operating unit as the user who created it can view the new entity. All the users with the same responsibility as the user who created it can update it.
Operating Unit Operating Unit Entity can be viewed and maintained by user who created it. Same as None/OU settings. The new entity can be viewed and updated only by users with the same default operating unit as the user who created the entity.
Operating Unit Global Entity can be viewed and maintained by user who created it. Same as None/Global settings. The new entity can be viewed and updated by all users.

Security Profile ON: Behavior when you are creating a new pricing entity for combination: values for Global

The following table shows behavior by combinations of profile settings when you are setting up new price lists and modifiers. Available values are: None, User, Responsibility, Operating Unit, and Global.

QP: Default View Only Privilege QP: Default Maintain Privilege Behavior while being created After saving and exiting the Entity's (Price list or Modifier) setup windows
Global None Entity can be viewed and maintained by user who created it. All the users can view the new entity. But nobody can update it.
Global User Entity can be viewed and maintained by user who created it. All the users can view the new entity. Only the user who created it can update it.
Global Responsibility Entity can be viewed and maintained by user who created it. All the users can view the new entity. All the users with the same responsibility as the user who created it can update it.
Global Operating Unit Entity can be viewed and maintained by user who created it. All the users can view the new entity. All the users with the same default operating unit as the user who created it can update it.
Global Global Entity can be viewed and maintained by user who created it. Same as None/Global. The new entity can be viewed and updated by all users

The Oracle Pricing Administrator can assign or change ownership of a pricing entity using the Entity Usage page (or the Bulk Update Entity Usage feature from the Entity Usage page).

Turning On Pricing Security

WARNING: The concurrent program QP: Security Control with Views Conversion turns pricing security on or off for your entire installation. If you are upgrading or freshly installing the security feature for the first time, ensure that you have completed the following setup and implementation steps before turning pricing security on or setting the default security profile options; otherwise, users will be unable to query any price lists or modifiers in the pricing windows.

When security control is first turned ON, a Global check box appears in the header region of all price lists and modifiers. If the Global check box is enabled for the entity, then that entity is available across all operating units in your organization. The Global check box is visible to end-users and can be updated (cleared or selected) by users with Maintain access privileges.

You can update the Global check box for each price list and modifier one at a time, or do bulk updates in the Bulk Update Entity Usage page. For more information, see Assigning Pricing Entity Usage.

Prior to your turning security on, pricing entities are not identified by an operating unit. It is very important that the Oracle Pricing Administrator assigns ownership to all price lists and modifiers prior to upgrading to or implementing pricing entity security. You can use the Bulk Update Entity Usage feature in the Entity Usage page to assign or reassign global usage values.

After you turn pricing security on, the default operating unit is used if the Global check box is deselected.

The following table shows the behavior of existing pricing entities when pricing security is turned ON and no pre-security is assigned:

QP: Default View Only Privilege QP: Default Maintain Privilege Privileges from Pricing Security Administrator Behavior
Not applicable Not applicable No privileges granted Entity cannot be viewed or updated by anybody except the Oracle Pricing Administrator through the security management pages that are selected from the Oracle HTML user interface.
Not applicable Not applicable Maintain Entity can be viewed and updated by the user with Maintain access privileges.