Search Results fte_pricing_comp_request_s

Overview

APPS.FTE_FREIGHT_RATING_PUB is a public PL/SQL package body within the Oracle E-Business Suite Transportation Management (FTE/OTM-adjacent) schema. Its name and dependency footprint identify it as the freight rating engine of the ETRM (Enterprise Transportation Management) module: the component responsible for calculating the freight charges that a carrier would apply to a shipment, trip, or order release, based on configured rate structures, lanes, and carrier service definitions. The package is classified as a PUB (public) API, meaning its single exposed procedure is intended to be callable from external code — Oracle Forms, concurrent programs, workflow activities, or customer-written PL/SQL — rather than being an internal helper used only within the module.

The package body is marked VALID and is owned by APPS. It is a consumer, not a provider: ETRM metadata records that it is not referenced by any other database object, while it depends on two other packages (it is referenced by two more), confirming it sits at the top of the call stack for rating requests rather than being invoked internally by sibling packages.

Key Procedures and Functions

Exactly one documented entry point is exposed:

• GET_FREIGHT_COSTS — the public function/procedure that returns freight cost information for a given transportation movement. In practice it accepts the shipment, trip, or pricing context, gathers the applicable rate and lane data, evaluates freight pricing rules, and returns rated cost amounts. Because the object is a PUB API, GET_FREIGHT_COSTS is the supported integration surface; all other logic in the body is private.

The dependency list reveals the internal machinery that supports GET_FREIGHT_COSTS. FTE_FREIGHT_PRICING and FTE_FREIGHT_PRICING_UTIL supply the rate calculation and pricing utility routines. FTE_LANE_SEARCH, FTE_LANE_REC, and FTE_LANE_TAB handle lane identification — determining which origin/destination lane applies so the correct rate is selected. FTE_PROCESS_REQUESTS and FTE_PRICING_COMP_REQUEST_S represent the pricing computation request structure used to batch or stage rating inputs. FTE_TL_RATING, FTE_TRIP_RATING_GRP, and FTE_SCHEDULE_TAB support trip-level and time-line rating, while FTE_VEHICLE_PKG and FTE_SEARCH_CRITERIA_REC supply equipment and search-context data. FND_API, FND_MESSAGE, and FND_MSG_PUB provide the standard EBS API error-handling and message stack conventions, and GL_CURRENCY_API supplies currency conversion for rated amounts.

Tables Accessed

Named table references, all resolved through APPS synonyms, include:

• FTE_PRICING_COMP_REQUEST_S — the pricing computation request table (the object surfaced in the user's original search for "fte_pricing_comp_request_s"). The rating package creates/reads a request record describing what is to be rated, then writes back the resulting costs.
• WSH_CARRIERS, WSH_CARRIER_SERVICES, and WSH_ORG_CARRIER_SERVICES — carrier and carrier-service definitions, including the carrier-service combinations enabled for a given organization, which define which rate agreements are eligible.
• WSH_FREIGHT_COST_TYPES — the freight cost type lookup that classifies each calculated charge.
• DBMS_UTILITY and PLITBLM — Oracle-supplied packages (not application tables); DBMS_UTILITY is used for name resolution and PLITBLM for index-by-table operations.

Usage Notes

GET_FREIGHT_COSTS is typically invoked when a transportation document requires rate determination: shipment or delivery confirmation in Oracle Shipping (WSH), trip planning/execution in Transportation Management, or a custom integration that must quote freight costs. It may be called from concurrent programs that pre-rate large volumes of shipments, from Forms-based flows triggered by the user, or directly from custom PL/SQL using the FND_API-standard call/return conventions. Because it is a PUB API and is not referenced by any database object, backward compatibility should not be assumed for its internals — only the documented GET_FREIGHT_COSTS signature should be treated as a supported interface. Callers should expect FND_MESSAGE/FND_MSG_PUB error semantics and should ensure carrier services and freight cost types are configured before invocation. Both 12.1.1 and 12.2.2 expose this body with the same APPS owner and VALID status.