Main changes include :
- Separate Repair and Sales/Invoicing functionalities
- Possible binding between a Sale Order and many Repair Orders
- Specific 'repair.line' model is now replaced by a 'stock.move' inheritance
- Added a new 'Repairs' Operation Type to warehouse(s)
Task : 3046560
Enterprise : odoo/enterprise#36088
Upgrade : odoo/upgrade#4391closesodoo/odoo#106911
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently, if the user change qty_done on any raw moves without
changing qty_producing on the MO, it's not possible to validate the
order. In this commit, we make it possible to validate the order as an
immediate production.
When qty_producing is 0 and validate the MO:
1. manual consumption moves: current consumed qty will be kept when
process the MO.
2. non-manual consumption moves: For tracked components, if
use_auto_consume_compoents_lots checked, and there is enough products
reserved, the qty_done will be filled, otherwise, an error will be
raise to ask user to fill in lot/sn. For non-tracked components,
qty_done will be filled.
Task-3116125
Part-of: odoo/odoo#113538
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
To reproduce:
1. create a BOM with analytic account
2. create a MO to produce 10 of the above product
3. change producing qty to 5, SAVE the form.
4. change producing qty to 10, SAVE the form.
It happens because the server receive at the same time a new
`stock.move.line` creation and a quantity_done to write on the
`stock.move`.
closesodoo/odoo#86431
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Suppose a tracked-by-usn and consumed product returns in the stock
thanks to a repair order. Using again this component in a new
manufacturing order will raise an error
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two products P_finished, P_compo
- Storable
- P_comp tracked by USN
3. Update the quantity of P_compo:
- WH/Stock: 1 x Lot01
4. Create a manufacturing order MO:
- Product: P_finished
- Components:
- 1 x P_compo
5. Confirm, Check availability and Mark MO as Done
- (Lot01 should be consumed)
6. Create a repair order RO:
- Product: P_finished
- Parts:
- Type: Remove
- Product: P_compo
- Lot: Lot01
- Destination Location: WH/Stock
7. Confirm RO, Start RO, End RO
- (There should be one Lot01 available in stock)
8. Repeat 4-5
Error: When checking the availability on the MO, Lot01 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number Lot01 used for component P_compo has
already been consumed" although this lot should be available
When checking the uniqueness of the lot, nothing includes the products
back in stock thanks to the repair orders.
OPW-2701668
closesodoo/odoo#82544
X-original-commit: 3d9355f90fa1dd9436f1745c515c89947ed04de0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
Issue: When replacing a tracked part while doing a repair, we
are changing the tracking number, but when checking for uniqueness,
we don't take that change into consideration
Steps to reproduce :
1) Manufacture product A with SN "A1" out of product B with SN "B2"
2) Make Repair Order for "A1" to replace "B2" with Product B (SN "B1").
3) Create Manufacturing Order product A (A2), select product B with SN
"B2" as one of the components.
4) Mark as done
-> Bug : "The serial number <B2> used for component <B> has already
been consumed".
Why is that a bug:
When checking for uniqueness we should take into consideration the
parts being replaced
opw-2625687
closesodoo/odoo#78407
X-original-commit: 79c673f9d15185be540dd535d7ebe10c8f138bf1
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Some reports displays the wrong partner.vat.
On the invoice report, when the shipping address is different than the
invoicing address, we also also display the shipping address in addition
to the invoicing address. But we displayed the VAT of the invoicing
address instead of the one from the shipping address.
Same issue on the MRP repair report and the sale report.
Purpose
=======
The attribute name isn't required on the <filter> tag. If not set, it can't be selected with a xpath and it can't be overwritten.
A lot of PR are coming from the community just to add a name on a filter because:
- It can't be selected with a xpath.
- It can't be used with `default_search_foo` on an action context.
Specification
=============
Make the atttribute name required
Mathias Mathy (MAMA)