Search Results ap_terms_val_v




Overview
Explore in AI Chat

Overview

AP_TERMS_VAL_V is a validation view owned by the APPS schema in Oracle E-Business Suite, registered under the Payables (AP) product family. Its documented purpose is to expose active payment terms for validation and list-of-values purposes. The view's underlying SQL applies a date-range filter against the AP_TERMS table so that only payment terms whose active date window includes the current system date are returned to the calling form or process.

The suffix convention "_VAL_V" identifies this object as a validation view, a standard Oracle EBS design pattern used to populate key and descriptive flexfield value sets, list-of-values (LOV) regions, and lookup validation logic. Rather than querying AP_TERMS directly, forms and concurrent programs reference AP_TERMS_VAL_V to ensure that inactive or expired payment terms are never offered to a user during data entry.

According to the ETRM metadata, this view is documented as "(Release 10SC Only)". This annotation indicates that the view originated in an early release of the product and remains catalogued for backward compatibility. In Oracle EBS 12.1.1 and 12.2.2 the object persists as a VALID view in the APPS schema, and existing customizations or integrations may still reference it.

Underlying Base Objects

The view is defined over a single referenced base object, documented in the ETRM metadata as AP_TERMS, accessed through a synonym. AP_TERMS is the core Payables table that stores payment term definitions, including the term name, description, the number of discount days, discount percentages, due date basis, and the start and end dates that control when a term is eligible for use.

The view definition selects from AP_TERMS (aliased AT) and constrains the result set with a SYSDATE predicate. Specifically, SYSDATE must fall between NVL(AT.START_DATE_ACTIVE, SYSDATE - 1) and NVL(AT.END_DATE_ACTIVE, SYSDATE + 1). The NVL wrappers ensure that a term with a null start date is treated as effective from the prior day, and a term with a null end date is treated as effective through the next day. This construction effectively returns every term that is currently enabled while excluding terms whose start date is in the future or whose end date has already passed.

Because the view is a simple, non-joined projection over AP_TERMS, it inherits the base table's security and does not aggregate or transform the underlying data beyond the date filter.

Key Columns

  • NAME — The payment term name from AP_TERMS.NAME. This is the value typically presented in a list of values and is the identifier most users recognize when selecting terms on an invoice or supplier record.
  • DESCRIPTION — The descriptive text associated with the payment term, taken from AP_TERMS.DESCRIPTION. It provides supplementary context in LOV displays.
  • TERM_ID — The unique primary key of the payment term, sourced from AP_TERMS.TERM_ID. This numeric identifier is the value stored in foreign key columns on related transaction tables whenever a term is assigned, making it the critical column for programmatic joins and integration mappings.

Common Use Cases and Queries

The primary use case is validation of payment terms during data entry, where an LOV or value set is required to return only currently active terms. A typical query retrieving all active terms for display would be:

  • SELECT term_id, name, description FROM apps.ap_terms_val_v ORDER BY name;
  • SELECT term_id FROM apps.ap_terms_val_v WHERE name = :term_name;
  • SELECT COUNT(*) FROM apps.ap_terms_val_v;

The first query supports an LOV or reporting extract of active terms; the second resolves a term name to its TERM_ID for assignment on an invoice or supplier site; the third verifies how many terms are currently within their active window.

Because the view filters on SYSDATE, results are date-sensitive. A term that is valid today may be absent from the view tomorrow if its end date passes, which makes the view suitable for real-time validation but unsuitable for historical reporting. For historical or audit purposes, AP_TERMS should be queried directly without the date predicate.