Amend order to already optimized tour

[andrei.koelsnikovich]

Hi,

Our team completing analyse and preparation phases to start progress in migration from xServer1 to Optiflow. However we detected some problems with attempt to implement Amend functionality we already have using xServer1. Our use case is next one:

1 tour with n scheduled orders to it, 1 vehicle assigned to this tour and m new unscheduled orders.
We expect: keep sequence of already scheduled orders and find the best place for the unscheduled orders.

Best regards,
Andrei

[Bernd Welter]

Hello Andrei,

here's the part of the Optiflow API you should check for this setting:

• Scheduled orders should remain scheduled.
• The scheduled "subsequence" should not be touched, the unscheduled orders are supposedto be inserted in between the existing ones.

Based on the two order categories you mentioned I'd recommend to approach the story like this:

• scheduledOrders
  • Give them orderProperties.outsourcingCost = NULL to ensure these orders will not be sacrificed for the benefit of the others. I'd say this is a mandatory setting.
  • Give each scheduled order a category that reflects it's sequence position, e.g. "seq-"+i
  • Use constraints.respectedSequences :

    Code: Select all

    [{     "orderCategories": ["seq-0","seq-1", ...."seq-200"]}]

• unscheduledOrders
  • Give them outsourcingCosts > 0 to tell the algorithm, these are not mandatory.

Remarks:

• The original xTour1 amending scenario was designed to handle multiple vehicle's input chains in one go and ensure that orders of a single chain are not moved into other chains: On the other hand a whole chain could have been reassigned to a different vehicle. As you ask for a single vehicle scenario we can ignore this.
• Based on a single vehicle: Feel free to skip the respectedSequences step if you only want to fill up the vehicle's tour, e.g. because the scheduled orders are already placed at the ramp for the loading process and therefore should not be shifted to another tour/vehicle. This gives the algorithm more flexibility and the option to recompute what is best.

If you have any questions or doubts let me know.

[Bernd Welter]

Here's one aspect you should be aware of if you want to apply the "respectedSequences" on more than 200 orders:

• A single respectedSequences element is restricted to a maximum of 200 order categories.
• Imagine you tried to compensate this limit by concatenating 2 respectedSequences via

  Code: Select all

  "respectedSequences":
  [
   { "orderCategories": ["seq_1", "seq_2", ... "seq_200"] },
   { "orderCategories": ["seq_200", "seq_201", ... "seq_..."] }
  ]
  

  If - for whatver reason - the order with the category "seq_200" isn't scheduled there's no rule taht enforces a "200+ order" to be scheduled after "199- order".
• In the 1–200 variant, it can happen at the very beginning that a solution is produced where one of the jobs from 1–200 isn’t scheduled while optional jobs are scheduled, but the ordering is still respected. As the optimization progresses, the correct outsourcing costs should then ensure that the mandatory jobs are prioritized and scheduled first.
• In the 1–200, 201–400 variant, however, we can end up initially producing solutions that violate the overall 1–400 order (e.g., a tour 399–10). That’s the crucial difference—and what makes this approach quite problematic.

If you are running into this scenario because you need to handle ">200" within a respectedSequence let us know.
Maybe this is an aspect where we can consider to increase the limit.

Bernd