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!
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.
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?
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?
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
Data reliability in different regions is an important point. Google Maps works about everywhere (outside of mainland China).
Maybe we could implement it with Google Maps for now and then work on a Mapzen or Mapbox integration. We would have to think how we can make this configurable. This is also something that could be implemented by someone else who has experience with Mapzen or Mapbox and could be done at a later stage.
