Other modules that was overriding old name method was just ignored.
Drop retro compatibility fixes in next freeze (saas-14) and stop
useless renaming.
This commit closes#13865
In a multi-company environment, we need to make sure to copy the company
of the PO to the company of the picking. Otherwise, it might happen than
the PO as a different company than the picking.
Closes#13129
Before this commit, we check everytime the subtype.
In some case (eg: portal user on the forum) don't have access to subtype of
type internal.
This commit fixes opw-688403
This commit closes#13510
This is an oversight of the revision
cb486d7eb6
In the above revision, which converts the module
`stock` to the new API,
the return value of the method `action_confirm`
has been changed:
- Before, it returned the list of move ids that have
been confirmed,
- After, it returns `True`
The former return value is expected by `mrp`,
when using kits BOM: In this use case,
the purchase of one product can lead to the reception
of multiple products, and therefore the confirmation
of one move can lead to the confirmation of multiple
moves.
In addition, the move that was initially confirmed could
no longer exist after the call of the method `action_confirm`.
The method `action_confirm` of `stock.move`
is expected to return the list of moves that were actually confirmed.
e.g. in purchase, before the conversion to the new API (<= saas-10),
to assign all the moves that were created through
the action confirm of the initial move, and not only the initial moves,
thanks to:
```
move_ids = moves.action_confirm()
moves = self.env['stock.move'].browse(move_ids)
moves.force_assign()
```
The above code has been wrongly converted in the new API with just
```
moves.action_confirm()
moves.force_assign()
```
Which changes the behavior, as, before, all the moves that were
created through `action_confirm` were being assigned, and, after,
only the moves with which the method `action_confirm` has been called
are being assigned.
Besides, with the kits BOM, the move with which `action_confirm` was
being called no longer exists after the call, and attempting to
call the `force_assign` method on it leads to the error
`Record does not exist or has been deleted.`
opw-688231
This reverts commit a57b10dbd5. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
When anglo-saxon accounting is enabled and the valuation of a product is
'real_time', rounding errors might occur in the price difference between
the invoice price and the product price. It occurs when the product
price precision is larger than the accounting precision.
To avoid these rounding errors, we calculate the difference as the
difference between the price before update and the price after update.
opw-686730
In purchase, a special key is set in the context to simplify the name
of the picking type: instead of the normal name, only the name of the
warehouse is used. This is problematic if more than one incoming picking
type exists for a given warehouse, as it prevents you from being able to
differentiate them. Asking users to modify the view to remove the
context key seem a bit too much to ask for something that should be
simple.
It is my understanding that this was implemented only for cosmetic
reasons, but I am willing to assume that having to select
"YourCompany: Delivery Orders" instead of simply
"YourCompany" for people who only have one picking type should not
be too disruptive or obscure.
opw-685751
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo (from a cron), we should force
the company from the context.
After https://github.com/odoo/odoo/commit/4162b8f as the context is force in get_fiscal_position,
we should call this method with a company (and not pass the company in the context).
This has been forgot in https://github.com/odoo/odoo/commit/fe92dea
opw-684802
Christophe Simonis