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>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@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>
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
This commit adapts the spacing between the buttons in the
sale_order_views to fit with Milk.
project: layout fixes:
- Fixed kog displaying on top of the project status button
- Fixed the flickering in project updates when selecting rows in list
view
task-2818586
Part-of: odoo/odoo#116641
Currently, Fields Sales are struggling to create quotations or sale
orders directly from the customer place. One of the issues is that it
is not easy to quickly add products to the SO. Products must be added
one by one and, in mobile, it requires completing a form with
quantities, ... for each new line.
This commit introduces a catalog view that allows users to select
products in a faster and easier way than before, both in desktop and
mobile view.
Task - 3062080
closesodoo/odoo#106382
Related: odoo/enterprise#37915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: chevalierv <vcr@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>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@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
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
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>
The delivery should provide the same feature before and after
validation of the picking (however lot/package need a validation)
So the HS code should be available direclty since it's a static value
closesodoo/odoo#113390
X-original-commit: 350015088d3822cde84b5dcf83d053350beafa66
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>
In the view 'view_order_form_with_carrier' we have an xpath to
'picking_policy' which is not in the parent view 'sale.view_order_form'.
The field 'picking policy' is set on the sale order view in the override
of sale_stock in view 'sale_stock.view_order_form_inherit_sale_stock'
So we've adapted the inherit_id to match the correct view.
closesodoo/odoo#111897
X-original-commit: 1e805aa773926f4ad8c9705cffdc433f5ca23621
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Masereel Pierre <pim@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>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@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>
Usecase to reproduce:
- Create a product with replenish on order route
- Create a SO for this product and add a shipping method
- Confirm the SO
The shipping method is not on the product.
It's due to the MTO delivery rule that miss the propagation of carrier
option. It's not set by default while it's is on the classic delivery
rule on the warehouse.
To avoid confusion we add it by default on both rules
opw-3112455
opw-3113180
closesodoo/odoo#109328
X-original-commit: c02df957d9f04c911f330aaaadd80fe97a601509
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>
There are three rationales behind this change to set USD as default
currency and to enable it in the demo data, from the beginning.
With a demo database, before this revision:
1. On runbot, with all modules installed, it's already USD the default
company currency. It's only when you install a module not depending
on account that it's EUR the company currency by default (e.g. CRM)
2. in the base demo data,
the company is set in the United States but with the currency EUR,
3. before installing account, the company currency is EUR,
after installing account, the company currency is USD,
this is due to the fact as the company is in the United States,
the US Chart Of Account is installed, switching the company currency
to USD.
4. when you install a demo database with a module not depending on
account, you are left with a database without any active currency,
and the monetary fields therefore do not show any currency.
For instance, install only CRM with demo,
you have no currency symbol before or after the expected revenue,
which is not the best user friendly experience.
On runbot you do not feel it because all modules are installed,
therefore with account installed, which activated the USD currency.
Additional weird thing with point 2.:
- Unit tests in modules not dependent on account with the
post-install tag had to handle this sudden change of currency change
before and after installing account.
For instance, when running their unit tests with only their module,
but not account, the company currency is EUR,
but when executing the same unit test with all modules installed,
the company currency is USD.
The unit tests had to handle this sudden change within the unit test,
for instance by setting a 1.0 rate for their own company currency,
which shouldn't be the case: the rate of your own currency should
always be 1.0.
closesodoo/odoo#107113
Related: odoo/enterprise#34613
Signed-off-by: Denis Ledoux (dle) <dle@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>
Valentin Vallaeys (vava)