The inline tree view of the purchase order lines has a state field that is used
in attrs.
The popup form does not have the state view.
Even if the state field is not used in the form view, closing the form view
produces an error as the field state is not found.
This patch is a workaround to avoid the error.
The real issue should be fixed in the future but is more complex.
closesodoo/odoo#27208
Steps to reproduce the bug:
On a new db, just launch:
./odoo-bin --addons-path=../enterprise,./addons --test-enable -d s11 -i l10n_be,account_accountant,stock,sale_management,purchase
An error occured in test_02_check_mto_chain due to the supplier taxes set on the product.
opw:1878341
closesodoo/odoo#27069
Overwrite vendor reference only if there is a PO linked to the bill.
Otherwise, any addition of product will erase what the user just typed.
Closes#26734
Create a PO and assign any string to the Vendor Reference field. Confirm
and create an invoice.
The Vendor Reference field on the invoice is empty, while it is expected
to be filled in.
opw-1879379
- Set 'Product Price' accuracy to 5 places
- Create a PO for a product to a new supplier
- Enter price at 3.14561 / unit
Supplier info entry rounded to 3.15, while it should be 3.14561.
Closes#22253Fixes#22252
PO that can be linked to an invoice are filtered via a domain
restricting the partner. However when no partner is selected yet, the
domain was `('partner_id', 'child_of', False)` which, beside being horribly slow, was also useless as it returns ALL partners.
Only generate a meaningfull domain.
Usecase to reproduce:
- Set a product buy and MTO
- Create a SO with it and cancel it
- All the pickings are cancel
- Cancel the PO
- The picking that generate the PO is set to confirm
The picking should remain in cancel state
It happens because the button_cancel method still
consider the canceled moves.
This commit only modify destination moves if they still
require an action from the user.
Canceling the delivery order created for a "Make to order" product
cancels the related procurement.
But canceling the receipt order created for a "Buy" product" with reordering rule
didn't cancel the related procurement. In some cases, it can block the application
of the reordering rules.
Now the related procurement is canceled when the receipt order is canceled.
opw:1845345
The `active_id` when clicking on "Receive Products" on a purchase order
is the one of the purchase order.
But the action used has a context with:
```
{
'search_default_picking_type_id': [active_id],
'default_picking_type_id': active_id,
'contact_display': 'partner_address',
}
```
So the active_id should be a stock.picking.type and not a purchase
order, thus:
- we could get an error at some instance (eg. a refresh) when loading
the facet of the stock.picking.type with the ID of a purchase order
- we could erroneously show a facet for a stock.picking.type with the ID
being the same as the purchase order
So this commit uses the same action without the offending `active_id` in
context.
opw-1870687
closes#26160
Purchase creates an activity when some stock move is deleted.
Howver when two moves are merged "behind the scenes", some moves may be deleted.
As a result it creates an activity "warning: some move has been deleted" for no
good reason.
We add a hook to clean moves before the merge.
opw 1826791
Odoo Translation Bot