The delivery line in the SO was added among other lines,
in second most of the time, due to the fact
the sequence of the line was set after
all other order lines sequences.
opw-649629
When delivery_set is called from the website_delivery module, the
uid is set to SUPERUSER_ID. In a multi-company environment, this
causes the linked taxes from the delivery product to be added
to the sale_order_line.
Closes#8311
The total used to check which delivery.grid.line to apply must be in
the currency of the company because the delivery.grid.line records with
variable == Price are expressed in the currency of the company.
opw:647799
When the invoice is created from the picking, the delivery charges needs to be
converted into the invoice currency. Indeed, there is no currency on a delivery
pricelist.
opw-646148
Before this rev.,
if you define a carrier
- without advanced price rules
- with a normal price set to 0.0
- Free if more than amount unchecked
When you try to invoice a delivery order
(coming from a sales order with as invoicing policy
"on delivery order)
No grid was found, while there was one, with as price 0.0
Closes#1364
Sales Order lines have a cancelled state, but this state is not
always considered when looping over lines. This check is
done in some places already and this patch's aim is to do it in the
remaining places.
- Cancel the procurement of a sale line in sale.order.line
instead of sale.order, so a line canceled individually with
sale_order_line.button_cancel will properly cancel it
procurement.
- Sale report: uses the state of lines instead of Sales order,
so canceled lines of not-canceled orders are correctly represented
in the analysis.
- test: do not create invoices lines for canceled sale lines
- test: creation of moves with canceled lines
- test: check if lines are still canceled when sale order is done
Closes#6036
The delivery module overrode the method _create_invoice_from_picking
to add the shipping costs according to the invoice and the shipping.
The issue is that the method _create_invoice_from_picking creates an empty
invoice, without any line. The lines are added afterwards, using the method
_create_invoice_line_from_vals, within the method _invoice_create_line.
So, after having called _create_invoice_from_picking, the invoice is indeed
created, but without lines, and therefore without the amount total value.
Adding the shipping costs there will thus prevent the shipping costs
based on the total price of the invoice (e.g. free for an order of 500€)
This rev. overrides the method _invoice_create_line instead, as, after
the call to this method, the invoice will be completely set, with all
its lines, and with a correct amount total. The side effect
is that we need to recompute the taxes a second time, using button_compute.
This is not the cleanest way to solve this issue. Indeed, a cleaner patch
would be to change the method _create_invoice_from_picking so it creates
the invoice along with its invoice lines, using the ORM command
(0, _, values) to creates the lines directly within the invoice creation:
invoice['invoice_line'] = [(0, _, values) for values in invoice_lines_vals].
Nevertheless, this is a bigger change, that will probably require API changes,
and therefore should be done in master.
opw-626226
opw-628517
Odoo Translation Bot
Denis Ledoux
Jos De Graeve
Martin Trigaux
Goffin Simon
Nicolas Martinelli
Lionel Sausin
Christophe Simonis
Robin Lucbernet
Olivier Dony
Alexandre Fayolle
Guewen Baconnier
Rucha Dave