Search Results ce_security_profiles_v




Overview
Explore in AI Chat

Overview

CE_SECURITY_PROFILES_V is a valid Oracle E-Business Suite view owned by the APPS schema in the Cash Management (CE) product family. Its documented purpose is to store organization security access information — that is, to resolve, at query time, the set of organizations that a given EBS user is authorized to access. The view is a pure selection construct: it materializes no data of its own and derives its results entirely from security grants, workflow role assignments, trading partner relationships, and HR/financials organizational definitions.

The view is typically consumed by Cash Management setup pages, bank account configuration, and any reporting or integration layer that must restrict cash, bank, and treasury data to the legal entities and operating units the session user is entitled to see. It is the organization-level counterpart to the access control that governs other treasury objects, and it is particularly relevant when an administrator investigates why a user can see certain legal entities but not others.

Underlying Base Objects

The documented dependencies include several package and view layers. FND_GRANTS and FND_OBJECTS supply the raw security grants issued against the object named 'CEBAA' (Cash Management Bank Account Access). WF_USER_ROLES and WF_LOCAL_ROLES resolve the roles or groups that a user inherits, while FND_USER and FND_GLOBAL identify the current session user and current user name. XLE_ENTITY_PROFILES provides the legal entity name and identifier, with GL_SETS_OF_BOOKS joined for the trading-partner branch. XTR_PARTIES_V, XTR_COMPANY_AUTHORITIES, XTR_DEALER_CODES, and XTR_USER_ACCESS support the Treasury (XTR) dealer-authority path. HR_OPERATING_UNITS provides operating unit identifiers and names, filtered through MO_GLOBAL.CHECK_ACCESS. FND_PROFILE and FND_ACCESS_CONTROL_UTIL resolve the business group, and DUAL supplies the single-row business group selection.

Because the view unions these paths together, it consolidates grant-based, role-based, business-group, and operating-unit access into one result set. Each branch contributes rows labelled with a literal ORGANIZATION_TYPE, so the source of a given access row remains visible.

Key Columns

  • ORGANIZATION_TYPE — The discriminator column and the focus of most searches. Documented literal values are 'LEGAL_ENTITY' (used by three union branches), 'BUSINESS_GROUP', and 'OPERATING_UNIT'. It tells the consumer which class of organization the row represents.
  • ORGANIZATION_ID — The numeric identifier. For legal entities this is the LEGAL_ENTITY_ID, for business groups the PER_BUSINESS_GROUP_ID profile value, and for operating units the HR_OPERATING_UNITS.ORGANIZATION_ID. Note the column is named ORGANIZATION_ID even though legal-entity rows carry a legal entity identifier.
  • NAME — The descriptive name of the organization, drawn from XLE_ENTITY_PROFILES.NAME, the business group name via FND_ACCESS_CONTROL_UTIL.GET_ORG_NAME, or HR_OPERATING_UNITS.NAME.

Common Use Cases and Queries

Typical uses include validating a user's accessible legal entities before bank account setup, driving LOVs on cash management forms, and building security-aware extracts. A common diagnostic is to list all accessible organizations for the session user, filtered by type, which directly answers the "organization_type" lookup:

  • SELECT organization_type, organization_id, name FROM ce_security_profiles_v ORDER BY organization_type, name;
  • SELECT organization_id, name FROM ce_security_profiles_v WHERE organization_type = 'LEGAL_ENTITY';
  • SELECT organization_id, name FROM ce_security_profiles_v WHERE organization_type = 'OPERATING_UNIT';
  • SELECT organization_type, COUNT(*) FROM ce_security_profiles_v GROUP BY organization_type;

Because the view has no bind parameters and resolves its filters from FND_GLOBAL and FND_PROFILE at execution time, results are session-dependent. Reports must therefore run in the context of the user whose access is being evaluated, and results should not be cached across users.