Search Results fv_voided_checks




Overview
Explore in AI Chat

Overview

FV_VOIDED_CHECKS is a Federal Financials (FV) module table in Oracle E-Business Suite, owned by the FV schema and documented as VALID in both 12.1.1 and 12.2.2. It stores checks that have been voided in Oracle Payables and serves as the staging repository consumed by the DIT (Data Improvement Team / disbursement interim) Voided Check process. Because Federal Financials must reconcile disbursement activity against Treasury reporting, voided payments must be captured in a dedicated table rather than inferred solely from Payables status flags. FV_VOIDED_CHECKS provides that durable record, linking the void event back to the underlying payment instruction.

From a dimensional modeling perspective, the object is a standalone transaction table rather than a conformed hub, link, or satellite. Its foreign key to IBY_PAY_INSTRUCTIONS_ALL through PAYMENT_INSTRUCTION_ID associates each void record with a payment instruction, while the absence of broader FK relationships suggests a narrow, event-oriented scope. Analysts building a Data Vault representation should consider treating this as a link between the payment instruction hub and a void-event hub, though the documented schema does not currently support that decomposition.

Key Information Stored

The table contains 12 documented columns. The surrogate primary key VOID_ID, enforced by the constraint FV_VOIDED_CHECKS_PK, uniquely identifies each void record. A second unique index, FV_VOIDED_CHECKS_U1, is defined on CHECK_ID, making CHECK_ID the principal business-key candidate and preventing duplicate voids on the same check.

  • VOID_ID — Surrogate primary key for the void transaction record.
  • CHECK_ID — Business key identifying the voided check; uniquely indexed.
  • CHECKRUN_NAME — Name of the check run from which the voided check originated, supporting reconciliation by payment batch.
  • PAYMENT_INSTRUCTION_ID — Foreign key to IBY_PAY_INSTRUCTIONS_ALL, tying the void to its payment instruction.
  • EVENT_ID — Identifier associating the void record with the event that generated it, relevant to subledger accounting and Treasury reporting.
  • ORG_ID — Operating unit identifier, enabling multi-org secured queries and reporting.
  • PROCESSED_FLAG — Indicates whether the DIT Voided Check process has already consumed the row, used to prevent reprocessing.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard EBS audit columns capturing insert and update provenance.

Common Use Cases and Queries

The primary use case is identifying voided checks awaiting or completing DIT processing. A typical query filters unprocessed rows within an operating unit:

  • SELECT void_id, check_id, checkrun_name, payment_instruction_id FROM fv.fv_voided_checks WHERE org_id = :org AND processed_flag = 'N';
  • Reconciliation of a specific payment instruction: join on PAYMENT_INSTRUCTION_ID to confirm which checks were voided against a given instruction.
  • Batch-level reporting by CHECKRUN_NAME to quantify void volume per check run over a period using CREATION_DATE.
  • Audit trails resolving CREATED_BY and LAST_UPDATED_BY to FND_USER for provenance reporting.

Reports should always include ORG_ID predicates to respect multi-org security, and PROCESSED_FLAG should be reviewed before reprocessing any row.

Related Objects

  • IBY_PAY_INSTRUCTIONS_ALL — Referenced via PAYMENT_INSTRUCTION_ID; the parent payment instruction for each void.
  • AP_CHECKS_ALL — Source of the voided check identified by CHECK_ID in Oracle Payables.
  • FV_VOIDED_CHECKS_PK / FV_VOIDED_CHECKS_U1 — The primary key and unique index constraints governing row identity.
  • FND_USER — Resolves audit columns CREATED_BY, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.
  • HR_ALL_OPERATING_UNITS / FND_ORG_SECURITY — Provide the operating unit context for ORG_ID.