Search Results trx_attribute

Overview

FA_ASSET_TRACE_PKG is an Oracle EBS Assets (FA) diagnostic and tracing package body owned by APPS. Its principal business function is to assemble and emit a detailed audit trail for a fixed asset across its entire lifecycle, consolidating information from asset definition, book assignment, transactions, and subledger accounting. The package body carries the header identifier faxtrcb.pls 120.27.12010000.4, indicating a mature, frequently revised implementation in the 12.1.1 and 12.2.2 code lines. It is classified as an OTHER API rather than a public business API, meaning it is intended for internal diagnostic, support, and troubleshooting use rather than for transactional integration by third parties. Practitioners commonly reach this object when investigating unexpected asset balances, depreciation results, or accounting entries, and its output is designed to explain, trace by trace, how Oracle Assets derived a given result.

Key Procedures and Functions

The ETRM documentation records two externally visible callable units on this package body:

• DO_TRACE — The primary entry point that drives the trace operation. It accepts a caller-supplied trace attribute or asset identifier and orchestrates the collection of asset, book, transaction, and distribution information into the trace output. In practice this is the procedure invoked when a user requests an asset trace from a diagnostic or support context.
• GET_DIST_INFO — Retrieves and returns distribution and accounting distribution details associated with a traced asset or transaction, supporting the subledger accounting portion of the trace.

Beyond these documented procedures, the package body header exposes a broader internal structure that supports the trace engine, including fafsc and fparse_header helper functions, table-loading routines such as load_tbls, load_setup_tbls, deprn_calc_info, and load_xla_info, a subrequest submission routine submit_subrequest, an advanced-queue coordination pair (enqueue_request and dequeue_request), and a log utility. These confirm that the trace executes as a coordinated, logged operation rather than a single query.

Tables Accessed

The package reads from core Oracle Assets and Oracle Application Object Library tables through APPS synonyms:

• FA_ADDITIONS and FA_ADDITIONS_B — current and base asset master rows, supplying the asset description, identification, and attribute values that anchor the trace (relevant to the th_attribute search, which resolves to transaction header attribute columns).
• FA_BOOKS and FA_BOOK_CONTROLS — book-level asset cost, depreciation, and book control parameters used for depreciation and balance trace steps.
• FA_TRANSACTION_HEADERS — transaction header records that give each trace its attribute context and transaction history.
• FND_ID_FLEX_SEGMENTS, FND_PROFILE_OPTION_VALUES, and FND_PRODUCT_GROUPS — key flexfield structure, profile option values, and product group/schema resolution.
• GAT_MESSAGE_TYPE and DBA_OBJECTS — message type definitions and object metadata inspection.
• DBMS_AQ, DBMS_AQADM, DBMS_LOCK, DBMS_SESSION, and PLITBLM — Oracle-supplied packages used for queue-based request coordination, locking, session context, and PL/SQL table handling.

Usage Notes

FA_ASSET_TRACE_PKG is typically invoked interactively from an Oracle Assets trace or diagnostic form, or indirectly from a concurrent program that drives DO_TRACE. Because it is classified as an OTHER API, the documented contract is limited and Oracle does not guarantee signature stability across patches. The package is referenced by one other package, indicating internal reuse within the FA diagnostic layer. Custom code should not depend on the internal helper routines; where tracing is required programmatically, call DO_TRACE or GET_DIST_INFO and treat the output as informational. Support personnel should be aware that the procedure submits subrequests and coordinates through DBMS_AQ, so concurrent manager availability and queue configuration can affect successful execution. Given the 2008 vintage of the header revision shipped into 12.1.1 and 12.2.2, the trace logic reflects pre-12.2 accounting only to the extent of its XLA integration routines; in 12.2.2 installations, subledger accounting trace information is gathered through the load_xla_info path.