Inventory
Inventory-tier cross-dock: a routing node that holds no inventory but receives a demand, forwards an upstream request, and on the upstream's delivery fills the original demand and ships it out through its own demandCarrier.
Slots into a ksl.modeling.supplychain.network.MultiEchelonNetwork alongside InventoryHoldingPoints via the common NetworkNodeIfc abstraction — both kinds of node share the network's level tracking, attachment plumbing, and transport-strategy wiring.
Per-cross-dock statistics:
numberOfDemandsCrossDockedResponse — counter of demands that completed the receive-fill-ship round trip.
crossDockWaitTimeResponse — observation: time from
receive(demand)to the upstream's delivery (i.e. how long the original parked at the cross-dock waiting for replenishment).
Phase 1.F migration: the cross-dock no longer uses a ksl.modeling.supplychain.flow.DemandForwarder. The upstream-forwarding mechanics are inlined into receive, and the round-trip completion lives in deliveryEndpoint — a custom DeliveryEndpointIfc that fires when the framework's Delivered dispatch routes the upstream's reply back here.
The cross-dock still creates a clone for the upstream request. The demand state machine does not permit a single demand to be re-sent upstream from Received/InProcess, so the request-path uses cloning of necessity. A future evolution (docs/supply-chain-framework-design.md §6 "Planned future direction: delivery-path multi-hop (full re-ship)") moves cross- docks off the request path entirely and uses a single demand making a multi-hop journey on the delivery path only.
Parameters
the parent model element
availability at the start of each replication
optional model-element name
See sc.inventorylayer.CrossDock See ksl.modeling.supplychain.facility.CrossDockFacility
Constructors
Properties
Per-observation response of upstream-delivered-time − receive-time for each demand routed through the cross-dock.
Fires when an upstream-forwarded request reaches Delivered back at this cross-dock. Recovers the parked original via SupplyChainModel.Demand.forwardedFrom, records the wait-time stat, increments the counter, completes the original (fill + dispatch via demandCarrier), and terminates the forwarded request at Stored.
Direct filler override; if set, used instead of demandFillerFinder.
Finder used to locate a filler for each generated demand.
All item types this filler is willing to fill.
Per-replication count of demands that completed the round trip.
Per-replication count of demands whose forwarded request was rejected upstream (the round trip failed and the original was rejected rather than fulfilled).
Functions
The status demand would receive if filled now. Only valid at the current simulation time.
Fill a previously received demand. Must be called at the same simulation time as the receipt — no time may elapse between receive and fillDemand.
True if this sender may produce demands of type.
Returns a DemandMessageIfc describing what would happen if demand were sent now, or null if negotiation is not supported.
Forward demand's replenishment request upstream by creating a forwarded request (a clone) that travels to demandFiller while the original parks in IN_PROCESS at this cross-dock. The framework's Delivered dispatch on the forwarded request invokes this cross-dock's deliveryEndpoint, which completes the round trip.
True if demand would be rejected if filled now.