Search Results get_addtnl_log_details

Overview

PV_OPPTY_ROUTING_LOG is an Oracle Applications (APPS) PL/SQL package within the Oracle E-Business Suite Partner Management / Channel Revenue Management product family, specifically the Partner Visibility (PV) module that supports opportunity routing, lead assignment, and partner notification workflows. The package is declared with AUTHID CURRENT_USER, meaning its SQL statements execute under the privileges of the calling schema rather than the package owner, which is consistent with a utility or formatting package intended to be called from within a larger assignment and routing process rather than to perform privileged DML on its own.

The package header is deliberately small. Its sole documented purpose is to render human-readable descriptive text for records held in the opportunity routing history log. When an opportunity or lead is routed to a partner, the routing engine records a row in PV_OPPTY_ROUTING_LOGS with an event code and the relevant workflow and assignment identifiers. Those identifiers and codes are not self-explanatory to an end user viewing routing history. PV_OPPTY_ROUTING_LOG bridges that gap by translating the log entry into displayable detail, including partner identity, assignment type, decline reason, and timeout outcomes.

Key Procedures and Functions

The package exposes exactly one documented program unit:

• GET_ADDTNL_LOG_DETAILS — A function that returns a VARCHAR2 value containing the additional descriptive detail for a single opportunity routing log entry. It is declared DETERMINISTIC, which signals that the same inputs always yield the same output; this allows the function to be called repeatedly within a query, including inside a SELECT list over PV_OPPTY_ROUTING_LOGS, without redundant recomputation. Its documented inputs are the routing log identifier (OPPTY_ROUTING_LOGS_ID), the event code (EVENT), the lead workflow identifier (LEAD_WORKFLOW_ID), and the lead assignment identifier (LEAD_ASSIGNMENT_ID). The function's comments state explicitly that these four values determine the returned detail text.

Supporting the function are package-level constants initialized at load time using FND_MESSAGE.GET_STRING against the PV message dictionary. These resolve the translatable labels PV_PARTNER, PV_ASSIGNMENT_TYPE, PV_DECLINE_REASON, PV_ASSIGN_OPPTY_TIMEOUT, and PV_ASSIGN_CM_TIMEOUT. The presence of the PV_DECLINE_REASON message constant is directly relevant to the user search term, since it confirms that decline reasons recorded against a routed opportunity or assignment are surfaced through this package's labels.

Tables Accessed

According to the documented dependencies, the package and its callers reference the following tables through APPS synonyms. The central table is PV_OPPTY_ROUTING_LOGS, which stores the routing history rows keyed by OPPTY_ROUTING_LOGS_ID. PV_LEAD_WORKFLOWS and PV_LEAD_ASSIGNMENTS supply the workflow and assignment context identified by LEAD_WORKFLOW_ID and LEAD_ASSIGNMENT_ID. HZ_PARTIES provides the trading partner or party name rendered against the PV_PARTNER label. PV_PARTNER_PROFILES and PV_PARTY_NOTIFICATIONS support partner-profile attributes and notification tracking associated with the routing event. AS_LEADS_ALL supplies lead and opportunity source data. Collectively these tables allow the function to reconstruct, in readable form, who the opportunity was routed to, how it was assigned, and why it was accepted, timed out, or declined.

Usage Notes

Because it returns only formatted detail text, the package is a presentation-layer helper rather than a transactional API. It is typically invoked from Oracle Forms routing-history and assignment-detail blocks, from OAF pages displaying opportunity routing history, and from custom reports or BI Publisher extracts that list routed leads with their outcomes. It has no dependent packages reported, indicating it sits at the top of the dependency chain and is called directly. Developers extending routing history views should treat GET_ADDTNL_LOG_DETAILS as the sanctioned access point for descriptive log text rather than rebuilding message lookups, since it centralizes message-dictionary usage and keeps multi-language rendering consistent across 12.1.1 and 12.2.2.