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
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
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>
Custom text decoration classes have been dropped with d9a0877096
in favor bootstrap default ones.
This commit will adapt the list-view generation code ans some mrp
translations that were mistakenly omitted.
task-2579123
This PR reverts this one https://github.com/odoo/odoo/pull/54364
because it introduces the following problem:
It is no longer possible to close the dialog when it is opened from a gantt view, because the buttons are overridden and they no longer close the window after the action.
In addition to the fact that this fix no longer makes sense at the moment
opw-2591597
closesodoo/odoo#74105
X-original-commit: ed09c16234f240fd52a5cc516465767b736fb40d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.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
A domain used in a ir action in mrp was syntaxically incorrect.
Strangely enough, it was nonetheless accepted by pyjs. However, pyjs
was recently remade, and is now stricter, so evaluating this domain
correctly throws an error.
This commit simply fixes the domain.
Task ID: 2601818
closesodoo/odoo#73670
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- 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>
Steps to reproduce the bug:
- Install manufacturing app
- Create a product “A”
- Create a Bill of Materials for product A > add any product > save
- Create another Product “B” > Create a BOM and add the product “A” in quantity “0” > save
- Click on “BOM Structure & Cost” for product “B” > open the sublevel BOM dropdown of the product “A”
Problem:
An error is triggered because the quantity of the product is "None"
opw-2585033
closesodoo/odoo#73323
X-original-commit: 06c172746f2d2dc8235c6e607342506bf9ef1551
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@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>
Before this commit, the operations for archived bills of materials are
still displayed in the operations list view. This commit adds a domain
on the action to hide them.
task-2417937
closesodoo/odoo#72483
X-original-commit: 1ca17dc750f6b9582acff659d9c32739fa28a1c2
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, suppose we have a scenario like below
Task-A:
Activity-1:
name: Email ( Today )
Assigned to: User-1
Task-B:
Activity-1:
name: Email ( Today )
assigned to: User-2
Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
When User-1 goes through the systray 'Today' filter shortcut he gets both
Task-A and Task-B in the list instead of only Task-A. Indeed currently
activities are not filtered based on current user with its deadlines.
However purpose of systray is to indicate activities current user has to
perform instead of global activities.
After this commit activities will be filtered based on deadlines as well as the
current user. In order to achieve this behavior we needed to pass a domain like
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that purpose we introduced a non-stored compute field with a search
method.
Task ID-2438822
COM PR odoo/odoo#72219
X-original-commit: f4eaf4d8fb2f97240201104dcd4fc7e2674bce02
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
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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>
Currently, across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.
PURPOSE
to update the definition of any many2one on which we applied a 'selection'
widget, and instead use the standard many2one widget with disabled
opening/creation instead.
after this commit,
for each many2one field defined with widget="selection", widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"
Task : 2476488
closesodoo/odoo#68387
Related: odoo/enterprise#17316
Signed-off-by: Aaron Bohy (aab) <aab@odoo.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>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Pratima Gupta