The dimensions UoM of the carrier packaging is useless: it is not the
one used in the requests and there is not any conversion
To reproduce the issue
(Need delivery_fedex. Use demo data. Enable debug mode)
1. In Shipping Methods, edit 'Fedex US':
- Package Weight Unit: KG
- Debug Requests: True
2. Edit its Fedex Package Type:
- Height: 1m
- Width: 1m
- Length: 1m
- Package Code: YOUR_PACKAGING
3. Create a SO with a US partner and one product
4. On the SO
- Add Shipping
- Select 'Fedex US'
- Click on 'Get Rate'
5. In Logging, open the request sent
Error: the dimensions of the packaging are expressed with "CM" but they
are not converted:
```xml
<ns0:Dimensions>
<ns0:Length>1</ns0:Length>
<ns0:Width>1</ns0:Width>
<ns0:Height>1</ns0:Height>
<ns0:Units>CM</ns0:Units>
</ns0:Dimensions>
```
When encoding the packaging in the request, the UoM defined on the
packaging (meter) is ignored. Instead, we define a length UoM depending
on the UoM of the weight and we don't convert any dimension:
https://github.com/odoo/enterprise/blob/e4fd13a0e073b9855864b7fabc26bc05b9a5fd19/delivery_fedex/models/fedex_request.py#L172-L178
There is even a `TODO` about the issue.
It will be the same with the other carriers. For instance, with UPS:
https://github.com/odoo/enterprise/blob/c9899f7860cd19c86f215d6dcea89f73b51433f3/delivery_ups/models/ups_request.py#L98-L102
We use the UoM of `ups_package_dimension_unit` and do not convert the
dimensions.
We can't implement the dimensions conversion on stable versions, since
it will break all existing packagings. So, as temporary solution, we can
simply hide the useless UoM defined on the packagings.
OPW-3053048
closesodoo/odoo#106338
X-original-commit: 3bc2f594395a08515ed362e3d9a816e7cc18c842
Related: odoo/enterprise#34305
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The _compute_related function can only update one translation but not all. We
decide not to update all translations to avoid increasing the time complexity.
As a result, the value for related translated fields should always be generated
in the runtime, and storing it is illegal.
A related translated stored field may work as expected in a single language
environment. But in mult languages environment, if you have a name field
name = fields.Char(related="parent_id.name", store=True)
changing parent_id in French, will only change the French translation of the
name field
This PR tries to remove these fields. And a warning is added to prevent
developers creating a related translated stored field in the future.
closesodoo/odoo#102553
Related: odoo/upgrade#4004
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
It is not possible for a user to add a carrier directly on a picking if
the invoicing policy of that carrier is set to "Real Cost"
To reproduce the issue:
1. Enable a carrier C
2. Setup a shipping method SM:
- Carrier: C
- Invoicing Policy: Real Cost
3. Create and confirm a SO with a product
4. Edit the related picking P:
- Carrier: SM
5. Validate P
Error: a Validation error is raised "The operation cannot be completed
[...] Model: Sales Order Line (sale.order.line), Field: Description
(name)"
When validating the delivery, we try to create a new SOL with the
shipping cost. We then update its description with the carrier name.
However, since the carrier has been directly added on the picking, the
sale order does not have that information. We should rather get this
information from the delivery.
OPW-2862306
closesodoo/odoo#103986
X-original-commit: 611bd008075f5b8f8080281ae877ada3076a9e7a
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Steps to reproduce:
1- install sale, accounting
2- create a fiscal position fp that maps
tax inc t1 to any other tax t2
3- create a delivery product dp with t1 and mark it "can be sold"
4- create a new delivery method with dp
5- in a new sales order, choose fp, click on add delivery
6- the unit_price is wrong, it hasn't mapped t1 to t2
7- try adding the delivery as a product in a new sales order line
8- the unit_price is correct and the taxes are correctly calculated
Bug:
`_create_delivery_line` is not using the same logic used
when normally adding a sales order line although technically
delivery product is still a product
Fix:
use `_get_tax_included_unit_price` to get the correct unit_price
OPW-2806965
closesodoo/odoo#96874
X-original-commit: 03bb18d12606447faaed0de04bb83dde5de53b96
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Steps to reproduce:
- Delivery module is installed.
- User_1 is stock_manager and sale_manager.
- User_1 creates sale_order with set carrier_id and confirms it
(Automatically is created a picking P).
- User_2 is stock user/manager but in sale is "Own documents only".
- User_2 open picking P and validates it.
=> Error: cannot validate due to access rules.
closesodoo/odoo#94684
X-original-commit: 465bb47b89e34609b34a647a5a4ba4db8a0ffc8a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit does a couple of small related improvements:
- adds new delivery options: "Local Delivery".
We replace the existing "Normal Delivery Charges" with the new "Local
Delivery" since it is now redundant.
- Originally a "Local Pickup" demo option was going to be added, but
this appeared redundant with the "[On Site Pick]" added in
odoo/odoo#87636 . Regardless, an additional `carrier_description`
field has been added so users can include extra instructions (e.g.
address to pick up from, when pickup can occur, etc) to sales orders/
confirmation emails (emails only via ecommerce sales).
- adds option to filter based on zip prefix rather than the previous zip
"range" option, which was too restrictive in some cases (e.g. in the
UK where zips can have letters in them). Note that users can view/edit
zip prefixes in menu under settings when debug mode is active. Note:
- prefixes are ordered by name so its easier to read large numbers
prefixes
- prefixes are always capitalized to avoid duplicate prefixes that
differ by case + avoid capitalizing all prefixes every time the
`_match_address` logic is called
Task: 2706451
Upgrade PR: odoo/upgrade#3384closesodoo/odoo#84620
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commodity now uses product county of origin code instead of
country of origin field directly since its a res.country model
and breaks the request if set on a product
closesodoo/odoo#93195
X-original-commit: 980d103050fee552a9f68421cf119c119397bbe2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Select any two storable product that has invoicing policy set on 'Delivery'
- Create a sales order lines with these two products and make sure that one of the lines should have a quantity set to 0
- Add shipping
Issue:
- The Invoice Status has changed to 'To Invoice'
Solution:
Add en extra filter to consider only lines that have not been invoiced.
opw-2750861
closesodoo/odoo#89548
X-original-commit: bfeb5f6317786edfd0fa464fe5798c7f7bc65ac9
Signed-off-by: yosa-odoo <yosa@odoo.com>
Observed Behaviour
When using a pricelist with a fixed price for all products with a different
currency than the one of the company, adding shipping cost in a sale order
using this pricelist will give a wrong value of the shipping cost
Expect Behaviour
The computed shipping cost added in the sale order should be the same as the
fixed price defined in the pricelist
Reproducibility
This issue can be reproduced using the following steps :
1. Define a pricelist PL1 with a fixed price for all products and a different
currency than the one used in the company (eg fixed price to 15KR)
2. Create a sale order and select PL1 as pricelist
3. Add a product and add a shipping cost
The shipping cost should be the defined fixed price (15KR) but it gives
another value, depending of the company currency
Fix Description
This fix remove a useless currency conversion coming from the fact that since
https://github.com/odoo/odoo/pull/86484 we get the delivery price from the SO
priceliste (using pricelist.get_product_price) giving us a price that is
already converted to the correct currency
Related issue/PR
opw-2810506
closesodoo/odoo#88861
X-original-commit: 25e2f403e88172d67ea6ce382ac1e3f5e0e37835
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
Expected Behaviour
When adding a shipping cost in a SO, with the shipping method being
associated to a product, the price should be calculated according to
the price of the product in the order's pricelist if available
Observed Behaviour
When adding a shipping cost related to a product, with a fixed price,
the public price of the product is used instead of the price defined
in the SO pricelist
Reproducibility
1. Create a product "Test Shipping" with a public price of 10
2. Create a shipping method "Test Shipping" associated with the
"Test Shipping" product
3. Create a pricelist "Test Pricelist", where the product "Test
Product" has a cost of 15
4. Create a contact "Test Contact" associated with "Test Pricelist"
5. Create a So for the "Test Contact" with "Test Shipping" as shipping
method -> Shipping cost will be 10 instead of 15.
Fix Description
The issue here was that the price computed by the delivery carrier didn't
took into account the selected pricelist. We tried to then change it in
the delivery chooser wizard, but some issue with particular case (i.e.
when the shipping cost should be 0 if the SO total is bigger than X)
appeared, leading us to add the fix directly in the delivery_carrier
classe.
Related Issues/PR
- opw-2754482
closesodoo/odoo#87028
X-original-commit: bb778cd7be835706f54e9e0f342eecf3e5e4e904
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
A modification made by Amazon on October 1st restricts the allowed
values for the carrier name. Since it now expects it in a formatted
state, this commit will allow Odoo to send the delivery type of the
carrier rather than its name, which can be customized by the user.
opw-2665099
closesodoo/odoo#84291
X-original-commit: 0b4530b124d4ac86dad34907c6d6b6e9ea69c7b6
Related: odoo/enterprise#24204
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Shipping insurance is a service which may reimburse senders whose parcels are
lost, stolen, and/or damaged in transit. Since most shipping connectors
provide it, it makes sense to put it in the base directory.
task-2701459
closesodoo/odoo#83896
Signed-off-by: Arnold Moyaux <arm@odoo.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When a package name is a valid SSCC number, we prefer to auto-print the
datamatrix to be used by shippers, which includes:
- the SSCC number
- the pack date (i.e. when it was put in pack)
- the weight of the package (only when less or equal to 6 digits)
Pack date field was added to accomodate this and defaults to when
package is created (e.g. when buying packaged meat at the supermarket,
it's assumed the pack date is when the package of meat was created).
SSCC datamatrix will auto-print now in 3 package reports:
- Package with contents
- Package Barcode (PDF)
- Package Barcode (ZPL)
Note if ability to create datamatrix appears to not work (only in PDF
versions) then standard 1D barcode will be used.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Upgrade PR: odoo/upgrade#3202
Part-of: odoo/odoo#82389
Before this commit, to aaccess some values of the DeliveryPackage
objects, we needed to take the value from the related picking. for
example, for the `payment country code` linked to the package, we need
to retrieve the value from the related picking or order.
To avoid passing too much data to the request objects, it is convenient
to be able to access to the order/picking related to the package
directly from the package.
Because these objects are not children of odoo.models.Model, I do not
need to follow the convention for the names, however, calling the
picking > picking_id in the DeliveryPackage suggests that the picking is
actually a odoo.models.Model child, which should be the case if it
exists.
reference-branch= https://github.com/odoo-dev/enterprise/tree/master-dhl_add_commercial_invoice-goaclosesodoo/odoo#83404
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Each delivery provider, requires some information about the packages
that need to be sent as well as about the commodities (for commecial
invoices). Since this is needed by each provider, and the required
values are very similar, these packages and commodities can be done one
step ahead: in the base delivery module.
These new `_get` functions return a list of custom objects containing
the most important values concerning packages and commodities, and can
be called directly from the child classes.
closesodoo/odoo#82891
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usually we want to create commercial invoices in case the warehouse is in a
different country than the recipient. However, some countries like India
need those documents for internal shipping as well.
The added function can easily be overriden in a dedicated module for the
countries that require such a commercial invoice.
Part-of: odoo/odoo#82084
In saas-15.1 move_lines on `stock.picking` has been rename in
move_ids.
It was miss during #81595 and it's fixed now
closesodoo/odoo#82397
X-original-commit: fd531c7b0baa742cefb7a09c557617806d8a563a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When having a shipper for a DO, if the user creates a backorder, the
information won't be sent to him.
To reproduce the issue:
(Use demo data)
1. Create a sale order SO with 2 products
2. Add Shipping: UPS US
3. Confirm SO
4. In the associated picking, deliver one of the products and create a
backorder
5. Process the backorder
Error: In the chatter, there is a label for the first picking but there
isn't any label for the backorder
When confirming the sale order, the backorder is first created and then
the initial picking is sent to UPS. As a result, considering the current
body of `send_to_shipper`, the field `carrier_tracking_ref` of both the
initial picking and the backorder is defined with the same value (i.e.,
the tracking number of the initial picking)
Therefore, when processing the backorder:
https://github.com/odoo/odoo/blob/f29da79ef64a8166e54544d1787912be5665076a/addons/delivery/models/stock_picking.py#L126-L129
`carrier_tracking_ref` is already defined, so `send_to_shipper` won't be
called
OPW-2678549
closesodoo/odoo#81599
X-original-commit: 89f9281b096e24583ff7780a1bb42f0c4b7b477e
Related: odoo/enterprise#22980
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Problem : Free Shipping is not translated in delivery
New Behaviour : Free shipping will now be translated
opw-2679727
closesodoo/odoo#79557
X-original-commit: 511bede06788ffb94308dc36d33abadc466a3168
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Steps to reproduce the bug:
- install delivery and sale_management
- Create a product with route "Buy + MTO" and a product with route "Buy"
- Create a SO with both products
- Confirm the SO
Problem:
A traceback is triggered, because in this case, we have two `stock.move`, so two` stock.rule`
therefore, when accessing the `propagate_carrier` field an error will be thrown
opw-2681427
closesodoo/odoo#79539
X-original-commit: 431fc082470df36bc2968f4e51423b41c0c08945
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behaviour :
Product of type service are accounted for when computing the quantity, weight and volume metrics used in the price computation of rule based delivery.
Planned behaviour :
Service-typed product should be excluded from such computations.
opw-2647067
closesodoo/odoo#78402
X-original-commit: 2993c82db51e16787de72cbb67f04d5ae1928b68
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Install delivery and active 'Addresses in Sales Orders' options
- Create a delivery allowed only in France
- Create a partner with two delivery address, one in France, an other in Belgium
- Create SO, select the delivery address in France
- Select the carrier
--> Change the delivery address in Belgium in the partner_shipping_id field,
recompute_delivery_price stay False.
This PR fix this issue, now the delivery is invalidate if you update the field
partner_shipping_id.
closesodoo/odoo#75762
X-original-commit: b53ff03b5cf43c2cd23039b8192f4d90d47e11d2
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit add a quick access to all the move lines of a picking
type (only transfers picking type) ready to be processed from the
Inventory dashboard
Task : 2411102
Part-of: odoo/odoo#63291
- Create a product with a kit BOM and weight
- kit components should have list price and weight as well
- Create SO with kit product
- Add shipping (fedex int. or bpost will do)
- Delivery product
A custom's form is generated but the value of the product it is not
correct as it take the valuation of the kit in the sale order
for every component of the kit, resulting in higher customs taxes for
the final customer
opw-2628309
closesodoo/odoo#75658
X-original-commit: e13f048a78b41d81602e868a3b0c7ded24ce992b
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
If you create an sale order with a section line you see the button add delivery.
closesodoo/odoo#75570
X-original-commit: 1db92688d9e7bf0843edfd248ffef89c38bb66f0
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Hook to be overridden when we need to add some field to product and use it in variable factor from price rules.
closesodoo/odoo#74561
X-original-commit: 6ec768d084da6bd7344c45750a2a5037ec366143
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Added a hook in delivery to check if an Amazon order's delivery is Amazon compliant.
task-2573260
closesodoo/odoo#73494
X-original-commit: eb23d10b22c0cafc935d01effc680aebdbdf0057
Related: odoo/enterprise#19578
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Currently, delivery packaging and product packaging share the same
model product.packaging. In this commit, we make delivery packaging
a new model stock.package.type. The code is also moved to stock
instead of delivery for compatibility reasons.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
In this commit -
1) Added new field propagate_carrier_id in stock.rule and propgate
carrier in PICK PACK and SHIP if it is ticked.
2) Allow to print Label at any stage of PICK PACK and SHIP after
validation of picking from chatter.
Task-2363484
closesodoo/odoo#62851
Related: odoo/enterprise#15148
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Add suport of gift card for ecommerce.
Split the generic part to allow others modules to us it (e.g. pos)
A customer buy 1 Gift Card, he receive a code by mail and see it into the
sale order.
Another customer can now use this code in the payment step to deduce this
amount.
Product Gift card is sold by default without tax, because we don't know on wich
ecommerce, the shipping address ans sot the tax that will be used.
So the tax is deduce from the sale order that use the gift card.
We considere to be in the MPV case from:
https://www.vandelanotte.be/fr/actuel/actualites/624-les-bons-soumis-a-un-nouveau-regime-de-tva-a-partir-de-2019
Courtesy of @bvr-odoo for the email and product image
Co-Reviewed by @rde-odoo and @jke-be
task-2428004
pr-64195
closesodoo/odoo#64195
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
If we're to change the invoice policy of a product we'd provoke a
chained computation of every sale line and sale order containing such
product. This change goes along with the policy of applying such changes
only to future orders, as stated here: https://github.com/odoo/odoo/pull/61135closesodoo/odoo#64641
X-original-commit: 806da3d67a5cf9919c6c0f5042b3e00c69825faa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A based on rules shipping method with the "Free if order amount is above" field enabled is not correctly applied.
To reproduce the error:
(Need website_sale)
1. Go to Settings > Website
2. Enable "Shipping Costs"
3. Go to Website > Configuration > eCommerce > Shipping Methods
4. Create a new one
- Select "Based on Rules"
- Enable "Free if order amount is above"
- Set the corresponding amount
- In pricing, add a line
5. Save & Publish (Click on "Unpublished")
6. Go to website's shop
7. Add the product set in the shipping method to your cart
- Select an amount sufficient to exceed the threshold amount set in step 4
8. Process Checkout
=> The shipping method is shown, but the associated amount is "No price rule matching this order[...]"
The shipping method price should be 0.
(This error also happens when creating a SO)
OPW-2383258
closesodoo/odoo#62290
X-original-commit: 393b7ad7b7dff1cbf830374c76ef0a681a71be6a
Signed-off-by: adwid <adwid@users.noreply.github.com>
Fine-tune of #59524.
If the delivery address doesn't have any delivery method assigned, you get an
undesired change of behavior: no delivery method is populated in that cases.
Note that the delivery method is not a commercial field that is propagated from
parent to children.
With this patch, we get a very similar behavior, which is fallbacking to the
commercial partner's delivery method if there's no delivery method in the delivery
address.
The only different behavior will be if the order partner is different from the
commercial partner of the delivery address.
closesodoo/odoo#60881
X-original-commit: 682b2e6c214b73f67e849df927bd4bda0af31d5a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Touati Djamel (otd)