Results for “je_nl_eft_specs”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The AP.JE_NL_EFT_SPECS table is an Oracle E-Business Suite localization object that stores formatting specifications for Dutch Electronic Funds Transfer (EFT) payment processing. It belongs to the JE - European Localizations product family and resides in the AP (Payables) schema. Its role is to hold the per-payment records that drive the layout and content of the EFT file generated for Dutch bank submissions, ensuring each disbursement conforms to the local payment format mandated by Dutch financial institutions.

The table is registered as VALID and is described in ETRM as holding "Information for Dutch EFT Payment formatting." Under the heuristic Data Vault classification mined from its foreign key structure, the object is treated as standalone. This classification is a modeling suggestion only; it indicates that the table does not participate in a parent-child FK dependency chain with other documented objects and may reasonably be modeled as an isolated hub or independent reference entity rather than as a link or satellite within a Data Vault design.

Key Information Stored

The documented physical schema for 12.2.2 contains seven columns. The principal business columns are:

• CHECKRUN_NAME — identifies the payment batch or check run to which the EFT specification belongs; a component of the composite primary key.
• CHECK_NUMBER — the individual payment or check identifier within the run; the second component of the composite primary key.
• LAST_UPDATE_DATE — audit timestamp of the most recent change.
• LAST_UPDATED_BY — the application user who performed the last update.
• CREATION_DATE — audit timestamp of row creation.
• CREATED_BY — the application user who created the row.
• LAST_UPDATE_LOGIN — the login identifier associated with the last update.

The surrogate primary key is defined by the constraint JE_NL_EFT_SPECS_PK on the composite of CHECKRUN_NAME and CHECK_NUMBER. There is no separate system-generated surrogate column documented; the PK is a natural business key composed of the payment run name and the payment number. Together these two columns uniquely identify a single EFT specification record. The remaining five columns are standard Oracle audit columns and are not business-key candidates.

Common Use Cases and Queries

Typical usage centers on the Dutch EFT payment program during Payables payment processing. The payment program writes one specification row per payment in the run, keyed by CHECKRUN_NAME and CHECK_NUMBER, and downstream formatting logic reads these rows to emit the EFT file. Reporting and reconciliation queries commonly filter by payment run:

• Retrieve all specifications for a given run: SELECT CHECK_NUMBER FROM AP.JE_NL_EFT_SPECS WHERE CHECKRUN_NAME = :run_name.
• Audit recent changes: filter on LAST_UPDATE_DATE to identify records modified after a cutoff, joining to FND_USER on LAST_UPDATED_BY to resolve user names.
• Verify completeness by counting specification rows and comparing the result to the payment count for the same run in the payment tables.

Because the table is standalone and narrow, it is most useful as a lookup or verification source alongside Payables payment data rather than as a primary reporting subject.

Related Objects

Given the standalone classification and the composite key on CHECKRUN_NAME and CHECK_NUMBER, the most significant related objects are those that supply the payment run and payment context:

• AP_CHECKS_ALL — the core payment table; joins on CHECKRUN_NAME and CHECK_NUMBER to link a specification to the underlying payment.
• AP_INVOICE_PAYMENTS_ALL — associates payments to invoices, enabling invoice-level traceability for each EFT specification.
• AP_PAYMENT_SCHEDULES_ALL — provides scheduled payment details for the associated payment.
• IBY_PAYMENTS_ALL / IBY_PAY_INSTRUCTIONS_ALL — Payments module tables that hold payment instruction and formatting context.
• FND_USER — resolves CREATED_BY and LAST_UPDATED_BY for audit reporting.
• JE_NL_EFT_SPECS_PK — the primary key constraint that enforces uniqueness on the run and payment number pair.

These relationships are inferred from the documented key structure and standard Payables localization behavior; no explicit foreign keys to external tables are recorded in the supplied metadata.