In order to [fine-tune the timeslots] As a [last-mile company], I want to [improve CUTOFF configuration]

[rayon9coop]

In order to achieve something To clearly distinguish between express and standard deliveries, it might be useful to set a cut-off time more extended than for the same day.

For example, if I decide that my customer needs to send me delivery orders before 2pm for a next day delivery in two different time slots (e.g. 10am-5pm and 5pm-9pm), I can't do this with the current functionalities because the prior notice is active on one time slot and then on the other but not on both.

Whereas currently this happens In the current configuration, I have two unsatisfactory possibilities: define a prior notice that will allow my customer to encode after 2pm a delivery for the next day in the second time slot, or define a prior notice that will not allow him before 2pm to encode a delivery for the next day in the first time slot.

I want something to be added or changed I see two ways to solve this problem:

1. add a checkbox that would solidify the time slots (if the prior notice overlaps the first time slot, then the second one would not be available either)
2. add a "CUTOFF time for next time slot" feature that would set a appointed time witch the customer must communicate delivery orders for the next open time slot.

[Paul-Eraman-CoopCycle]

@rayon9coop I am sorry but I do not understand the details of this issue. Can you explain more? Maybe an example?

[rayon9coop]

Yes, Paul, i understand you don't understand... Maybe I can explain to Adrien and he'll translate? I think this is the limit of deepL translations

[Paul-Eraman-CoopCycle]

@AdrienSICKLO translation help plz?

[rayon9coop]

Pour distinguer clairement les livraisons express des livraisons standard, il peut être utile de fixer une heure limite plus étendue que pour le même jour.

Par exemple, si je décide que mon client doit m'envoyer des ordres de livraison avant 14h pour une livraison le lendemain et qu'il peut choisir dans deux créneaux horaires de livraison (par exemple, livraison de 10h à 17h ou de 17h à 21h), je ne peux pas le faire avec les fonctionnalités actuelles car le délai de prévenance est actif sur le premier créneau horaire ou le second, mais pas sur les deux.

Dans la configuration actuelle, j'ai deux possibilités insatisfaisantes :

• définir un délai de prévenance qui agira sur le premier créneau horaire disponible mais qui permettra à mon client d'encoder après 14h une livraison pour le lendemain dans le second créneau horaire
• ou définir un délai de prévenance qui agira sur le second créneau horaire mais qui ne permettra pas d'encoder avant 14h une livraison dans le premier créneau horaire.

Après réflexion, je vois 2 façons de résoudre ce problème :

• ajouter une case à cocher qui solidarise les créneaux horaires de livraison du jour suivant. Cela permettrait de définir que si le délai de prévenance chevauche la première plage horaire disponible, alors la seconde plage du même jour sera considérée comme indisponible également.
• ajouter une fonctionnalité "CUTOFF pour le jour suivant" identique au "CUTOFF pour le jour-même" déjà présente dans la définition des tranches horaires @ERAMANrepartos : I can't tag Adrien, I will let you tag him to try to translate.

[Paul-Eraman-CoopCycle]

@AdrienSICKLO translation help?

[r0xsh]

Pour distinguer clairement les livraisons express des livraisons standard, il peut être utile de fixer une heure limite plus étendue que pour le même jour.

Par exemple, si je décide que mon client doit m'envoyer des ordres de livraison avant 14h pour une livraison le lendemain et qu'il peut choisir dans deux créneaux horaires de livraison (par exemple, livraison de 10h à 17h ou de 17h à 21h), je ne peux pas le faire avec les fonctionnalités actuelles car le délai de prévenance est actif sur le premier créneau horaire ou le second, mais pas sur les deux.

Dans la configuration actuelle, j'ai deux possibilités insatisfaisantes :

* définir un délai de prévenance qui agira sur le premier créneau horaire disponible mais qui permettra à mon client d'encoder après 14h une livraison pour le lendemain dans le second créneau horaire

* ou définir un délai de prévenance qui agira sur le second créneau horaire mais qui ne permettra pas d'encoder avant 14h une livraison dans le premier créneau horaire.

Après réflexion, je vois 2 façons de résoudre ce problème :

* ajouter une case à cocher qui solidarise les créneaux horaires de livraison du jour suivant. Cela permettrait de définir que si le délai de prévenance chevauche la première plage horaire disponible, alors la seconde plage du même jour sera considérée comme indisponible également.

* ajouter une fonctionnalité "CUTOFF pour le jour suivant" identique au "CUTOFF pour le jour-même" déjà présente dans la définition des tranches horaires
  @ERAMANrepartos : I can't tag Adrien, I will let you tag him to try to translate.

To clearly distinguish between express deliveries and standard deliveries, it can be useful to set a broader cutoff time for the next day.

For example, if I decide that my customer needs to send delivery orders before 14:00 (2:00 PM) for next-day delivery, and they can choose from two delivery time slots (e.g., 10:00 to 17:00 or 17:00 to 21:00), I cannot currently achieve this with the existing features because the cutoff time applies to either the first time slot or the second, but not both.

In the current configuration, I have two unsatisfactory options:

• Set a cutoff time that applies to the first available time slot but still allows my customer to place an order for the next day in the second time slot after 14:00 (2:00 PM).
• Set a cutoff time that applies to the second time slot but doesn't allow placing an order before 14:00 (2:00 PM) for delivery in the first time slot.

After giving it some thought, I see two ways to solve this problem:

1. Add a checkbox that links the delivery time slots for the next day. This would mean that if the cutoff time overlaps with the first available time slot, then the second time slot on the same day would also be considered unavailable.
2. Add a "CUTOFF for the next day" functionality similar to the existing "CUTOFF for the current day" in the definition of time slots.

I hope it's clear enough, I'm not sure I fully understood the French text either :sweat_smile: