This PR implements a bulk-generation feature on Delivery Note creation for high volume delivery businesses. It allows to choose — during bulk creation — a cut-off date up to which deliveries should be created on all selected Sales Orders.
This means that businesses can now manage partial delivery with ease and en masse.
All I need is feedback to drive this PR to completion for everyone’s benefit. 
As an end user, this functionality serves the purpose of streamlining the delivery process. It involves the selection of all relevant sales orders slated for delivery, followed by the creation of delivery notes. However, just before initiating the bulk creation, it is essential to designate a specific date for the impending deliveries.
Given our business’s operational requirement to ensure multiple sales orders are fulfilled on a single date, this date needs to be uniformly assigned to all applicable sales orders.
The efficiency of this process is notably enhanced by utilizing the bulk-date-assignment tool, allowing us to accomplish this task seamlessly in a single action.
See how it works here:
I forgot: 
The bulk-date-assignment tool also takes into account the delivery date assigned to each item in the sales order. In cases where the delivery date specified in the item sales order aligns with the date selected in the bulk-date-assignment tool, the tool will generate the delivery note exclusively for that particular item within the sales order. This ensures precise and tailored handling of delivery schedules for individual items in alignment with the specified dates.
This is how a sales order item table with different delivery dates looks like:
Green dots indicate items already delivered, red dots are those pending to be delivered, which will be considered by the next bulk-date-assignment tool, only if the selected date matches.
What happens to those orders which are not actually delivered on the given date?
What happens in case there are like 1000 orders with multiple items?
I like this function but it needs to be more specific.
If you mean: “not received by the customer on the doorstep” → they managed as regular returns in our dispatch operations c/o sales departement to re-schedule with teh customer.
If you mean: “where planned but never left the warehouse because of a problem” → draft delivery notes are not validated and pending delivery, in this case the dispatch department reaches out to sales to manage the customer communication
If you mean: “where never planned”, → they are not created as per the cut off date.
As with any other bulk action, this too scales linearly in the background. If that’s not the case, it would be a bug with the bulk action feature. Only line items within the cut-off date are schedule into a Delivery Note and previously delivered line items are not rescheduled. This allows for convenient management of partial (timed) delivery, say “2 tomorrow and 2 next week”.
That’s nice, we couldn’t even operate without it. Maybe my explanations clarify already a bit, but beyond that: what specifically should be more specific in your opinion?
In this case, the delivery note is already submitted and inventory is out, so this case will have to be handled manually by the sales department.
Bulk Delivery note creates DN in Draft on submits it ? If in draft then its ok.
Interesting concept, might need this soon, How are delivery processed and documented as delivered? Just using the core functions only or there is a custom workflow?
Thanks for the clear case by case explanation.
Yes, that is correct. This is how we currently operate.
Yes, indeed, they are created in draft state. This is also our current delegation point between sales department and fulfillment. Sales bulk-schedules, fulfillment dispatches.
Indeed, we have developed in-house and adopted a VRP solver and made some more amendments to allow (draft) Delivery Trips from draft Delivery Notes during trip planning.
VRP runs are executed on draft delivery notes and draft delivery trips, but in order to submit the delivery trip, delivery notes must be “dispatched” (i.e. submitted),before the delivery person can leave (i.e. DT submitted). Then the delivery person has a special link sent by Document Notification to their whatsapp where they can click to confirm the delivery. In this case, the Delivery Stop (“Items of Delivery Trip”) is marked “visited = True” and renders a green dot in our VRP dasboards (in the above linked VRP video you only see green, i.e. visited stops and because stops, albeit distinct documents, map 1:1 to delivery notes, we transparently display that state on the delivery note).
The VRP flow overview is like this (even that’s already veering a bit off-topic, here):
