Search Results ahl_fleet_unit_assocs

Overview

AHL_FLEET_UNIT_ASSOCS is a table in the AHL schema belonging to the Complex Maintenance Repair and Overhaul (CMRO) product family within Oracle E-Business Suite 12.1.1 and 12.2.2. The table records the association between a fleet and the unit configurations that belong to it over a defined period of time. In aerospace, defense, and high-value asset maintenance operations, a "fleet" is a logical grouping of serialized units—aircraft, engines, or repairable components—managed together, while a "unit configuration" describes the as-built or as-maintained configuration of a specific unit. AHL_FLEET_UNIT_ASSOCS is the intersection that ties the two together, capturing the effective date range during which a given unit configuration was associated with a given fleet.

The ETRM relationship metadata classifies this table heuristically as standalone under the Data Vault model, meaning that based on its foreign-key structure the object behaves as an independent record set rather than as a pure link between two hubs. In practice, however, the presence of FLEET_HEADER_ID alongside UNIT_CONFIG_HEADER_ID makes it functionally resemble a link table with an edge, carrying its own start and end dates. Modelers may therefore reasonably treat it as either a standalone entity or a dated link, depending on how the fleet and unit configuration hubs are defined in their warehouse design.

Key Information Stored

The table contains 14 documented columns. The surrogate primary key is FLEET_UNIT_ASSOC_ID, an internal system-generated identifier that uniquely identifies each association row. Business-key candidates include the combination of FLEET_HEADER_ID and UNIT_CONFIG_HEADER_ID together with the effective dates ASSOCIATION_START and ASSOCIATION_END; this tuple typically defines the time-bound relationship between a fleet and a unit configuration.

• FLEET_UNIT_ASSOC_ID — surrogate primary key for the association record.
• FLEET_HEADER_ID — reference to the fleet header to which the unit configuration is attached.
• UNIT_CONFIG_HEADER_ID — foreign key to AHL_UNIT_CONFIG_HEADERS, identifying the specific unit configuration linked to the fleet.
• ASSOCIATION_START — effective start date (and time) of the fleet-to-unit-configuration association.
• ASSOCIATION_END — effective end date of the association; a null or open value typically indicates an active association.
• SIMULATION_PLAN_ID — foreign key to AHL_SIMULATION_PLANS_B, tying the association to a simulation or planning scenario when the row is used in what-if analysis.
• RECONFIG_SR_ID — identifier linking the association to a reconfiguration service request that drove the fleet/unit change.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, supporting row-level access control across operating units and responsibilities.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the AHL (OAF) framework to detect concurrent updates.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns recording creation and last modification metadata.

Common Use Cases and Queries

The most common reporting requirement is to retrieve the currently active unit configurations for a given fleet, or to reconstruct the historical configuration of a fleet as of a specific date. A typical active-association query filters on the fleet and the effective date window:

• SELECT fua.unit_config_header_id, fua.association_start, fua.association_end FROM ahl_fleet_unit_assocs fua WHERE fua.fleet_header_id = :fleet_id AND TRUNC(SYSDATE) BETWEEN fua.association_start AND NVL(fua.association_end, TRUNC(SYSDATE));
• Historical as-of analysis: substitute a bind parameter for SYSDATE and compare against ASSOCIATION_START and ASSOCIATION_END to determine which configurations were valid on that date.
• Reconfiguration traceability: join to RECONFIG_SR_ID to report which service requests caused fleet composition changes.
• Simulation planning: filter on SIMULATION_PLAN_ID to isolate fleet composition used in a specific simulation plan.
• Security-scoped reporting: join SECURITY_GROUP_ID to FND_SECURITY_GROUPS to restrict results to the current user's security profile.

Because the table carries OBJECT_VERSION_NUMBER and WHO columns, integrations should read but not write these values directly; changes are normally made through CMRO application flows rather than by direct DML.

Related Objects

The FK metadata documents three direct parent references, and additional related objects participate through the fleet header and unit configuration relationships:

• AHL_UNIT_CONFIG_HEADERS — joined on UNIT_CONFIG_HEADER_ID; source of the unit configuration definition associated with the fleet.
• AHL_SIMULATION_PLANS_B — joined on SIMULATION_PLAN_ID; base table for the simulation plan under which the association applies.
• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID; enforces multi-org/row-level security.
• AHL_FLEET_HEADERS (via FLEET_HEADER_ID) — the fleet definition to which the association belongs; the primary business parent of this table.
• Service Request tables (via RECONFIG_SR_ID) — the reconfiguration service request that triggered the association change, typically in the CMRO service request model.
• AHL_UNIT_CONFIG_HEADERS_B / unit configuration child tables — used indirectly to expand configuration details for each associated unit.

Collectively these relationships position AHL_FLEET_UNIT_ASSOCS as the dated bridge between fleet composition and unit configuration history, and it is a key source for fleet configuration reporting and CMRO reconfiguration traceability in Oracle EBS.