Order Splitting

The core mechanism that evaluates Available-to-Promise (ATP) across a distributed network. When a single warehouse cannot satisfy the full quantity, the engine simultaneously checks inventory at alternative distribution centers, dark stores, or retail locations. The algorithm then partitions the order line, allocating partial quantities to the optimal combination of nodes to minimize total landed cost while meeting the delivery promise.

Splitting logic balances the trade-off between transportation cost and delivery speed. The engine calculates the incremental freight cost of each partial shipment against the penalty of a delayed consolidated shipment. Key variables include:

• Zone skipping opportunities for bulk line-haul
• Dimensional weight optimization across split parcels
• Carrier rate shopping for each individual shipment leg
• Carbon footprint minimization through modal shifts

Splitting is not purely spatial; it is also temporal. The system may intentionally defer a portion of an order to a later shipment wave to consolidate with other orders destined for the same geographic region. This dynamic wave planning reduces cost-per-package by building denser delivery routes. The algorithm ensures that any deferred portion still meets the Customer Delivery Window (CDW) originally promised.

Splitting is often triggered by inventory exceptions rather than standard planning. Common triggers include:

• Stockout at the primary fulfillment center during pick confirmation
• Shelf-life failure where allocated batch is too old for the customer's minimum freshness requirement
• Carrier capacity constraints preventing a single large shipment
• Regulatory hold on a specific lot at one location The engine must reactively re-promise the unfulfillable quantity against alternative sources in real time.

Business rules govern the maximum number of splits permitted per order to avoid degrading the unboxing experience. Configurable parameters include:

• Max split count per order line or per order header
• Minimum split quantity to prevent uneconomical partial shipments
• Consolidation preference for premium loyalty tiers
• Communication triggers to proactively notify customers of multi-package deliveries with distinct tracking IDs These rules are enforced within the Order Promising Engine before the split is executed.

Splitting an order creates multiple fulfillment lines, each with its own tax calculation, payment capture, and revenue recognition event. The system must:

• Prorate discounts and promotions accurately across split shipments
• Handle partial invoicing and multi-capture payment gateways
• Manage return authorizations that reference the original order but may involve separate reverse logistics flows Failure to correctly decompose the financial transaction can lead to audit discrepancies and customer disputes.