Steps to reproduce the bug:
- Create a MO
- Click on 'MARK AS TODO'
- Update the quantity to produce
- Produce the MO and click on 'MARK AS DONE'
- Unbuild the MO
Bug:
A traceback was raised because finished_move was not a singleton.
opw:2199529
closesodoo/odoo#46765
X-original-commit: a48573f3089bf78892f90df1dc883a257d047312
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit a4c0994 uses variable `qty` as input parameter but override it
at each loop iteration. The original value of `qty` is lost after the
the first pass and so give wrong results for all next iterations.
This commit uses another name to never lose the given value.
closesodoo/odoo#46587
X-original-commit: e1c30bceba6d47d8e087e540f995a02086fa6283
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Purpose
=======
A 'book icon' link to the documentation of a feature has been
added in its settings panel, when it is useful (complex feature).
Add a nightly test that parses all the res_config_settings views
from the base one and checks that all documentation links are still valid.
Add the o_doc_link class to all documentation links to be able to easily
catch them if needed.
closesodoo/odoo#45813
Taskid: 2180574
Related: odoo/enterprise#8601
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Since 5118d248cc , the action with
id='act_product_mrp_production' was unused.
- Since 85a3e1e385 , the action with
id='action_mrp_unbuild_move_line' was renamed due to duplicate ids
(with action_mrp_unbuild_moves), then remove it (unused) and move
the helper message to the original one.
- Since 81577bf24e , the action with
id='mrp_workcenter_productivity_loss_action' is unused because
the commit remove the menu item using this action
- Since it was integred, the action with
id='mrp_workorder_delta_report' was unused, then remove it.
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps to reproduce the bug:
- Install Manufacturing
- Go to General Settings/Inventory and tick Units of Measure
- Create a product P (storable) with UOM kg
- Create a Bill of Material for this product: e.g. 1 kg
- Add a component C with UOM "kg", but in the BOM uses "g"
- Create a MO for P, Mark as todo, Produce
- Click on C to change the quantities (e.g. change the first line to 900 g)
- Add a second line with 0.1 kg (as the uom of C is in kg, you are forced to set in kg)
Bug:
The strict consumption check is raised. It happens because the
lines quantity done are not correctly converted in the same
UoM
opw:2181892
closesodoo/odoo#46103
X-original-commit: e385930f8687fc4051ddd375fe0551dba59a8750
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In case of MTO+Manufacture, a sale order have a count of
manufacturing order created from it :
1. create SO with MFG+MTO product with quantity of 5.
2. confirm it. MO will be created for 5 Nos.
3. increase it to 7 . another MO created for 2 Nos.
4. there are 2 MO created based on 1 SO.
It was due that new stock move was merge, and the
'created_production_id' info was lost during the merge (keep only
the original one). To fix, avoid merging stock move with distinct
'created_production_id' (done by override
'_prepare_merge_moves_distinct_fields' and
'_prepare_merge_move_sort_method' methods ).
task-2199568
closesodoo/odoo#45800
X-original-commit: 1fb32cfd17122b625d211a7d22ec319fba35e87f
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider two production locations L1 in C1 and L2 in C2
- Let's consider that the company of SUPERUSER is C1
- Add the field Production location in the form view of mrp.production
- Log in C2
- Create a product P with a BOM in C2 with L2 as production location
- Create a MO for P
Bug:
The production location of P was L1 instead L2
PS: related_sudo is set to True by default.
opw:2196707
closesodoo/odoo#45692
X-original-commit: aef3d1864826a939fbd9cfd9b666614169a1db0e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit c883ed1087 let the possibility to
add additional stock moves in a confirmed production. The issue is those
move don't get the production group and their procure method is set
(and never changed) to make_to_stock.
This commit call adjust_procure_method before confirming additional
moves.
closesodoo/odoo#45660
X-original-commit: 96cc10fa79a120172b3cde88d50ba2fda5e75ab5
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Let's say we have a chain of move
wh1 - intercomp transit -> intercomp transit - wh2
The second move will be reserved according to what the first move
brought since they are chained. This behavior resulted in rev[0] which
tries to work around the ir.rule limiting the access of stock.move and
stock.move.line records in multi-company environment.
This patch wasn't perfect since, if the first move brought a lot, the
second move will reserve this lot and it will result in another access
error since the lot will still have the company of the first move.
We fix this by implementing the following logic: receiving from another
company should behave the same as receiving from the supplier, no
reservation is applied. We fix this by marking the inter company transit
as `_should_bypass_reservation` and we break the move chain if the
pull/push rule create an intercompany chain.
[0] 6ff34073153767d449804669f31e26c04de0a670
closesodoo/odoo#45601
Task: 2160847
X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Set the following product configuration:
Storable finished product with a flexible BOM made of storable
components in manufacture + MTO:
Component choice 1 Quantity = 0
with BOM made of component 1, quantity 1 with purchase mto route
Component choice 2 Quantity = 0
with BOM made of component 2, quantity 1 with purchase mto route
Create a MO for finished product, set the "to consume" quantity of
"Component choice 1" to 1, and try to mark it as to do. The following
issue is raised: The quantity to produce must be positive!
This is because a procurement with 0 quantity will be solved in a MO
producing 0 quantity. We fix this issue by ignoring procurements with 0
quantities.
Also, this MO without initial demand is not considered assigned. We fix
this issue by considering 0 move as assigned.
task-2159374
closesodoo/odoo#45552
X-original-commit: dffb3a1f2762d6e1517eb9b7d225521f99d874d5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
VAT, NIF in Spanish, is translated NIT in Spanish from Bolivia
Clean and translate the files with the correct translation.
opw-2197155
closesodoo/odoo#45533
X-original-commit: 641c14f08435b1df1d89184cc00855416bf40bc5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The icon of the json popover become a warning icon
when there is a issue. Also, create a
field show_json_popover in mrp_production
to avoid using d-none to put in invisible the popover.
task-2178494
closesodoo/odoo#45420
X-original-commit: 270e8d34b2adec07e8ae3b8952514184d2a00b59
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`action_explode` unlinks the kit move and create the stock moves for the components.
As the `create_multi` is not used, it results in lots of delays. Use the `create_multi`.
closesodoo/odoo#45326
X-original-commit: 4818ee61b4f23ab7b388acd2bdd452c27e25fc0d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`action_explode` is called when confirming the moves of a picking. It
calls unlink() when the move contains a kit. As this method is not
multi, when confirming 50 kit moves, unlink is called 50 times resulting in
a lot of cache invalidation, prefetching and so on.
We make `action_explode` multi in order to call one time `unlink` per
kit levels.
X-original-commit: 096c682e748f7e581e48f0070ec8a3284d8a2fe7
Usecase to reproduce:
- Create a product MTO manufacture with a BoM
- Set produce delay as 1 day.
- Create a SO for the product and validate
The production order is created but with a duration of 1h.
It's due to commit 8944674d6d
It will use the moves finished date in order to determine the MO
finished date. However before this commit during _run_manufacture
the MO was created with a fix finished date and the move finished
date_expected was created with this date as date_expected.
Now the MO is created with the finished date, the inverse does
nothing since the finished moves do not exist yet.
In order to fix it, generate move_finished_ids use the product/company
manufacture delay. A first patch tried to rewrite date_planned_finished
after action_confirm. However it triggers the propagate date on
following moves.
closesodoo/odoo#44532
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase to reproduce:
- Create a product with 10 days manufacture lead time
- Create a procurement in order to fullfill a need the 01/15
The MO start date is the 01/05 that's the expected values
The MO finished date is the 01/05, 1 h later than the start date
It happens due to commit 92aeaa47ff
This commit modified the wrong start date in order to take the
procurement date - manufacturing lead time. However it also
modified the finished date to 'the start date + 1h'. That returns
the problem to the opposite direction. Now the finished moves have
a wrong planning.
Fix it by using the production + company lead days when it's set
instead of 1h.
opw-2181962
X-original-commit: 6a5ce8de91d3ab2cb7f73127a6ee1c11578ccef9
Issue
- Install MRP
- MO > Import with BOM
The lines are not populated but it
was the case in v12.
Cause
In 7206b385b5, the lines generation
are done in a onchange but they are
not trigerred in imports
Solution
Call the onchange manually when we
are in an import case
OPW-2188066
closesodoo/odoo#45118
X-original-commit: 26c44fae1ad8a3ac2d79d9673255aef12fddeb17
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
As `_do_unreserve` was rewrited, the `_decrease_reserved_quanity` method
isn't useful since its purpose was to avoid to unlink all stock moves
and it is what `_do_unreserve` cares about.
See 2e41338f42e2ef9f2ac2b3e73b274c4af242b28a
closesodoo/odoo#42582
Related: odoo/enterprise#7488
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
purpose of this commit is to make import template compatible with v13
task-2146510
closes-#42279
closesodoo/odoo#44375
X-original-commit: 37aadf1227531838ada7dc3810cf463379736e96
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Due to the setting `ready_to_produce` = `asap` on Bill of Material. The
Check Availability button could be hidden even if some stock moves are
still in confirmed state.
Task : 2121714
closesodoo/odoo#41631
Related: odoo/enterprise#7253
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose: adding new component in a specific workorder via the form view.
This behavior is only available if the Bill of Material is in flexible
consumption. Adding new component was already made possible in
e1f518bb83 but the ability to add new
workorder lines conditionnaly in the workorder form view was missing.
Task: 2121714
Consuming product tracked by lot (or serial number ) to produce product
also tracked must ensure the link between the two lots (consumed and produced)
is always set. This test is not done in community version while there is
one in the enterprise conterpart (mrp_workorder module). This commit
move this test to the mrp module to have it everywhere
Task : 2121714
This commit let the manufacturing user to add new components or update
the quantity to consume of existing ones in a manufacturing order even if
the state confirmed. The BoM should be in flexible consumption.
In case of reserved quantity, updating the quantity on a raw move will
unreserve it entirely. We apply the same logic than the stock.picking one
Task : 2121714
This commit adds the possibility to choose in which operation a new product
will be consumed. New product can be added to the production once the
manufacturing order is in state draft.
Before this commit, the new product was consumed
automatically in the last workorder.
Task: 2121714
The next commits will allow changing the initial demand of
confirmed moves as well as adding move once the production
order is confirmed. In order to not duplicate again the unit
factor computation in multiple write and create, make the
field a stored computed.
Unit_factor is stored and only depends on product_uom_qty because
updating only quantity_done (after a partial production for
instance) should leave unit_factor unchanged for the futur
partial production.
Task: 2121714
We get a traceback when we try to unbuild a MO
due to a inexistant field call (scrap_qty) instead
of product_qty -> 8458cc1867.
Fix the issue.
closesodoo/odoo#44249
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usecase for example A black T-shirt made from a white T-shirt and
black color. This behavior was possible in 12.0 and 11.0 and was
removed by commit 77a8d92196Close#40540closesodoo/odoo#44084
X-original-commit: 575353e251a0cce3bbff759edaeb56b5718beb11
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Display the readable value of lot name in the Production Order report.
opw-2178868
closesodoo/odoo#43990
X-original-commit: 7e82b77a80fe70da45676fd87a458ffe9948e48d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a picking type for operation 'Manufacturing Operation'
- From the dashboard, click on 'Production Order'
The picking type set on the MO is not correct.
This is because the current picking type is not used when choosing a
default value.
We set it in the context to do so.
opw-2171977
closesodoo/odoo#43898
X-original-commit: 3e2ee43fd0aa6a06d5d5ecd1ff669f4a09698330
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In this commit:
- On done MO's form, add an Unbuild button, it would open a
wizard with the form view of an unbuild, and some pre-filled fields
such as MO, product, BOM, quantity and total quantity finished which
can be edited.
- In the unbuild order, improve the on_change of mo_id:
if the selected product is tracked by serial number,
set quantity to 1 by default and readonly
- Also clean the testcase of unbuild order.
task-2144636
closesodoo/odoo#43719
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: Ankita Raval <anr@odoo.com>
Improve the inherited wizards of 'stock.warn.insufficient.qty' by adding
some piece of information about the quantity involved. Also
change titles to integrated the related product into.
task-2144636
Co-authored-by: Ankita Raval <anr@odoo.com>
In case of MTO (+buy) on products used in a MO,
add the link between the MO source and the PO generated.
Also add links between MO's when MTO+manufacturing.
task-1913392
closesodoo/odoo#43366
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In some flows, a planned_datetime_start/finished will contains
milliseconds. In these cases, we can detect overlaps/conflicts between
workorders but these conflicts can't be see in the web interface
(because datetime is truncate when it is display).
Then, change the conflicts computation to remove milliseconds
in search of conflicts.
task-2169447
closesodoo/odoo#43013
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Now, the fields date_planned_start and date_planned_finished is
required in views, because it was strongly related to the leave date_to, date_from
which are required.
- Change the name_get in case of single WO in MO and replace the dot
by a dash.
- Improve the WO form view to be more responsive when it is open from the
gantt view.
- Change name of a Operation in the demo data
task-2169447
- Before, the auto-planning of workorder autorize overlaps between then.
E.g. if a workorder (WO1) begin at Now + 30min with a duration of 60 minutes
and we try to plan a new workorder (WO2) Now, this one will be plan now
until Now + 120 min (30 min of WO2 + 60 min of WO1 + 30 min of WO2).
In our case we don't want this behavior by default,
because in real case, it is not efficient to work on job A during
30 min, after change to pass to a other job B, and rework on A after
the job B.
But in a other hand, we need to accept overlaps with no-working hours
intervals. Then, rewritte the _plan_workorders method to take
these features in account.
Also small fix about the planning has been done:
- Due to the strong link of date_planned(_...) between the MO and WO,
the replan of the late first WO was wrong.
If the MO is planned before now, then don't take in account
date_planned_start and try to plan WO as soon as possible.
- Also, fix error handling when the WO is planned before the
previous one.
task-2169447
- Create a new Product
- Add a BOM to this product
- Set the BOM to be a kit
- Add components to the BOM
- Create a PO for the components for a qty of 5
- Confirm the PO but don't transfer the products
- Check the phantom kits outgoing_qty and incoming_qty they will match
A Phantom Kit Products outgoing_qty and incoming_qty are identical
Closes#43447closesodoo/odoo#43584
X-original-commit: 4b2e235be6cab947ce2e0b3b17b54530f984ce72
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Show the Post Inventory button to manufacturing users,
also if they are not in debug mode.
task-1887035
closesodoo/odoo#43294
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Keep the same UOM than the MO.
opw-2169377
closesodoo/odoo#43407
X-original-commit: 942154b3140cb3fc92e8aeff0241149e701581a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In this commit,
-The behaviour of drag and drop is blocked when grouping the
operation type and warehouse on inventory dashboard.
closesodoo/odoo#43229
Task-id: 2167610
X-original-commit: 5e8bcd3a5bfff9a5dc740287605d4ff661a701f7
Related: odoo/enterprise#7689
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Previously when the BoM on a product do not have components but only
services. Then during scheduler a log was posted on the product explaining
that components are required.
However since this process is possible in another usecase it should be
possible with procurement. The only difference is that procurements
confirm records in order to propagate. In this case since there is
no components and services are not propagate with procurements, it's
not needed to confirm the MO.
closesodoo/odoo#43133
Task: 2170845
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.
Task-2043927
closesodoo/odoo#41056
Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Goffin Simon