Hello,
As this is generic feature, we can get idea from other developer who already build solution for UPS, FedEx integrations. In such integration we need to match ERPNext and Other software values.
When I was developing similar solution, we find best doctype is packing slip in ERPNext.
We can also make new doctype, but we need to capture all fields which needed for such integrations.
Also this need to link with Delivery Note and Sales Invoice if update stock is checked.
@kolate_sambhaji I think that packing slip is the right basis for courier shipments such as DHL or FedEx since it has dimensions and could have weights and an associates tracking number.
Maybe for us this could also be the right one to reference in deliveries.
Can you ask your developer to initiate pull request?
We will get feedback from other developers.
Following doctype already present in ERPNext
We need to create Driver Doctype and Delivery Tour or just Tour
My suggestion if to Create Packing Slip form Delivery Note or Sales Invoice(Update stock checked)
Create Tour from Packing Slip
We can also implement Bin Tracking Algorithm that will easily create Delivery Tour based on Vehicle size and packing slip size.
Yes we are working on it. We are generalizing the code and we are writing tests. This takes a moment.
I have read through the naming suggestions so just indulge me briefly.
I think the name Delivery Trip and Delivery Trip Stop would capture intent clearly. A Delivery Trip Stop (may additionally include a Type column say Pick-up or Drop-off) with linked Delivery Note as already described by yourself.
A Delivery Schedule as also pointed out earlier would then be an overview say using the Calendar widget to visualize planned/previous trips with Delivery Trip Stop marked on the date/time with colour codes to differentiate Pick-up/Drop-off and Planned vs. Completed trips.
Really dude 
thanks for lightening things up here!!
I think using Driver doctype makes things easier and cleaner from a maintenance perspective. In another discussion this question of extending vs. doctype inheritance has come up and I favour doctype inheritance (not supported presently but at least linking may suffice for now) to allow creating/modifying custom work flows better.
Say for instance doctype Room in Schools is a candidate for that where it could be a Classroom or a Hotel room and so on as opposed to trying to define what it is in the original doctype.
Our contribution is making progress, it is still a some work. We are now continuing to clean up the code and writing tests.
Since there are a lot of good discussions here and since you have asked to see code we have made our code available at frappe/frappe branch:delivery and frappe/erpnext branch:delivery. Please check it out and help improve through pull requests.
We have separated the google maps configuration which is needed for calculating the distances into a Setup DocType (Integrations) in Frappe so it can be used at other places within the framework at a later stage. This adds a requirement for googlemaps in frappe’s requirements.txt. It was also necessary to change the way Standard Reply works in order to being able to have Jinja variables in the subject of the email (e.g. “Delivery for you on January 1st at 10 AM”).
We now have a new Driver DocType and Driving License Categories for that driver as a child table. These live under HR. The Delivery and it’s Delivery Stops are in the ERPNext Stock module.
In order to test this. You will need to check out both the frappe and erpnext delivery branch and you will have to set the googlemaps API key in integrations. You will also have to configure a standard reply “Delivery Notification”.
You may already know this, but Google Maps in this context would require a paid Premium Plan, which is not cheap. OpenStreetMap may be more appropriate, but that’s your call!
That’s right, GoogleMaps isn’t cheap and open.
Another alternative with a good API can be Mapzen (https://mapzen.com/).
It relies on Leaflet and OpenStreetMap and their free tier is interesting.
But as @felix says, it’s your call 
I thought that the standard use model (1000 free calls) included our use case but it doesn’t. This means that the google maps API is not a good idea because it doesn’t provide basic free use.
So we have two suggestions now:
Any more suggestions and any strong favorites?
I we use something like Mapzen we could use their Time-Distance Service which automatically calculates the best route.
Hello,
I have checked branch delivery, but code is not available in delivery branch.
https://github.com/frappe/erpnext/tree/delivery
Thanks,
Sam
should be there now
Thanks
Yes that’s the main advantage of Mapzen: you can use their Time-Distance Matrix calculator, which can have a lot of applications.
Hi,
Sorry about this is a bit offtopic
This is why I think that’s very important the existence of a Party Doctype. All community Frappe/Erpnext should join efforts to join all this separated doctypes into one. It should be a Party doctype and you can select the roles for all driver,employee, customer, supplier, doctor, student, user, etc etc. for instance, how many times we have to enter the name of the same person in erpnext/frappe?
Mapzen and Mapbox are both built on top of OpenStreetMap, so the list can effectively look like
Has anybody successfully integrated either Mapzen or Mapbox and would you be willing to contribute to this by replacing Google Maps in the code and config?
Hi @dominik
Thanks a lot for this awesome contribution. Could we still keep Google Maps as an option for those who might prefer/need it? We tried building a feature with OpenStreetMap a little while back but the level of detailing in our region was too poor and generally unusable
Kind regards,
