After removing the company from a delivery method, every checkout done
in website fails due to odoo trying to convert the price to the
company currency.
This PR fix the bug by doing the conversion only when there is a
company set on the delivery method.
opw-1905466
closesodoo/odoo#28626
With a fixed price delivery method, the error message was not displayed when
the address doesn't match.
Inspired from function base_on_rule_rate_shipment
The error message was not clear enough.
opw:1879204
The commitment date is computed using every line from the sale order.
When the picking policy is set to direct, it takes the earliest date
among the sums of the order date and lead time.
However when the delivery is set, is adds a line with an order date of 'now' and
no lead time.
This date thus necessarily becomes the commitment date, bypassing what was
intended by setting a lead times on products.
We simply ignore delivery lines in this computation.
opw 1855646
- Create a picking, set as 'Carrier': 'Free delivery charges'
- Enter a 'Tracking Reference'
- Validate the picking
The tracking reference is removed.
opw-1849279
In this way the name of a delivery method can be translated on a SO line.
Inspired from function 'product_id_change' in model 'sale.order.line' where
the description of a SO line must be in the language of the partner.
opw:1849656
When adding a SO line with a delivery method (e.g. The Post) for a customer
with a different language that the one set on the current language, the description
of the SO line was not translated. Inspired from function 'product_id_change' in
model 'sale.order.line'
opw:1843934
The calculation of the delivery cost for a sale order / invoice was not correct when
free over a limit had been satisfied.
Steps to reproduce the bug:
- Set a delivery method DM with a fixed price = 10.0 and free when the amount of the order exceeds 100
- Create a SO for an amount of 150 and set on it DM
- Confirm the SO and deliver it
Bug:
A SO line with DM was created with a fixed price of 10.0 instead of 0.0
opw:1838070
- Define 2 companies A and B. Delivery methods are linked to products in
company A
- Deactivate 'Share product to all companies'
- Create a user B in Company B only
- As user B, create a SO and open the drop-down list for delivery
methods
An access error is raised.
Delivery methods should follow the same record rules than the products
they are linked to.
opw-1815490
Steps to reproduce the bug:
- Set your company currency to USD
- Set multicurrency on your user
- Create a delivery method with a fixed price to 50$
- Create a SO with a pricelist in EUR
- Set the delivery method and check the price
Bug: It displayed 50€ while this amount should be converted
opw:1817666
Steps to reproduce:
* Create a sales order (SO).
* Assign a carrier.
* Don't press on "Set price" button next to carrier.
* Validate SO.
* Validate picking.
* Delivery line is added to the SO with price 0.
This is because the delivery SO line is added with the value of
picking carrier_price field, but that field hasn't been set.
If you modify on view carrier field, there's an onchange that
fills correct price, so I use that onchange method for getting
same results.
Use case to reproduce:
- Install delivery/batch picking
- Process 2 pickings in a batch.
-> Traceback due to ensure_one.
It happens because the action_done method in delivery is
not multi and batch_picking launch action_done on multiple
picking.
This commit makes action_done in delivery multi.
install delivery
Create a SO with a shipper
Validate it
validate the delivery
Before this commit it was:
- impossible to do the setup for the delivery cost on the SO to get updated with the delivery validation
- the delivery cost on the SO did not update
This was because the stock API changed a bit a some functions were not here anymore
OPW 786500
The package weight is computed by summing all move lines related to it,
which is wrong, because if you have a package that is in two pickings,
its weight will two times bigger than the real weight.
To fix this, we will compute the weight based on the quants in the
package, except if we are opening the package from a pickin, it's weight
will be the sum of move lines of the package that are in the current
picking. This allow user to see the weight of a package after a put in
pack when there are not yet any quants in the package
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
Some countries, such as Canada, are using letters in their zip code.
When we check if the zip code is within the accepted range, we should
make sure to normalize it by making it case insensitive.
opw-767866
* can't compare a function and a float in Python 3 (it works in
Python 2, though it makes no sense and was just hiding a bug)
* no iteritems method on dict in Python 3 (use compat helper)
* P3-invalid "except" syntax (sadly pylint apparently does not have a
standard lint for that, though it's easy to catch... if you can run
the code under P3)
Thanks to @xmo-odoo and its Python3 virtual machine for spotting this
one (and shame on Python2 that does not crash when comparing a method to
a float because voilà).
When an order is shipped, a notification email is sent to the customer.
If there is a tracking URL, it is included in the email.
(and also a bit of refactoring)
Having price and availability as computed fields of a delivery.carrier
may sound handy.
Actually, it comes with is batch of lame hacks, poor performances and
terrifying heisenbugs.
We will try to make something better. It has to start with a breaking.
Julien (juc) Castiaux