Computation of the field 'Difference amount' was wrong as it was converting amounts in base currency in the following use case:
- company currency USD
- invoice currency EUR
- payment's journal currency USD but payment's currency EUR
- invoice of 100€, payment of 20€: difference was not 80€ because it was converting to USD
A stock user is not allowed to save a picking. It happens
because the picking view use the field show_operations that is
a related to stock.picking.type.show_operations. Since stock user
do not have right to write on picking type it will fail.
This commit add a readonly on show_operation on the picking view
(already invisible). With that change the field will not be send
to the server and thus not writed.
When a mix of quants and move lines is displayed in traceability report,
they are not correctly ordered by date.
To fix this we sort them after having all quants and move lines
When an operation has the check for create new lots/serial numbers
activated and it exists a return that use this operation. The return
with serial number is not possible since it will display the view for
creating new serial number while we are returning some of them.
Trying to add the serial number name will fail due to the constraint
that ensure maximum one specific serial number by product.
This commit change the context before calling the view in order to
always display the many2one lot_id if the move is a return.
Use case to reproduce the bug:
- Create a PO line with 10 product -> validate the picking
- Edit the PO line and add 10 product -> it creates a new picking with a move line
- Edit the PO line and remove the 10 products
-> There still an empty picking that is not linked to the PO.
This happens because the _create_or_update_picking in purchase
only remove the stock move if it is empty but do not check anything
on the picking.
This commit add a check on the picking if there is no move inside,
delete it.
Since refactoring in saas-17 quant_ids are removed and
the logic is instead locate on stock_move_line. This commit
adapt the method by trying to undo the created move_line
during the MO.
This commit also add a default_uom_id in the view's context in order
to remove a traceback. Since 0469d2e
uom is mandatory on stock_move_line.
It also add a bunch of tests in order to check the behavior of unbuild
with 4 test: without tracking, consumed product tracking, produced product
tracking and everything tracking.
Know limitation of this commit:
-> No warning message when unbuild more than in stock.
-> Wrong result if trying to unbuild twice the same MO
with consumed product tracked with different lot/SN
Trying to set multiple lines with different lot on a MO
will raise an odoo server error with the field product_uom
on model stock.move.line.
This bug is linked to stock refactoring commit 0469d2e712
where the uom become required on move line. In order to get a default
value on create call the uom should be pass in the view's context.
On the production wizard when you are using a product tracked
by SN/lot and another not tracked as consumed element. You edit
the form view by settings the correct quantity -> Use the produce
wizard. It will display the tracked product (you can see the details
you entered before) -> validate. It will double the quantity done
for the not tracked product.
This commit will change the wizard behavior by only set the quantity
done on untracked product if it is not already set.
The traceability report in downstream was looking for newer move lines
instead of older ones, which leads to not showing all related traceable
moves.
We also changed the sort order of the move_lines in downstream
The purpose of this is to help stock manager in their quants analysis.
An overview of quants can be accessed via inventory menu and for specific
lot/SN via the locate button.
This commit add quants in every location (only internal location previously)
The purpose is to introduce a double entry for quant (add quants to a destination
location will always remove quant from a source location).
Quants in customers/suppliers location are shared between all customers/suppliers.
In order to know the amount of product that come from a specific customer/supplier
the tracability report should be used.
There was an issue if you make a backorder for a reserved move while not
having any quantity done on it. The 0 move will have its `picking_id`
field set to the backorder, but not its move lines, and the result was
that a stock move could be considered `assigned` while not having any
move lines.
The test that could show this issue did not fail because of an unwanted
call to `_free_reservation` that would call `_recompute_state` on the
inconsistent stock move.
Bug introduced in https://github.com/odoo/odoo/commit/c8601f4384e0c95abc92d1f0b3092cfe2cb2a79d
Purpose
=======
If a module installation is supposed to load an action (example: a wizard like in l10n_eu_service) and if the related action is defined in this module (example: l10n_eu_service.wizard), currently we're using the environment defined on self, which is not updated after the module install, and the key is not defined in the registry.
Specification
=============
Instead of using the environment on self, let's use the new environment created after the cursor commit.
The rev. https://github.com/odoo/odoo/commit/99ae418bf24171fbc6bb27584059c27efb857e77
introduced a trigger_up `mutexify` when quick creating a record in a many2one ;
this broke the behaviour when the many2one was standalone (because it has no
BasicController and mutexify is handled in the latter).
An attempt to fix this issue has been made in the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
by adding an option `standalone` in the field widget options. In this case,
the action was directly executed instead of the trigger_up. While this correctly
works, this implies that the option needs to be added in every standalone
many2one (and only many2one as the others won't use the option), which is not
very convenient.
An other attempt is made in this rev. by moving the mutexify handler from the
BasicController to the FieldManagerMixin ; as a widget that instantiates a field
widget needs to extend this mixin, both cases will work and we won't need to
specify the option anymore.
This commit thus partially reverts the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
When creating a customer invoice with description/reference with more than
64 characters, the description was cut to generate the name of the account move
lines. But it's possible to create an entry with more than 64 characters as name
by the interface. The limitation is deprecated.
opw:760316
A bug happens in stock move's action_assign method. It tries to get
the quantity done and the reserved quantity from the parent move and
sibling move in order to guess the available quantty.
With uom activatred, the quantity done is not always the same than the quant
quantity and the quantity done on stock move/stock move lines has to be
converted in order to know the real quantity available/
This commit change the quantity done in action assign to the
associate product uom.
On a list view, if we group records the arrows and changing page
feature are disabled. But if then we removed the grouping, the arrows
never reappeared.
note: not necessary as of 9.0 it was already solved in 1280bf251
opw-760956
closes#18596
the field data-max is supposed to be stored in the database.
Currently, the arg is 'stored=True' which is not recognised by the orm.
This fix ensures the field is correctly sotred and thus not computed at reading.
Add into the warning message the list of stock.move that raise the constraints
error.
When you create an 'Inventory Ajustment' of 1000 lines and see this error,
it is not easy to find which product could cause the problem.
This solution is not perfect since the name is not uniq, but it decrease
drastically the number of record to check manually.
opw-760643
Pierre Masereel