36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue
where the volume and weight were incorrectly computed
for carriers based on rules.
But it was done by changing the method api, which
seems to break some custom modules using/extending
the modified methods.
This commit reverts the API change, conveying the
needed information through the context for now
(the api change will be done in master only).
opw-3826165
closesodoo/odoo#159220
X-original-commit: d6e004b23822e98e8d1052b75b66a7d4f6d2c38c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when using a shipping method with the variable
weight*volume for price computation, the price was growing with the
square of the ordered quantities. This is because both volume and
weight were multiplied by the quantity, before being multiplied with
each other in the next step.
This commit fixes the issue by introducing the variable weight*volume
at the beginning of the computation.
In order not to break anything in stable, the new variable is added as a
kwarg to the useful methods.
OPW-3802315
closesodoo/odoo#159007
X-original-commit: 0a8db0fa14bb63abd0b2a8f0234d86700b6c1e2e
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Purpose
=======
Lots of tickets are issues when the end user deleted this product
category, leading to the impossibility to install another carrier
as this category is referenced by all the specific carriers products
Ticket example: 3789116
closesodoo/odoo#158626
Taskid: 3802440
X-original-commit: 9383b6f4a5ef0394588c522efcc92e6f37a245cb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Create a shiping method based on rule
- Set margins and then swith back to fixed price
Bug:
since this PR https://github.com/odoo/odoo/pull/108794
margins aren't displayed on the form anymore for fixed price
but they are still set on the model if we edit the delivery type
opw-3759128
closesodoo/odoo#157452
X-original-commit: 79bc772c8d48f64e0bd41fa0f5a40b1cd853293f
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
If user created pricelist which applied discount on fixed prize delivery
and set the discount visibilty to be shown in sale order, the discount
would be applied twice. Due to stable version limitation, the visibility
of discount on sale order for pricelist discount for delivery is removed.
opw-3517879
closesodoo/odoo#154663
X-original-commit: f96ce5102aea5651710bb5bf50903b1c1d4f101e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
Following a fix in 16.3 with 5052b9e4a15155c694cf005fdf330997770c6cac,
backported in 16.0+ with commit d28a8f67da06e58358b40636d1dca1f91a84e1ad,
the rates for the different carriers were computed on page loading,
to make sure unavailable carriers were hidden.
Nevertheless, this leads to significant increases of /shop/payment page
loading time depending on the enabled carriers.
This commit restricts the previous fix to the targeted type of carriers,
aka `base_on_rule` ones, whose rates do not depend on third party API
requests.
closesodoo/odoo#149657
X-original-commit: 99c8bda43f6f3bb027f8e03a753aaf2bb7ac585f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit when you unlink a sale.order.line the field carrier_id of sale.order is set False for each delivery line.
This commit prevent also serialisation failure on ecommerce.
closesodoo/odoo#143533
X-original-commit: c9fe8d113deb8103ad531d999f75f74c5475f46e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: vava-odoo <112173839+vava-odoo@users.noreply.github.com>
Main Changes:
Precise (copy) in the name of a duplicate of a delivery carrier
Before:
When we duplicate a delivery carrier, the name of the copy is
exactly the same as the name of the source
After:
When we duplicate a delivery carrier, we append ' (copy)' at the end
of the name for the copy
closesodoo/odoo#140540
Signed-off-by: Mathias Mathy (mama) <mama@odoo.com>
This commit makes two major things:
1. Move the product catalog from `sale` to `product`.
It moves the product catalog's code from `sale` to `product` module in
order to be able to use it in other modules.
A mixin, `product.catalog.mixin`, was created for to make other models
catalog compatible.
2. It enables the product's catalog in `purchase`.
In `purchase`, the catalog differs a little bit from `sale`:
- If Unit of Measure is enable, the UoM for each product will appear in
the catalog;
- If the product purchase's UoM or the purchase order line's UoM is
different than the default product's UoM, the former one will be
displayed (in bold so the user can know it's the UoM to refer);
- When opening the product's catalog from a purchase order, the products
will be filtered by the PO's vendor;
- Some data from the vendor list will be used if appliant: the minimum
quantity and the price;
- If there is at least one product's packaging, a button will be
displayed to increase the qty by the packaging's one. If a packaging
is set on the purchase order line, this one will be used.
task-3373589
Part-of: odoo/odoo#135502
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
1) Create loyalty program with default settings (10% discount on all
orders above $50)
2) Create quotation with amount >50, all products must be invoiceable on
delivered quantity, not ordered quantity
3) Add promotion with 'Promotions' button
4) Confirm order
5) Order has invoice status 'Nothing to invoice'
6) Add shipping
7) Order now has invoice status 'To invoice'
An order with shipping and no promo, or no promo with shipping, would in
both cases have nothing to invoice as long as the 'real' products are
not delivered. But when you have both a promo and delivery line, the
order is 'to invoice'.
The '_compute_invoice_status' methods of sale.order in the delivery and
sale_loyalty modules are not compatible, as the delivery compute filters
out delivery but not reward lines.
OPW-3357289
closesodoo/odoo#139014
X-original-commit: 201a4fc7144935947cd2909e4830a666bbdac02d
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In this commit
https://github.com/odoo/odoo/pull/121354/commits/7d1092ba0e970170ce66e77e6ddc4cab0e09563d
the forward-port automatically moved the test to `stock_delivery` but
the code change remained in `delivery`. Since it handles `stock.picking`
on a `sale.order`, and that `delivery` does not depend on `stock`
anymore, it should move to `stock_delivery` as well.
closesodoo/odoo#123993
X-original-commit: d5b64650d043f94f8e244c993eff36ed26a93a32
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Step:
- Create a product with sale price 120 USD
- Create a giftcard with balance 40 uSD
- Create a free Shipping cost of 40 USD fixed price and freeing above 100 USD
- Go to website->shop, select the product and checkout the cart(the shipping is free because price exceeds 100)
- Add the gift card to payment
Issue:
The shipping price gets from free to 40
Cause:
When computing the cost of the shipping the fact of the presence of a giftcard is not considered.
Solution:
Create a method to returns the amount of giftcard from a sale order and add to total price to check if the shipping is free
opw-3107284
closesodoo/odoo#120174
X-original-commit: c57184fd1c3d2846df4f618dee0027364eb62596
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Before this commit
==================
when SO is confirmed and Delivery is created then add the shipping method
in SO, in this case, the shipping carrier is not set in the existing undelivered
delivery of that SO.
After this commit
=================
So in this commit, we set the shipping carrier for undelivered delivery.
taskId - 2946360
closesodoo/odoo#121363
X-original-commit: 51523c0dbf6ce9dd1a1ff35e03fa6a51267da14b
Signed-off-by: Tiffany Chang <tic@odoo.com>
In delivery address, `country name` and in shipping method, `country name`
will be same and no zip in delivery address. While creating new sale order
along with product and clicking on "Add shipping", error will be generated.
Steps to Reproduce
-Install `sale_management' and 'delivery' modules
-Go to the settings and enable the 'Customer Address'.
-Go to the settings and enable 'Shipping Methods' and configure it.
-Select a shipping method and go to the 'Destination Availability' tab and
set to the 'Countries' and set to 'Zip Prefixes'.
-Create a new customer and add the delivery address of the customer in
res.partner.
-The delivery address and shipping method of the 'Countries" or 'Country'
name should be the same.
-Set the 'Zip Prefixes'
-Set the delivery address of zip code null.
-Create a new quotation and add to the customer and delivery address
-Add to the product in the sale order line.
-Click on the 'Add Shipping' or 'Update Shipping Cost' button.
A trace back will be generated.
Applying this commit will resolve this issue.
sentry-4147077852
closesodoo/odoo#120968
X-original-commit: 60d5c7d5668da542e251d7d6fb8774043cfddea8
Signed-off-by: Tiffany Chang <tic@odoo.com>
This trace back raises when we try to create delivery price rule,
while delivery product is not selected in the delivery carrier.
Steps to produce:
* Install delivery,sales modules
* Open Sales/Configuration/Shipping Methods
* Create a new shipping method keep provider as 'Based on Rules'
* Try to add a line for pricing
* At this moment trace back raises ('Expected singleton: res.currency')
We resolve this issue by not formatting the name if the currency does
not exist yet, as the currency is related to the one of the product.
Sentry :- 4067992652
closesodoo/odoo#119958
X-original-commit: d20431758c0c4943394a63250ad0a83894b795c8
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit prevents inclusion of negative qty SO products from
the calculation of its estimated shipping weight. Negative qtys can
indicate a return, which would be a separate picking from the delivery
=> we shouldn't subtract their weight from the delivery. This
subtraction, may have resulted in shipping rates being calculated as
lower than they should have been within the SO.
Additionally fixes the following use case (requires Fedex connector):
- create a SO with 2 products with the same weight
- set 1st product qty = 1
- set 2nd product qty = -1
- add shipping => Shipping Method = Fedex US
- click on "Get Rate"
An error will occur because the SO._get_estimated_weight() = 0, and
you cannot have a rate for weight = 0
TaskId - 3028023
closesodoo/odoo#118348
X-original-commit: ecf0262e3ef746c33a29c4f2de7868e3ab61cce2
Signed-off-by: Tiffany Chang <tic@odoo.com>
In ecommerce, the form vue of shipping methods should be improved to
easily set up fixed delivery costs. This commit improves the
user-experience and solves bugs on the fields displayed.
task-3203210
Part-of: odoo/odoo#110686
Extract the Inventory logic from the `delivery` module into a new
`stock_delivery` module. This will allow to integrate the basic delivery
features into the website_sale app in a one-app free database.
task-3074497
Part-of: odoo/odoo#110686
Removed the margin on rate when the provider is Fixed Price
Removed the margin on rate, free, amount when the provider is Based on Rules
Added a fixed margin for all the other providers
task-3043063
closesodoo/odoo#108794
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit:
1. Set up an EasyPost shipment setup, using
"Canada Post" as the Carrier Type and
"XpresspostUSA" as the Default Service Level.
2. Create a SO with a US customer (like Deco Addict)
3. "Add Shipping" using the button and choose the one created in 1.
4. When you try to "Get Rate" using the EasyPost shipment,
the API does always return the same error:
```
Easypost returned an error:
Unable to proceed, 'customs_info' is required for
international shipments, shipments bound for US
military bases, or US territories. Please see
https://www.easypost.com/docs/api#customs for more information.
```
After this commit:
As no commodities were set, `_customs_info` will return
an empty dictionary.
To solve that, we set the `DeliveryPackage` commodity
value on its initialisation to compute the customs
information the way it should.
opw-3104305
closesodoo/odoo#112988
X-original-commit: 06beca4373743787ae629b2c7ea623bf0583727a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Install eCommerce, delivery
- Shpping methods > Create > Name = TEST, Product = Acoustic Bloc Screen,
Provider = Based on rules, Add a line > Condition = "Weight <= 0",
Delivery Cost = "50 + 0 * Weight" > Publish shipping method
- Go to the website > Add acoustic Bloc Screen to cart > Proceed to checkout
In the delivery section, the TEST shipping method will display the
warning message `No price rule matching this order; delivery cost
cannot be computed.` This message can be confusing to the customer.
opw-3110715
closesodoo/odoo#112002
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
As sale does not know about special lines it will always update
the price based on product and price list instead of applying the correct
shipping rate, so we do skip those lines by using a newly introduced hook method
closesodoo/odoo#110782
X-original-commit: f1265b7fdce6bbe3fea97fc4b275dc2dca18103d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
On the PR https://github.com/odoo/odoo/pull/107558 some performance improvements were made when computing the weights.
Unfortunately, this caused some slowdown on other cases.
This PR keeps the read_group introduced on https://github.com/odoo/odoo/pull/107558 but reduces the number of 'get' by taking all the information needed only once before entering the for loop.
For comparison, these are the differences on _compute_bulk_weight when going to Inventory/Receipts:
| Before PR 107558 | After PR 107558 | After this PR
| ------------- | ------------- | ------------- |
| 550 ms | 10.30 s | 560ms |
And these when removing the filter by default (leading it to fetch heavier records):
| Before PR 107558 | After PR 107558 | After this PR
| ------------- | ------------- | ------------- |
| 2.27 s | 24.48 s | 1.89 s |
OPW-3107540
closesodoo/odoo#109481
X-original-commit: 4bbf782505e72761c7c77abfe4fbd53e151e5bf0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Due to hefty data the RAM limit gets exhausted.
The process gets killed due to the computed field weight on
- stock.move
- stock.picking
When installing the delivery costs module.
To solve the problem:
We add the column weight to the DB schema.
Ticket ids:
- 3013955
- 2628251
- 3028081
closesodoo/odoo#109164
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previously, when adding shipment to sale order, the user did not know
the total weight of the order when getting rate of shipping method.
This commit shows the total order weight to the user with the ability to
set it to any value to get the rate with.
Taskid: 2797613
Part-of: odoo/odoo#96660
Currently _compute_bulk_weight and _compute_weight are
going through each picking in self and each stock_move_line
in picking.move_line_ids to compute the pickings' weight.
This can be slow when there are lots of move_lines by pickings
as the field cache will be filled by the move_lines records
and uom._compute_quantity will be called once by move_line.
This is especially true for pickings with SN-tracked products.
For SN tracked products there will be one move_line by product_qty
(so a picking with 1 SN tracked product with a qty of 100 will have
100 move_lines). In this case doing a read_group yields the highest
speedup.
Following the same reasoning a search_count is done in _compute_packages
before retrieving package.move_line_ids.
When package.move_line_ids.result_package_id is empty doing a count
is much faster as it avoids calling _in_cache_without for the package
move_line_ids. The search_count overhead is negligeable in the other
case so adding it leads to an overall speedup on average.
opw-3017013
closesodoo/odoo#107994
X-original-commit: c95abbe8fa09decca2f94a035934e8d6ae7903e1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
In the country of Bahrain, they have 3 and 4-digit zip codes. With the
current implementation of the delivery module, they can not add 3-digit
zip codes because they will be matched with some 4-digit zip codes,
which is incorrect.
For example, consider '101' and '1011' as two different zip codes related to
two separate zones. If you add '101' to a delivery method, it would also
accept '1011'.
The solution is to accept regular expression to allow them to use $ to
define the end of the zip code.
opw-3072592
closesodoo/odoo#107636
X-original-commit: 0a68d171af2645d3047d561acb354730aebfa753
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the issue:
- Let's consider two currencies C1, C2
- Let's consider two pricelists P1 in C1 and P2 in C2
- Let's consider that the current company CY has the default currency C1
- Let's consider that the current rate of C1 = 1.0 and C2 = 5.0
- Create a shipping method SM with fixed price = 50 and free shipping is above 100 (expressed in company currency)
- Create a SO with P2 and add a line with a product of 200 C2 (equal to 40 C1)
- Add shipping method SM
Bug:
The shipping was considered as free but the total of the SO was not above 100 in the currency of the company
opw:3010266
closesodoo/odoo#107456
X-original-commit: c93ab6615f0370963b152cc0320478fe4ceed164
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
Victor Feyens