Search Results bill_round_number

Overview

JTF_BILLING_PREFERENCES_V is an APPS-owned database view in Oracle E-Business Suite 12.1.1 and 12.2.2, delivered under the JTF – CRM Foundation product family. The view describes the invoicing format preferred by customer accounts or customer account sites, exposing the billing preference attributes that Oracle Receivables, Order Management, and CRM applications rely on when determining how a customer is to be billed. Because billing preferences drive decisions such as billing language, currency, media type, and number of copies, the view serves as a stable, read-consistent access point for that configuration data across reporting and integration layers.

Typical consumers include custom reports, concurrent programs, Oracle Business Intelligence extract routines, and interface programs that must resolve the correct invoicing format for a given customer account or site before generating a transaction. Its status is VALID, and it is available in the APPS schema in both releases referenced above.

Underlying Base Objects

Per the documented metadata, JTF_BILLING_PREFERENCES_V is defined over HZ_BILLING_PREFERENCES, referenced through a synonym in the APPS schema. The view is a thin projection of that base table: it selects all business columns plus audit columns and includes ROWID as ROW_ID. No joins, aggregations, or filters are applied, so row cardinality and content match the underlying HZ_BILLING_PREFERENCES rows exactly.

The relationship is therefore one-to-one. Any DML or data change in HZ_BILLING_PREFERENCES is immediately visible through the view, with no transformation logic to reconcile. Because the base object is a synonym, the physical table resides in the HZ schema, consistent with the Trading Community Architecture data model that underpins customer and site information in Release 12.

Key Columns

• BILLING_PREFERENCES_ID – Primary identifier for a billing preference record.
• CUST_ACCOUNT_ID – Customer account associated with the preference.
• SITE_USE_ID – Site use (location) to which the preference applies; null when the preference is defined at account level.
• BILL_TYPE – Billing type indicator governing the invoicing format.
• BILL_LANGUAGE – Language in which the invoice is to be produced.
• BILL_ROUND_NUMBER – Rounding rule applied to invoice amounts.
• CURRENCY_CODE – Currency for invoicing.
• MEDIA_TYPE and MEDIA_FORMAT – Delivery medium (for example, print or electronic) and its format.
• NUMBER_OF_COPIES – Copies of the invoice to be produced.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE – Concurrent program context that last touched the row.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard audit columns.
• ROW_ID – ROWID of the underlying row, useful for identifying records in bulk processing.

Common Use Cases and Queries

The view is most often queried to resolve billing preferences for a customer or site, to validate that preferences exist before an invoicing run, or to feed downstream extracts. A representative query returning all preferences for a customer account follows:

• Account-level preferences: SELECT billing_preferences_id, cust_account_id, site_use_id, bill_type, bill_language, currency_code, media_type, number_of_copies FROM jtf_billing_preferences_v WHERE cust_account_id = :p_cust_account_id;
• Site-specific preferences: SELECT site_use_id, bill_type, media_format, currency_code FROM jtf_billing_preferences_v WHERE site_use_id = :p_site_use_id;
• Missing-preference check: SELECT c.cust_account_id FROM hz_cust_accounts c WHERE NOT EXISTS (SELECT 1 FROM jtf_billing_preferences_v b WHERE b.cust_account_id = c.cust_account_id);
• Audit trail: SELECT billing_preferences_id, last_updated_by, last_update_date, program_id FROM jtf_billing_preferences_v WHERE last_update_date >= :p_since_date;

Because the object is a view rather than a table, it should be treated as read-only in custom code. Applications requiring inserts or updates must operate on HZ_BILLING_PREFERENCES through supported APIs or forms rather than through the view.