Search Results delete_crossdock_criteria

Overview

WMS_XDOCK_PEGGING_PUB is a public PL/SQL package in the APPS schema that implements the cross-docking pegging engine within Oracle Warehouse Management (WMS). Cross-docking is the practice of moving received or in-transit material directly to an outbound demand without first putting it away into storage. The pegging logic in this package determines whether an inbound supply can be matched, or "pegged," to an outbound sales order, transfer order, or internal requisition demand, and it governs the decision rules under which that match is considered valid. The package serves as the central programmatic interface for evaluating cross-dock eligibility, retrieving and maintaining cross-dock criteria, and applying both planned and opportunistic cross-dock strategies. It is classified as a PUB API, meaning it is intended to be called by other Oracle EBS modules and, where Oracle permits, by customer extensions. The package is documented as VALID in ETRM for both Oracle EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes nine documented procedures and functions, each addressing a distinct aspect of cross-dock pegging and criteria management.

• SET_CROSSDOCK_CRITERIA — Establishes or updates the criteria rows that define how cross-dock opportunities are evaluated for a given context, writing to the cross-dock criteria repository.
• GET_CROSSDOCK_CRITERIA — Retrieves the currently defined cross-dock criteria so that callers can inspect or reuse the active rules.
• DELETE_CROSSDOCK_CRITERIA — Removes existing cross-dock criteria entries, typically during setup maintenance or reconfiguration.
• CLEAR_CROSSDOCK_CACHE — Clears cached cross-dock data so that subsequent pegging evaluations read current values rather than stale in-memory results.
• GET_DEFAULT_ROUTING_ID — Returns the default routing identifier used when pegging demands to supply, ensuring the correct transportation path is associated with the cross-dock movement.
• PLANNED_CROSS_DOCK — Performs pegging for supply and demand that are known in advance, such as confirmed inbound POs matched against firm sales order lines.
• OPPORTUNISTIC_CROSS_DOCK — Performs pegging where a cross-dock opportunity arises at execution time and is not part of the original plan, matching available supply to unplanned or newly created demand.
• GET_EXPECTED_TIME — Calculates the expected time associated with a cross-dock movement, used to sequence and schedule activity.
• GET_EXPECTED_DELIVERY_TIME — Calculates the expected delivery time for the pegged demand, supporting promise-date and scheduling decisions.

Tables Accessed

The package reads and writes a broad set of supply, demand, and setup tables through APPS synonyms. Cross-dock rules are persisted in and read from WMS_CROSSDOCK_CRITERIA. Order demand is sourced from OE_ORDER_LINES_ALL, OE_DROP_SHIP_SOURCES, and PO_DISTRIBUTIONS_ALL, while inbound and supply-side data come from PO_HEADERS_ALL, MTL_SUPPLY, and MTL_RESERVATIONS. Item and inventory context is provided by MTL_SYSTEM_ITEMS, MTL_PARAMETERS, MTL_INTERORG_PARAMETERS, and MTL_INTERORG_SHIP_METHODS. Internal requisition and transfer movement detail is drawn from MTL_TXN_REQUEST_HEADERS, MTL_TXN_REQUEST_LINES, and MTL_TXN_REQUEST_LINES_S. Unit-of-measure conversion relies on MTL_UNITS_OF_MEASURE. Together these tables supply the pegging engine with the demand, supply, organizational, and item attributes required to evaluate cross-dock eligibility.

Usage Notes

WMS_XDOCK_PEGGING_PUB is invoked primarily during pick release, order management, and inbound receiving flows. The dependency metadata shows that WSH_PICK_LIST references this package, indicating that pick-list generation triggers cross-dock pegging logic, and that INV_PICK_RELEASE_PUB, WMS_CROSS_DOCK_PVT, WMS_XDOCK_CUSTOM_APIS_PUB, and WMS_XDOCK_EXCEPTION also depend on it. This confirms that the package is referenced by six other packages and is deeply integrated into both the outbound picking and inbound cross-dock processing chains. The dependent reference on WSH_PICK_LIST is particularly relevant to searches concerning pick-list behavior, because the pegging results determined here influence which supply is consumable directly on a pick list rather than through standard put-away and picking. Customizations should call the PUB procedures rather than the underlying WMS_CROSS_DOCK_PVT private logic, and should invoke CLEAR_CROSSDOCK_CACHE after changing criteria to avoid stale pegging results.