Search Results fv_1099c




Overview
Explore in AI Chat

Overview

FV_FLATFILES is an Oracle E-Business Suite package body owned by APPS that generates flat file output for federal financial reporting and payment-related concurrent programs. It serves as a central dispatch routine for producing the physical data files required by U.S. Treasury and agency-specific reporting formats, most notably the GOALS FMS 1219/1220 reports and related FACTS (Federal Agencies' Centralized Trial-Balance System) submissions. The package is classified as OTHER in the ETRM metadata, indicating that it is not a public API but an internal implementation package invoked through the concurrent manager rather than through external programmatic interfaces.

The design follows a common EBS pattern: a single entry point, MAIN, accepts the concurrent program short name and standard concurrent request parameters, then routes processing to the appropriate generation logic. This allows a single package to back multiple concurrent program definitions while sharing common initialization, request-tracking, and error-handling code.

Key Procedures and Functions

  • MAIN — The primary entry point for the package and the procedure recognized by the concurrent program definition. It accepts the standard concurrent manager OUT parameters (errbuf, retcode) plus a conc_prog argument identifying the calling concurrent program, along with numbered positional parameters passed from the concurrent program definition. Within MAIN, the value of conc_prog is evaluated in a conditional dispatch, directing execution to the correct flat file generator. For example, when conc_prog equals 'FV1219BF', the package calls FV_1219_TRANSACTIONS.gen_flat_file to produce the 1219/1220 transactions flat file, subject to the reporting mode parameter. When conc_prog equals 'FVFCTHRC', processing related to the FACTS withholding report is selected. Messages are written to the concurrent program log and output file using FND_FILE.PUT_LINE.
  • CREATE_FLAT_FILE — A supporting routine responsible for assembling and writing flat file records. It encapsulates the low-level formatting, record concatenation, and file output operations reused across the individual report formats, so that each concurrent program branch in MAIN need only supply its data and control values.

Tables Accessed

The package references the following application tables (through APPS synonyms), all of which support FACTS reporting and payment formatting:

  • FV_FACTS_SUBMISSION, FV_FACTS_TEMP — Submission-level control data and the temporary staging area holding extracted balances and entities before formatting.
  • FV_FACTS_FOOTNOTE_HDR, FV_FACTS_FOOTNOTE_LINES — Header and line records for FACTS footnotes, used to emit footnote counts and detail into the flat file.
  • FV_PAYMENT_FORMAT_TEMP — Temporary staging of payment format records, used when producing payment-related flat files.
  • FV_1099C — The 1099-C cancellation-of-debt table, referenced for report extracts requiring creditor and TIN information.
  • DBMS_SQL — Oracle's dynamic SQL package, used to construct and execute statements at runtime where the file layout or query is determined by concurrent program parameters.

Usage Notes

FV_FLATFILES.MAIN is registered as the executable for one or more concurrent programs within the Federal Financials (FV) application, most commonly the GOALS FMS 1219/1220 Report program and the FACTS-related extraction programs. The conc_prog parameter is supplied by the concurrent program definition and identifies which output layout is required; the remaining numbered parameters carry the request ID, SOB (set of books) identifier, and mode indicators such as the reporting mode ('F' for final versus preliminary).

When the 1219/1220 request set is submitted in Preliminary mode, the package deliberately suppresses flat file creation and writes an explanatory message to the output file, reflecting the business rule that official GOALS flat files are produced only from finalized data. The package is referenced by four other packages and should be treated as an internal component; customizations should avoid direct calls to MAIN and instead duplicate the concurrent program registration or wrap the documented behavior, since changes to parameter ordering or dispatch logic may affect dependent modules.