oca / delivery-carrier

Odoo Carriers And Deliveries Management

delivery-carrier

TODO: add repo description.

Available addons

addon	version	maintainers	summary
base_delivery_carrier_label	16.0.1.1.1		Base module for carrier labels
carrier_account_environment	16.0.1.0.0		Configure carriers with server_environment_files
delivery_auto_refresh	16.0.2.0.0		Auto-refresh delivery price in sales orders
delivery_automatic_package	16.0.1.0.0		Allows to set a delivery package automatically when sending to shipper.
delivery_carrier_account	16.0.1.0.1		Delivery Carrier Account
delivery_carrier_agency	16.0.1.0.0		Add a model for Carrier Agencies
delivery_carrier_deposit	16.0.1.0.0		Create deposit slips
delivery_carrier_info	16.0.1.0.0		Add code on carrier
delivery_carrier_max_weight_constraint	16.0.1.0.1		Constrain package maximum weight
delivery_carrier_package_measure_required	16.0.1.0.0		Allow the configuration of which package measurements are required on a delivery carrier basis.
delivery_carrier_partner	16.0.1.0.0		Add a partner in the delivery carrier
delivery_correos_express	16.0.1.0.0		Delivery Carrier implementation for Correos Express using their API
delivery_cttexpress	16.0.1.1.1		Delivery Carrier implementation for CTT Express API
delivery_deliverea	16.0.1.0.1		Delivery Carrier implementation for Deliverea using their API
delivery_driver	16.0.1.3.0		Allow choose driver in delivery methods
delivery_driver_stock_picking_batch	16.0.1.1.0		Add drivers from delivery in stock picking batch
delivery_estimated_package_quantity_by_weight	16.0.1.0.0		Compute the amount of packages a picking out should have depending on the weight of the products and the limit fixed by the carrier
delivery_multi_destination	16.0.1.0.0		Multiple destinations for the same delivery method
delivery_package_fee	16.0.1.1.1		Add fees on delivered packages on shipping methods
delivery_package_number	16.0.2.0.0		Set or compute number of packages for a picking
delivery_package_type_number_parcels	16.0.1.0.1		Number of parcels in a package type
delivery_postlogistics	16.0.1.0.7		Print PostLogistics shipping labels using the Barcode web service
delivery_postlogistics_server_env	16.0.1.0.0		Server Environment layer for Delivery Postlogistics
delivery_price_method	16.0.1.0.0		Provides fields to be able to contemplate the tracking statesand also adds a global fields
delivery_purchase	16.0.1.0.0		Delivery costs in purchases
delivery_roulier	16.0.1.0.0		Integration of multiple carriers
delivery_state	16.0.1.1.0		Provides fields to be able to contemplate the tracking statesand also adds a global fields
partner_delivery_schedule	16.0.1.0.0		Set on partners a schedule for delivery goods
partner_delivery_zone	16.0.1.0.1		This module allows to create partner delivery zones for physical products
server_environment_delivery	16.0.1.0.0		Configure prod environment for delivery carriers
stock_picking_delivery_link	16.0.1.1.3		Adds link to the delivery on all intermediate operations.
stock_picking_report_delivery_cost	16.0.1.0.0		Show delivery cost in delivery slip and picking operations reports

Licenses

This repository is licensed under AGPL-3.0.

However, each module can have a totally different license, as long as they adhere to Odoo Community Association (OCA) policy. Consult each module's __manifest__.py file, which contains a license key that explains its license.

---

OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.

delivery-carrier's Issues

Migration to version 12.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0

Modules to migrate

• base_delivery_carrier_label - ~~By @Timo17100-c2c - #187 - By @yvaucher - #205 ~~ By @bealdav - #212
• base_delivery_carrier_files - By @MPoch-PlanetaTIC - #237
• delivery_auto_refresh - By @cubells - #182
• delivery_carrier_label_batch - By @TDu - #222
• delivery_carrier_label_default #217 @i-vyshnevska
• delivery_carrier_partner - By @ValentinVinagre - #221
• delivery_dropoff_site - By @saxomanu #244
• delivery_free_fee_removal - By @pedrobaeza - #240
• delivery_multi_destination - By @luismontalba - #193
• delivery_price_rule_untaxed - By @rdeheele - #203
• partner_delivery_zone - By @antoniorubiopesol - #170
• partner_delivery_schedule - By @sergio-teruel - #236
• stock_picking_delivery_info_computation - By @victormmtorres - #211

Bug in delivery_auto_refresh

6a01ca6#r38339765

partner_delivery_zone: Zone auto attribution to partner depending on zip/city

@sergio-teruel Did you have the same requirements or do you set partner zone manually ?

[14.0] [RunBot] Can't make Colissimo (delivery_roulier_laposte_fr) work

I've tried to:

• get into your runbot ( http://3499001-14-0-257892.runbot2-2.odoo-community.org/ )
• go to the shop
• add an item to the cart
• set up a (fake) French address
• hit "Process Checkout",
• the delivery methods are correctly listed:

• But then the fee estimation is shown as an ever turning wheel, and a popup error appears:

Traceback (most recent call last):
  File "/.repo_requirements/odoo/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
    result = request.dispatch()
  File "/.repo_requirements/odoo/odoo/http.py", line 684, in dispatch
    result = self._call_function(**self.params)
  File "/.repo_requirements/odoo/odoo/http.py", line 360, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/.repo_requirements/odoo/odoo/service/model.py", line 94, in wrapper
    return f(dbname, *args, **kwargs)
  File "/.repo_requirements/odoo/odoo/http.py", line 348, in checked_call
    result = self.endpoint(*a, **kw)
  File "/.repo_requirements/odoo/odoo/http.py", line 913, in __call__
    return self.method(*args, **kw)
  File "/.repo_requirements/odoo/odoo/http.py", line 532, in response_wrap
    response = f(*args, **kw)
  File "/.repo_requirements/odoo/addons/website_sale_delivery/controllers/main.py", line 30, in update_eshop_carrier
    order._check_carrier_quotation(force_carrier_id=carrier_id)
  File "/.repo_requirements/odoo/addons/website_sale_delivery/models/sale_order.py", line 64, in _check_carrier_quotation
    if res.get('success'):
Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/.repo_requirements/odoo/odoo/http.py", line 640, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/.repo_requirements/odoo/odoo/http.py", line 316, in _handle_exception
    raise exception.with_traceback(None) from new_cause
AttributeError: 'NoneType' object has no attribute 'get' 

I had the same error on my own system when I tried to install the module.

I don't know if there is some configuration missing or it's an actual bug.

Proposal: EasyPost Connector

We are about done with an EasyPost Connector for Odoo, so I am now trying to figure out where we should actually put it.

Code is in its own repo for the moment, mainly because I had no clue where the final product would end up. I've seen a few modules that seem to be connectors hit carrier-delivery, so I figure this is the place to start.

Current Main features include:

• Address verification
• Rate quotes
• Label purchasing

Features that will be complete for launch:

• Package tracking via callback hook

This code is dependent on a slew of modules:

• connector
• base_delivery_carrier_label
• stock_picking_rate
• stock_picking_package_info

Unfortunately due to reliance on connector, this code cannot be tested on RunBot - part of the reason I didn't bother moving repos yet.

Do note while we are trying to determine where this does go. There are five total planned modules:

• connector_easypost - Basically what you see here
• connector_easypost_track - Callback hooks for package tracking
• connector_easypost_batch - Glue to support batch pickings
• connector_easypost_batch_track - Glue module for package tracking at batch level
• connector_easypost_web - Provides interface adjustments to allow for connector utilization in TBD web barcode interface

ReadMe:

Installation

To install this module, you need to:

• Install Python dependencies -
  pip install easypost
• Install OCA Connector module from https://github.com/OCA/connector
• Install Easypost Connector module
• Restart Odoo (requirement of any new connector to set proper DB triggers)

Configuration

To configure this module, you need to:

• Go to Connectors => [EasyPost] Backends
• Configure one EasyPost backend per company you would like to use with

Usage

Address Verification

• Edit a partner in backend form view
• Click Validate button above street address
• Click Confirm button to validate address is correct, or Cancel to cancel

Note that the address change will be made immediately after hitting Confirm,
regardless of whether you save the partner or not.

Known Issues / Roadmap

• Handle validation errors from addresses
• Some duplicate calls to EasyPost (Address, Shipment) - seems to be just in the tests though
• Add a default EasyPost connection to span all companies
• Mass address verification
• Label import operates in Shipment context, due to needing selected rate info not within PostageLabel
• Shipment buy workflow is a little ghetto with the intermediary wizard

---

cc @t3ddftw @LasLabs

13.0 delivery_postlogistics - generate postlogistic label failed with rollback

In V13, we had an issue where the postlogistic label failed to be generated because of a malformated zip code (there was an extra space at the end).

There is rollback done when postlogistics has failed label results:

delivery-carrier/delivery_postlogistics/models/stock_picking.py

Line 214 in 4a66d8e

if failed_label_results:

Then in write_tracking_number_label, we get the following error after the rollback:
Record does not exist or has been deleted. (Record: stock.quant.package(142,), User: 2)

I saw in version 12.0 that we raise the error as soon the API rejects to generate a label:

delivery-carrier/delivery_carrier_label_postlogistics/models/stock.py

Line 83 in e4799f3

raise exceptions.Warning('\n'.join(res['errors']))

At least in this case user gets the error message and not the side effect of the rollback.

Migration to version 9.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0

Modules to migrate

• base_delivery_carrier_files > base_delivery_carrier_file - By @angelmoya - #129
• base_delivery_carrier_files_document
• base_delivery_carrier_label @yvaucher #72
• delivery_carrier_b2c
• delivery_carrier_deposit - By @hparfr - #114
• delivery_carrier_file_laposte
• delivery_carrier_file_tnt
• delivery_carrier_label_default_webkit
• delivery_carrier_label_dispatch renamed delivery_carrier_label_batch @yvaucher #99
• delivery_carrier_label_gls
• delivery_carrier_label_postlogistics @yvaucher #73
• delivery_carrier_label_postlogistics_shop_logo
• delivery_dropoff_site - By @lmignon - #209 (Backport from 10.0)
• delivery_optional_invoice_line

delivery_multi_destination bugs

I found two bugs for app delivery_multi_destination bugs in odoo 12.

1. If you add more than two multi destination shipping methods, the website will return 500 internal error on checkout page.

2. The Multi destination shipping methods with shipping rates do not show in the Delivery Method selection list on backend order. So you can not quote the shipping rate from the multi destination shipping method if you want create an order manually in back end.

Thank you in advance for any contributor who will solve this.

Branches removal

@yvaucher I see two branches on this repo where you push commits.

In order to clean, I will delete them as they should not appear on OCA side.

Ok for you ?

Split base_delivery_carrier_label

Hello,
base_delivery_carrier_label is not used as a dependency for all oca carrier module. I think it is a shame not to have some consistency between oca modules on this matter, because that becomes a problem when using multiple carriers that works differently (not user friendly + harder to override in case of custom behavior).

The most important example, IMHO, is the carrier.account model.
In some module like delivery_ups_oca (probably multiple others) the carrier account is set directly on the delivery method, on others, based on base_delivery_carrier_label, it is managed with the carrier.account model from base_delivery_carrier_label.

I believe it is important that all modules use carrier.account for the following reasons :

• No delivery.carrier duplication in case we use multiple carrier accounts.
  In case of multi company instance for example, it allows you to share the delivery.method between companies
  In case of complicated use case you may have multiple account for a same carrier depending on custom criterias. In this case, you definitely don't want to duplicate the delivery.carrier

• no carrier account duplication : some times we have multiple delivery method for 1 carrier (depending on the service...) and it is easier to have a separated object for this, to avoid duplicating the account information on each delivery method.

• possibility tu customize the way to get the account information for all carrier instead of overriding the same for each carrier...

• we basically have at least an account number/password as common field for all carrier account, no duplicating this fields for each carrier make is easier, for instance we have a generic carrier_account_environment module instead of having one by carrier...

I am probably missing other pros arguments, and I don't really see any cons ?

The reason for not using base_delivery_carrier_label as a dependency I was told, if I remember well, was because it had too much features, it added too much maintenance burden, etc
That is why, I'd like to propose to split this module for version 16.

As I see it, base_delivery_carrier_label has 3 main features/areas :

1. carrier account model and (overridable) method to choose the right one
2. Possibility to have option for a delivery carrier with possibility to choose specific option for a picking and not another...
3. miscellaneous helpers that could help/standardize the carrier modules (special model to store labels, store parcel number on pack, auto generate pack if missing, etc)

So we would have 3 modules

1. delivery_carrier_account => dependency of all OCA carrier modules
2. delivery_carrier_option => optional for carrier modules that want to use it
3. delivery_carrier_helper => optional for carrier modules (I would make it mandatory as well, but I guess it is more controversial so let's forget this)

What do you think ? If the module is splitted in this way, would you be ok to make delivery_carrier_account a mandatory dependency for all carrier modules ?
@pedrobaeza @sebalix @sonhd91 @yvaucher

[RFC] stock_package_rate: Rates in Dispatch Wizard

This module will add a view of the Dispatch Rates provided in stock_picking_delivery_rate from within the Packaging wizard in a stock picking (delivery.view_quant_package_form_save).

As it stands right now, the packaging wizard contains the ability to select a package type to be used for dispatch, and manually select the shipping weight if necessary.

Below the shipping weight, the rates will be listed. An onchange will also be provided to watch for changes in the packaging/weight and adjust accordingly.

Simple enough of a module I think. I feel like this should be a common need though, so I feel like I'm missing something.

How does everyone else solve the problem of letting a user select which shipping rate should be used against a specific package? Are you all directing users to enter that in the Additional Info page of the stock picking before actually packing the order and just shipping all via the same carrier/method? Or is there a module/workflow I'm missing?

Same Delivery description on duplicated carriers

Hello, i've duplicated the delivery method and changed the values for the prices, destinations, and description. All changed ok but the description is the same . If i change the description, it change in both methods thah had been duplicated one from another. Expected each method diferent description.

Porting base_delivery_carrier_files to v8

Our company is planning on porting base_delivery_carrier_files. I saw in one of the commits (dee67b5) that some work was already done on it. I'm writing just to know whether someone is already doing this so that we don't duplicate work already done. Thanks for the info.

delivery_carrier_label_postlogistics: broken by a change on 'delivery.carrier.template.option'

This commit: 59038bd

Replaced the field state (with values 'mandatory', 'default_option', 'option') by boolean fields.
However, the PR did not changed the modules that depends on this state field.

I just stumbled upon delivery_carrier_label_postlogistics that still uses the state field:
https://github.com/OCA/carrier-delivery/blob/7.0/delivery_carrier_label_postlogistics/delivery.py#L221

Migration to version 14.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0

Modules to migrate

• delivery_auto_refresh - By @simahawk - #466
• delivery_carrier_default_tracking_url - By @xavier-bouquiaux - #386
• delivery_carrier_deposit - By @florian-dacosta - #332
• delivery_carrier_label_batch - By @khoivo1601 - #468
• delivery_carrier_label_default - By @sonhd91 - #456
• delivery_carrier_label_gls - By @paradoxxxzero - #778
• delivery_carrier_multi_zip - By @victoralmau - #539
• delivery_carrier_partner
• delivery_cttexpress - By @chienandalu - #549
• delivery_dropoff_site - By @chafique-delli - #771
• delivery_free_fee_removal - By @johnho91 - #411
• delivery_package_fee - By @dzungtran89 - #337
• delivery_package_number - By @hildickethan - #360
• delivery_price_method - By @victoralmau - #518
• delivery_price_rule_untaxed - By @AshishHirapara - #474
• delivery_purchase - By @victoralmau - #725
• delivery_tnt_oca - By @victoralmau - #484
• delivery_ups_oca - By @manuelregidor - #776
• partner_delivery_schedule - By @sergiocorato - #688
• partner_delivery_zone - By @MeetKD - #374
• stock_picking_delivery_link - By @hparfr - #389

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Github page not available

@OCA/board

For this repository we generate the branch https://github.com/OCA/delivery-carrier/tree/gh-pages

This branch was displaying a doc on http://oca.github.io/carrier-delivery
But this later url show nothing.

Could an OCA owner check this repository has the same settings for github page than on https://github.com/oca/connector ?

Thanks

14 base_delivery_carrier_label refactore

Since Odoo has implemented some carrier label modules I think there are issues with the module base_delivery_carrier_label.
Indeed, when we install it, we have 2 buttons.
"Shipping Label" (def action_generate_carrier_label) implemented by base_delivery_carrier_label
"Send to Shipper" (def send_to_shipper) implemented by Odoo, but really usefull with carrier label enterprise modules.

I don't use yet these module in recent version...but it seems to me that it is impossible for the end user to understand this !
Also, not using the native button, we have to override some native method to avoid problems (done in carrier modules, like here : https://github.com/OCA/delivery-carrier/blob/12.0/delivery_carrier_label_postlogistics/models/delivery.py#L224)

So, I'd like to change this, and I'd like to know the opinion of the main contributors.

Option 1) We display one button or the other depending on the carrier
I saw that we display the OCA button only if we have a carrier code. There are no reason to have a code with an enterprise carrier since it is an OCA field.
We could hide the native Odoo button if we have a code. (If not good enought, we could eventually add a flag on carrier or something
But we still would have a different workflow depending if the carrier is implemented by odoo or OCA

Option 2) Always hide the Odoo native button, override the send_shipping method.
=> Module is then totally incompatible with enterprise modules.
I guess this is not the way to go...

Option 3) Remove the OCA button and make base_delivery_carrier_label use the send_to_shipper method/button.
The main issues I see are :

• label is printed automatically at picking transfer. Not sure it is an issue, but it is a change for the OCA modules.
• Odoo SA always manage label with a price features, which is not the case at all in the OCA module.
  For example, in France, until now, we never got the price from carrier webservice and some just don't have this feature or we don't even want/need this feature.
  So Odoo always post a message of this kind on picking : Shipment sent to carrier %(carrier_name)s for shipping with tracking number %(ref)s<br/>Cost: %(price).2f %(currency)s
  which make no sense if the price is always 0 because not returned by carrier api.
  So we would need to patch it one way or another to remove the price part.
  (but from what I see, it is the case anyway if we have the Get Rate and Create Shipment set on integration_level field...so it is kind of a problem already since it is the default value when choosing a carrier delivery_type)

I in favor or solution 3) since it is the more compatible with Odoo enterprise.
And I don't really see big issues in doing it. At least if a user user enterprise and oca modules, it will really have only one workflow.

Concretly, we would get rid of action_generate_carrier_label / _compute_show_label_button / generate_default_label / generate_shipping_labels / _get_packages_from_picking (no relation with the subject it seems it becames useless, we could just ask for the field package_ids)
maybe bypass send_to_shipper if any shipping label exists (this way make it possible to generate labels before picking processing)

I'd make the change only in v14 as the module is still no migrated and it will break modules depending on it.
Any opinon @yvaucher @bealdav @sebastienbeau @hbrunn ?

Transfer validation error with TNT module 14.0

Module

delivery_tnt_oca

Describe the bug

When I validate the shipment I get this error described below

To Reproduce

1. Create a shipment with TNT courier;
2. Validate the transfer document

Expected behavior
It should validate the shipment, communicate the data to TNT, and generate the shipping document

Additional context
Errore:
Odoo Server Error

Traceback (most recent call last):
File "/opt/odoo/odoo/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
result = request.dispatch()
File "/opt/odoo/odoo/odoo/http.py", line 685, in dispatch
result = self._call_function(**self.params)
File "/opt/odoo/odoo/odoo/http.py", line 361, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/opt/odoo/odoo/odoo/service/model.py", line 94, in wrapper
return f(dbname, *args, **kwargs)
File "/opt/odoo/odoo/odoo/http.py", line 349, in checked_call
result = self.endpoint(*a, **kw)
File "/opt/odoo/odoo/odoo/http.py", line 914, in call
return self.method(*args, **kw)
File "/opt/odoo/odoo/odoo/http.py", line 533, in response_wrap
response = f(*args, **kw)
File "/opt/odoo/odoo/addons/web/controllers/main.py", line 1392, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/opt/odoo/odoo/addons/web/controllers/main.py", line 1380, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/odoo/odoo/api.py", line 399, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/opt/odoo/odoo/odoo/api.py", line 386, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/opt/odoo/odoo/addons/stock/models/stock_picking.py", line 973, in button_validate
pickings_to_backorder.with_context(cancel_backorder=False)._action_done()
File "/opt/odoo/odoo/addons/sale_stock/models/stock.py", line 91, in _action_done
res = super()._action_done()
File "/opt/odoo/odoo/addons/stock/models/stock_picking.py", line 800, in _action_done
self._send_confirmation_email()
File "/opt/odoo/odoo/addons/delivery/models/stock_picking.py", line 179, in _send_confirmation_email
pick.sudo().send_to_shipper()
File "/opt/odoo/odoo/addons/delivery/models/stock_picking.py", line 221, in send_to_shipper
res = self.carrier_id.send_shipping(self)[0]
File "/opt/odoo/odoo-custom-addons/oca/delivery-carrier/delivery_state/models/delivery_carrier.py", line 11, in send_shipping
res = super().send_shipping(pickings)
File "/opt/odoo/odoo/addons/delivery/models/delivery_carrier.py", line 194, in send_shipping
return getattr(self, '%s_send_shipping' % self.delivery_type)(pickings)
File "/opt/odoo/odoo-custom-addons/oca/delivery-carrier/delivery_tnt_oca/models/delivery_carrier.py", line 166, in tnt_oca_send_shipping
return [self.tnt_oca_create_shipping(p) for p in pickings]
File "/opt/odoo/odoo-custom-addons/oca/delivery-carrier/delivery_tnt_oca/models/delivery_carrier.py", line 166, in
return [self.tnt_oca_create_shipping(p) for p in pickings]
File "/opt/odoo/odoo-custom-addons/oca/delivery-carrier/delivery_tnt_oca/models/delivery_carrier.py", line 173, in tnt_oca_create_shipping
self._tnt_oca_action_label(picking)
File "/opt/odoo/odoo-custom-addons/oca/delivery-carrier/delivery_tnt_oca/models/delivery_carrier.py", line 154, in _tnt_oca_action_label
res = iar._get_report_from_name(report_name).render_qweb_text(picking.ids)
Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/opt/odoo/odoo/odoo/http.py", line 641, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/opt/odoo/odoo/odoo/http.py", line 317, in _handle_exception
raise exception.with_traceback(None) from new_cause
AttributeError: 'ir.actions.report' object has no attribute 'render_qweb_text'

Questions on package_ids

Hi,

I started the implementation of Laposte WS (according to 2016 specifications).
While digging in the sources, I don't understand this :

    def generate_labels(self, package_ids=None):
        """ Generate the labels.
        A list of tracking ids can be given, in that case it will generate
        the labels only of these packages.
        """
        label_obj = self.env['shipping.label']

        for pick in self:
            if package_ids:
                shipping_labels = pick.generate_shipping_labels(
                    package_ids=package_ids
                )

https://github.com/OCA/carrier-delivery/blob/9.0/base_delivery_carrier_label/stock.py#L120

If there is multiple picks in self and package_ids is not None, where is the check to exclue all the package_ids which doesn't belongs to pick ?

And more globally, what's the point of package_ids in params ?
It means we can deliver a part of a picking with one carrier and the rest with another one ?

Missing readme.rst

./delivery_carrier_b2c

module migration to 8.0 summary

TODO:

• base_delivery_carrier_files
  • #47
• base_delivery_carrier_files_document - By @thomaspaulb - #163
• base_delivery_carrier_label
  • #33
• delivery_carrier_b2c
  • #33
• delivery_carrier_deposit
  • #33
• delivery_carrier_file_laposte
• delivery_carrier_file_tnt
• delivery_carrier_label_default_webkit
  • To be replaced by a QWeb label
• delivery_carrier_label_dispatch
• delivery_carrier_label_postlogistics
  • #41
    • depends on #33
• delivery_carrier_label_postlogistics_shop_logo
• delivery_optional_invoice_line

Migration to version 16.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0

Modules to migrate

• base_delivery_carrier_label - By @florian-dacosta - #570
• carrier_account_environment - By @florian-dacosta - #616
• delivery_auto_refresh - By @RabbitJon-S73 - #651
• delivery_carrier_agency - By @florian-dacosta - #571
• delivery_carrier_default_tracking_url - By @gaelTorrecillas - #679
• delivery_carrier_deposit - By @clementmbr - #764
• delivery_carrier_info - By @florian-dacosta - #568
• delivery_carrier_label_gls - By @glitchov - #599
• delivery_carrier_max_weight_constraint - By @glitchov - #594
• delivery_carrier_package_measure_required - By @RodrigoBM - #713
• delivery_carrier_partner - By @glitchov - #640
• delivery_carrier_service_level - By @ntsirintanis - #607
• delivery_correos_express - By @vicentecom - #813
• delivery_cttexpress - By @chienandalu - #566
• delivery_dropoff_site - By @jdoutreloux - #754
• delivery_multi_destination - By @carolinafernandez-tecnativa - #766
• delivery_package_fee - By @tuantrantg - #693
• delivery_package_number - By @chienandalu - #553
• delivery_postlogistics - By @lehoangan - #619
• delivery_price_method - By @chienandalu - #554
• delivery_purchase - By @carolinafernandez-tecnativa - #755
• delivery_state - By @chienandalu - #551
• delivery_tnt_oca - By @hildickethan-S73 - #649
• delivery_translatable - By @David-Luis-Mora - #800
• partner_default_delivery_carrier - By @BT-mrobles - #727
• partner_delivery_schedule - By @victoralmau - #770
• partner_delivery_zone - By @gerardoOperu - #648
• stock_picking_delivery_link - By @glitchov - #596
• stock_picking_report_delivery_cost - By @victoralmau - #706

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Remove manifest.wizard from base_delivery_carrier_label ?

In the module base_delivery_carrier_label, there is a wizard "manifest.wizard", cf https://github.com/OCA/delivery-carrier/blob/10.0/base_delivery_carrier_label/wizard/manifest_wizard.py

It was introduced 3 years ago by this commit of @ismaelcj e9ebf25

This wizard doesn't do anything by itself ; it needs to be inherited by carrier-specific modules I guess. But I don't find any carrier-specific modules that use it in the OCA. And I don't understand what's the point of this wizard anyway.

The problem is that it adds a very visible menu entry under the Inventory menu, and most of us don't need it... which bother our users. Could we remove that wizard (or at least remove the menu entry) ?

Remove master branch

As it is no longer needed.

Repository name

This branch name is carrier-delivery and modules inside are [base_]delivery_carrier_blabla

It's error prone. Nobody can remember what is the real name.

I suggest to rename carrier-delivery repo by delivery-carrier.

As we had could see when switch from lp: to github:, github manage really well alias repositories.
Then there'll no impact to production environment.

Please thanks to vote.

ping @yvaucher @guewen

Migration to version 13.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0

Modules to migrate

• base_delivery_carrier_label - By @ps-tubtim - #251
• delivery_auto_refresh
• delivery_carrier_label_default
• delivery_carrier_partner - By @acsonefho - #261
• delivery_dropoff_site - By @acsonefho - #281
• delivery_free_fee_removal - By @guewen - #280
• delivery_multi_destination - By @CarlosRoca13 - #329
• delivery_package_number - By @misern2 - #292 By @pedrobaeza - #339
• delivery_state - By @misern2 - #291
• partner_delivery_schedule - By @sergio-teruel - #247
• partner_delivery_zone - By @sergio-teruel - #248
• stock_picking_delivery_info_computation
• stock_picking_report_delivery_cost - By @victoralmau - #310

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

RFC delivery carrier in v12 and above

According different features implemented on carriers modules, I think we need to refactor several points like :

1. remove carrier.account model https://github.com/OCA/delivery-carrier/blob/11.0/base_delivery_carrier_label/models/carrier_account.py to be replaced by server env or any equivalent features
2. in the purpose to reduce useless code, always use package to define parcel (no more picking)
3. open carriers features to the whole python ecosystem (or more) : other python ERP, other applications dealing with carriers, etc. An example has been made here http://akretion.github.io/roulier https://pypi.org/project/roulier
4. other stuff

For now there is #187 to be merged. I don't want to block the merge by this RFC, just plan evolution

cc @Timo17100-c2c @yvaucher @guewen

[9] refactorisation of base_default_label

Hi folks,

These days tere is some work against branch 9.0, it's still time to do heavy refactors before freezing the code.

For new commers, it's quite hard to understand how to integrate / develop a new carrier.
I think there is 3 types of methods :

• helpers methods (like get_weight)
• logic methods (glue between UI and carrier's specific methods)
• carrier's specific methods (fetch relevant data, then call webservice and so on)

I suggest to make a clear distinction between these methods by :

• better naming
• write the type in docstrings
• move all carrier specific method in separate files or modules.

What do you think ?

[12.0] Field duplicated: number_of_packages

If the modules delivery_package_number and stock_picking_delivery_info_computation are installed together, the field appears twice.
See:

delivery-carrier/delivery_package_number/models/stock_picking.py

Line 9 in 726d786

number_of_packages = fields.Integer(

delivery-carrier/stock_picking_delivery_info_computation/models/stock_picking.py

Line 10 in 726d786

number_of_packages = fields.Integer(

Perhaps stock_picking_delivery_info_computation is a more complete alternative of delivery_package_number , so I can close the issue.

Inheritance

Hi folks,

Let's say, I have two modules installed : delivery_carrier_label_postlogistics and delivery_carrier_label_gls

In stock.py I can see both inherit from stock.picking.

It means at run time :

#when I do :  
a_picking.generate_shipping_labels()
# it may call
gls/stock.py:generate_shipping_labels ->  postlogistics/stock.py:generate_shipping_labels -> base/stock.py:generate_shipping_labels

How can a gls' picking be a child of postlogistics' picking ?

Can't we do the same way res.user extends res.partner :

#poststocklogitics/stock.py
class StockPickingStockLogistics(models.Model):
    _inherits = {'stock.picking': 'picking_id'}

#gls/stock.py
class StockPickingGls(models.Model):
    _inherits = {'stock.picking': 'picking_id'}

?

Migration to version 15.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-15.0

Modules to migrate

• base_delivery_carrier_files - By @wytzejan - #667
• base_delivery_carrier_label - By @fshah-initos - #476
• connector_routific - By @CarlosRoca13 - #544
• delivery_auto_refresh - By @pilarvargas-tecnativa - #614
• delivery_automatic_package - By @nikolausweingartmair - #765
• delivery_carrier_category - By @pere-aquarian - #602
• delivery_carrier_city
• delivery_carrier_info - By @fshah-initos - #475
• delivery_carrier_multi_zip - By @victoralmau - #560
• delivery_carrier_partner - By @hbrunn - #709
• delivery_carrier_pricelist
• delivery_cttexpress - By @chienandalu - #550
• delivery_free_fee_removal - By @victoralmau - #569
• delivery_multi_destination - By @victoralmau - #542
• delivery_package_fee - By @bizzappdev - #804
• delivery_package_number - By @victoralmau - #515
• delivery_postlogistics
• delivery_postlogistics_server_env
• delivery_price_method - By @victoralmau - #536
• delivery_purchase - By @victoralmau - #610
• delivery_roulier
• delivery_roulier_laposte_fr
• delivery_roulier_option
• delivery_send_to_shipper_at_operation
• delivery_state - By @victoralmau - #516
• delivery_ups_oca - By @jaredkipe - #525
• partner_delivery_schedule - By @victoralmau - #538
• partner_delivery_zone - By @cesar-tecnativa - #510
• server_environment_delivery
• stock_picking_delivery_link - By @flachica - #532
• stock_picking_report_delivery_cost - By @pilarvargas-tecnativa - #595

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Partner Shipper (similar to partner_delivery_zone)

Hi, we have created a module (after searching from here) called partner_shipper. It is a simple module, that allow a partner to tie to multiple shippers (company that do the shipping). On Sales Order, user select 1 shipper from multiple available shippers specific to the partner. The shipper from SO will be passed on to both Delivery Order and Invoice.

https://github.com/ecosoft-odoo/addons/tree/12.0/partner_shipper

Is this module welcome to be in OCA/delivery-carrier? it is quite generic. If so, we can do the PR.

Migrating delivery_carrier_multi_zip to 14.0

Is your feature request related to a problem?

No

Describe the solution you'd like

The module to also be available on the 14.0 branch in addition to the 13.0 branch.

Describe alternatives you've considered

None

Additional context

It is a small module and we use it in our installation on Odoo 14 from the 13.0 branch for now. Can I help somehow to get it also on the 14.0 branch? The tests run successful and it seems no code changes are needed.

[RFC][WMS] Delivery round

Source : https://docs.google.com/document/d/1mct6bFFWJqW01wGFcjc-uQNEjyCxvh6Y9TuFdRhe-b0/edit#
Part of: OCA/wms#1

This RCF to propose a POC implementation for the following

• Manage the delivery round and related cut-off time (both order taking and release of picking)

• Pilot the reservation of the goods when the release of operations within the warehouse are released (reservation occurs virtually during order confirmation, release of operations occurs depending on several criteria)

• Handle the concepts of

  • "Geographical zone" as a group of zip codes
  • "Delivery Template" as a configuration of your round
  • "Delivery Round" as a list of order that belong to customers included in the related geographical units
  • "Resources" as the notion of vehicles (or any means to ship your goods)

Background and strategic fit

In order to drive the warehouse operations in the most effective manner, we must be able to pilot who's working on what in a sequenced order depending on several criteria.

Assumptions

• The delivery round weekday is mapped to the weekday of the customer (e.g. the customer wants to receive the delivery on wednesday → the delivery round is called wednesday (not tuesday)

• Customers may have fixed weekday delivery

• Sales order may have a fixed term delivery date

• We do have a general delivery round lead time (in days) → re-use the Odoo one (Security Lead Time for Sales)

[13.0]base_delivery_carrier_label unit tests failed cause travis to fail on dependencies

Module

base_delivery_carrier_label

Describe the bug

Unit tests are failing in travis for all module depending on this one : https://app.travis-ci.com/github/OCA/delivery-carrier/jobs/480295199

To Reproduce

Affected versions:
13.0

Steps to reproduce the behavior:

1. create a module depending on this one and create a PR, eg #281

Expected behavior

test successful

delivery-carrier: sudo() missing on retrieving postlogistics_client_id and postlogistics_client_secret

delivery-carrier/delivery_postlogistics/postlogistics/web_service.py

Line 382 in fc709c7

client_id = delivery_carrier.postlogistics_client_id

postlogistics_client_id and postlogistics_client_secret are both defined as fields.Char(..., groups="base.group_system"). Because of this, when retrieving such fields, sudo() must be used; otherwise, only admins can perform the operation.

Suggestion:

REPLACE:
client_id = delivery_carrier.postlogistics_client_id
client_secret = delivery_carrier.postlogistics_client_secret

WITH:
delivery_carrier_sudo = delivery_carrier.sudo()
client_id = delivery_carrier_sudo.postlogistics_client_id
client_secret = delivery_carrier_sudo.postlogistics_client_secret

RFC Roulier fondation for Odoo delivery carrier ! ?

Roulier Library

created by @hparfr

https://github.com/akretion/roulier
https://github.com/akretion/roulier-gls-fr/tree/develop

Why

• to be less impacted by odoo versions
• get profit of large audience of python in recent years, hoping more contributors
• get a wider audience, not only python with entry points and json (every language can use this lib)
• api inspired from easypost and https://www.shippypro.com/ShippyPro-API-Documentation/#authentication

Todo

• move to python 3 WIP
• each new carriers should be implemented as new lib WIP
• improve error management
• add more tests
• improve consistency of signature methods

Roulier lib could move to an independent github organization

[14.0] Can't get producto price to add Correos delivery method in sale order ()

Module

delivery_correos_express

Describe the bug

When you select the correos express shipping method in the sale order Add shippment wizard, the price of the shipment is always set to 0. The price should be the price of the product selected in the shipping method.

To Reproduce

• Create a new shipping method selecting correos express
• Select the configured product for the shippment whith a price different to 0
• Create a new sale order
• Add shippment
• Select Correos express
• The price of the line should be the price of the product selected in the configuration process and as you can check is 0.

generic module name for carrier

@hparfr made a generic module for carrier but with a dependency on base_delivery_carrier_label.

It has a https://pypi.python.org/pypi/roulier an API for package delivery

you can see there:

https://github.com/akretion/delivery-carrier/tree/8-roulier/delivery_carrier_label_roulier

We want to propose it for OCA but we want rename module shorter. Here are some options:

• delivery_carrier_roulier
• delivery_roulier

For my part the last is the best (shorter), then for other module delivery_carrier_mycarrier

Are you ok ?

Schenker TLS V1.2

I have this email from DB Schenker relating to the TLS version

Dear DB Schenker web service user,

We would like to connect with you regarding the following eSchenker web service(s) that you are using:

BookingWebServiceV1_1
GermanLabelServiceV1 
BookingParcelRestApi_V1
BookingParcelWebserviceV1
BranchWS_V1
TrackingWebsService_V1

There are upcoming technical changes to these web services which might impact you.

What is the change?
We will upgrade our security and only allow TLSv1.2 or higher to connect with our web services.
For more information on TLS, please see the following article - https://en.wikipedia.org/wiki/Transport_Layer_Security

When is the change planned for?
We will upgrade our security at the end of July 2022.

From what I could find zeep uses V1.2+ by default, so I don't think there needs to be a change, but I want to confirm with @chienandalu , I assume one of your clients will also have received something like this

If everything is ok then feel free to close the issue

Migration to version 11.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Modules to migrate

• base_delivery_carrier_files
• base_delivery_carrier_files_document
• base_delivery_carrier_label - By @hugosantosred - #150 By @asaunier - #154
• delivery_carrier_b2c
• delivery_carrier_deposit
• delivery_carrier_file_laposte
• delivery_carrier_file_tnt
• delivery_carrier_label_default - By @sebalix - #169
• delivery_carrier_label_default_webkit
• delivery_carrier_label_dispatch
• delivery_carrier_label_gls
• delivery_carrier_label_postlogistics - By @grindtildeath - #155
• delivery_carrier_label_postlogistics_shop_logo
• delivery_carrier_partner - By @SimoRubi - #172
• delivery_multi_destination
• delivery_optional_invoice_line
• delivery_price_rule_untaxed - By @tarteo - #173
• sale_delivery_rate
• stock_picking_delivery_rate

delivery_shipstation

This module allows you to connect Odoo with ShipStation and create various delivery methods based on the carriers and services supported by ShipStation (http://www.shipstation.com).

As with any delivery method, you can:

• get a delivery price on the sales order
• get the tracking number and shipping documents (label, etc) on the delivery order

method call generate_labels() doesn't match signature

It seems there is a difference between this call
https://github.com/OCA/carrier-delivery/blob/7.0/base_delivery_carrier_label/stock.py#L148
return self.generate_labels(cr, uid, ids, context=context)

and this method
https://github.com/OCA/carrier-delivery/blob/7.0/base_delivery_carrier_label/stock.py#L105
def generate_labels(self, cr, uid, ids, tracking_ids=None, context=None):

Personally and I do not use 'action_generate_carrier_label'.
Which args should change ?

Thanks

Migration to version 10.0

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-10.0

Modules to migrate

• base_delivery_carrier_files - By @thomaspaulb - #206
• base_delivery_carrier_files_document - By @mFlayyan - #184 By @thomaspaulb - #206
• base_delivery_carrier_label #124 @angelmoya
• delivery_carrier_b2c #116 @EBII
• delivery_carrier_deposit - By @EBII - #133
• delivery_carrier_file_laposte
• delivery_carrier_file_tnt
• delivery_carrier_label_default - By @thomaspaulb - #207
• delivery_carrier_label_dispatch
• delivery_carrier_label_gls
• delivery_carrier_label_postlogistics @yvaucher
• delivery_carrier_label_postlogistics_shop_logo
• delivery_optional_invoice_line

[14.0]delivery_free_fee_removal doesnt work if sale order is locked

Module

delivery_free_fee_removal

Describe the bug

If setting group_auto_done_setting is true, sale orders are locked after action_confirm.

This line

 delivery_lines = self.order_line.filtered(
            lambda line: line.order_id.state == "sale" and line. 

in sale_order.py should probably be

 delivery_lines = self.order_line.filtered(
            lambda line: line.order_id.state in ("sale","done") and line.

To Reproduce

Steps to reproduce the behavior:

1. Enable locking sale from settings after completion
2. Create a sales order with a delivery

Odoo 12 Manifest - Error

Im getting the below error when i try to view a manifest for any carrier in odoo 12.

Any ideas why or how to fix?

THANKS

Error:
Odoo Server Error

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/http.py", line 656, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 314, in _handle_exception
raise pycompat.reraise(type(exception), exception, sys.exc_info()[2])
File "/usr/lib/python3/dist-packages/odoo/tools/pycompat.py", line 87, in reraise
raise value
File "/usr/lib/python3/dist-packages/odoo/http.py", line 698, in dispatch
result = self._call_function(**self.params)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 346, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/usr/lib/python3/dist-packages/odoo/service/model.py", line 97, in wrapper
return f(dbname, *args, **kwargs)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 339, in checked_call
result = self.endpoint(*a, **kw)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 941, in call
return self.method(*args, **kw)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 519, in response_wrap
response = f(*args, **kw)
File "/usr/lib/python3/dist-packages/odoo/addons/web/controllers/main.py", line 966, in call_button
action = self._call_kw(model, method, args, {})
File "/usr/lib/python3/dist-packages/odoo/addons/web/controllers/main.py", line 954, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/usr/lib/python3/dist-packages/odoo/api.py", line 759, in call_kw
return _call_kw_multi(method, model, args, kwargs)
File "/usr/lib/python3/dist-packages/odoo/api.py", line 746, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "", line 2, in get_manifest_file
File "/usr/lib/python3/dist-packages/odoo/api.py", line 382, in loop
result = [method(rec, *args, **kwargs) for rec in self]
File "/usr/lib/python3/dist-packages/odoo/api.py", line 382, in
result = [method(rec, *args, **kwargs) for rec in self]
File "/usr/lib/python3/dist-packages/odoo/addons/base_delivery_carrier_label/wizard/manifest_wizard.py", line 33, in get_manifest_file
self.carrier_id.delivery_type)
NotImplementedError: Manifest not implemented for 'fixed' carrier.

Postlogistics - improve configuration process

Right now, configuration is not well documented, plus returned error message from API are not very helpful

[13.0] delivery_free_fee_removal behavior not coherent with standard behavior

The module delivery_free_fee_removal allows to ignore the creation of delivery lines when they have a zero amount.
I migrated it in 13.0 (#280) but overlooked changes in version 13.0 which bring new problems.

The delivery line becomes more important in 13.0 (probably to simplify the UI/UX):

• the carrier field is not shown, as the delivery line contains the delivery method's name
• the button "add shipping" becomes "update shipping" only when the computed field "delivery_set" is True, which is True when a delivery line exists
• for users, removing the delivery method is done by deleting the delivery line

Summarizing: the delivery line is now the indicator of the delivery method. If we remove the free lines, we have these side-effects:

• we don't know if and which method has been selected
• the button "update shipping" is never shown, only "add shipping"
• no way to remove a delivery method

One way to solve this would be to change the delivery_set computed field and show the carrier field: I don't like it because it brings back complexity and different ways for users to work with delivery methods.

IMO a better solution, since 13.0, would be to:

• keep the 0 lines but maybe show them in gray
• ignore the 0 lines when creating the invoice (set qty_to_invoice to 0)
• hide delivery lines in sale reports

Any thoughts?
@cubells @pedrobaeza ?

Also, should I rename the module to delivery_free_fee_hide if I make these changes?

12.0 always shipping cost added in sale

If i set 'False' on setting parameters 'delivery_auto_refresh.auto_add_delivery_line' the delivery line is added but is not correct

ZPL recovery mode

Ping @yvaucher @guewen @hparfr @sebastienbeau

What do you think to add generic method to use this webservice for our customers just in case of the printer is out of order ?

http://labelary.com/service.html

With
GET http://api.labelary.com/v1/printers/{dpmm}/labels/{width}x{height}/{index}/{zpl}

you can add pdf attachement to picking.

Thanks for your reply.