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>
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>
Christophe Simonis