Search Results sort_demand_lines




Overview
Explore in AI Chat

Overview

WMS_XDOCK_CUSTOM_APIS_PUB is a public PL/SQL package in the Oracle E-Business Suite Warehouse Management System (WMS) module that exposes a set of extensibility hooks governing the cross-docking process. Cross-docking is the logistics practice of unloading inbound material and loading it directly onto outbound transport with minimal or no putaway into storage. The standard WMS cross-docking engine requires several decisions that are sensitive to a customer's specific distribution model: which receipt or release lines qualify for cross-docking, how far in advance supply must arrive to be useful, and in what sequence supply and demand lines should be considered. Rather than hard-coding this logic, Oracle provides WMS_XDOCK_CUSTOM_APIS_PUB as a stub package of overridable APIs. Customers implement their own business rules inside these procedures, and the cross-docking engine calls them at defined extension points. The package header declares the procedures and the body supplies placeholder implementations, including the boilerplate that sets a savepoint, initializes the FND message list, sets the API return status to success, and reports through the x_api_is_implemented flag whether the customer has actually supplied logic. Where a procedure is not implemented, the caller falls back to seeded Oracle behavior. The package is a customization-layer object, not a seeded process driver, so the header revision shown in the source (120.1, dated 2005) reflects a long-stable interface carried forward into EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The package body documents five callable units, all published for customer override:

  • GET_CROSSDOCK_CRITERIA — Returns the identifier of the cross-dock criteria definition that should govern a given planning record. It accepts the WSH_PR_CRITERIA release record type as input and returns the criteria ID along with the standard API return status, message count, message data, and the x_api_is_implemented Boolean that signals whether the customer has replaced the default.
  • GET_EXPECTED_TIME — Supplies the expected time associated with an inbound supply or planning record, used when the engine evaluates temporal eligibility for a cross-dock match.
  • GET_EXPECTED_DELIVERY_TIME — The procedure associated with the searched term. It returns the expected delivery time for the record under evaluation, allowing a customer to substitute their own date or time derivation — for example, based on carrier schedules, supplier commitments, or appointment data — instead of the value the standard engine would derive.
  • SORT_SUPPLY_LINES — Controls the ordering of candidate inbound supply lines before the cross-docking engine attempts to match them against outbound demand, enabling prioritization rules based on carrier, date, item, or priority attributes.
  • SORT_DEMAND_LINES — Controls the ordering of candidate outbound demand lines, so that the most urgent or highest-priority demand is satisfied first.

Tables Accessed

The package body itself performs no direct DML against application tables. Its documented signature references WSH_PR_CRITERIA.relRecTyp for the criteria procedure, and the print_debug helper delegates to INV_MOBILE_HELPER_FUNCTIONS.tracelog for diagnostic logging. All persistent data retrieval and update is performed by the calling cross-docking engine and by the customer logic that replaces the stub bodies; any tables a customer implementation touches are supplied by that implementation rather than by the seeded package.

Usage Notes

WMS_XDOCK_CUSTOM_APIS_PUB is invoked internally by the WMS cross-docking engine during planning and release processing, and it is documented as being referenced by one other package. Customers customize it by editing the bodies of the affected procedures and setting the corresponding x_api_is_implemented output to TRUE; leaving a procedure unmodified preserves standard Oracle behavior. The rms contain standard API scaffolding — SAVEPOINT, FND_MSG_PUB.initialize, and FND_API return status — and debug output is gated on the INV_DEBUG_TRACE profile option, which must be enabled before print_debug emits messages through INV_MOBILE_HELPER_FUNCTIONS. Because the interface is an extension point rather than a seeded concurrent program or form, direct invocation from custom code is possible but not the intended usage; changes should be migrated as a customization and re-validated after any Oracle patch or upgrade, since the package header version is subject to change.