mrp - when a MO is generated from replenishment report, a log note is added
to chatter with the link of replenishment report, as this report got deleted
when to to qty is 0.0 then link dost not work. Hence added the simple text
for Relenishment report.
purchase_stock - When click on the order once button of replenishment report,
if vendor is not added on product then, added a new wizard with functionality
to directly jump on the edit product.
Added log note to the PO if po lines are generated through the Replenishment
report.
TaskId - 2427738
[IMP] stock: split method to create new or unlink unused OP
As, server action was added to the Replenishment menu, unless
until user clicks on the menu, new order point will not get
generate. Hence splitted the method and added to auto vaccum for
this.
TaskId - 2427738
closesodoo/odoo#66130
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Step to reproduce :
- Create a Manufacturing Order for several pieces of a product with a
work center routing
- Open the Work Order which has been created
- The Manufacturing Order is set to 'to close', instead of 'in progess'
Cause of the issue
The state of the MO was never computed based on WO status.
Solution
The state of a MO is set to 'to close' when a WO is set as 'done'
or 'cancel'
opw-2584446
closesodoo/odoo#74411
X-original-commit: c237c9c3214b58d303a8597df2c836872c5e522c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
Before this commit, it was required to always use the widget to edit the
consumed quantity of a component when multi-location or packages setting
is active. This was not user friendly so this commit relaxes the
requirement to only tracked products and gives users the option to still
edit the consumed move lines directly if desired. We also distinguish
between when using the widget is required or not with the widget button
color. Note that if quantity consumed is greater than amount reserved in
different locations, the difference will default to the move's source
location (this is consistent with what happens when the `qty_producing`
is changed in the MO and the consumed quantities are scaled to match.)
Task: 2518523
Upgrade PR: odoo/upgrade#2655closesodoo/odoo#73939
Related: odoo/enterprise#19732
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previous specification of making MOs unlocked by default was confusing
for users and made it too easy to accidentally change the qty to consume
rather than the consumed amount. This fix makes it so MOs are now locked
by default and will be unlocked/locked (including existing draft /
confirmed / in progress MOs) automatically when setting is changed.
Previous setting (Lock Quantities To Consume) has been repurposed for
this. When setting is active, no lock/unlock button will be visible to
match the updated setting description (i.e. non-done MOs can
never be locked).
Task: 2518523
ENT PR (only fixes test): odoo/enterprise#19732
Upgrade PR: odoo/upgrade#2655
Usecase:
- Create a production order without BoM
- Add a component
-> Traceback
It's due to a compute that try to access the UoM
while it's not set
closesodoo/odoo#74177
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
And convert the `t-esc` in the template to `t-out` while at it.
So this was a bit of a bummer initially, the PopoverWidgetField gets a
pile of JSON as its value (so from the server), and that pile contains
a template name (optionally) and... the template context,
basically. For leadDaysPopOver the issue was some of that context is
supposed to be rendered HTML to straight inject into the template,
marking that as HTML-safe would be a bit of an issue (having the JSON
specify which parts of the value it returns are HTML-safe being a bit
of a conflict of interest).
However turns out the thing is way over-complicated and
over-engineered: `lead_days_description` necessarily has a very
regular structure owing to being injected as a set of table rows, so
the various overrides to `_get_lead_days` just make their own lives
complicated by formatting the values they want to return into table
rows matching the format of an unrelated template.
Instead we can change the signature of `_get_lead_days` so the
"description" is a list of values to inject in the table (list of
pairs, each pair matching the corresponding columns of the table). The
template can then take care of formatting those values into table rows
the usual way, removing the need for any injection of raw content.
This also makes for better / clearer translation strings.
Step to follow
- Create a product with 2 variants and set route to Manufacture
- Create a BOM for the product
- Create an MO for one of the variants
- Save (in Draft State)
- Edit
- Change to the other variant
- Confirm
- Finish the MO Order
- Look at product moves on MO
Cause of the issue
In MrpProduction._onchange_move_finished method, self.move_finished_ids
was not empty before being assign.
Solution
Removed the records from self.move_finished_ids before
assign another one to it.
opw-2572644
closesodoo/odoo#73563
X-original-commit: 5e34a02c3d897d888bf52b1977c25047326b76a8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
Making a dynamic domain with a `allowed_xxx_ids` field is a bad idea
when the domain doesn't filter out the most of records. It can create a
performance issue, if the `allowed_xxx_ids` contains too much ids, then
a lot of data will be exchange to/from server for each onchange which
slows down all the form views.
task-2558097
- The work order state changes based on the availability of the components
- So if all BOM components are available the state of the first WO is set to ready
- The color of ready in the WO tree editable view will stay blue as long as done reserves the green color
- If one or multiple components are not available, the state of the first WO is set to waiting
- The color of waiting in the WO tree editable view is set to orange
By default to launch takes workorder_ready_count so it counts only ready WOs
- The user can always process the WO without restrictions even if the WO state is waiting
Task-2426773
closesodoo/odoo#71250
Related: odoo/enterprise#18523
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: nouraellm <nea@odoo.com>
Issue: we can't canceled a MO without component to consume when the MO
is in the state 'to_close'. It is due to
bf5e1debf9 which now allows to confirm a
MO without component to consume.
Like for the 'done' state. the state 'cancel' can't be modify after to
be set.
task-2426773
backorder name is generated in `_get_name_backorder`, which tries to change last
numbers first or adds new number to the end. The problem comes when we need to
generate more than 1000 backorders (e.g. on using mrp_subcontracting with
products tracked by serial): in that case the name would be
> WH/XXX/00001-1000-1001-1002-1003-1004-1005-1006-1007-1008-1009-...
Which is not user friendly and may lead to postgres constrain errors:
> psycopg2.errors.ProgramLimitExceeded: index row size 2712 exceeds btree version 4 maximum 2704 for index "mrp_production_name_uniq"
Fix it by using `re.sub`
STEPS:
Create a few test products (4 or 5) with route Buy + Resupplier subcontractor
from order.
Then make product which:
- has BoM and BoM type = subcontracting with components test 2, test 3, test 4, ...
- has costing method = FIFO , inventory valuation = automated, Tracking = unique SN
Now Create a receipt transfer of 4000 units. Click "Validate" and use "Create backorder" option.
---
opw-2579461
closesodoo/odoo#73578
X-original-commit: 9220ff89659898df2a1e1951b0466fc5adaa2c97
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
A kits bom has a component but qty is 0. When sale this kits, the 0 qty
component won't be delivered, and the delivered qty of the kits will
always be 0.
To fix it, we don't find a stock.move and bypass the quantity check
since the stock.move are not generated when bom line quantities are 0.
Task-2580118
PR #72637closesodoo/odoo#72920
X-original-commit: fad7a15560c1d454be294f1a8d1ce5a57d576900
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The commit 1355c9694e
archive all mrp operations at "Work Order" setting unticking. The good
way would be to hide the operations if the setting is deactivate.
closesodoo/odoo#72985
X-original-commit: 58d42aea296ac9ff548542a3120c6e81bbd61d02
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Infobox to help the user with the replenishment. Allow those actions:
- See the different supplier with their lead time, price and quantity
- Be able to select a supplier and set it on the orderpoint
⁻ See the last delivery by mmonth for the product
- Last purchase date for each supplier
Technicaly it use a wizard and a fields char with JSON used by
a widget to display a static template. Also it creates directly
the wizard in backend instead of just let the view manage the new
object since we need a button on a one2many and if the records do
not have an id, it's not possilbe to use it.
closesodoo/odoo#72039
Task: 2519761
Related: odoo/upgrade#2596
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Since we can't transfer service product, when compute delivered or
received kit quantities, we should skip the service components.
Task-2566373
PR #72306closesodoo/odoo#72575
X-original-commit: f86c7c0dfa09a2136ed1789a905eae9205de0c03
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Conflicting fixes for unusual cases of MO validation when no components
assigned and when components assigned all with 0 consumed made it so we
cannot validate an MO with no components despite there being a
confirmation popup that makes it seem like you can. This fix makes it
so we can validate a MO when no components are assigned (ideally we
would allow validating both cases, but fix for 0 consumed is much more
difficult + an extremely unlikely use case).
closesodoo/odoo#72343
Task: 2422698
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
Create 2 product (Finish product , RM product)
Create 1 Kit BOM for Finish product with 1 Component(RM Product) and quantity : 0.0860
Create SO for 10 Finish product and confirm SO
Deliver RM product : Quantity : 0.86 ( as per define ratio in BOM) -> validate
Bug:
Delivery quantity on SO line shows : 9 instead of 10
opw:2540671
closesodoo/odoo#72724
X-original-commit: 89aa85f32e0a87d537f4d9ed9c22955d3269ddd1
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When a serial number SN is trying to be consumed and has been unbuilt in the past,
an evaluation is used to check that the # of times SN was unbuilt is equal to
the # of times SN was consumed. However, when counting the unbuild SN it did not take into account if
it was from an unbuild order.
opw:2510294
closesodoo/odoo#72272
X-original-commit: 47d6ff49b19e68d84a68d8c4b999cb6115398805
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The problem arises when a user creates a backorder for a MO after
registering overconsumption of some components through the simplified view.
The quantities of the components of the new backordered MO are then wrong.
Components that were over consumed in the first MO will have smaller
quantities in the new MO, the difference being the amount over consumed.
This problem does not appear in the case of the Tablet View where a proper
recalculation of quantities is done.
closesodoo/odoo#64911
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> fields
1) maintenance.request -> description
2) maintenance.equipment -> note
3) maintenance.equipment.category -> note
4) mrp.workcenter -> note
5) mrp.workorder -> operation_notes
6) mrp.routing.workcenter -> note
7) repair.order -> internal_notes
8) repair.order -> quotation_notes
Task Id: 2499504
X-original-commit: 0cca26b5358cd9d69a65c6b93cfecb33d7e659c5
When planning a Manufacturing Order, if an operation takes place in work
center with a different time zone, the computed date may be incorrect
(the start date may be outside the working hours)
To reproduce the error:
(Use demo data. Current timezone: Europe/Brussels)
1. In Settings, enable "Work Orders"
2. Open an existing Work Center
3. Click on "Standard 40 hours/week"
4. Set Timezone to "Asia/Bangkok"
- Note that all slots are between 8:00-12:00 and 13:00-17:00
5. Create two storable products P_compo and P_finished
6. Create a Bill of Materials BM:
- Product: P_finished
- BoM Type: Manufacture this product
- Components: 1 x P_compo
- Operations: 3 x Operation with existing work centers
7. Create a Manufacturing Order:
- Bill of Material: BM
- Quantity: 100
8. Save, Confirm, Plan
Error: (it depends on the time the test is done) The 'Scheduled Start
Date' of the second operation is incorrect. Adding the time zone
difference gives a time that is outside the work center's timetable
(i.e., outside 8:00-12:00 and 13:00-17:00).
The computations do not consider the time zone of the work center.
OPW-2393330
closesodoo/odoo#71332
X-original-commit: dab24e497f095d0c7857f07d037e9cb16749e2ea
Related: odoo/enterprise#18572
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
In a Manufacturing Order, the components' quantities are rounded using
the rounding precision of the produced product's UoM. This leads to
incorrect values.
To reproduce the error:
1. In Settings, enable "Units of Measure"
2. In UoM, edit Units:
- Rounding Precision: 1
3. Create two products P_finished and P_compo
- P_compo's Product Type: Consumable
- P_compo's UoM: L
- P_finished's UoM: Units
4. Create a Bill of Materials
- Product: P_finished
- 1 Component:
- Product: P_compo
- Quantity: 0.2
- UoM: L
5. Create a Manufacturing Order:
- Product: P_finished
6. Confirm, Mark as Done
Error: Qty to consumes became 0 and consumed qty is 0. Both values
should be 0.2L, but they have been rounded using the rounding precision
of Units
OPW-2529462
closesodoo/odoo#71293
X-original-commit: aff3a2e06801dfb7a58df5180fb4ab5487b27f02
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
With this commit, changing the scheduled date on a planned production
order will unplan the workorders and so highlight the 'Plan' button to
replan them from the new scheduled date.
closesodoo/odoo#71089
X-original-commit: a6783acaef3c7c2224d1cda72717a36c4b38c001
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Batch the bom_search of bom_lines in mrp_bom.explode.
If we represent the bom hierarchy as a graph, essentially
switch from a depth-first to a breadth-first search, allowing
to batch search boms for each depth level, hence improving
the overall performance.
closesodoo/odoo#71137
X-original-commit: 44ae26e4477e1b76b3dbb0f1acd50e8553b14d71
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When updating the quantities available for a product, an inventory move
is generated without setting the product_tmpl_id, as this field is related
to the product_id of the move. However, when creating the move, Odoo will
consider it a default missing value and will try to fill it in the method
default_get.
When navigating to the product variants of a template from the template form,
a default_product_tmpl_id is set in the context pointing to the template. This
context is propagated to the update quantity action to create/update quants for
the variant.
The problem when dealing with kits is that the products available to update
their quantities are the components of the kit. When navigating to a variant
and updating the quantities of a component of the kit variant, the default product
template in the context will be the kit template.
This is causing that, when generating the inventory move, the move is created with
product_id of the component, and product_tmpl_id of the kit template.
This issue creates a critical data inconsistency as the component's template is set
to the kit's template, which apart from making no sense generates a recursion error.
To fix this, when triggering the action to create/update quants for a kit product, it
must be ensured that no default product template is being set.
closesodoo/odoo#71069
X-original-commit: bdeea73dc1efb6ff7d02cc2f58347a69762bcc3c
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
If a MO is validated with all of its (component)
move_raw_ids.quality_done = 0, then when trying to validate the
nonsensical "The quantity to produce must be positive" validation error
will occur. This is due to all move_raw_ids being marked as Cancelled,
which auto-updates the MO state to cancelled, which prevents the
validation from properly completing.
To avoid this error, we prevent the user from having 0 consumption for
all components.
Task: 2422698
Related (v13 fix + bug description) Task: 2463893
ENT PR (test fixes): odoo/enterprise#18355closesodoo/odoo#71068
X-original-commit: 81ba7084aeb3899787d083a2a2568a490f9c53e5
Related: odoo/enterprise#18411
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <ticodoo@users.noreply.github.com>
On unbuild order creation, when the user selects a manufacturing order,
the UoM of the quantity will be defined with the product's UoM instead
of MO's UoM.
To reproduce the error:
(Use demo data)
1. In Settings > General Settings, enable "Units of Measure"
2. Create two products P_finished and P_compo
- Both are storable
- Qty on Hand of P_compo = 12
3. Create a Bill of Material
- Product: P_finished
- Component: 1 x P_compo
4. Create a Manufacturing Order MO
- Product: P_finished
- Quantity To Produce: 1 Dozen(s)
5. Check Availability, Produce, Mark as Done
6. Create an Unbuild Order:
- Manufacturing Order: MO
Error: The unit of measure of the quantity is incorrect, this is
Unit(s), it should be Dozen(s)
The method `onchange_mo_id` defines the product, therefore the method
`onchange_product_id` is also called and here is the issue:
`onchange_product_id` will override the UoM using the product's UoM.
OPW-2467017
closesodoo/odoo#71017
X-original-commit: 1ec10d89ed265e0fb30e98063e80a51a37773ec7
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
This commit makes it so boms are no longer required for a replenishment
of a product via the manfuacture route. This change is related to the
v14 refactoring of the manfacturing app to make it more flexible and
user-friendly. In the refactoring, manufacturing orders no longer
require a BoM, therefore a MO created by a replenishment should also no
longer require a BoM.
closesodoo/odoo#64910
Task: 2422698
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Prior to this commit, MOs would throw a usererror if there were no
components in it. This restriction made it so MOs created by a
replenishment (i.e. `warehouse.orderpoint`) for a BoM with no components
were never confirmed and the `qty_to_order` would accumulate for each
replenishment's new draft MO.
Steps to reproduce:
1. create a bom for a new product (w/ manufacturing route) with no
components
2. create and confirm a sales order for the new product
3. go to Replenishment and automate the product's replenishment
4. create a new sales order for the product
Expected result: 2 confirmed MOs where the quantity of the first MO
matches the first sale order's quantity and the 2nd MO matches the
second sale order's quantity
Actual result: 2 draft MOs where the first MO matches the quantity of
the first sale order and the second MO matches the quantity of the first
sale order + the quantity of the second sale order
This commit makes it so MOs can now be confirmed even when it has no
components. Note this requires changing the logic in a few locations to
ensure expected behavior still occurs including:
- backorders are automatically confirmed.
- `reservation_state` is recalculated when expected (will be blank when
no components).
Task: 2422698
To reproduce:
1. create and confirm a MO with register number checks on operations
2. duplicate the MO
The register number checks won't show up in the new MO
We didn't set copy=False for workorder_id on stock.move, when copy a
confirmed MO, the new moves are linked to old WOs on old MO. New WO
didn't link to any moves.
When create quality checks, we only create "register ..." checks for WOs
with move_id. As a result, new WOs without move_id won't have those
checks.
To fix, set copy=False on workorder_id of stock.move
Task 2484939
closesodoo/odoo#71000
X-original-commit: 6aaf337558e59474efcef937f0175ee531b4b477
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.
This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.
This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.
opw : 2451298
closesodoo/odoo#70975
X-original-commit: e8c1f6b1a3f58b68181bf4d2599bd37efb83b5c7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The button plan of in the manufacturing order tree view doesn't
confirm correctly the draft MO selected (but only the related moves).
task-2479111
closesodoo/odoo#70608
X-original-commit: ef9515611ac96368eae14fc941bca15e3724557a
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
If you modify an archived warehouse, it may happen that the associated operations get unarchived. Operations should be active only if their warehouse is active.
closesodoo/odoo#70607
X-original-commit: 63167ac8ae6ac08fa54a133ed9089dd872c7d73c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, User can select Cancelled MO before selecting Product.
but it is already blocking since we already have constrains to not allow ubnuilding
Cancelled MO.
With this commit, We are always showing Done MO.
closesodoo/odoo#70316
X-original-commit: 48c0efcc97e35e00ec5803235a89a2c18e821990
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, It was always showing all
Unit of Measures in By Product lines.
With this commit, We are showing UoMs based on Category
of Selected Product's UoM.
closesodoo/odoo#70367
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit there would be trackback (TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'NoneType') when you will try to remove field Start date as we are using the field to compute duration.
With this commit, we compute duration when Both fields are present.
closesodoo/odoo#70482
X-original-commit: f29597fce37350f1c05d98341b959809bbb160b2
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, Creating Unbuild order using
Unbuild Button was resetting Bom as it was calling
`_onchange_product_id` after setting `mo_id` which was
resetting Bom on Unbuild order.
To Fix Issue, We setting `default_product_id` so It would not
reset `bom_id` when `_onchange_product_id` is called.
Fixes: #70216
Odoo Ticket: 2521788
closesodoo/odoo#70304
X-original-commit: 4de0ae434d1adc97fc1077b8d0f23c7e800ec161
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Without this commit, User was not allowed to create Unbuild Order
for the product without BoMs from Unbuild Orders menu.
But User was able to create Unbuild Order using 'Unbuild Order' button
on MO.
With this commit, We are allowing user to select Products without BoMs
to make this behavior consistent so user can create Unbuild Order from
Unbuild Orders menu.
closesodoo/odoo#70246
X-original-commit: eb332de42a36b7235d5578d39d345a5ff1df7759
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, if any workorder is stared to produce, qty
producing was 0. After this commit, if product tracking is none
then system will suggest the remaining qty of workorder to produce
when user is start it.
TaskId - 2480775
closesodoo/odoo#70207
X-original-commit: 5bbc234d43a415be18fcfa42dad33b1577644719
Related: odoo/enterprise#18086
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for the field on a product with ~1000 variants
Measuring total request time:
* Before 9,5 sec
* After:
** without module upgrade 1,5 sec
** with module upgrade 0,3 sec
Measuring query execution in psql:
* Before 7,2 sec
* After:
** without module upgrade 0,7 sec
** with module upgrade 0,001 sec
---
opw-2494423
closesodoo/odoo#69293
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Method `_onchange_workorder_ids` will create workorder_ids
for the the selected bom but it was not re-setting it on removing
BoM.
It was causing issue on `_action_confirm` as Bom for the selected
WO will not be found.
closes odoo/odoo#69662
Fixes: #68261
X-original-commit: 13832912daafad7c472d7414eaacede9e302e787
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Usecase to reproduce:
- BOM PROD 1 -> No operation -> KIT COMP 1
- BOM KIT COMP 1 -> at lease one operation
Create a MO and confirm it -> Traceback.
It happens because workorders_by_bom[production.bom_id] will try to
find the bom related to production order. However they don't exist but
it will create the entry [BOM PROD 1] = mrp.workorder()
The [0] will be call on each values of the list afterward and raise
the traceback
opw-2477269
closesodoo/odoo#69651
X-original-commit: edabb86a306c4dda088b39f163de5668b5d90392
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for field ``used_in_bom_count`` on a product with ~1000 variants
* Before 9,5 sec
* After 1,5 sec
---
opw-2494423
closesodoo/odoo#69341
X-original-commit: a2d63e8ae5d6bc0e822d12d724b5e3ff5a979cad
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Ease bill of material - operation configuration.
- allow to change the BoM of an operation,
- allow to update a BoM by duplicating existing operations(& quality points),
- by extension, changing the operation of a quality point update the products.
closesodoo/odoo#65628
Task: 2413246
Related: odoo/enterprise#16159
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When we deactivate the work orders in the settings, new MOs still
use operations that were assigned to the BoM, it just does not show the
Operations tab. We fix that by archiving the operations when work orders
are deactivated in the settings.
closesodoo/odoo#66108
Related: odoo/upgrade#2344
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When marking an operation as done, the quantity produced may be zero.
Therefore, the duration computation will not work.
To reproduce the error:
1. In Settings, enable "Work Orders"
2. Create two products P_prod and P_compo
- P_compo is consumable and its cost is 100
3. In Manufacturing, edit/create a Work Center WC
- Cost per hour must be 60
4. Create a Bill of Materials BM
- Product: P_prod
- Component: P_compo
- Operation:
- Work Center: WC
- Duration Computation: Compute based on tracked time
- Based on last 3 work orders
- Default Duration: 10:00
5. In Structure & Cost, notice that BoM Cost is 110
- 100 (P_compo's cost)
- 10 (OP's cost based on default time)
6. Do the following 3 times:
- Create a MO with P_prod using BM, Confirm
- In Work Orders, click on Start, then Done
- Edit the Real Duration of OP: 20:00
- Mark as Done
7. Back to BM, open Structure & Cost again
Error: BoM Cost is 110, this is incorrect: OP's cost is still 10, it
should be 20 (from step 6).
The problem is the quantity produced for each operation. Since this
quantity is never defined, it remains at 0. Therefore, when computing
the duration, since there is no quantity, the module keeps the default
value.
This fix changes the behavior. When the user marks the operation as done
from the form view, the module defines the quantity produced using the
quantity in production (this quantity may have been defined by the user
through the tablet mode). If this value is also 0, the module will use
the quantity expected by the MO.
`('qty_produced', '>', 0)` is added to avoid lines with zero quantity
produced, which was possible before this fix. Otherwise, the duration
calculation will give wrong values.
OPW-2453996
closesodoo/odoo#68917
X-original-commit: 93be6c6cfcfb3c4e52790569632dbdcdb1a3ae54
Related: odoo/enterprise#17540
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
We introduced new Smart Putaway Rules.
Locations now can have a storage category, on each storage category,
we can specify the amount of products/packages(with certian package
type) that can be stored in the location.
On putaway rules, we can also set a storage category. Now when apply a
putaway rule, we will find a suitable child location of the out
location according to quantity/weight setting on the storage category.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
Pratima Gupta