Agreed.
Possible, most people voted for new DocType and I thought it makes sense, so that’s why I did it that way.
A driver could be a contractor, not an employee.
Also, I am of the opinion that making super generic doctypes slows things down in the long run. If every scenario is linked to a single doctype, then you have to worry about “what workflow is broken” when making changes to the doctype. I think we see something similar in the project module, where rather than duplicating some functionality and tailoring to specific workflows, we do a one-size-fits all. And whenever a change is made, we almost inevitably have a user saying “this broke my workflow”.
Payment and Journal Entry is one area where I think ERPNext has nailed it down - yes, you can do a Payment Entry as a Journal Entry, but this tailored process helps users work with the system faster.
Also, we should be cognizant about MariaDB column limits when making huge doctypes. At some point, users will not be able to add the custom fields they want to doctypes because of limits.
1 Like
Driver may not be an employee but you may want to track expenses of the trip. If you maintain them as employees then you already have them as a party type. This is the route I would go but if increasing doc types and tables makes more sense to the community then that’s also fine.
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.
1 Like
Can you ask your developer to initiate pull request?
We will get feedback from other developers.
Following doctype already present in ERPNext
- Vehicle,
- Vehicle Service
- Vehicle Log
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.
1 Like
Yes we are working on it. We are generalizing the code and we are writing tests. This takes a moment.
2 Likes
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”.
1 Like
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!
1 Like
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 
1 Like
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:
- OpenStreetMap
- Mapzen
- Mapbox
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.
1 Like
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
1 Like
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?
1 Like