Search Results fte_vehicle_pkg




Overview
Explore in AI Chat

Overview

APPS.FTE_VEHICLE_PKG is a PL/SQL package in Oracle E-Business Suite (12.1.1 and 12.2.2) that serves as the primary programmatic interface for defining and maintaining vehicle types within the Oracle Transportation Management / Fleet Management footprint bundled with EBS. Translated literally from the German "Fuhrpark" (vehicle fleet), the object belongs to the broader transportation execution feature set that allows organizations to model their physical carriage assets as standardized, reusable vehicle type definitions. The package encapsulates the business logic required to create and update vehicle types, validate their attribute completeness, and synchronize each vehicle type with a corresponding inventory master item in Oracle Inventory. The package is declared with AUTHID CURRENT_USER, meaning all SQL statements execute under the privileges and schema resolution context of the calling user rather than the package owner, which is significant for implementations where APPS synonyms must resolve correctly.

Key Procedures and Functions

  • CREATE_UPDATE_VEHICLE_TYPE — The central procedure of the package. It creates a new vehicle type or updates an existing one by maintaining the FTE_VEHICLE_TYPES base and translation tables, inserting, updating, or deleting associated feature rows in FTE_VEHICLE_FEATURES, and delegating inventory item creation or update to INV_ITEM_GRP.CREATE_ITEM / UPDATE_ITEM so that each vehicle type is mirrored as a master item. Its parameter surface covers main properties, load capacities, dimensions, features, door specifications, and a set of descriptive attributes.
  • VALIDATE_VEHICLE_TYPE — Performs consistency and completeness validation on a prospective or existing vehicle type definition before persistence, guarding against invalid UOM codes, missing mandatory attributes, and inconsistent capacity or dimensional values.
  • UPGRADE_ITEMS — Supports data migration or patching activity by re-aligning existing vehicle type records with their underlying inventory master items, typically invoked during upgrades or retrofits of pre-existing vehicle data.
  • GET_VEHICLE_TYPE_ID — A lookup function that resolves the internal vehicle type identifier from supplied business keys, allowing callers to avoid direct table queries.
  • GET_VEHICLE_ORG_ID — Returns the relevant inventory organization identifier associated with the vehicle type, establishing the inventory context under which the mirrored item resides.

Tables Accessed

The package reads and writes FTE_VEHICLE_TYPES and FTE_VEHICLE_TYPES_S (the base and translation/denormalized store for vehicle type headers), and FTE_VEHICLE_FEATURES with FTE_VEHICLE_FEATURES_S for the feature-level detail rows. It consults MTL_SYSTEM_ITEMS and MTL_PARAMETERS to validate and locate the mirrored inventory item and organization defaults, MTL_ITEM_STATUS to apply valid item lifecycle statuses, and MTL_UNITS_OF_MEASURE_TL to validate weight, volume, and dimension unit-of-measure codes. WSH_GLOBAL_PARAMETERS supplies shipping execution global settings, while PLITBLM is used as a PL/SQL index-by table type for the feature array parameter. All references resolve through APPS synonyms.

Usage Notes

FTE_VEHICLE_PKG is characteristically invoked indirectly rather than from ad hoc scripts. In standard EBS flows it is called by the Fleet/Transportation setup forms and by concurrent programs that maintain vehicle type master data, and it is referenced by five other packages in the same product family, confirming its role as a shared service routine. Customizations that need to mass-create or mass-update vehicle types should call CREATE_UPDATE_VEHICLE_TYPE rather than inserting into the FTE tables directly, because the procedure also drives the corresponding Oracle Inventory item maintenance through INV_ITEM_GRP. Existing vehicle data carried forward from earlier releases should be reconciled with UPGRADE_ITEMS after patching. Because the package executes as the calling user, implementers must verify that custom callers possess the necessary privileges on the underlying MTL and FTE tables and that APPS synonyms are correctly resolved in the target environment.