Search Results r_count

Overview

APPS.POS_OSP_JOB is a PL/SQL package body that supports Outside Processing (OSP) functionality within Oracle Purchasing. Its central purpose is to resolve the Work in Process (WIP) job context associated with an outside processing purchase order line or distribution, and to expose that context to the applications that display or process OSP sourcing information. In an OSP flow, a purchase order line is linked to a discrete WIP job and operation so that the supplier's service (for example, plating, painting, or machining) can be fed back into the manufacturing routing. The package encapsulates the join logic required to translate a purchasing identifier — most commonly PO_LINE_LOCATION_ID — into a human-readable WIP job reference composed of the WIP entity name, the WIP line code, and the WIP operation sequence number.

The package is classified as OTHER in the ETRM metadata and is owned by APPS. It is a lightweight utility package rather than a full business API, and its documented interface consists of seven functions. The source header indicates the object originated in the late 1990s and has been carried forward through successive EBS releases, including 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes the following documented functions. All are read-only lookups; none perform DML.

• R_COUNT — Returns the number of rows in PO_DISTRIBUTIONS_ALL for a given outside processing line location that carry a non-null WIP entity identifier. It is the cardinality test that governs the behavior of the other functions.
• GET_OSP_INFO — Accepts a PO_LINE_LOCATION_ID and returns a formatted job information string. When exactly one matching distribution exists, it returns the concatenation of the WIP entity name, WIP line code, and WIP operation sequence number. When more than one match exists it returns a blank placeholder, and when no match exists it returns a non-breaking space placeholder.
• GET_PO_DISTRIBUTION_ID — Returns the single PO_DISTRIBUTION_ID associated with a line location when the distribution count is exactly one; otherwise it returns null. This function is the bridge from the purchasing line location to the distribution-level key used by the remaining accessors.
• GET_WIP_ENTITY_ID — Returns the WIP entity identifier linked to the outside processing distribution.
• GET_WIP_LINE_ID — Returns the WIP line identifier associated with the distribution.
• GET_WIP_SEQ_NUM — Returns the WIP operation sequence number for the linked job operation.
• GET_WIP_INFO — Accepts a PO_DISTRIBUTIONS_ID (rather than a line location) and returns the same formatted job information string as GET_OSP_INFO, using the WIP entity, WIP line, and operation sequence number.

Tables Accessed

The package reads three tables through APPS synonyms:

• PO_DISTRIBUTIONS_ALL — The driving table. It is queried on LINE_LOCATION_ID or PO_DISTRIBUTION_ID and filtered on WIP_ENTITY_ID being non-null to isolate outside processing distributions. It supplies the WIP entity, WIP line, and operation sequence number used in the returned strings.
• WIP_ENTITIES — Joined on WIP_ENTITY_ID to obtain the WIP entity name, which identifies the manufacturing job.
• WIP_LINES — Joined on WIP_LINE_ID via an outer join to obtain the line code. The outer join ensures that a distribution is still reported even when no WIP line row exists, consistent with the optional nature of the WIP line for some routings.

Usage Notes

POS_OSP_JOB is typically invoked from Oracle Purchasing and Manufacturing forms and from custom code that must display the WIP job reference on an outside processing purchase order or distribution. The package is referenced by two other documented packages, indicating it serves as a shared resolution layer rather than a standalone entry point. Because its functions return formatted display strings and single-column identifiers, it is well suited to form field defaulting, folder-based query results, and reporting. Callers should note that GET_OSP_INFO and GET_WIP_INFO return placeholder characters rather than null when no single job match is found, and that the identifier-based functions return null in the ambiguous multi-distribution case. The package performs no updates and no commits, so it is safe to call repeatedly within a query or validation cycle.