Search Results sec_amount_g

Overview

FII_AP_INV_B_V2 is an Oracle EBS APPS-schema view that belongs to the Financial Intelligence (FII) product family, the analytical and reporting layer historically shipped with Oracle Financials and E-Business Suite analytics. In Oracle EBS 12.1.1 and 12.2.2, FII objects serve as denormalized, reporting-friendly representations of transactional data sourced from the Payables subledger and generalized into a star-schema-style model. FII_AP_INV_B_V2 presents Payables invoice distribution data at a level suitable for financial analysis, budgeting comparisons, and integration with external reporting or extraction processes.

The view has a documented status of VALID and is owned by APPS. Its definition projects a subset of columns from its parent object, FII_AP_INV_B, renaming the ACTUAL_G column to SEC_AMOUNT_G in the process. This aliasing is significant for report authors, since the user search term "sec_amount_g" corresponds directly to this exposed column. In 12.1.1 and 12.2.2 the view definition is effectively identical, as FII is a legacy analytic schema that was not materially re-architected between these releases, though 12.2.x introduces the Online Patching (adop) editioning model that governs physical objects in the APPS schema. References to the view should therefore use the standard APPS synonym or fully qualified APPS.FII_AP_INV_B_V2 syntax.

Underlying Base Objects

The documented definition of FII_AP_INV_B_V2 is a simple projection over a single base view, FII_AP_INV_B:

SELECT ACCOUNT_DATE, SEC_AMOUNT_G, COST_CENTER_ORG_ID, INVOICE_ID, SUPPLIER_ID, FIN_CATEGORY_ID, CHART_OF_ACCOUNTS_ID, POSTED_FLAG, COMPANY_ID, COST_CENTER_ID FROM FII_AP_INV_B

Because the ETRM metadata documents no further referenced base tables, the underlying pages of FII_AP_INV_B are not enumerated here. As a general rule of the FII model, the FII_AP_INV_B family ultimately derives from Payables invoice and distribution tables (AP_INVOICES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL) joined to FII dimension/staging constructs. The "B" suffix in the FII naming convention typically denotes a "base" or balance-oriented variant. Practitioners needing the authoritative dependency chain should query ALL_DEPENDENCIES or ALL_VIEWS in the target instance rather than assume the physical lineage, since local customizations or patches may alter the intermediate layer.

Key Columns

• ACCOUNT_DATE — The accounting date associated with the invoice/distribution, used as the primary time dimension for period-based reporting.
• SEC_AMOUNT_G — The secondary (functional or reporting) currency amount, exposed by aliasing ACTUAL_G from the base view. This is the column targeted by searches for "sec_amount_g" and supports currency-specific analysis.
• COST_CENTER_ORG_ID — The organization identifier for the cost center, enabling organizational rollups.
• INVOICE_ID — Surrogate key linking back to the Payables invoice.
• SUPPLIER_ID — Reference to the supplier/vendor.
• FIN_CATEGORY_ID — The financial category used to classify the transaction for analytical grouping.
• CHART_OF_ACCOUNTS_ID — Identifies the chart of accounts in multi-chart environments.
• POSTED_FLAG — Indicates whether the transaction has been posted to the general ledger.
• COMPANY_ID and COST_CENTER_ID — Organization dimension keys used for hierarchical reporting.

Common Use Cases and Queries

Typical scenarios include period-end spend analysis, supplier cost aggregation, and extraction feeds into a data warehouse. A representative query filtering on the amount column and accounting period:

SELECT invoice_id, supplier_id, company_id, sec_amount_g, account_date
FROM apps.fii_ap_inv_b_v2
WHERE account_date BETWEEN :p_from AND :p_to
AND posted_flag = 'Y'
ORDER BY account_date;

Aggregation by financial category is equally common:

SELECT fin_category_id, SUM(sec_amount_g) total_amt
FROM apps.fii_ap_inv_b_v2
WHERE company_id = :p_company
GROUP BY fin_category_id;

Because the view is a thin projection, it carries no additional filter logic; all slicing, posting-status filtering, and date restriction must be applied by the calling report or interface. Applications should treat the view as read-only and avoid DML against it.