Search Results fa_inventory_u1

Overview

FA.FA_INVENTORY is a transactional configuration table in the Oracle E-Business Suite Fixed Assets (FA) module. It defines named "physical inventory" runs — discrete, time-bounded cycles during which an organization reconciles its recorded asset register against assets physically observed on site. Each row represents a single inventory definition, carrying its own name, valid date range, and a flag that governs whether the purge process will clean up its associated records. In Oracle EBS 12.1.1 and 12.2.2 the table resides in the APPS_TS_TX_DATA tablespace under the FA schema, with FND Design Data registered as OFA.FA_INVENTORY.

From a Data Vault modeling perspective, the mined relationship structure classifies FA.FA_INVENTORY as hub-leaning. It is referenced by FA_INV_INTERFACE via the INVENTORY_NAME column, and it does not itself reference any other database object. This suggests treating INVENTORY_NAME as a durable business key around which an inventory hub could be constructed, with descriptive attributes such as START_DATE, END_DATE, and RUN_PURGE_FLAG modeled as satellite columns. The table is a low-cardinality, master-style object rather than a high-volume transactional fact.

Key Information Stored

The documented physical schema contains nine columns. The most significant are:

• INVENTORY_NAME (VARCHAR2 80) — the business identifier for the inventory run. This column is the primary key (FA_INVENTORY_PK) and is also enforced by the unique index FA_INVENTORY_U1 in the APPS_TS_TX_IDX tablespace, making it the single business-key candidate for the table.
• START_DATE (DATE) — the effective start of the inventory window; controls which asset transactions and interface rows fall within the cycle.
• END_DATE (DATE) — the closing boundary of the inventory window. Together with START_DATE it defines the reporting period for reconciliation and variance analysis.
• RUN_PURGE_FLAG (VARCHAR2) — flag determining whether purge processing should remove stale interface records linked to this inventory name.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns captured on every DML operation.
• CREATED_BY, CREATION_DATE — insertion audit information identifying the original creator and timestamp.

The table is not a surrogate-key design in the classical sense; the natural business key INVENTORY_NAME doubles as the primary key, and there is no separate numeric ID column.

Common Use Cases and Queries

Typical reporting scenarios include listing all open inventories, validating overlapping date ranges before creating a new cycle, and identifying inventories configured for purge. Because the unique index FA_INVENTORY_U1 is on INVENTORY_NAME, lookups by that column are indexed and efficient.

• Active inventory list: SELECT inventory_name, start_date, end_date FROM fa.fa_inventory WHERE SYSDATE BETWEEN start_date AND end_date;
• Purge candidates: SELECT inventory_name FROM fa.fa_inventory WHERE run_purge_flag = 'Y' AND end_date < SYSDATE;
• Interface reconciliation: join to FA_INV_INTERFACE to count records awaiting physical confirmation: SELECT i.inventory_name, COUNT(*) FROM fa.fa_inventory i, fa.fa_inv_interface f WHERE i.inventory_name = f.inventory_name GROUP BY i.inventory_name;
• Audit trail: retrieve last_updated_by, last_update_date to trace configuration changes.

These queries support physical inventory reconciliation reports, period-close validation, and interface cleanup routines in the FA module.

Related Objects

• FA.FA_INV_INTERFACE — the primary dependent object. It holds physical inventory interface rows and references FA_INVENTORY via INVENTORY_NAME. This is the most significant join path in the schema.
• FA_INVENTORY (APPS synonym/view) — the APPS-layer synonym exposing FA.FA_INVENTORY to the application schema, used by concurrent programs and forms.
• Fixed Assets standard APIs — physical inventory processing and purge concurrent programs read INVENTORY_NAME, START_DATE, END_DATE, and RUN_PURGE_FLAG to drive their logic.

Because FA_INVENTORY has no outgoing foreign keys, its dependency graph is shallow: it functions as a parent reference for the interface table and a configuration anchor for FA physical inventory processing.