Search Results auto_accepted

Overview

FTE_TENDER_PVT is a private PL/SQL package owned by APPS within the Oracle E-Business Suite Transportation Management (ETRM) module. It implements the core tender-handling engine for freight tendering: the process by which a shipper offers a load, trip, or trip segment to a carrier, receives an accept or reject response, and routes that response back through Oracle Workflow for further processing. The package is declared with AUTHID CURRENT_USER, meaning executing privileges are resolved against the invoking schema rather than the defining schema. Its source header (FTETEPVS.pls, 120.1.12000000.1) indicates an established code line present in both 12.1.1 and 12.2.2.

The package defines two important sets of constants. Tender status constants (TENDERED, ACCEPTED, REJECTED, SHIPPER_CANCELLED, AUTO_ACCEPTED, NORESPONSE, RETENDERED, SHIPPER_UPDATED) enumerate the valid lifecycle states of a tender. Source constants (XML, CP, WL) identify how a tender or response originated, distinguishing XML messaging, the collaborative portal, and workflow-based events. These constants are used throughout the Transportation tender flows and constrain the values this package accepts and emits.

Key Procedures and Functions

• RAISE_TENDER_EVENT — Builds and raises the workflow business event that transmits a tender to a carrier. It assembles event attributes from the supplied tender, trip segment, shipper, and carrier context, including wait time, contact information, auto-accept flag, action, and callback URL.
• CAN_PERFORM_THIS_ACTION / CAN_PERFORM_THIS_ACTION_STR — Boolean and string-valued validators that determine whether a proposed tender action is legal for the current trip segment status. The string variant returns a message suitable for display or logging.
• VALIDATE_TENDER_REQUEST — Standard API-style validation entry point. Accepts an API version, message-list initialization flag, trip identifier, action code, tender action, and trip name, and returns the standard return status, message count, and message data triad.
• IS_AUTO_ACCEPT_ENABLED — Evaluates carrier configuration to determine whether auto-acceptance of tenders is enabled for the given carrier.
• GET_ITEM_KEY — Derives the workflow item key associated with a given trip segment, linking the database record to its workflow instance.
• TAKE_TENDER_SNAPSHOT / DELETE_TENDER_SNAPSHOT — Capture and remove point-in-time copies of tender data, supporting audit and retender comparison.
• RAISE_TENDER_ACCEPT, RAISE_TENDER_REJECT, RAISE_TENDER_UPDATE — Raise the respective workflow events when a carrier accepts, rejects, or updates a tender.
• CHECK_THRESHOLD_FOR_STOP, CHECK_CARRIER_ARRIVAL_TIME, LOG_CARRIER_ARR_EXC — Evaluate arrival-time thresholds against trip stops and log carrier arrival exceptions where breached.
• COMPLETE_CANCEL_TENDER, HANDLE_CANCEL_TENDER, RELEASE_TENDER_BLOCK — Complete or process tender cancellation and release any blocking condition held against the tender.
• UPDATE_CARRIER_RESPONSE, HANDLE_TENDER_RESPONSE, HANDLE_UPDATE_TENDER — Persist and route carrier responses, including updates, through the tender handling logic.

Tables Accessed

• WSH_TRIPS, WSH_TRIP_STOPS — Source trip and stop data used to validate and contextualize tender actions.
• FTE_TENDER_SNAPSHOT — Storage for tender snapshots written and deleted by the snapshot procedures.
• FTE_TENDER_ID_S — Sequence used to generate tender identifiers.
• WF_PARAMETER_LIST_T — Workflow parameter list table used when raising tender events.
• WSH_EXCEPTIONS — Destination for exception records, notably carrier arrival exceptions.
• FND_USER — Resolves user context for processing and audit purposes.
• DUAL, PLITBLM — Utility references for scalar evaluation and message handling.

Usage Notes

As a PVT (private) package, FTE_TENDER_PVT is not intended as a public integration surface; it is invoked by Transportation tender forms, Oracle Workflow event activities, and the other EBS packages that reference it, and is referenced by five packages in total. The documented table list contains no direct tender detail table such as FTE_TENDER, suggesting core tender persistence is handled by the referencing packages while this package orchestrates workflow events and validations. Customizations should not call this package directly; use the supported tender APIs instead. Because behavior is governed by the status and source constants, upgrades between 12.1.1 and 12.2.2 should be validated against those enumerated values.