Results for “freight_term”

50+ results




Overview
Explore in AI Chat

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

Overview

The view ASO_I_CUST_ACCOUNTS_V is an Oracle E-Business Suite database object owned by the APPS schema. It belongs to the ASO - Order Capture product family and is documented in ETRM as VALID for releases 12.1.1 and 12.2.2. Its stated purpose is to present information regarding customer accounts for use in the Order Capture and related order entry flows.

The view functions as a denormalized read-only access point that joins customer account records to the corresponding party records, exposing a single row per customer account enriched with the parent party name. Because it is a view rather than a table, it does not store data; instead it projects columns from the underlying Oracle Receivables / Trading Community Architecture (TCA) entities at query time. This makes it suitable for reporting, concurrent program logic, and integration queries where account-level attributes such as price list, order type, tax code, freight term, warehouse, and payment term must be retrieved alongside the customer identity. The freight_term column is of particular interest to users researching shipping and freight defaulting behavior, as it surfaces the account-level freight term directly.

Underlying Base Objects

Per the documented ETRM metadata, the view is defined over two referenced base objects, both exposed through synonyms in the APPS schema:

  • HZ_CUST_ACCOUNTS (SYNONYM) — aliased as ACCT, supplying the customer account identifier, account number, status, and the majority of the defaulting attributes.
  • HZ_PARTIES (SYNONYM) — aliased as PART, supplying the party name used to derive the CUSTOMER_NAME column.

The join is an inner join on PART.PARTY_ID = ACCT.PARTY_ID, meaning only customer accounts that have a valid matching party record are returned. Because both base objects are TCA entities owned by the trading community and receivables model, the view inherits their standard validation and security characteristics. The documented view text confirms a straightforward two-table definition with no aggregation, so row counts and cardinality mirror HZ_CUST_ACCOUNTS for accounts with existing parties.

Key Columns

The view exposes the following columns, each aligned with an account-level or party-level attribute:

  • CUST_ACCOUNT_ID — Primary identifier of the customer account in HZ_CUST_ACCOUNTS.
  • PARTY_ID — Identifier of the owning party in HZ_PARTIES.
  • ACCOUNT_NUMBER — The customer account number used for reference and lookups.
  • CUSTOMER_NAME — Derived from PART.PARTY_NAME; the party name associated with the account.
  • STATUS — Account status indicator.
  • ORDER_TYPE_ID — Default order type for the account.
  • PRICE_LIST_ID — Default price list reference.
  • TAX_CODE — Default tax code.
  • FOB_CODE — Sourced from ACCT.FOB_POINT and aliased as FOB_CODE.
  • FREIGHT_TERM — Account-level freight term, directly relevant to shipping defaulting inquiries.
  • WAREHOUSE_ID — Default warehouse reference.
  • PAYMENT_TERM_ID — Default payment term reference.

Common Use Cases and Queries

This view is commonly queried during order capture configuration, customer defaulting analysis, and reporting on account-level commercial terms. A typical query to inspect freight terms alongside account identity is:

  • SELECT CUST_ACCOUNT_ID, ACCOUNT_NUMBER, CUSTOMER_NAME, FREIGHT_TERM, FOB_CODE, PRICE_LIST_ID, PAYMENT_TERM_ID FROM ASO_I_CUST_ACCOUNTS_V WHERE ACCOUNT_NUMBER = :p_account_number;

To list all accounts configured with a specific freight term:

  • SELECT ACCOUNT_NUMBER, CUSTOMER_NAME, FREIGHT_TERM, WAREHOUSE_ID FROM ASO_I_CUST_ACCOUNTS_V WHERE FREIGHT_TERM = :p_freight_term ORDER BY CUSTOMER_NAME;

For reporting that joins account defaults to order types or price lists, the view is frequently aliased and joined to lookup or reference tables using ORDER_TYPE_ID, PRICE_LIST_ID, WAREHOUSE_ID, and PAYMENT_TERM_ID. Because the view returns only accounts with matching parties, queries requiring orphaned accounts should instead read HZ_CUST_ACCOUNTS directly. All access should respect the standard APPS schema privileges and any TCA security policies applied to the underlying objects.