oca / delivery-carrier Goto Github PK
View Code? Open in Web Editor NEWOdoo Carriers And Deliveries Management
Home Page: https://odoo-community.org/psc-teams/logistics-18
License: GNU Affero General Public License v3.0
Odoo Carriers And Deliveries Management
Home Page: https://odoo-community.org/psc-teams/logistics-18
License: GNU Affero General Public License v3.0
If i set 'False' on setting parameters 'delivery_auto_refresh.auto_add_delivery_line' the delivery line is added but is not correct
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-10.0
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 :
I suggest to make a clear distinction between these methods by :
What do you think ?
base_delivery_carrier_label
Unit tests are failing in travis for all module depending on this one : https://app.travis-ci.com/github/OCA/delivery-carrier/jobs/480295199
Affected versions:
13.0
Steps to reproduce the behavior:
Expected behavior
test successful
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 :
So we would have 3 modules
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
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:
Features that will be complete for launch:
This code is dependent on a slew of modules:
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:
To install this module, you need to:
pip install easypost
To configure this module, you need to:
Connectors => [EasyPost] Backends
Validate
button above street addressConfirm
button to validate address is correct, or Cancel
to cancelNote that the address change will be made immediately after hitting Confirm
,
regardless of whether you save the partner or not.
cc @t3ddftw @LasLabs
delivery_free_fee_removal
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.
Steps to reproduce the behavior:
delivery_correos_express
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.
As it is no longer needed.
I've tried to:
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.
created by @hparfr
https://github.com/akretion/roulier
https://github.com/akretion/roulier-gls-fr/tree/develop
Roulier lib could move to an independent github organization
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0
Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list
./delivery_carrier_b2c
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0
Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list
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):
Summarizing: the delivery line is now the indicator of the delivery method. If we remove the free lines, we have these side-effects:
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:
qty_to_invoice
to 0)Any thoughts?
@cubells @pedrobaeza ?
Also, should I rename the module to delivery_free_fee_hide
if I make these changes?
According different features implemented on carriers modules, I think we need to refactor several points like :
For now there is #187 to be merged. I don't want to block the merge by this RFC, just plan evolution
@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 ?
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0
Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list
@sergio-teruel Did you have the same requirements or do you set partner zone manually ?
delivery_tnt_oca
When I validate the shipment I get this error described below
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'
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.
Right now, configuration is not well documented, plus returned error message from API are not very helpful
If the modules delivery_package_number
and stock_picking_delivery_info_computation
are installed together, the field appears twice.
See:
Perhaps stock_picking_delivery_info_computation
is a more complete alternative of delivery_package_number
, so I can close the issue.
@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
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
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:
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:
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
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 :
Shipment sent to carrier %(carrier_name)s for shipping with tracking number %(ref)s<br/>Cost: %(price).2f %(currency)s
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 ?
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.
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 ?
TODO:
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
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0
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.
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.
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?
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.
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-15.0
Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list
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) ?
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.
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:
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'}
?
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
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)
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
@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:
For my part the last is the best (shorter), then for other module delivery_carrier_mycarrier
Are you ok ?
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0
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.
I found two bugs for app delivery_multi_destination bugs in odoo 12.
If you add more than two multi destination shipping methods, the website will return 500 internal error on checkout page.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.