Search Results get_vendor_name




Overview
Explore in AI Chat

Overview

The APPS.HXC_MISSING_TCARD_REPORT package is a PL/SQL API belonging to the Oracle E-Business Suite Time and Labor (HXC) module. Its purpose is to support the Missing Time Card Report, a reporting utility that identifies employees or contingent workers for whom no time card records exist within a specified reporting period. In the Oracle EBS 12.1.1 and 12.2.2 releases, this package is classified under the generic API classification of OTHER, indicating that it is not part of the standard public OTL (Oracle Time and Labor) API set but instead serves as an internal helper for the missing time card reporting process.

The package is declared with AUTHID CURRENT_USER, meaning that its procedures execute with the privileges of the invoking user rather than the package owner (APPS). This design is consistent with reporting utilities that rely on the caller's security context when querying HR and resource data. The source header (hxcmistc.pkh 115.2) dates to November 2003, indicating the package has been stable across many EBS releases and was carried forward into 12.1.1 and 12.2.2 without structural change.

Key Procedures and Functions

The package exposes three documented program units:

  • CHECK_ASSIGNMENT_SET — A function that accepts an assignment set identifier and an assignment identifier and returns a VARCHAR2 result. It validates whether a given assignment belongs to a specified assignment set, which is used to scope the population of workers included in the missing time card report.
  • GET_VENDOR_NAME — A function returning a VARCHAR2 value. Based on its parameters (a start date, an end date, and a resource identifier), it resolves and returns the vendor name associated with a particular resource for the given time period. This is the function most commonly referenced in searches, as it supports the display of supplier or vendor information for contingent workers—typically those sourced through a staffing or contingent labor arrangement—within the report output.
  • CHECK_VENDOR_EXISTS — A function returning a VARCHAR2 result that determines whether a vendor record exists for a given combination of start date, end date, assignment, resource, and vendor identifier. It complements GET_VENDOR_NAME by confirming vendor presence before a name is retrieved or displayed.

Tables Accessed

Per the ETRM metadata, the package references the following objects through APPS synonyms:

  • HR_ASSIGNMENT_SET_AMENDMENTS — Supports the assignment set validation logic in CHECK_ASSIGNMENT_SET, providing the assignment set membership data used to filter the reporting population.
  • PER_ALL_PEOPLE_F — The core HR person and assignment dated table, used to resolve people and assignment details relevant to the missing time card determination and resource-to-person relationships.
  • DUAL — Used for simple single-row evaluations and return-value construction within the functions.

Usage Notes

HXC_MISSING_TCARD_REPORT is typically invoked indirectly rather than being called directly by end users. Its most common invocation paths are:

  • Concurrent programs and report generation — The Missing Time Card Report concurrent program calls these functions to build its output, using GET_VENDOR_NAME to populate vendor columns for contingent workers and CHECK_VENDOR_EXISTS to conditionally display supplier data.
  • Oracle Forms and OAF pages — Time and Labor inquiry or reporting screens may reference these functions when rendering assignment and vendor details for missing time cards.
  • Custom code and extensions — Because the package is marked OTHER and AUTHID CURRENT_USER, it is not a supported public API. Developers encountering the get_vendor_name reference should treat it as an internal dependency of the missing time card reporting feature rather than a reusable integration point. Customizations should avoid direct calls and instead rely on the standard report or supported OTL APIs.

The metadata records that this package is referenced by zero other packages, confirming its role as a leaf-level reporting helper rather than a shared library. There are no documented wrapper APIs, which further reinforces that it should be used only within its intended reporting context.