Search Results finalize_update_tender

Overview

FTE_TENDER_WF is an Oracle E-Business Suite workflow support package belonging to the Transportation Execution (FTE) module. It encapsulates the business logic that drives the carrier tender and response cycle used during outbound logistics planning and execution. In Oracle EBS 12.1.1 and 12.2.2, the package serves as the PL/SQL backbone behind the seeded Oracle Workflow process that submits shipment tenders to carriers, tracks carrier responses, applies reminder and escalation rules, and finalizes tender outcomes such as acceptance, rejection, modification, and no-response. It is declared AUTHID CURRENT_USER, so it executes with the privileges of the calling schema rather than as its owner, APPS.

Although the header was last revised in 2005, the package remains active in 12.2.2 and is catalogued in the ETRM repository with a classification of OTHER. It exposes 24 documented procedures and functions and references no fewer than ten base and interface tables across the FTE, WSH, MTL, and HZ schemas.

Key Procedures and Functions

The documented entry points fall into three groups. Workflow callback procedures conform to the standard itemtype/itemkey/actid/funcmode/resultout signature and are invoked by the Workflow engine at specific activity nodes: INITIALIZE_TENDER_REQUEST, FINALIZE_TENDER_REQUEST, FINALIZE_UPDATE_TENDER, FINALIZE_NORESPONSE, and FINALIZE_AUTO_ACCEPT. Conditional functions in the same style evaluate workflow branch logic: IS_TENDER_MODIFIED, IS_REMINDER_ENABLED, IS_AUTO_ACCEPT_ENABLED, and CALCULATE_WAIT_TIME, the latter computing reminder or expiry timing.

A second group performs direct data retrieval and validation: GET_DOCK_CLOSE_DATE determines the dock cutoff date for a given location and tender date; GET_TENDER_INFO returns tender header and response attributes; GET_ITEM_INFO supplies item-level tender detail; GET_NOTIF_TYPE resolves the notification template to use; and VALIDATE_XML_INFO verifies inbound carrier XML payloads.

The third group performs outbound messaging and audit actions: RAISE_TENDER_ACCEPT, RAISE_TENDER_REJECT, and RAISE_XML_OUTBOUND generate workflow events or XML messages, while UPDATE_CARRIER_RESPONSE persists carrier replies, EXPAND_RANK_LIST resolves ranked carrier preference lists, and LOG_HISTORY records tender audit history.

Tables Accessed

The package reads and writes transportation and trading-partner data through APPS synonyms. FTE_VEHICLE_TYPES supplies equipment type definitions used when building tender content. WSH_TRIPS and WSH_DOCUMENT_INSTANCES provide the trip, shipment, and document context that a tender references, while WSH_CARRIER_SITES identifies eligible carrier locations. MTL_SYSTEM_ITEMS supplies item attributes for the tendered goods.

Trading partner data comes from the HZ schema: HZ_PARTIES, HZ_ORG_CONTACTS, HZ_CONTACT_POINTS, HZ_PARTY_SITES, and HZ_RELATIONSHIPS are used to resolve carrier organizations, contacts, notification addresses, and party relationships. These reads support notification routing, response validation, and history logging.

Usage Notes

FTE_TENDER_WF is not typically called directly by end users. It is invoked by the seeded Oracle Workflow definition for transportation tendering, which is started when a planner releases a trip or shipment for carrier tender, and it may also be called from the Transportation Execution forms and concurrent programs that manage tender processing.

The user search term "remove_service_apply_next" is not part of the documented interface of this package. It most likely refers to workflow attribute or transition handling used when a service is removed and the process must advance to its next activity; such logic is normally implemented through Workflow activity attributes and PL/SQL document attributes rather than a packaged procedure named remove_service_apply_next. Custom code requiring that behavior should therefore be implemented via Workflow configuration or a wrapper, not by altering FTE_TENDER_WF. Because the package executes AUTHID CURRENT_USER and is referenced by no other packages, changes are isolated but still carry regression risk for live tenders; any customization should be restricted to extension points rather than direct modification of the APPS-owned code.