My decision is: Delivery and Delivery Stop
2 Likes
Due to the great response I have decided to contribute it back to the core. We are now working to clean it up and make things like the email text and the google maps api configurable.
I can’t tell you how long this will take exactly but I hope to get this out and merged within the next 4 weeks.
6 Likes
We have to make a decision about wether we are having an “Employee” to be the driver or if we have a dedicated “Driver” DocType and if so what information will be in there. The other solution would be to add a “Is Driver” Checkbox in the Employee.
1 Like
Hey!!! you are having naming party !! 
2 Likes
I would go for a driver doctype because you will need driver specific fields such as driving license number. Then driver will be linked to the corresponding employee record.
1 Like
Seconded. In the US (and I imagine elsewhere) there are tiered licenses that restrict the vehicles a driver can use. Things like: air brake endorsement, Class A Commerical Drivers License, Class B CDL, as well as some cargo specific pieces like a hazardous waste restriction (which applies to lots of things like delivery of fuel oil or even collecting domestic garbage). I don’t think these fields need to be set there but it would be good to have the framework available for customization.
1 Like
I think we have 2 facts here: The fact that the vehicle is moving from point A to B, with eventually some stops in between. The second fact is the reason the vehicle is moving: it could be delivery of some stuff, transport of people, etc. If the first fact of moving is abstracted from the reason of movement, then it opens the opportunity to use the doctype (for example Vehicle Trip) for different purposes. I have in mind a bus scheduling system as a possible other use. I am currently gathering requirements for a local bus company and will share on this thread
What about Journey? And Journey can have Stops
@KanchanChauhan Thanks! 
I will try to implement it 
after I reach 
home. I will let you know if I have questions, but should give it a spin 
and test by November 5 at the latest. Right now I will focus on prepping the AgriNext module.
We worked yesterday with @codingCoffee for about 6 hours straight. I think I overwhelmed him with data, but out of this meeting came a solid set of necessary DocTypes for the AgriNext module. 
.
Thanks to you and @dominik for pushing this fantastic feature. It will make our produce delivery a more robust experience for customers.
5 Likes
If this is made before the actual event, then another naming candidate is “Delivery Plan”.
Edit: Naming Guidelines · frappe/erpnext Wiki · GitHub
Also wanted to understand how is this linked to Delivery Notes (it should!) and other relevant transactions. How about costing? This should also be part of the order-level profitability.
2 Likes
I agree that this should be included in the order-level profitability. Sometimes, Delivery Service is an additional charge to the Customer and sometimes it is free of charge. Aside from that, we need to track costs involve in the Delivery Service like gasoline, toll fees and sometimes truck rental for some. With regards to linking it with Delivery Note, I think it doesn’t make sense to have a 1 to 1 relationship as most of the time a Delivery Service tour comprises of many Delivery Note. If it will be linked, we should have multiple Delivery Note in a single Delivery Service Tour.
1 Like
Of course it should be a many-many link!
We will go with a new DocType Driver instead of Employee to track important information raised in this issue.
2 Likes
This is out of the scope of what I am trying to do.
It already has the feature to link Delivery Notes to the Delivery Stop.
While I agree, I will not include this in my first contribution. We can think about how to implement this in a second stage.
2 Likes
Maybe make “Employee” an optional field, in case a driver is a contractor and not an employee.
And if a user wants to make it mandatory, they can use “Customize Form” and make it mandatory.
I suppose a point could be made that default should be mandatory and Customize Form can also make it non-mandatory, but I am of the opinion to only validate when confirmed.
3 Likes
Can’t additional fields be added to employee doc type itself instead creating a new doc type of driver? These fields can be hidden based on a check box “Driver?”
1 Like
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.