Search Results activity_date

Overview

BIL_DAILY_ACTIVITY is a fact table within the Oracle E-Business Suite Sales Intelligence (BIL) product family. Its documented purpose is to store activity facts that are updated for each object type, providing a consolidated daily record of transactional activity across the sales intelligence domain. The table captures activity metrics keyed by country, transaction code, activity date, object type, and operating unit, making it a summary-level repository rather than a purely transactional table.

The object is not implemented in every EBS database; the metadata explicitly notes "Not implemented in this database" for the referenced instance, meaning availability depends on whether Sales Intelligence components have been installed and configured. This is common for BIL objects, which are tied to the Sales Intelligence and Trade Management feature set rather than the core order-to-cash schema.

The heuristic Data Vault classification mined from FK structure is standalone. From a modeling perspective, this suggests the table behaves as an independent fact or satellite structure without documented foreign key dependencies to other hub or link tables. Where a dimensional or Data Vault design is desired, it would typically be modeled as a fact satellite capturing daily activity measures, with its composite key serving as the grain definition rather than a foreign key path.

Key Information Stored

The primary key, BIL_DAILY_ACTIVITY_PK, is a composite surrogate/business key defined over five columns. The most important columns are:

• ACTIVITY_DATE — The date for which activity facts are aggregated or recorded. This is the primary time dimension anchor and the column most frequently used in filtering and reporting.
• COUNTRY — The country associated with the activity, part of the composite primary key and a geographic partitioning attribute.
• TRANSACTION_CD — The transaction code classifying the type of activity recorded, part of the primary key.
• OBJECT_TYPE — Identifies the business object type for which activity facts are updated (for example, order, quote, or customer entities), part of the primary key.
• ORG_ID — The operating unit identifier, part of the primary key and the standard Multi-Org partitioning column across EBS.

The five primary key columns collectively form the business-key candidate for uniqueness. Because the metadata documents no separate unique index beyond BIL_DAILY_ACTIVITY_PK, these columns should be treated as the definitive grain. No descriptive measure columns are enumerated in the available metadata excerpt, but activity fact tables of this type typically carry counters, amounts, or quantities accumulated per key combination.

Common Use Cases and Queries

Typical usage centers on time-series reporting of sales activity by object type and operating unit. A representative query filters on the activity date range and groups by object type:

• SELECT object_type, country, SUM(activity_measure) FROM bil_daily_activity WHERE activity_date BETWEEN :start_date AND :end_date AND org_id = :org_id GROUP BY object_type, country;
• Trend analysis of transaction codes across periods to identify shifts in sales intelligence activity.
• Operating-unit-level dashboards that compare daily activity volumes across countries.
• Feeding downstream Sales Intelligence reports or data warehouse extracts keyed on activity_date.

Because the table is a daily rollup, queries should always constrain ACTIVITY_DATE to avoid full scans, and ORG_ID filtering is required under Multi-Org security policies.

Related Objects

The metadata classifies this object as standalone, so no foreign key relationships are documented. Related objects therefore derive from the shared BIL (Sales Intelligence) schema and from the composite key columns:

• Other BIL activity and fact tables sharing OBJECT_TYPE and TRANSACTION_CD semantics.
• BIL setup and lookup tables resolving TRANSACTION_CD and OBJECT_TYPE domain values.
• ORG_ID referencing HR_OPERATING_UNITS for operating unit validation.
• COUNTRY referencing FND_TERRITORIES or similar territory definitions.
• Sibling fact tables in the BIL schema keyed on ACTIVITY_DATE for cross-fact reporting.

Any joins should be validated against the installed BIL schema, since the documented instance did not implement this table.