Search Results create_status_record

Overview

FVFCCHKB_PKG is a Treasury/Financials edit-check validation package in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 releases. It belongs to the Treasury module family, as indicated by the FV_ prefix on both the package itself and its supporting tables (for example, FV_FACTS_TEMP and FV_TREASURY_SYMBOLS). The package is owned by the APPS schema and classified as OTHER under the ETRM documentation model, meaning it is not registered as a public, supported API. It is instead an internal validation engine invoked during treasury reconciliation and reporting workflows.

The core business function of FVFCCHKB_PKG is to execute a series of edit checks ("Check B" per the package name suffix) against treasury data staged in temporary and reporting tables. These checks verify accounting integrity—such as ensuring that credits and debits balance for budgetary accounts, validating SGL (Standard General Ledger) account mapping, and confirming that reported data conforms to expected treasury symbol structures before it is committed to the Federal Treasury reporting process.

Key Procedures and Functions

The documented ETRM metadata lists a single public procedure: PERFORM_EDIT_CHECKS. This is the entry point for the package's validation logic. It orchestrates the execution of the individual edit-check routines (internally labeled edit_check_1, etc.) and aggregates their results into the edit-check status tables. The exact parameter list is not documented in the available metadata and should not be assumed.

The source excerpt reveals additional private (declare-only) procedures that support the work of PERFORM_EDIT_CHECKS:

• create_status_record — records the outcome of an individual edit check (check number and check status) into the FV_FACTS_EDIT_CHECK_STATUS table. This is the procedure most relevant to the user's search term "create_status_record."
• create_log_record — writes diagnostic text and contextual detail (for example, the SGL account number and amount that failed a check) into a logging buffer for troubleshooting.
• edit_check_1 — a specific validation routine that uses the check1 cursor to sum credit and debit ending balances for budgetary accounts (SGL accounts beginning with '4') from FV_FACTS_TEMP, then verifies the totals are balanced.
• init_vars — resets package-level global variables (edit check number, edit check status, amount accumulators, SGL account number, log text, and row count) before each check executes.

Tables Accessed

The package reads from and writes to the following documented tables (referenced through APPS synonyms):

• FV_FACTS_TEMP — the primary staging table for treasury fact records. The edit-check cursors select reported block detail rows (fct_int_record_type = 'BLK_DTL') from here.
• FV_FACTS_EDIT_CHECK_STATUS — the destination for edit-check results written by create_status_record.
• FV_FACTS_AUTHORIZATIONS — captures authorization context for submitted facts.
• FV_FACTS_SUBMISSION — identifies the submission under validation.
• FV_FACTS_RT7_ACCOUNTS and FV_FACTS_RT7_CODES — support RT7 (Treasury Report 7) account and code validation.
• FV_FACTS_USSGL_ACCOUNTS — provides the U.S. Standard General Ledger account hierarchy used for account-mapping checks.
• FV_TREASURY_SYMBOLS — supplies the treasury symbol (g_treasury_symbol_id) that scopes every edit check to a specific reporting entity.
• DUAL — used for singleton queries and sequence-like value retrieval.

Usage Notes

FVFCCHKB_PKG is an internal, non-public package. Because the ETRM metadata reports zero packages referencing it, it is not exposed as a shared API to other PL/SQL units. In practice it is invoked indirectly—typically from a concurrent program or a Treasury module form that runs the edit-check validation for a given submission or treasury symbol. The package sets the global g_treasury_symbol_id before executing its checks, so any caller must supply a valid treasury symbol context.

Customizations should avoid calling create_status_record or the perform routine directly unless the caller establishes the same initialization sequence (init_vars followed by symbol assignment) that the package expects. Because the package is not registered as an API in ETRM, Oracle does not guarantee backward compatibility across patches; any direct invocation from custom code should be validated after each EBS patch or upgrade.