-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
When we return goods and a refund is created, we check the purchase order
linked to the original move. Therefore, the appropriate currency and unit
prices will be chosen.
opw-643085
Returning `picking_id` can be useful for overrides.
In addition, when there is no return statement,
the method basically returns None.
As this is a public method (not beginning with '_'), it can
be called with an xmlrpc call, and `None` is not an
accepted return value for the xmlrpc protocol.
Closes#1714
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Fixes the impossibility to invoice purchase order lines, which were never
invoiced but set to invoiced by validating a first invoice created by invoice
control "manual".
When a PO line is deleted, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
In case of a partial delivery of the products to receive, the procurement is
not considered as done since procurement.purchase_line_id.order_id.shipped is
false.
opw-641503
If the state of the PO is 'approved', there is no transition foreseen in
order to cancel the PO.
The user might be blocked in the following situation:
- Create a purchase order with invoicing set as Based on incoming shipment
- Validate the purchase order, create the shipment
- Then, cancel it (the shipment)
- Return back in the purchase order, the PO should be in shipping exception
- Hit the "manually corrected"
- Then, try to cancel the PO: nothing happens.
opw-641014
Canceled lines must be excluded from most of the operations done on a purchases orders.
The check has been done in some places but some of the loops on the order lines do not do it.
This commit correct them.
If an extra move contains a product which is not initially in the order,
the taxes set on this product must be considered according to the fiscal position
of this order.
opw:634305
Goffin Simon
Odoo Translation Bot
Christophe Simonis
Denis Ledoux
Nicolas Martinelli
Adrien Peiffer (ACSONE)
Nicolas Lempereur
Martin Trigaux
Daniel Dico
Xavier Morel
czoellner
sve-openerp
Guewen Baconnier
Olivier Dony