[SOLVED] 5.5 CU3: Bulk Plan Does Not Consol A Subset Of Selected Orders Into Expected

[ianlo]

Hi everyone, I am encountering an issue with bulk planning on OTM 5.5 CU3. Basically, bulk plan does not consolidate orders having pickup and delivery time windows that are close by each other. Expected results are two shipments built, instead four individual shipments are built.

Summary:
Four order movements bulked plan together did not yield an optimal result. In these four order movements, two of them OM1 and OM2 can be consolidated into one shipment as they have a pickup and delivery time window that is close to each other; and another two, OM3 and OM4 could have also been consolidated for the same reason. I've managed to prove my hypothesis by performing bulk planning separately on OM1 and OM2 to yield ONE shipment. Likewise, on OM3 and OM4.

Observed results:
4 OMs bulked plan resulted in 4 individual shipments

Expected results:
4 OMs bulked plan should result in two shipments, i.e. 2 OMs consolidated into one, and the other 2 OMs consolidated into another.

Business impact:
The current behaviour results in a shipment cost that is much higher than what is optimal. In the example on my slides, the shipment cost resulted from the bulk plan is 100% more because there was no consolidation.

Has anyone encountered such an issue? Attached is the powerpoint description of the issue.

Appreciate any replies!

Thanks!
Ian

[ianlo]

Re: 5.5 CU3: Bulk Plan Does Not Consol A Subset Of Selected Orders Into Expected Ship

Hi everyone,

Fyi, I have resolved this with the help of Oracle Support. The solution is as follows:

There are two problems that are causing the consolidation to fail.

1. The default consolidation logic for same origin/destination orders is greedy and attempting to is not evaluating all options to be consolidated. It eventually fails and results in 4 shipments. This is controlled by the already visited property (earlier discussed). This controls the use of the "greedy" algorithm or the iterative algorithm. Therefore suggestion is that we make the following permanent property change:

glog.business.consolidation.multistop.disableSameO DPairing = true

2. The consolidation is done via the Multistop logic (even though the orders have the same origin/destination). The multistop logic first ignores the interim stop as it is trying to consolidate the potential shipments. Because of this, we are trying to locate the Service Time between the order's source location and destination location.

In the example, we do not have any Service information defined for the leg: Origin -> Final Dest and therefore this calculation is failing.

You will need to define this information in your rate service to allow the Multistop to complete successfuly.


Thanks to Oracle Support for this info!