Search Results generated_offset_ccid

Overview

FA_XLA_CMP_CCID_PKG is a private Oracle Assets (FA) package whose stated purpose is to create the Code Combination ID (CCID) extract for each extract type used by the Subledger Accounting (XLA) integration. In Oracle E-Business Suite, the Create Accounting process for Assets requires each accounting line to be mapped to a valid General Ledger chart of accounts combination. This package supplies the logic that derives, validates, and loads those generated CCIDs into the extract lines structure so that the accounting engine can associate a distribution account with every transaction line. The header comment identifies it as an FA private package containing "all the APIs required for to create ccid extract for each extract type," indicating it is not exposed as a public API but is called internally by the Assets accounting extraction flow.

The package body embeds large constant VARCHAR2(32000) strings (for example C_PRIVATE_API_1 and C_PRIVATE_API_DEPRN) that hold dynamically constructed PL/SQL blocks. This metadata-driven design allows the same package to execute different CCID generation logic depending on the extract type and the related application, and it explains the documented dependency on DBMS_SQL.

Key Procedures and Functions

ETRM documents a single public entry point:

• GENERATECCIDEXTRACT — The primary API through which callers request CCID extraction for a given extract type. It orchestrates the generation and loading of account code combinations.

Within the package body, a private procedure named Load_Generated_Ccids is defined in the embedded dynamic PL/SQL source. Its header identifies it as an "Account Generator Hook," and it is referenced internally as fa_xla_extract_def_pkg.load_generated_ccids, with a comment noting a possible future refinement to make the reference dynamic by type. This private procedure accumulates messages and log output during CCID generation and relies on dynamic SQL to perform its work.

Tables Accessed

Per the documented metadata, the only referenced object via APPS synonyms is DBMS_SQL, the Oracle-supplied dynamic SQL package. This confirms that FA_XLA_CMP_CCID_PKG does not execute static DML against a fixed extraction table; instead it parses, binds, and executes SQL statements assembled at runtime. Because the embedded source includes record definitions for extract lines (fields such as rowid, book_type_code, distribution_id, and distribution_ccid), the dynamically generated statements target the Assets XLA extract lines structures. This is also consistent with the search term fa_xla_ext_lines_b_gt_u1, which corresponds to a global temporary table used to stage XLA extract lines (including their CCID column) during Create Accounting processing. The package therefore functions as a producer of CCID values into that extract line staging area rather than as a consumer of base transaction tables directly.

Usage Notes

FA_XLA_CMP_CCID_PKG is typically invoked indirectly, not from a user-facing form. Its callers are other Assets accounting programs: the documented metadata records that it is referenced by one other package, and the internal naming convention points to FA_XLA_EXTRACT_DEF_PKG as the coordinating extraction package. Downstream of the Create Accounting concurrent program (and the related Create Accounting: Assets execution), the extract definition logic calls GENERATECCIDEXTRACT to populate account combinations for the extract lines before they are consumed by the XLA accounting engine.

Because the package is a private FA component, custom code should not call it directly; integrations should use the supported Create Accounting flows and the XLA accounting APIs instead. When diagnosing a failure such as an invalid CCID on an Assets accounting line, DBAs commonly enable logging and inspect the staging content in the fa_xla_ext_lines_b_gt_u1 global temporary table, since that table holds the extract lines populated by this package's dynamic generation logic. The package is delivered at version 120.6.12010000.1 (2008), so its behavior is consistent across the 12.1.1 and 12.2.2 releases, with no functional change noted in the metadata.