- Create a picking type with specific default locations, for type
Manufacturing
- Go to Inventory, click on the 'To Process' button
- Create a MO
The default locations are not taken into account.
This is because the default picking type is not in the context.
opw-2128182
closesodoo/odoo#41049
X-original-commit: 6f7cbedd0ad252352209391501ba8971f7e90d00
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
-previously, in the mobile view, while accessing Manufacturing
orders from the dashboard in inventory, the default view was
set to tree. changed it to be kanban instead.
-Same in case user tries to access WO from dashboard when there
are none and user is redirected to MO.
Task-2127508
closesodoo/odoo#40857
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Updating the quantity to produce in a production order will recompute
each raw move's unit factor. The issue was this computation did not
take care of the previously product quantity. The unit factor was wrong
and so the next created workorder lines get the wrong quantity.
Example:
- 1 components for 1 finished product (unit_factor = 1)
- Create a production for 2 finished product -> quantity to consume = 2
- Produce 1 then change quantity to produce to 3 -> quantity to consume = 3
and quantity done = 1 but unit factor became 1.5
closesodoo/odoo#40990
X-original-commit: 79976600df45afc6150150734eef405fd41a70a3
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit disables quick create in calendar view for
`mrp.production`, because it uses name field for storing
`ir.sequence` and calendar quick create also uses `name` field to
create quick create record.
So in this case, even if user enters summary field, it will be replaced by
`ir.sequence`, thus quick create doesn't make sense here.
Task-2052536
If a component is used in a production with another unit of measure
than it's one, the created stock move line could not convert the quantity
correctly.
If there is enough quantity in stock, the created move line takes the
quant uom but the quantity in the production ones.
ex: consume 1 dozen, the quantity on the stock move line is 1 unit
This commit always uses the wo line's UoM and quantity to create the
stock move line.
closesodoo/odoo#39222
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue: open a done production. Unlock it. Add a new raw stock move.
This action will called _compute_order_finished_lot_ids on the new
stock_move. This method uses
move.raw_material_production_id.move_finished_ids.
raw_material_production_id is available but not move_finished_ids. The
reason is move_finished_id is not loaded by the web client in the
production form view.
This commit added the one2many (invisible) in the view in order to
get all the information in the compute method.
This form is mostly used in the 'Cost Analisys report' (mrp_account_enterprise module)
and needed an update to better integrated with the report
Task : 2082448
Before this commit, The addition of new stock move lines in a
finished production via the unlock button did not impact the
traceability report. This was due to the fact that the new sml
has not been linked to the finished_lot_id.
This commit extend the flexible consumption. On the workorder form view.
It's now possible to add directly new workorder line with any product
(even one not in any BoM line). For those new wo line. A confirmed stock
move is create in the record_production step.
Task : 2082448
Process a workorder in the community version. Change the quantity to
produce. The quantity to consume is adapted for each component. Save the
workorder and the quantities to consume are rollbacked to the previous values
Those quantities are readonly so not saved to the server.
Task : 2127443
closesodoo/odoo#40579
X-original-commit: 4fc6d8a206c03c7db4ce7dd88e85f0e5312ad3f5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Without the product_uom_category_id set you cannot edit this tree view. There is a domain [('category_id', '=', product_uom_category_id)] triggered from this view whcich is not fulfilled if we do not have the field set in the tree.
closesodoo/odoo#40186
X-original-commit: 4873e5ef3192480fdd3889331f13ff0e10ba5d6a
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
If a Bill of Material is created without code (eg. when created as a new
group from a kanban view grouped by BoM) we would get a traceback
instead of an error.
With this changeset, we get a "You cannot create a new Bill of Material
from here." error if it is being tried.
opw-2124162
fix#38904closes#40289closesodoo/odoo#40457
X-original-commit: 32c13cd7d1387c0ea81a9bb5968d18c2b8f32051
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If a warehouse is created without code (eg. when created as a new group
from a kanban view grouped by warehouse) we would get a traceback
instead of an error:
```
The operation cannot be completed:
- Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.
Model: Warehouse (stock.warehouse), Field: Short Name (code)
```
opw-2124162
fix#40233closes#40267closesodoo/odoo#40382
X-original-commit: b6caa179e17199b29a9ca4009c53acb378423926
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create Product A:
Routes: MTO and Manufacture
Manufacturing Lead Time: 20 days
- Create Product B:
Routes: MTO and Buy
Add a supplier with Delivery Lead Time: 10 days
- Create a BOM: 1 unit of B to produce 1 unit of A
- Create a SO for A, validate
A MO is created with a Deadline set at SO order date - 20 days => OK
A PO is created with order date set at SO order date - 10 days => Not
OK, it should be - 30 days.
In v13, the raw materials expected date is the order date.
In v12, this date is computed as: order date minus Manufacturing Lead
Time
However, in both versions the PO order date is computed as the raw
materials expected date minus Delivery Lead Time of the supplier.
This comes from a change in the semantic of 'Planned Date' and 'Planned
End Date'. In v13, the Manufacturing Lead Time is only taken into
account in the Deadline, while in v12 it was taken into account in the
Planned Date. However, the expected date of the raw materials still
relies on the latter, not on the Deadline.
In order to solve this, we apply the 'Manufacturing Lead Time' of the
product and the company to 'Planned Date', 'Planned End Date' and
'Deadline' when the MO is created. Note that the solution is still not
ideal in case no routing is set on the BOM since 'Planned Date' and
'Planned End Date' won't be updated later in the process.
opw-2118951
closesodoo/odoo#40360
X-original-commit: b523f991572e32e69c5f8000a21553191ca54773
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
_action_done() creates extra stock move when quantity_done is superior
to initial demand. This extra move should be, after confirmation, either
merge into the original stock_move, either stay extra but the move lines
still linked to the first one should be shared accordingly to the quantity
done. The fix 561b3461a0 adapted the code
for MRP to split the move lines but neither those cases are applied in
MRP because the extra move has no picking_id field.
condition :
```if merge_into_self and extra_move.picking_id:```
will therefore be false as well as
```if not merge_into_self:```
To be sure the two extra move management cases are complementary, this
Commit keeps make sure the conditions are mutualy exclusive.
closesodoo/odoo#40230
Opw: 2087864
X-original-commit: 4e8ac38a6d67bcd5040af0b580bfa43da7841548
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Planning the workorders depends on the quantity to produce of those workorder
This will create as much as production batch needed regarding the workcenter
capacity.
This method is good except in case of product tracked by serial number. In that
case the quantity to produce on the workorders is force to 1 regardless of
the quantity to produce on the production
closesodoo/odoo#40226
X-original-commit: 3c4133ddac256c63802a99461db49cc9bd9fa1d6
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
commit 89f20d2c29 removed thumbnail but didn't adapt the views that used it.
Adapt the view and directly use the datas and not the thumbnail.
Close#38747closesodoo/odoo#40126
X-original-commit: e73b468135d27ce8c1e84c3ecf2d0b3af176d760
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Some tests (test_00_workorder_process, ...) are executed several times, only
because we extend a test class to retrieve the setUp (or setUpClass) instead
of creating a common class.
This could lead to issues, (like for test_00_workorder_process) depending on the
installed modules.
Steps to reproduce the bug:
- Let's consider two storable products P1 and P2
- Update the cost of P2 to 10€
- Create a BOM for P1 with P2 as component
- Click on Bom Structure & Cost
- Click on P2
- Try to update the cost
Bug:
A traceback was raised saying that "Record does not exist or has been deleted" or the cost of an other
product was displayed because the active_id was still the id of the bom.
opw:2093199
closesodoo/odoo#39710
X-original-commit: e984d8f94534373fde894e9e6ad0c932585deb46
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before commit: - If there are multi level production order,
and user cancelled any one then,
there is no activity logged on related production order.
After this commit: - In multi level production order
(i.e. one production order creates another production order
to consume the raw material)
if user cancelled raw material production order then,
exception will be generated on main production order,
so that user can easily get the idea that
raw material for this production order is not available.
[ADD] sale_mrp: add testcase for cancellation of the multilevel production orders
task-1819526.
closesodoo/odoo#28708
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a product A with a barcode, UOM as 'Unit(s)' with a BOM
- Create a MO for A with more than one unit, validate
- Print the 'Finished Product Label (PDF)'
A single label is printed for all units, although it is not logical: a
label should be printed for each unit, as already done for the Zebra
labels.
In case the product UOM is 'Unit(s)', we print a label per unit. To do
so, we use a template similar to `label_transfer_template_view_pdf`.
opw-2091663
closesodoo/odoo#39311
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a BoM is using a component with a quantity required set to 0,
tracebacks were occuring when computing the available quantities
for the kit.
Fixes#38807closesodoo/odoo#39267
X-original-commit: 7676269ba56c8e293ef4cd3dffbe7eccbad4a9d0
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Records were filtered so not every record was set in the for loop
Fixesodoo/odoo#38992Closesodoo/odoo#39071closesodoo/odoo#39234
X-original-commit: f7d5ba6f9ffccecffbb5b851bd2770ecef28520c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
*:
delivery
hr_timesheet
mrp
sale
sale_coupon
stock
This commit makes the static strings / labels editable with studio
by wrapping them in appropriate tag (mostly span) whenever needed.
Task-Id 2030430
closesodoo/odoo#34685
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The commit 0679d0d introduced a new
planning mechanism for the workorder. Two issues have been instroduced
since this patch.
1. Cancelling a workorder didn't free the time slot in the workcenter
calendar
2. Validation a workorder sooner than the planned date didn't update
the workcenter calendar to plan another production sooner.
This commit update the date_planned_start and date_planned_finished
at cancellation and validation to impact the workcenters calendar.
To keep the original planning dates, they are now tracked
This commit also fix the button_start() method that always rewrited the
date_start even if the production had already been started.
Task : 2082442
closesodoo/odoo#38947
X-original-commit: 4ca6c773a00320865142e4efb3645f36c54ce9a2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Since `check_company` is intended for relational fields.
closesodoo/odoo#38939
X-original-commit: bf2f3f6ce1430c2603fe7fe199a28296b2d7416f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usecase to repdroduce:
- Create a manufactured product with route manufacture and a RR
- Run the scheduler.
Orderpoint will prepare procurement values's date as string. Other
module could possibly also use string as date and a call to from_string
will not break anything if the value is already a date or a datetime.
closesodoo/odoo#38900
X-original-commit: e4c654f8e5e768288226c725a1018ae31e8f5606
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit redo the way workorders are planned on their workcenter
calendar. The resource_calendar_leaves introduced in 0679d0d is now linked
to the effetives dates (date_start and date_finished).
The planned dates copy their information onto effective date at the
workorder plannification or any modification before the actual production
(state = draft, pending or ready)
This way, the gantt view and calendar view display either the plannifaction
slot if the production isn't started yet and the effective production
time if it's done. The plannification is also impacted by validating
a production sooner than expected or cancelling it. In the first case,
the date_finished is set at 'now' and in the second case, all the dates
are emptied. The futur workorders will be planned on the newly recover
time slot.
This commit also fix the button_start() method that always rewrite the
date_start even if the production had already been started.
Task : 2082442
closesodoo/odoo#34038
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
With this commit, the manufacturer will now be noticed earlier in
the process if he produced/consumed a serial number already produced/consumed in a
previous production. Before this commit, an error was triggered as
well but only at the very last step of the production.
This leaded to two issues :
- The user had to unlock-edit-lock to update the wrong serial number
- On large production, it was difficult to figure out which was/were
the product(s) to fix.
The search on previous production is done each time the produce wizard is closed
or once the production is done on a workorder
Task 2002133
...Only on mobile device.
closesodoo/odoo#38469
X-original-commit: 484e7bdc5ac11f33f9aa8a0f697a5f23d8f20c4a
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
before this commit: mrp work center kanban card has UI glitch in
kanban card, work center stage was overlapping kanban card right
div
after this commit: overlapping issue of work center stage will
not occur, issue was occuring due to absolute position given on
work center stage div, added margin bottom of 16px on kanban
card right div
task-2060181
closesodoo/odoo#38210
X-original-commit: 7143e570bb186a8d7c42455e9c02072fdde8aa49
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install stock and purchase. Make a RFQ for just one product, coonfirm
and receive in one transfer. Click on the delivery (should be only 1).
The picking will display. Open studio, select view, activate list view.
Javascript traceback will popup. Moreover the view of the stock
module will be altered in a faulty way (can be recovered from "Window
Actions", looking for the stock.picking action with external id
"stock.action_picking_tree_all" and removing the last added tree from
"View Mode").
This is caused by studio not detecting all the active views, thus giving
the possibility to add an already active view, because when there is just
one picking all other views are filtered out.
Changing the way the form view is retrieved in case of a single picking
fix the issue.
opw-2076241
closesodoo/odoo#38093
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Small improvement in order to not trigger twice the write
function on state
close#34884closesodoo/odoo#38177
X-original-commit: d45d50b4f145a0bfb60465f7eb783a3c5fd85e6c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
*: account
crm
event
fleet
hr_expense
hr_holidays
hr_recruitment
mail
maintenance
mrp
note
project
purchase_requisition
repair
stock_landed_costs
stock_picking_batch
survey
website_event_track
This commit is making sure that the exception activities filters are
only defined where it make sense (i.e. where the system can actually
create an exception activity).
We have therefore removed 'exception activities' filters where the
system won't be creating any.
Task-2056425
closes odoo/odoo#36027
Closes: #36027
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: mrp
product
purchase
stock
Renamed the 'activities_exception' filter to 'Warnings' and moved it
to the bottom of the filters, isolated by separators
Task-2056425
Closes: #36027
Nicolas Martinelli