Search Results fte_moves_s

Overview

FTE_MOVES_PVT is a private PL/SQL package body within the Oracle E-Business Suite Applications (APPS) schema that supports the Oracle Freight and Transportation Execution (FTE) module. As indicated by the _PVT suffix and its absence from the general dependency graph, this package is an internal implementation layer — it is not referenced by any other database object and is intended to be called only by its corresponding public wrapper package, FTE_MOVES_PUB. In the ETRM (E-Business Suite Technical Reference Manual) context for release 12.1.1 and 12.2.2, the package encapsulates the core business logic for creating, modifying, and maintaining FTE "moves" — the transportation execution records that represent individual movements of goods within a trip, shipment, or delivery leg. By centralizing this logic in a private body, Oracle enforces the API layering convention used throughout EBS, ensuring that direct table manipulation is avoided and that validation, auditing, message-stack handling, and locking semantics are applied consistently.

Key Procedures and Functions

The ETRM metadata documents eight procedures and functions within this package body, of which seven are named explicitly. Their purposes are as follows:

• CREATE_MOVE — Inserts a new move record, applying the standard FTE validation and defaulting rules before persisting the row.
• UPDATE_MOVE — Modifies an existing move, accommodating changes to attributes such as status, quantities, or association with trips and deliveries.
• DELETE_MOVE — Removes a move record, typically subject to business-rule checks and possibly logical deletion semantics.
• MARK_MOVE_REPRICE_FLAG — Sets or clears a reprice indicator on a move so that downstream freight costing processes know the record requires recalculation.
• LOCK_MOVE — Obtains a lock on a move row to prevent concurrent modification, a standard concurrency-control pattern in FTE APIs.
• POPULATE_RECORD — An internal helper that builds or maps the record structure used by the API from table columns or inbound parameters.
• GET_NAME — Retrieves a descriptive or identifying name associated with a move or its related entity.

All of these procedures rely on the FND_API framework for standardized return statuses and on FND_MSG_PUB for message-stack handling, consistent with EBS API conventions.

Tables Accessed

The package body reads and writes three documented tables through APPS synonyms:

• FTE_MOVES — The primary move table where the substantive move data is persisted and maintained by CREATE_MOVE, UPDATE_MOVE, DELETE_MOVE, and LOCK_MOVE.
• FTE_MOVES_S — The corresponding _S (secondary/child) table, which typically holds supplementary or attribute-flexfield data keyed to the parent move; this is the object a user searching for "fte_moves_s" is most directly interested in.
• FTE_TRIP_MOVES — The association table linking moves to trips, accessed when establishing or validating a move's trip membership.

The package also references utility packages WSH_UTIL_CORE, WSH_DEBUG_SV, and WSH_DELIVERY_LEGS_ACTIONS, reflecting its integration with the Oracle Shipping (WSH) execution layer that FTE extends.

Usage Notes

FTE_MOVES_PVT is not intended for direct invocation by customers or integrators. Its private status and the fact that no other database object references it confirm that it is reached only through FTE_MOVES_PUB, which itself may be called from FTE forms, concurrent programs, or WSH-driven workflows. When custom code needs to manipulate moves, the supported approach is to call the public API; calling the private body directly bypasses the API contract and risks inconsistent message-stack or locking behavior. Because the package is VALID in both 12.1.1 and 12.2.2, its structure is stable across those releases, though Oracle may revise the privatized implementation without notice.