Search Results msd_dem_collect_history_data




Overview
Explore in AI Chat

Overview

The APPS.MSD_DEM_COLLECT_HISTORY_DATA package is a member of the Oracle E-Business Suite Demand Planning and Demand Signal Repository (DSR) family of PL/SQL objects, distributed under the MSD (Demantra Supply/Demand) application schema. Its principal business function is to collect and stage historical demand, shipment, and order data for use by Oracle Demantra and related analytical engines. Within the EBS 12.1.1 and 12.2.2 environments the package operates as a server-side engine rather than a user-facing form, and is typically invoked by the DSR collection framework to move transactional history from EBS source tables into the Demantra staging and interface tables.

The header comment ($Header: msddemchds.pls 120.0.12000000.2 2007/09/25 ...) confirms the package forms part of the standard MSD shipped code and is classified as OTHER in the ETRM API register. It relies on global constants drawn from MSD_DEM_COMMON_UTILITIES (notably C_YES and C_NO) to drive boolean-style flags passed to its procedures.

Key Procedures and Functions

ETRM documents four callable units within the package. Each is a PL/SQL procedure; no functions are exposed.

  • ANALYZE_TABLE — Performs a table analysis (statistics gathering) against a caller-supplied table name. It is used to refresh optimizer statistics on staging tables prior to or following a collection run, ensuring the CBO generates efficient execution plans.
  • COLLECT_HISTORY_DATA — The core collection routine. It accepts a very broad parameter set covering the source instance identifier, the collection group and method, a date-range type, a collection window with from/to dates, and a series of bucket/range combinations that drive the historical vs. current and shipment vs. order dimension of the extract. Dedicated parameters control ISO collection, whether all order types are collected, and explicit include/exclude order-type lists. The procedure also accepts an auto-run-download flag so the subsequent load step can be chained automatically.
  • RUN_LOAD — Executes the load phase that follows collection, moving the staged history data into the Demantra-facing tables. Like COLLECT_HISTORY_DATA it takes an auto-run-download indicator so operators can drive the end-to-end sequence from a single invocation.
  • INSERT_DUMMY_ROWS — A utility procedure that inserts placeholder rows, typically used in setup or test scenarios to guarantee that collection queries return a non-empty result set and to seed reference data.

Tables Accessed

The package reads and writes the following objects via APPS synonyms:

  • MSD_DEM_SERIES — The series definition table that describes each demand/shipment measure and its source mapping. It drives which history items are collected.
  • MSD_DEM_NEW_ITEMS — Holds newly introduced items that must be captured during the collection window.
  • DBA_OBJECTS — Consulted by ANALYZE_TABLE to validate that the target table exists and is of the expected type before analysing it.
  • DUAL — Standard Oracle single-row utility table used for control queries and constant resolution.
  • PLITBLM — The PL/SQL integer table used for bulk processing of row identifiers during collection and load.

Usage Notes

In EBS 12.1.1 and 12.2.2, MSD_DEM_COLLECT_HISTORY_DATA is most commonly invoked from the Demand Signal Repository concurrent programs that perform history collection and load. It is also referenced by eight other packages in the MSD schema, indicating it acts as a shared service for the Demantra integration layer. Direct invocation from forms is not typical; instead, administrators schedule the collection concurrent request, which calls COLLECT_HISTORY_DATA and then RUN_LOAD with the auto-download flag set. Custom integrations may call the package directly from PL/SQL, but must supply a valid source instance identifier and collection group consistent with the DSR setup. Because the package name contains the token DEM and the header references MSD Demantra source files, it is unrelated to any browser or client-side "browserdatacollecter" folder; the "collect" token refers solely to demand-history collection on the database tier.