Search Results no_timecards_exist

Overview

PO_PRICE_HELPER is a server-side PL/SQL package in the APPS schema that encapsulates the business rules governing whether a purchasing document line's price may be modified, and how that price should be re-derived. It is part of the Oracle Purchasing pricing infrastructure and is most heavily exercised by the Purchase Order and Purchase Agreement entry forms whenever a user attempts to change a unit price or when the pricing engine is asked to recalculate a line. The package is not an end-user API in the conventional sense; it is an internal helper that evaluates system options, reservation and accrual state, receipt and timecard activity, and retro-accounting eligibility before allowing or rejecting a price update.

The package header carries the original revision marker $Header: PO_PRICE_HELPER.pls 120.0 2005/06/07, indicating that its interface has been stable since early Release 11i, and it remains present and unchanged in the 12.1.1 and 12.2.2 code lines. Its API classification in ETRM is OTHER, confirming that Oracle does not publish it as a supported public interface, although many procedures are technically callable from custom code.

Key Procedures and Functions

• ATTEMPT_LINE_PRICE_UPDATE — The central routine. It accepts a full set of line-attribute inputs (order quantity, ship-to organization and location, line and header identifiers, need-by date, contract, supplier and supplier site, item and revision, category, UOM, incoming price, currency, and price-break lookup code) and returns the derived base unit price, price-break identifier, effective price, return status, whether advanced pricing was applied, and whether the system permits the update at all.
• CHECK_SYSTEM_ALLOWS_UPDATE — Evaluates whether the current system configuration and document state allow a price change for a given line and price-break lookup code, returning the flag x_system_allows_update.
• NO_DISTS_RESERVED — Determines whether any purchasing distributions associated with the supplied line identifiers still carry reserved funds, populating a result set identifier and result type.
• ACCRUALS_ALLOW_UPDATE — Evaluates accrual state across a collection of line identifiers and returns a validation results structure indicating whether accruals block the change.
• NO_TIMECARDS_EXIST — Confirms that no Oracle Projects timecards reference the supplied line identifiers. If timecards exist, a price change could corrupt already-captured labor cost, so the update is disallowed; the procedure returns its findings through the x_results validation structure.
• NO_PENDING_RECEIPTS — Provides the equivalent guard for open or pending receipt activity against the line set.
• RETRO_ACCOUNT_ALLOWS_UPDATE — Tests whether retroactive accounting rules permit repricing of the affected lines.
• ATTEMPT_MAN_MOD_PRICING — Handles the manual price-modification path, supporting the same eligibility logic outside the standard repricing call.
• WARN_AMT_BASED_NOTIF_CTRLS — Issues warnings relating to amount-based notification controls when pricing changes are attempted.

Tables Accessed

The package reads and writes the core Purchasing tables through APPS synonyms: PO_HEADERS and PO_HEADERS_ALL, PO_LINES and PO_LINES_ALL, PO_LINE_LOCATIONS and PO_LINE_LOCATIONS_ALL, and PO_DISTRIBUTIONS_ALL. PO_SYSTEM_PARAMETERS_ALL supplies the organization's pricing and control options. RCV_TRANSACTIONS_INTERFACE is consulted for pending receipt activity, and the global temporary structures PO_SESSION_GT and PO_VALIDATION_RESULTS_GT hold session-scoped working data and validation output. PLITBLM and DUAL support PL/SQL table handling and singleton queries respectively.

Usage Notes

PO_PRICE_HELPER is invoked primarily from the Purchasing forms layer (POXPOEPO and related order-entry forms) and from concurrent or workflow processes that manage approved supply. It is referenced by one other package in the EBS code set. Because Oracle does not document it as a public API, customizations should call supported interfaces such as PO_CHANGE_API or the PO_LINE_LOCATIONS_APIs instead of invoking PO_PRICE_HELPER directly; the behavior of its procedures, particularly the validation routines, may vary with profile options and system parameters.