When adding a line in a PO with the SUPERUSER_ID all the record rules
didn't apply on him. Then all the supplier taxes set on the product
were written in the PO line even if some of its were not in the company
of the user. Then with the SUPERUSER_ID, just the company taxes of this
user must be applied. Inspired from product_id_change in model
'sale.order.line'.
opw:659236
When a make to order product is sold, a purchase order is created or added to an
existing one. In the second case, the origin of the sale order was lost.
It is now added to the existing source.
opw 656688
If the invoicing policy of a PO is set to "Based on incoming shipments"
and the PO contains a product of type "service", it is never considered
as invoiced, and therefore reach the state "Done".
The reason is that no stock move is linked to this PO line, and
therefore it is never considered as invoiced since we check the invoice
state of the associated sotck moves.
This fix assumes that in this specific case, a PO line for a service is
always invoiced, since there is anyway no incoming shipment linked to
it.
opw-654317
When invoice_method == 'picking', a po line is invoiced if all the lines
linked to the po line are in invoices with state not in ['draft', 'cancel'].
To keep the same logic than before commit 9b1ab76.
opw:649746
The journal_id used in a purchase.order created in auto procurement
(by the function make_po) must be the journal_id of the company_id
set on the procurement. The company_id set on the procurement is
the company_id set on the SO (function _prepare_order_line_procurement).
When creating the PO in function make_po, the company_id must be set in the
context to use the right journal_id with the function _get_journal in
"purchase.order" model.
opw:648600
When creating a SO in dropshipping with 'create invoice' = 'on delivery order',
the resulting invoice must not be linked to the PO but to the SO created.
Inspired from '_create_invoice_line_from_vals' in addons/sale_stock/sale_stock.py
opw:647628
With 3e82c94d we use the timezone in the context to format date
sequences when formatting an ir.sequence.
This commit adds the other missing context when getting a sequence, so
these sequences are also dependant on the timezone.
closes#8351
opw-646487
-account:_fix_tax_included_price
If a fiscal position mapped an included tax on a SO or on a PO line
then the price unit of the product must be recomputed.
-purchase: onchange_product_id test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
-sale:product_id_change test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
opw:647321
Introduced by f7f18ba5b1
The lang of the customer must be used.
In the drop shipping use case (order.location_id.usage == 'customer'), the customer
is in the destination address of the order (order.dest_address_id).
opw:647628
When a move is creating from a purchase order line and the destination
of the order("location_id") is "customer", the description of the created
move must be the name of the product. To avoid that the supplier description
of the product appears on the customer invoice because in "drop shipping",
the customer invoice line is created with this created move by the function
"_get_invoice_line_vals".
opw:647628
When a product is in "dropshipping" with one supplier and with a few SO
created for the same customer, the origin of the resulting PO must
include all the SO names.
opw:647409
The group applied on the purchase invoices stat button
was "Accountant", while "Invoicing & payments" is enough.
That way, the customer and purchase invoices stat buttons
have the same group applied, which makes sense.
opw-646748
Before this fix, a PO line was set as invoiced if all associated invoices were
validated. This is an issue if the invoice_method of a PO is set on 'picking',
and that only a partial quantity is received and invoiced. Indeed, in this case
it was never possible to meet the condition, and the PO could not be set to
'done'.
After this fix, the PO line invoice state is calculated from the invoice state
of the related moves, if the invoice_method of a PO is set on 'picking'. This
is more logical, and moreover this makes possible to set a PO line as invoiced
as soon as all the related moves are done or cancelled.
opw-644399
When a purchase order line doesn't have a product_id, the current onchange
method would return False as uom_id since b675ff1, thus introducing an issue
since uom_id is required and the field may be not shown (so not changeable).
closes#7770
opw-646088
When a PO is created automatically from a procurement, the fiscal position is
not chosen correctly. We need to choose the fiscal position in the same way if
the PO is created manually or automatically.
Follows commit 1062905acbFixes#3863
opw-643916
Odoo Translation Bot
Danimar Ribeiro
Goffin Simon
Martin Trigaux
Nicolas Martinelli
Nicolas Lempereur
Pedro M. Baeza
Denis Ledoux
Christophe Simonis
Adrien Peiffer (ACSONE)