Search Results wsh_fte_comp_constraint_pkg




Overview
Explore in AI Chat

Overview

WSH_FTE_CONSTRAINT_FRAMEWORK is the validation engine within Oracle E-Business Suite's Transportation Execution (FTE) module that enforces shipping and delivery constraints against outbound logistics documents. The package resides in the APPS schema and carries a status of VALID in both release 12.1.1 and 12.2.2. Its central purpose is to evaluate whether a proposed delivery, delivery leg, trip, or trip stop satisfies the constraint definitions configured by the warehouse or transportation administrator before the document is confirmed or released to execution.

Constraints in FTE represent business rules such as maximum weight or volume per delivery, carrier capacity limits, calendar cutoffs, and customer-specific shipping restrictions. This framework abstraction allows the application to apply a common validation path across multiple document types without duplicating constraint logic in each calling module. The package is registered as an OTHER API classification in ETRM, reflecting its role as an internal framework layer rather than a public, externally versioned interface.

Key Procedures and Functions

Eleven documented program units make up the package's callable surface:

  • VALIDATE_CONSTRAINT — the generic entry point that evaluates a constraint against its target entity and returns the pass/fail outcome.
  • VALIDATE_CONSTRAINT_DLVY — applies constraint evaluation at the delivery header level.
  • VALIDATE_CONSTRAINT_DLEG — performs the equivalent validation for a delivery leg, the segment between two stops.
  • VALIDATE_CONSTRAINT_DLVB — validates constraints against delivery details (delivery lines), supporting line-level checks.
  • VALIDATE_CONSTRAINT_TRIP — evaluates trip-level constraints, such as total trip weight or carrier capability.
  • VALIDATE_CONSTRAINT_STOP — validates constraints attached to an individual trip stop.
  • GET_CONSTRAINT_DISPLAY — returns a user-facing display or description of a constraint, used in messages and forms.
  • IS_LAST_TRIP — a Boolean helper that determines whether the trip under evaluation is the final trip in a planning sequence.
  • POPULATE_CONSTRAINT_CACHE — loads constraint definitions and related metadata into a memory-resident cache, significantly reducing repeated database lookups during batch validation.
  • GET_CUSTOMER_FROM_LOC — derives the customer associated with a given location, supporting customer-driven constraint resolution.
  • GET_ORG_FROM_LOCATION — resolves the inventory or shipping organization that owns a location.

Tables Accessed

Constraint definitions live in WSH_FTE_COMP_CONSTRAINTS, with WSH_FTE_COMP_CLASSES providing their classification. A temporary staging table, WSH_CONSTRAINT_DLEG_TMP, holds intermediate results during delivery leg validation. The logistics entity tables read during validation include WSH_NEW_DELIVERIES, WSH_DELIVERY_DETAILS, WSH_DELIVERY_LEGS, WSH_TRIPS, WSH_TRIP_STOPS, WSH_CARRIERS, and WSH_LOCATIONS, along with WSH_LOCATION_OWNERS for organizational ownership. Customer identity is resolved through the Trading Community Architecture tables HZ_CUST_ACCT_SITES_ALL, HZ_PARTIES, HZ_PARTY_SITES, and HZ_RELATIONSHIPS.

Usage Notes

This package is invoked internally rather than by end users directly. Documented referrers include FTE_LANE_SEARCH, WSH_FTE_COMP_CONSTRAINT_GRP, WSH_FTE_COMP_CONSTRAINT_PKG, WSH_MDC_SRS, and, notably, WSH_UTIL_CORE — the shared utility library that itself appears in this package's dependency list, indicating a mutual relationship used during constraint validation of delivery legs. The procedures execute when shipping documents are planned, modified, or confirmed through the Transportation Execution forms and concurrent programs. POPULATE_CONSTRAINT_CACHE is typically called once per batch run before repeated validation calls, while the VALIDATE_CONSTRAINT_* family is invoked per entity. Custom extensions should reference the generic VALIDATE_CONSTRAINT entry point rather than the entity-specific wrappers to remain compatible across patch levels.