The workorder opening wizard view need a footer to be closed when
clicking on a button.
Task : 2278147
closesodoo/odoo#54364
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The custom 'to consume' widget wrap the classic float widget into a
<span> tag to add a non editable part to display. The issue this commit
fix is the following: the float widget element is this.$el in
_renderEdit. Appending it to a new element make it loose its link to the
DOM. The custom widget is totally blank.
This commit clone this.$el before surrounding it by the new span
Task : 2278147
closesodoo/odoo#54042
X-original-commit: 01bb1fce77cce3d54cd969e643b7c720673f2b22
Related: odoo/upgrade#1451
Related: odoo/enterprise#11645
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit bring together sanity check functions called during
production order validation in a separated method. Other modules will
override it to add other sanity checks.
Task : 2278147
X-original-commit: e11f8da6674e9a21ab61d0aa67ef1797752273e2
If the consumption wizard is triggered in a workorder (via 'Mark As Done
And Close MO'). We would like the confirm button redirect to the
workorder list view afterwards.
Task : 2278147
X-original-commit: 55e2a4d16d3a56b8f509d2d67a344c53d62474b6
The Table (MTO) production hasn't its finished moves created in the demo
data. This lead to the impossiblity to mark as done the production
order.
Task : 2278147
X-original-commit: d6e20db6f6b372707a67ec63d71a1c2737511765
Duplicate a BoM with operations and some BoM line consume in specific
operation. The operations are well duplicated but the 'consume in
operation' field still point to the original BoM's operations.
This commit search for the operation to replace based on the name and
the workcenter_id.
Task : 2278147
X-original-commit: 4c6d445dfd561a236b1b171ccbcc2ff2b6236640
Consuming all the components for only a part of the finished product
will ask the manufacturing user to create a backorder. Confirm it will
fail as there are no component left to consume to produce the
remaining quantity of finished product. This commit only confirm
backorders that still have some quantities to consume.
Task : 2278147
X-original-commit: 51c9281d715e27143955c7b9b51f60b22e672f52
This commit makes some changes in the production order views
as well as in the workorders one. This commits make sure there
is now only one form view left for the mrp.workorder model.
This commit take part of the MRP refactoring
(69c48add32)
Task : 2278147
X-original-commit: 8b389ab3601cf5ed9328b7ce55ee91d54aa70150
This commit extends the delivery slip so that products added as a kit
component to a stock.picking are grouped together by kit (or non-kit)
when at least 1 kit exists. Kit grouping occurs for products from a kit
without a package assigned. Non-kit section appears only when no
packages are assigned.
Implementation notes:
- Sub-kits (i.e. kits within kits) of kits are purposely not included
- Duplicate product names with different BOMs will be merged into one
since there is no straightforward way to distinguish them within
current db structure
- There are some cases where this doesn't work as expected and may lead
to components being grouped together under the same kit even if they
are from different kits (e.g. kit1 has bolts and so does kit2 => on
slip bolts will only show under kit1 section). Two cases where this
happens is when kits are added before 'Operation Type' is specified
and 'Operation Type = Manufacturing'
This completes subsection 1 of overall Improve delivery slip task.
Task: 2039720
Create some attributes with "create dynamically" set
Create a product template using these attributes (=> product variants
should not be created)
Set this product as manufactured, and create an associated BOM with some
components
Try to print the BOM
User will face a traceback due to the product_id being non existant
opw-2283649
closesodoo/odoo#53872
X-original-commit: 4d77ada68fb4d8113a5fbf95f20ccb49d0611fc5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P with 2 variants A & B (e.g. 2 colors)
- Create the following BOM
Component 1
Component 2a, applies to variant A
Component 2b, applies to variant B
- Create a MO
- Set the product to variant A
=> 2 components are added: 1 and 2a
- Change the product to variant B
The component 2b is added but 2a is not removed.
The issue is coming from the result of the onchange, when comparing the
2 snapshots. The result contains the following commands:
- [(5,)]: clear the lines
- [(1, ...): ]: update component 1
- [(4, ...)]: keep component 2a
- [(0, ...)]: add component 2b
In case we are changing the product, we clear the lines.
opw-2270990
closesodoo/odoo#53689
X-original-commit: 89d9e759ae0cc31ad1fc398d41fa7a638056309e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 3 products A, B1, B2
- Create a BOM for A:
Manufacture, 1 unit of B1
- Create another BOM or A:
Kit, 1 unit of B2
- Create a MO for A
- Click on 'Produce'
B2 appears as a 'By-product'. Upon saving, an error occurs because of a
rounding set to zero.
The issues is coming from the generation of the `move_finished_ids`.
Since the product A has a BOM kit, the latter is exploded and added as
'By-product'.
We should not try to find phantom BOM for this specific use case. A
solution is to not explote the move produced.
opw-2251423
closesodoo/odoo#53526
X-original-commit: 226ccc2f64d00a19e0ae8851c45051106aa49adc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit sets attribute sample="1" in a bunch of list and
kanban views, to enable the new sample data feature when views are
empty.
Task 2232801
X-original-commit: 5471309b35619f307242c2704c7681ba63d2be42
- Create 3 products:
A: kg, no tracking
B: kg, tracked by lot
AB: kg, no tracking
- Create a BOM for AB:
1 kg of A
30 g of B
- Create a MO for 1 kg of AB, validate and close the MO
- Unbuild the MO
A stock move for 0.03 g of B is created instead of 30 g.
This happens because we wrongly compare the quantity in the UoM of the
stock move with a normalied quantity.
opw-2278727
closesodoo/odoo#53390
X-original-commit: 6790e89f97d6bbbaab4e071af52cce9ccee98821
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Support two new syntaxes with `_()` method:
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. "Foo %s" translated "Foo s%").
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
closesodoo/odoo#52155
Task-id: 1853119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
This commit makes it so products can be replenished without any other
module. This is achieved by adding a "pull" rule to the default receipt
route generated when a warehouse is created. "Pull" rule is added to 1-,
2-, and 3-step receipt routes. Previous to this commit, an additional
module (e.g. purchase, mrp, etc.) was needed for a pull rule to trigger
with the existing receipt route rules. Replenishments can be triggered
via "Replenish" button in product form, recording rules (auto trigger),
and replenishment (manual trigger).
Additionally, this commit makes it so when other modules (mrp, purchase)
that handle replenishment are installed, this additional "pull" rule is
removed from the default receipt route to prevent undesired behavior
(e.g. MTO manufacturing components magically being received from no
where). Unfortunately this means 2 undesirable situations:
1. If a user adds adds/changes rules to the receipt route and then installs
mrp or purchase then their additions/changes will be removed.
2. If a user removes either (when only 1 installed) or both of these
modules then stock module will again not be able to replenish as the
pull rule will not be re-added to the receipt route.
It is expected that these 2 cases do not need to be handled in most
cases or can be handled by advanced users.
Stock tests have also been updated to accomodate this new pull rule.
Specification 4 of overall inventory onboarding improvement task.
Task: 2220129
Related Enterprise PR: odoo/enterprise#10719
This commit makes it so the default "Product Type" = "Storable
Product" ('type'='product') when creating a new product in a
manufacturing order or an inventory transfer. Previously the default
was "Consumable".
Specification 1 of Inventory Onboarding task.
Task: 2220129
Enterprise PR: odoo/enterprise#10719
Usecase to reproduce:
- Create 2 table(MTO)
- Produce 1 and use BO button
Traceback due to a reference to enterprise field.
closesodoo/odoo#53077
X-original-commit: 2fffc12f8e3cdccba4b1c9820f997f4b10dac330
Related: odoo/enterprise#11191
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create flexible BOM for product P
- Create a MO for 5 units
- Produce 3 units
- Post the inventory
- Cancel the MO
The MO remains 'In Progress'.
In case of a flexible BOM, the quantity produced is compared to the
quantity to produce to know whether the MO should be done. In this
specific case, however, the MO should be closed.
It's not possible to rely on the move states in this case, so we
force the MO state.
opw-2270279
closesodoo/odoo#53010
X-original-commit: c99fe9dc5b5054d8d92b7283ad9f27f150de410b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
Bunch of last minute fixes including:
- serial handling in tablet view
- expected durations and backorders
- button unplan unlinks the leave but the computed aren't recomputed
then we need to manually set the date_planned_start/finished
then we need to not propagate them on the related document
(move/production) because they are required
- operation company_id wrongly set
task-2241471
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
- The Scheduled Date can't be change if the MO have some planned WO.
(WO defines the scheduled date of the MO)
- Now the Scheduled Date 'date_planned_start' is set by default
with the deadline date if there is or now if there isn't (same than before).
- For MO, 'plan_date_finished' is now invisible. But keep the field
because it is used to set the date_expected of finished moves.
- Change the plan behaviour: Plan depending of the scheduled date if
this one is bigger than now, else try to plan as soon as possible.
task-2241471
Instead using production name + name of WO as name in the
leave record, use the display name of WO to reprensent uniquely
the leave (even this record is not really reprensent in views).
task-2241471
Previously, when we upate the "Quantity to Produce" on a MO, we update
the components to consume according to the BOM we use. After this
commit, we now update the components according their current number set
on the MO.
For example, if we have a MO to use x component A to produce y product
B. When we update the number y to z, the number of A we want to consume
will be updated from x to x / y * z, regardless of the setting on the
BOM. If multiple components are used, all components will be updated
according to this rule.
Task: 2241471
This commit updates 4 features related to a MO being locked/unlocked.
1. Manufacturing orders are by default unlocked. A new configuration
setting has been added so users can set the default to be locked.
This setting only applies to new manufacturing orders after the setting
has been changed.
2. A MO now shows the same button options regardless if it is
locked/unlocked ('scrap', 'cancel', 'unreserve')
3. Workers can always change "Consumed Quantities"/"Produced" when
clicking on a component/finished product line unless state=Done and MO
is_locked. This includes adding new components/finished products.
4. Workers can now change "To Consume" quantity when clicking on a
component line, unlocked, and not in states 'Done' or 'Cancel'.
This is part of specification 6-Lock/Unlock of overall Editing in MO
form and backorders task.
Task: 2241471
Currently the related on the property use the company in the context and
not on the current object. It implies that a raw move created on the MO
form view will have the wrong destination location and trigger the
check company error.
Use a compute instead of related.
task-2241471
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
Cause
When kit BOM line quantity is equal to zero in a sale order, it raise error
because trying to divide bom_line_data['qty'] / bom_line_data['original_qty']
when computing kit quantities.
Solution
As BoMs allow components with 0 qty, a.k.a. optionnal components,
we simply skip those to avoid a division by zero.
Cherry-pick of #38890
opw-2262540
closesodoo/odoo#52362
X-original-commit: ab780a9d65e43f58a5745a5b92a25fb234827eb7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When owner and/or packages are activated, a MO doesn't give the
possibility to set the proper owner/package of the reserved products.
We add the fields in the view, and set them as optional.
Important note: this will only work with the move lines created during
the reservation. If additional move lines are created manually, this
won't work. Indeed, it would be necessary to add both fields to
`raw_workorder_line_ids`, hence to `mrp.abstract.workorder.line`.
opw-2260450
closesodoo/odoo#52180
X-original-commit: 7f84ef7c8a292a5e95b26f7923923271b7b109b7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The field note of mrp.routing.workcenter was not very usefull, and not
appear in the workorder related to this operation. Sometime, we need to
have a small description of the work to do for a opeartion in the WO,
instead of a complet pdf or google slide.
-> Convert the note field as a description of the job to do and add a
"text" worksheet_type to select it, in the mrp.routing.workcenter and
add the related field in the WO. Update the view of accordingly.
-> (migration): The 'note' content remain the same, then migration is
not needed. If the user change the worksheet_type into text, the
"note" will be the previous "description".
task-2196687
- Rename "Master Data" menu into "Products" in both stock and mrp.
And move not producte reclated menu to configuration menu.
- In the stock setting move all shipping connector in a dedicated
section.
- Improve helper of MO
- Merge filter "Late" and Planning Issue
- Remove badge of duration field in WO.
task-2196687
Issue
Step to do on mobile or chrome debugger in mobile mode
- Install "Manufacturing" app
- Go to "Manufacturing"
- Click on "Create"
- Select a product with already default bom lines
- Alter quantity
BOM lines are duplicated.
Cause
Missing "bom_line_id" field in kanban view,
who is required for onchange "_onchange_move_raw".
Solution
Create inherited kanban view with "bom_line_id" in
mrp module.
opw-2257732
closesodoo/odoo#52002
X-original-commit: 2905d05fc3d30562c5e7510217a6e97e26e87a37
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
William Henrotin