Search Results web_password

Overview

POS_PO_USER_DETAILS_V is a Purchasing (PO) module view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes user account attributes maintained by the Oracle EBS security and user-management layer, presenting them under a PO-facing name for consumption by Purchasing forms, concurrent programs, and reporting objects. Functionally the view is a filtered or direct projection of user records drawn from the applications user repository, and it is registered in the E-Business Suite Technical Reference Manual (ETRM) as a VALID object within the PO product family.

The view is commonly encountered when building operational reports around buyer, approver, or preparer activity, because user identifiers and login metadata must be joined to purchasing documents. The specific search term "last_logon_date" refers to the LAST_LOGON_DATE column exposed by this view, which records the most recent successful authentication timestamp for a user. This makes the view a convenient reporting source when administrators or auditors need to correlate purchasing activity with the last time the responsible user signed in.

Underlying Base Objects

The ETRM metadata documents a single referenced base object for this view: the FND_USER table, accessed in the APPS schema through a SYNONYM. FND_USER is the central Oracle Applications table storing user accounts, credentials, password policy attributes, and sign-on history. Because POS_PO_USER_DETAILS_V is defined directly over FND_USER, it inherits the row population of that table without aggregation or transformation; the SELECT list reproduces the source columns in a fixed order rather than computing derived values.

No additional joins, lookups, or PO-specific base tables are documented for this view. Consequently, the view adds a Purchasing-owned namespace and a stable column contract, but it does not introduce new data. Any change to FND_USER column semantics, such as a patch altering password or login tracking, is reflected automatically in the view's output. Users querying the view are effectively querying FND_USER with a PO-oriented alias.

Key Columns

• USER_ID – Surrogate primary key for the user account; the join key to PO tables such as PO_HEADERS_ALL.CREATED_BY or EMPLOYEES.
• USER_NAME – The application login name used at sign-on.
• LAST_LOGON_DATE – Timestamp of the user's most recent successful logon; the attribute most frequently searched on this object.
• START_DATE / END_DATE – Effective dating for the user account, controlling when the account is active.
• PASSWORD_DATE, PASSWORD_ACCESSES_LEFT, PASSWORD_LIFESPAN_ACCESSES, PASSWORD_LIFESPAN_DAYS – Password policy and expiry tracking attributes.
• EMPLOYEE_ID – Link to the HR employee record representing the same individual.
• EMAIL_ADDRESS, FAX – Contact attributes available for notification workflows.
• ENCRYPTED_FOUNDATION_PASSWORD, ENCRYPTED_USER_PASSWORD, SESSION_NUMBER, USER_PASSWORD – Security-sensitive credential and session columns; these should not be selected in general reporting.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN – Standard EBS audit (WHO) columns.
• DESCRIPTION – Free-text description of the user account.

Common Use Cases and Queries

A typical reporting scenario identifies purchasing users who have not logged on recently, supporting access reviews and segregation-of-duties checks. A representative query is:

• SELECT user_id, user_name, last_logon_date, start_date, end_date FROM apps.pos_po_user_details_v WHERE last_logon_date IS NULL OR last_logon_date < SYSDATE - 90 ORDER BY last_logon_date;
• SELECT u.user_name, u.last_logon_date, h.segment1, h.creation_date FROM apps.pos_po_user_details_v u, apps.po_headers_all h WHERE u.user_id = h.created_by AND h.creation_date >= SYSDATE - 30;
• SELECT user_name, employee_id, email_address, password_date FROM apps.pos_po_user_details_v WHERE end_date IS NULL OR end_date > SYSDATE;

Because the view maps directly to FND_USER, results are identical to querying FND_USER with the same predicates; use of POS_PO_USER_DETAILS_V is a matter of convention within PO customizations rather than a functional requirement. All queries should exclude the encrypted password and session columns unless a security-specific purpose exists.