Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Mixed Pickup-Dropoff in Dispatcher #8

Open
sperka opened this issue Jan 25, 2022 · 2 comments
Open

Implement Mixed Pickup-Dropoff in Dispatcher #8

sperka opened this issue Jan 25, 2022 · 2 comments
Labels
component:dispatcher Dispatcher component effort:high Needs a lot of effort to accomplish this task enhancement New feature or request feature priority:low This item should not be prioritized over items with high or medium priority

Comments

@sperka
Copy link
Contributor

sperka commented Jan 25, 2022

No description provided.

@sperka sperka added enhancement New feature or request feature priority:medium This item will be prioritised over items with low priority component:dispatcher Dispatcher component labels Jan 25, 2022
@sperka sperka added priority:low This item should not be prioritized over items with high or medium priority effort:high Needs a lot of effort to accomplish this task and removed priority:medium This item will be prioritised over items with low priority labels Jan 27, 2022
@rodrigokestler
Copy link
Contributor

Hi @sperka
Are you planning on implementing penalization for drivers that have rejected orders previously? In other words, penalize driver scores for orders that they have rejected. I see a commented-out code for this, but it is using a class that does not exist

protected Constraint hasDriverCancelledThisOrderBefore(ConstraintFactory factory) {

       return factory.from(PlanningVisit.class)
         .penalizeLong(
           "hasDriverCancelledThisOrderBefore",
           HardMediumSoftLongScore.ONE_SOFT,
           PlanningVisit::hasDriverCancelledThisOrderBefore
         );
   }

@sperka
Copy link
Contributor Author

sperka commented Jan 14, 2023

Hi @rodrigokestler

We added these constraints as examples. If your business use-case requires such a thing, you can introduce it to your system.
As far as I can imagine, assigning the same driver that already rejected the order can happen if..

  1. using one provider: order assigned -> driver rejected -> order back in queue -> order assigned again to same driver
  2. using multiple providers: order assigned -> driver rejected -> order lifecycle manager cycles through all other providers and gets back to the "original" that assigned that driver -> order gets assigned to the same driver again.

In both cases you can maintain a list in the PlanningDelivery object which drivers were assigned to that delivery item with what status (Accepted, Rejected, etc) and from which provider, or just simply which provider's which driver rejected the order. (I'd say in a prod environment you'd be maintaining already all the events that happen to an order, so you'd have this information already). Then hasDriverCancelledThisOrderBefore is a simple lookup.

Make sure that the information is accessible in-memory (i.e: pull the order data from a DB before kicking off the optimization phase).

Hope this helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:dispatcher Dispatcher component effort:high Needs a lot of effort to accomplish this task enhancement New feature or request feature priority:low This item should not be prioritized over items with high or medium priority
Projects
None yet
Development

No branches or pull requests

2 participants