Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
While creating a Manufacturing Orders, when user give date format as '%d/%m/%Y'
and when it tries to match the date format with '%m/%d/%Y' in
'_add_transit_line' method, the error will be generated.
Steps to Produce:-
1. Install 'mrp' and 'purchase' module
2. Change the format of date in 'Languages' as '%d/%m/%Y'
3. Activate 'Multi-Step Routes' in inventory configuration
4. Go to 'Warehouse' and select 3 steps route in 'Incoming Shipments' and
'Manufacture' and save
5. Go to 'mrp' and create a new BOM
6. Go to 'purchase' and create a PO with the same product in BOM and confirm it
7. Click on smart button 'Receipt' -> 'set quantities' -> 'validate'
8. Go to 'mrp' and create a MO with same BOM change the 'Scheduled Date' and
confirm it
9. Click on smart button 'Overview'
Trace-back will be generated.
Applying these changes will resolve this issue.
sentry-4088257491
closesodoo/odoo#128453
X-original-commit: d1d7141fd52bd7167910074adcde2cd95e8b9440
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
While printing the "mo overview" report we get a traceback because in some cases
decorator passes as False because of that we can not concatenate with the string
value.
Applying these changes will resolve this issue.
sentry - 4199472992
closesodoo/odoo#128164
X-original-commit: 6dbec317e63db37f787bdc1a3758b2f20a18706f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
"ValueError max() arg is an empty sequence" occurs when user try to
open the manufacturing overview. This is because the component
product on hand quantity is negative so it generate empty replenishments.
Step to produce:
1. install manufacturing
2. Go to Inventory > Configuration > setting
3. Enable storage locations in the warehouse > save
4. Create a product, e.g., "x"
5. Click on the Hands unit to update the product quantity.
6. Click New on Update Quantity.
7. Enter any negative value in the counted quantity (e.g., -50) > click apply
8. Go to Manufacturing > Click New
9. Select any product (e.g., "A") for manufactoring
10. Add "x" in component product > enter 0.0 in To consume > save
11. Click on Overview (smart button)> Error occur
This commit solves the above issue by making receipts available in the
Manufacturing Overview report when the missing quantity in a
manufacturing order is less than 1.
sentry-4110696764
closesodoo/odoo#127629
X-original-commit: 27697fd6f9b601714b0aef9884eaadca963f32f1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
Issue
=====
A traceback occurs when we print MO Overview Report If the `Receipt` data has no decorator.
Steps to reproduce
=================
- Create a MO with 0 qty components Availability and set the Scheduled Date in future.
- Make a purchase for the MO components with same day Order Deadline, and confirm PO.
- Go to the MO Overview Report Click on the PRINT button and you will get the traceback.
In this commit, we ignore setting a decorator when the receipt does not have a decorator.
TaskID - 3300853
closesodoo/odoo#125009
X-original-commit: f03b22b62427ae8a4bd235c353eaa1ea0bf3ff16
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since employees can be assigned directly to a workorder, their hourly
cost must be added to the operations cost in the Overview.
Those changes allow further override in odoo/enterprise#40953closesodoo/odoo#123551
X-original-commit: 8802907637b5d862aaa98a1828d29bc7890c53e3
Related: odoo/enterprise#41893
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce :
- Create a product with a default `kg` uom
- Create a MO to produce 100 `g` of this product
- Open the MO Overview
- The first line indicates we try to produce 0.1 `g`.
For a `mrp.production`, `product_qty` is the quantity using the record's
linked uom, while `product_uom_qty` is the quantity using the product's
default uom.
closesodoo/odoo#122417
X-original-commit: 825d69636453d45f689983d1948850f35a696534
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When overviewing a BoM with a "kit" type and with no route,
the availability was always unavailable, wich is wrong if all the parts
are in stock or can be replenished.
Task-3184663
closesodoo/odoo#121783
X-original-commit: f13b4d1ae8c12a1668222e6994dea26a27c6f5d4
Related: odoo/enterprise#41248
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit merges BoM overview's lines if they are about a same component.
Before this commit, if the BoM divided it's same components to use them
in different steps, the overview would separate them as well, which is wrong.
Task-3184663
X-original-commit: 37ac2e603f332dee1c4c18a105f070cb4ae9eda6
Part-of: odoo/odoo#121783
Minor visual improvement for the BoM Overview printing document
Task-3184663
X-original-commit: 9e01083e605a0b91558e2b3c525bfbdae06ca91c
Part-of: odoo/odoo#121783
When calculate Days to Prepare Manufacturing Order, we didn't take into
account Days to Purchase and Security Lead times for Purchaseing of the
company. In this commmit, if the (sub-)bom has company_id set, these two
days will added to the calculation.
Task-3078049
X-original-commit: bf59aedad649dec350f091bb074d3ef1e51d5fcb
Part-of: odoo/odoo#121813
Related enterprise PR: odoo/enterprise#39669
Steps to reproduce:
Install mrp_workorder
Create Product P1, Workcenter W1
Edit W1 > Specific capacities > Add line: Product = P1, Start time = 5, End time = 5
Create BoM > Product: P1, Operations tab > Add line: Workcenter = WC1, Default duration = 60:00 min > Save
Click on overview stat button
Issue:
The created operation has expected time of 60:00, instead of 70:00. The workcenter start and stop times are considered in this calculation, so the workcenter capacities should be considered too.
Solution:
Use `_get_expected_duration` to compute the expected duration.
opw-3229485
closesodoo/odoo#121060
X-original-commit: 7b5a30fb3e51434154050052ec39ed299c6094d3
Related: odoo/enterprise#40905
Signed-off-by: Tiffany Chang <tic@odoo.com>
When using the Reserve / Unreserve buttons on the forecast report, this
will [un]reserve every move of the picking / production. We want to be
able to do it on a product base, so that when using the [un]reserve from
the forecast of a product, it will only affect the said product.
Part of task-3218314
Part-of: odoo/odoo#119381
Steps to reproduce the bug:
- Go to Decimal accuracy:
- Select the “Product Unit of Measure”
- Set the Value to “4”
- Create a storable product with BoM:
- add any product as component
- save
- Click on the BoM overview widget
Problem:
The “Product UoM” precision is not used
opw-3288403
closesodoo/odoo#120296
X-original-commit: 837a6ca90d6944f9faf4b28e69703f5310c6ec6a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When a reception picking was created to resupply a component (without
using a purchase order), the picking was correctly linked in the MO
Overview, but the date was set as "Not available" as the planned date of
the picking wasn't read.
Also adds the color scheme for pickings states for the Overview.
Part of task-3217757
closesodoo/odoo#118023
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Following odoo#116983, there's a new line indicating products still in
transit in the Forecast Report. So we can use it in the MO Overview to
better show when some products are in stock but not yet available.
Task-3217757
Part-of: odoo/odoo#118023
When opened from the MO Overview, the uom in the wizard is the one from
the product's form.
The problem is that the quantity given to it is in the overview's line
uom. So instead we add an already converted quantity to the `to_order`
lines.
Part of task-3217757
Part-of: odoo/odoo#118023
While the cost of a line related to an RFQ was saved, it was not used in
the displayed costs.
Also, it used the wrong cost (don't need to factor in taxes), not did it
factor the quantity used in the cost.
Fixes as well the MO Cost for partially in-stock products.
Part of task-3217757
Part-of: odoo/odoo#118023
When a product was used more than once in a MO, then replenishment lines
were duplicated in the MO Overview, as it didn't check which forecast
line was already used, nor the total quantity it should have for this
replenishment.
Part of task-3217757
Part-of: odoo/odoo#118023
Instead of using the `date_start` of a MO to check if the MO will be in
time for the Final product in the MO Overview, use the `date_deadline`
if it is defined instead.
Part of task-3217757
Part-of: odoo/odoo#118023
The MO Overview would display the wrong uom in the replenishments lines
of the MO Overview. Since the data was pulled from the forecast report
(which displays it in the product's uom), it could not coincide with the
ones used in the MO.
Part-of: odoo/odoo#118023
Following 6825c44, the `produce_delay` is now defined on the bom rather
than on the product, thus raising a traceback when trying to access it
from the product.
Part-of: odoo/odoo#118023
The free quantity was only checked to see if there was a reason to order
more quantity in the MO Overview, but wasn't counted in the missing
quantity to order, leading to having a `to order` line with bigger
quantity than required.
Part of task-3217757
Part-of: odoo/odoo#118023
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Wrong key was used to display the unit of measure in the BoM Overview,
leaving the cells empty.
closesodoo/odoo#114934
X-original-commit: a6eba909a8f2ab07ddb239b4b64e82d51f724e66
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Add a way to disable the read() done in the forecast report. While those
are useful to send the right data to the client, they have no use and
even slow down the process when the forecast report lines are generated
for a python-side use.
Part of task-3059467
Part-of: odoo/odoo#113394
Adds in a new report that allows the user to monitor the entire
production of a product, including the resupply of the components (i.e.
subassemblies, purchases, ...) in a single view.
Task-3059467
Part-of: odoo/odoo#113394
Before this commit, the reserve and unreserve buttons did not appear
for MOs.
Another bug was also fixed, removed the 0 Inventory on Hand line that appeared
when there are no moves in the report.
closesodoo/odoo#112981
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, the reserve/unreserve buttons did not work / were
hidden with multi-step delivery settings. The report now works with the
entire linked chain of moves, it displays which step is reserved,
if more than one is reserved in the chain the later move is shown.
Because reservation works differently on chained moves (they reserve
quantities brought by previous move in the chain) any extra unreservable
quantities are shown as on stock in transit.
closesodoo/odoo#112162
Taskid: 2858139
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Refactoring of report_stock_forecasted to owl
Since it wasn't really a report (no print action),
it changed from a report to a client action.
Task: 2885757
See Upgrade : odoo/upgrade#3926
See Enterprise : odoo/enterprise#32116closesodoo/odoo#101247
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Variant: Color: Black and white
- BOM 1:
- product variant: P1 - White
- Type: Kit
- Consumable: C1
- BOM 2:
- product variant: P1 - Black
- Type: Kit
- Consumable: C1
- Create another kit product “P2” without variants
- Create an SO:
- Add “P1 - white”, “P1 - black”, “P2”
- Confirm the SO
- Go to the delivery → validate it Print the delivery slip
Problem:
only product "P2" is displayed in the report.
The `product_id.name` is used as `move.name`:
https://github.com/odoo/odoo/blob/16.0/addons/sale_stock/models/sale_order_line.py#L333
but then only compare it with the name of the `product_template` set in
the bill of material to filter the moves.
Solution:
Check if the `move.name` is equal to the `product_id.display_name`
set in the bill of materialale au product_id set dans la bill of
material.
opw-3051639
opw-3047822
closesodoo/odoo#110837
X-original-commit: eae5cf84625f8155bc72b63eaed28819698810cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create an attribute with "Variant Creation Mode" = Dynamically
- In a product template, add the attributes and some values
- Create a new BoM for this product
- Click on "Stucture&Cost" smart button
Problem:
A traceback is raise, because the `_match_all_variant_values` function
is called but without the product, while it takes at least one:
https://github.com/odoo/odoo/blob/15.0/addons/mrp/models/mrp_bom.py# L456
https://github.com/odoo/odoo/blob/15.0/addons/mrp/models/product.py#L286
As the variant creation mode is set “dynamically”, the object must be a
`product.template` model and not `product.product` so the first
condition should be `True` and return a `false` value:
https://github.com/odoo/odoo/blob/5c16aa22c70f8a0a377a55b912307ab07222c643/addons/mrp/models/mrp_bom.py#L453-L454
Therefore, if the product has no variant, we have to use the
`product_template` and set it in the `_get_bom` function, but from this
commit:
odoo@ca3dfec
If there is no variant product, the template is no longer set:
odoo@ca3dfec#diff-e8f576a790cd7f3f0976358b9b07f63cee0c6f05b0ba6203fc7bcf91af3ad283L107
The change in this commit from line 107 to line 118 is useless because
it does not change any behavior and does not improve the code, the only
change is that the product_template is no longer set. So it makes sense
to revert this part of change
opw-3008838
closesodoo/odoo#110341
X-original-commit: 1d830b5080e4d05dc1ac6fbd4c435af532443f88
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Incorrect variable reference + calculation for unit BoM cost for
byproduct/product (to produce) within in BoM overview report. This
was leading to the displayed value having the cost_share being multipled
into the unit cost twice.
Steps to reproduce:
- create component with cost 100
- create BoM with 1 of this component + 1 byproduct with
qty = 2 and cost_share = 50.00
- click on Overview
result before this commit:
Manufactured Product unit cost = 25.00
Byproduct unit cost = 12.50
actual result should be:
Manufactured Product unit cost = 50.00
Byproduct unit cost = 25.00
closesodoo/odoo#107410
X-original-commit: 2339bed170b5f670b1f5a6cebd533a9cee72d4db
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Since fixes done on the bom overview had to be done in a released
version, no method signature changes could be done, hence the use of
excessive context keys to bypass it.
Changes the signatures so that future work is done on better grounds,
and so that each method explicitely asks for what parameters it needs to
do its work.
closesodoo/odoo#107006
Related: odoo/enterprise#34577
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Take the following BoM :
Final_product
Semi_final_1 (Subcontracted)
Component_1 (Dropshipped to subcontractor)
Semi_final_2 (Manufactured by us)
Component_1 (Bought then put in stock)
Component_1 is used in both semi_finals, but in different contexts. For
Semi_final_1, it's directly dropshipped to the subcontractor, while for
Semi_final_2 we resupply our stock and then use it from there.
Problem is, since both components are the same, there was no distinction
made when fetching the data for the resupply methods. So if the first
case encountered was the dropship (like here), then for Semi_final_2 the
dropship would be used as well, while we're not in a subcontracting
context anymore.
Now we consider the parent_bom when fetching and storing the resupply
data, as different boms can have different contexts.
Part of task-2985735
X-original-commit: 9ceb6b4f5996f962689ea671ea79ba81deeee763
Part-of: odoo/odoo#106935
Before this commit, the rules were checked related to the currently
selected warehouse. Doing this didn't allow to check the subcontracted
locations for their related rules (like Drophip subcontractor on order).
The point here is that when no rules are found within the warehouse, it
checks the subcontracted location of the parent if the parent is
subcontracted itself.
Part of task-2985735
X-original-commit: feeef868093042ae4cb788d513c02244b8c36623
Part-of: odoo/odoo#106935
Before this, when working on a bom with variants, when checking the
parent from the component / child_bom, it would always take the first
variant since it used the bom's product_template.
This could lead to incorrect data when working with subcontracting, as
when another variant from the first would be selected, when fetching
quantities no parent info would be found as it would seek info from the
first variant of the bom instead of the correct one.
By doing this, we can now have the right variant and fetch the right
informations.
Part of task-2985735
X-original-commit: c855038c73e2c964ef78b41090c35e3a07d30f9b
Part-of: odoo/odoo#106935
Steps to reproduce
==================
- Create a BOM
- Add a line with a product of type product
- Set the quantity to 0
- Save and click on overview
-> ServerError: Division by 0
Cause of the issue
==================
Lines with a quantity of 0 should be excluded from the computation
opw-3053167
closesodoo/odoo#104980
X-original-commit: b0f5170252ed73d31543b8d1dcf114ae6f0b65bc
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In order to correctly handle dark-mode (#99755) elements
that match views bg-color should use `bg-view` class.
task-3012970
closesodoo/odoo#103132
X-original-commit: e29347b4c45325584b0dd30a15fdf5d662f62c99
Related: odoo/enterprise#32753
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Changes "Structure & Cost" report to "Overview", as the goal for this
report is improved.
The point is to have on a single report all components and sub-assemblies
that make it up, in parallel with the route and lead times associated to
each. This way it becomes easier to identify issues, such as:
- Missing routes.
- Longer lead times on a specific sub-assembly.
- Unavailable component in the foreseable future.
- ...
Also did the conversion to OWL, changing drastically the structure of
the report.
Task-2628323
Part-of: odoo/odoo#93194
Steps to reproduce:
- Inventory app > Settings > enable barcode scanner
- Manufacturing app > Create a new manufacturing order
- Under components, add a product that has a barcode
- Save > Print > Production order
The barcodes of the products on the report all encode the
same (incorrect) value, which is the manufacturing order name.
This commit changes the barcode value to the corresponding
barcode string of the products.
opw-2930848
closesodoo/odoo#97968
X-original-commit: 71d4d977d42e69e8e3d7e069098707b84812ee07
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: stcc-odoo <stcc@odoo.com>
This commit improves the design and removes unnecessary SCSS.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2896849
Part-of: odoo/odoo#94767
- Change some section and column headers to make content clearer based on MO status
- Add in columns/field for in progress MOs for easier tracking of MO status
- Update words to match field names more closely (i.e. Actual Duration, To Consume, etc.)
Task ID - 2688146
closesodoo/odoo#93066
Signed-off-by: Tiffany Chang <tic@odoo.com>
yhu-odoo