So the thing is that this is also not a delivery itself, it is a “Delivery Tour” which is on a certain date with certani “Delivery Stops”. So Either “Delivery Service Tour” or “Delivery Tour” and “Delivery Service Tour Stop” or “Delivery Tour Stop” for the child table.
What about “Delivery Service” for the parent with “Delivery Service Stop” for the child?
Yes, we set the date and the time when we will be at that customer.
So when we think about DocType naming we have to think about what the user creates. Does the user really create a “Delivery Service” when he clicks new or does he create a new “Delivery Service Tour”? I think he creates the tour / trip / route of specific “Deliveries” which will be delivered in “Delivery Service Tour Stops”.
Sorry It’s not about the name really, its just to be very clear about what we “create” when we click the “new” button.
2 Likes
Delivery Service Trip/Tour just seems unnecessarily wordy.
Or “Delivery Route” as a parent and “Delivery Stop” as the child.
EDIT: Either way, the feature, whatever it is named, looks good. 
EDIT2: Or “Delivery Schedule” as the parent
For Naming, We don’t have any issues.
In new version of ERPNext we can easily rename any doctype name using custom translation.
There are lots of developers already developed solution for fleet management and delivery tracking, I think pull request/ github issue is best to discuss this, where we will get ideas from other developer.
Can you ask your developer to put initial pull request to discuss this?
1 Like
If we want to keep it short then “Delivery” and “Delivery Stop” seem ok. I don’t think there will be a big conflict because the shipping with a courier would be called “Shipment” I think.
2 Likes
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!
