One of my customers would like to implement interconnection with DPD WebService. Perfect, a standard module exists for this: stock_package_shipping_dpd. After a few checks, it would seem (according to DPD France) that the implementation would be for DPD Germany, bad luck my customer is French and of course the WebService for French customers is not the same 
Maybe it should be indicated somewhere.
I had to change 3 links in the code to make it work.
configuration.py)configuration.py)stock.py)For now I have made the changes in the module itself and after the changes everything works like expected.
Thank you for your feedback.
It seems to me that for France the changes will be more important.
As I already said, it will be good to update the module to include the configurations.
Where is the documentation?
Yes, I did see that 
Indeed it is a complete different API. So it will probably simpler to create a new module.
Another option is to use Sendcloud.
My customer contacted DPD France directly, so I think a new module would be more appropriate. However, it’s still in version 6.0 (migration is envisaged but not at all planned). I’m waiting for his reply to see if he wants to finance this development.
If we were to create a new module, what name would be most appropriate: stock_package_shipping_dpd_fr?
I think it will be better to avoid country bound as we already see the current DPD implementation works for different countries. Here I think stock_package_shipping_cargonet seems more accurate.
I’ve got the customer’s agreement to develop the module, and I’ll be starting in the 2nd week of June.
To add this module to the list of official modules, do I have to go through a blue print? Or can I directly create a new topic on Heptapod?
I know that this module (if accepted) will be for the next version, but my client is still in version 6.0, so there’s bound to be a version 6.0. Is there a place where I can make this version available?
As it is just a derived module from the stock_package_shipping* familly, I think you can start directly with an implementation as long as it follows the same design as the other modules.
We do not have such place, but you can publish this version yourself.
Indeed at B2CK we often develop new modules (or feature) that are indeed backported on custom module to older series. I would strongly suggest to first implement in trunk and once it is finalized (or almost) you make a backport version for the series 6.0. This ensures that the latest tools are used for the official version and minimize for you the backport work.
If I were to add relay point distribution services. Should I do this in this module or add another module, e.g. ‘stock_package_shipping_cargonet_pickup’?
I’m pretty sure it requires a general review of all the stock_package_shipping modules.
I didn’t see in the other “stock_package_shipping_*” modules the possibility of cancelling labels when it is possible to cancel shipping.
Can I do this in this module?
Usually we do not care about cancelling a label because carrier invoice only when label is actually used on a package shipped.
In the specific case of DPD France, if the carrier does not collect the parcel, charges may apply. For this reason I think it is wiser to cancel the label.
So I guess it should be first implemented to all modules.
Usualy they also have a web interface. I use the web interface for my carrier to delete any wrong labels and then correct it manually in tryton. Sure it is nice to be able to cancel in Tryton, but I think it adds complexity.
Yes, certainly in the case of a small number of parcels, but beyond a dozen or so I think the added complexity is outweighed by the time saved.
Having said that, I’m not going to get into it just yet (for all the shipping modules)