Results for “ar_customer_calls_all”

50+ results




Overview
Explore in AI Chat

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

Overview

AR_CUSTOMER_CALLS_ALL is a Receivables (AR) module table that stores customer call information — the transactional record of collection activities, dunning contacts, promises to pay, and follow-up actions logged against a customer or site. It sits at the intersection of the collections and customer master domains, capturing both the commercial context (which customer, which site use, which collector) and the outcome of the interaction (call outcome, promise, forecast). It is an org-stripped ("_ALL") table, meaning it carries an ORG_ID column to support multi-org/Operating Unit partitioning, even though the records are owned by the AR schema.

From a heuristic Data Vault modeling perspective, mined from the foreign-key structure, this table classifies as a link. Rather than being a pure hub of business keys or a passive satellite of descriptive attributes, it resolves relationships between customers (HZ_CUST_ACCOUNTS), contacts (HZ_CUST_ACCOUNT_ROLES), sites (HZ_CUST_SITE_USES_ALL), collectors (AR_COLLECTORS), and contact points (HZ_CONTACT_POINTS). A link classification is therefore a modeling suggestion: the table functions primarily as an associative transaction record joining several conformed dimensions, while also carrying its own descriptive outcomes such as promise amounts and forecast dates.

Key Information Stored

The surrogate primary key is CUSTOMER_CALL_ID, enforced by the unique index AR_CUSTOMER_CALLS_U1. This single-column unique index is the documented business-key candidate; in EBS practice the call identifier is typically sequence-generated rather than user-supplied, so downstream joins and updates should always resolve through CUSTOMER_CALL_ID.

The most significant columns fall into four groups:

Common Use Cases and Queries

Typical scenarios include collection activity reporting, promise-to-pay monitoring, and collector productivity analysis. A common pattern calls for calls due for follow-up:

  • SELECT customer_call_id, customer_id, collector_id, promise_date, promise_amount FROM ar_customer_calls_all WHERE complete_flag = 'N' AND follow_up_date <= SYSDATE;
  • SELECT cc.customer_call_id, cc.call_date, cc.call_outcome, hp.phone_number FROM ar_customer_calls_all cc, hz_contact_points hp WHERE cc.phone_id = hp.contact_point_id AND cc.customer_id = :customer_id;
  • Promise-to-pay aging reports join CUSTOMER_ID to HZ_CUST_ACCOUNTS and aggregate PROMISE_AMOUNT by PROMISE_DATE and CURRENCY_CODE.
  • Org-specific extracts filter on ORG_ID to isolate a single Operating Unit.

Related Objects

The table's six documented foreign keys define its primary reference graph:

  • AR_CUSTOMER_CALLS_ALL.CUSTOMER_ID → HZ_CUST_ACCOUNTS (the customer master account).
  • AR_CUSTOMER_CALLS_ALL.CONTACT_ID → HZ_CUST_ACCOUNT_ROLES (the contact role at the account).
  • AR_CUSTOMER_CALLS_ALL.SITE_USE_ID → HZ_CUST_SITE_USES_ALL (the specific site use).
  • AR_CUSTOMER_CALLS_ALL.PHONE_ID → HZ_CONTACT_POINTS (the phone contact point).
  • AR_CUSTOMER_CALLS_ALL.FAX_ID → HZ_CONTACT_POINTS (the fax contact point).
  • AR_CUSTOMER_CALLS_ALL.COLLECTOR_ID → AR_COLLECTORS (the assigned collector).

These relationships make HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNT_ROLES, HZ_CUST_SITE_USES_ALL, HZ_CONTACT_POINTS, and AR_COLLECTORS the most significant join partners. Referential integrity enforces that a call cannot exist without a valid customer and collector, so any deletion or merge of customer master records must be coordinated with this table.