Search Results ship_from_party_id




Overview
Explore in AI Chat

Overview

MSC_SUP_DEM_ENTRIES_V is a view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the MSC – Advanced Supply Chain Planning product (also marketed as Oracle Supply Chain Planning and VCP). It exposes supplier and demand scheduling entries that have been generated or received through the collaborative planning and supplier scheduling flows, including entries exchanged with trading partners through the XML Gateway and EDI/ASN transport layer. The view is instrumental for reporting on enterprise-wide supply and demand collaboration, vendor-managed inventory, and shipment notifications, and it allows planners, integration developers, and analysts to query a normalized, flat representation of scheduling and shipment data without joining the numerous underlying operational tables directly.

Because it is a view rather than a table, it carries no data of its own; it materializes at query time from the base object, applying column aliases and format mappings defined at creation. This makes it safe for read-only reporting and for extraction into downstream data warehouses.

Underlying Base Objects

Per Oracle's documented metadata for 12.2.2, MSC_SUP_DEM_ENTRIES_V is defined over a single base object, the synonym MSC_SUP_DEM_ENTRIES, which is owned by APPS. The synonym resolves to the physical MSC table that stores supply and demand collaboration entries populated by the Advanced Supply Chain Planning engine and the supplier scheduling concurrent programs. The view text is essentially a direct projection of that table, exposing nearly all of its columns with their canonical names, plus derived and descriptive fields. Because the view references a synonym, DBAs should verify that the synonym points to the intended base table in each environment and that public grants allow the reporting account to query it.

Key Columns

The view returns a broad set of transactional and planning attributes. Notable columns include TRANSACTION_ID, PLAN_ID, and SR_INSTANCE_ID, which identify the individual collaboration record, the plan context, and the source system instance. Trading partner information is provided through PUBLISHER_ID, PUBLISHER_NAME, PUBLISHER_SITE_ID, SUPPLIER_ID, CUSTOMER_ID, and the corresponding _SITE_NAME fields. Schedule and logistics details are carried by NEW_SCHEDULE_DATE, NEW_DOCK_DATE, NEW_SHIP_DATE, NEW_ORDER_PLACEMENT_DATE, ORDER_NUMBER, RELEASE_NUMBER, LINE_NUMBER, CARRIER_CODE, VEHICLE_NUMBER, CONTAINER_TYPE, and CONTAINER_QTY.

The column directly relevant to the search term "tracking_number" is TRACKING_NUMBER, which stores the shipment tracking identifier associated with a supplier collaboration or advance ship notice entry. It is complemented by BILL_OF_LADING_NUMBER, SHIP_METHOD, and the ship-to/ship-from party and address columns used to trace a shipment end to end. Item-level facts are supplied by INVENTORY_ITEM_ID, QUANTITY, TP_QUANTITY, UOM_CODE, and PLANNER_CODE, while bucket classification is provided by BUCKET_TYPE and BUCKET_TYPE_DESC.

Common Use Cases and Queries

Typical uses include reconciling supplier scheduling releases, monitoring in-transit shipments by tracking number, auditing dock-date adherence, and feeding ASN data into custom operational dashboards. A representative query to locate records by tracking number is shown below.

  • SELECT transaction_id, order_number, release_number, line_number, tracking_number, carrier_code, new_ship_date FROM apps.msc_sup_dem_entries_v WHERE tracking_number = :p_tracking_number;
  • SELECT supplier_name, order_number, quantity, uom_code, new_dock_date FROM apps.msc_sup_dem_entries_v WHERE plan_id = :p_plan_id AND bucket_type = 'SHIPMENT';
  • SELECT publisher_name, order_number, tracking_number, bill_of_lading_number, new_dock_date FROM apps.msc_sup_dem_entries_v WHERE sr_instance_id = :p_instance AND new_dock_date BETWEEN :p_from AND :p_to ORDER BY new_dock_date;

Because the view is a simple projection, no DISTINCT or aggregation is implied; callers should apply their own filters and joins to MSC plan or item master tables as needed, and should confirm column availability against the 12.1.1 or 12.2.2 ETRM listing for their patch level before relying on newer descriptive columns.