Before this commit
==================
MO not closed even when flexible consumption is confirmed from the tablet view.
If in some operations less or more commodity is consumed then when we click on
mark as done and close mo, it only generates consumption warning wizard and the
state of MO is still in to_close and not done, since the backorder wizard is not
generated.
After this commit
=================
MO is closed along with consumption warning wizard and backorder wizard.
TaskID - 3192078
closesodoo/odoo#119491
X-original-commit: 8bd83439e3b5ae547e4fc2e21677ab8e925cb73a
Related: odoo/enterprise#40181
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The finished move of a production order should be deleted if we change
the product to avoid having draft stock move detached from any business
documents
closesodoo/odoo#118957
Task: 3172098
X-original-commit: 4478560d7769a8a795a94aead875e02d1394dd71
Signed-off-by: Adrien Widart <awt@odoo.com>
Some demo data bill of material have workorder operation. Trying to use
them without the workorder setting activated will give an error on some
fields not instantiated.
This commit activate/deactivate the operations depending on the
workorder setting.
opw - 3229621
closesodoo/odoo#119254
X-original-commit: aaba4eb4deb3f9e10fd611924c5a24680d633537
Related: odoo/enterprise#40092
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue :
- When mass producing a tracked product, an User Error is raised on validation of splitted MO.
Reproduction :
- Create Serial storable product "Component A", Lot storable product "Component B", Serial Storable product "Finished Serial Product"
- Immediate Transfer 10 * "Component A" and 20 * "Component B"
- Create a BoM for "Finished Serial Product", consuming 1 * "Component A" and 2 * "Component B"
- Create a Manufacturing Order for 10 * "Finished Serial Product" and Confirm :
- Click on "Mass Produce", Set "First SN", Generate all the serials and Apply
- Click on "Produce All"
Task : 3274962
closesodoo/odoo#118592
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
Problem:
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
closesodoo/odoo#119172
X-original-commit: 227d038efbadf25e3a7be7cceedd9159b71162a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When Operation is 'Archive' and it is still in use as 'Consumed in Operation' in
bom while creating Manufacturing Order and confirming it, KeyError will be
generated.
Steps to Produce:-
1) Create a new product, create bom for that product, add components, and
create or add at least 2 operations to the BoM.
2) In the components of 'Consumed in Operation' add the newly created operation.
3) Now, Archive one operation.
4) Create new Manufacturing Order with a newly created BOM
5) Try to confirm it.
KeyError will be generated.
By applying this commit, if there are no operations left after archiving
one linked to the component then the server error won't occur
sentry - 4042593205
closesodoo/odoo#119098
X-original-commit: ba2364f9188ff44c68a1b86d5029884815a33216
Signed-off-by: Tiffany Chang <tic@odoo.com>
To reproduce:
1. Manually create lot "0000001" for a lot product
2. Create a MO for this product and click generate-serial button.
Validation error raised since we are trying to generate lot/sn "0000001"
again.
When useing action_generate_serial, ir.sequence always try create a
lot/sn in form "00000dd". If user already created the same one, the
generation will fail.
We already tried to avoid this issue for sn in _get_next_serial() by
finding the latest sn and create new one base on it.
To fix, we also allow _get_next_serial to be applied to lot.
Part of Tast-3187003
closesodoo/odoo#118481
X-original-commit: dc69748ea2698077782d839cf7da48e987f17ffc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a reception picking was created to resupply a component (without
using a purchase order), the picking was correctly linked in the MO
Overview, but the date was set as "Not available" as the planned date of
the picking wasn't read.
Also adds the color scheme for pickings states for the Overview.
Part of task-3217757
closesodoo/odoo#118023
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Following odoo#116983, there's a new line indicating products still in
transit in the Forecast Report. So we can use it in the MO Overview to
better show when some products are in stock but not yet available.
Task-3217757
Part-of: odoo/odoo#118023
When opened from the MO Overview, the uom in the wizard is the one from
the product's form.
The problem is that the quantity given to it is in the overview's line
uom. So instead we add an already converted quantity to the `to_order`
lines.
Part of task-3217757
Part-of: odoo/odoo#118023
While the cost of a line related to an RFQ was saved, it was not used in
the displayed costs.
Also, it used the wrong cost (don't need to factor in taxes), not did it
factor the quantity used in the cost.
Fixes as well the MO Cost for partially in-stock products.
Part of task-3217757
Part-of: odoo/odoo#118023
When a product was used more than once in a MO, then replenishment lines
were duplicated in the MO Overview, as it didn't check which forecast
line was already used, nor the total quantity it should have for this
replenishment.
Part of task-3217757
Part-of: odoo/odoo#118023
Instead of using the `date_start` of a MO to check if the MO will be in
time for the Final product in the MO Overview, use the `date_deadline`
if it is defined instead.
Part of task-3217757
Part-of: odoo/odoo#118023
The MO Overview would display the wrong uom in the replenishments lines
of the MO Overview. Since the data was pulled from the forecast report
(which displays it in the product's uom), it could not coincide with the
ones used in the MO.
Part-of: odoo/odoo#118023
Following 6825c44, the `produce_delay` is now defined on the bom rather
than on the product, thus raising a traceback when trying to access it
from the product.
Part-of: odoo/odoo#118023
Product availabilities and their related replenishments are no longer
relevant when displaying a completed MO. Therefore, those columns are
disabled in the Overview when the the MO is either done or cancelled.
Part of task-3217757
Part-of: odoo/odoo#118023
The free quantity was only checked to see if there was a reason to order
more quantity in the MO Overview, but wasn't counted in the missing
quantity to order, leading to having a `to order` line with bigger
quantity than required.
Part of task-3217757
Part-of: odoo/odoo#118023
Steps to reproduce:
Go to Manufacturing App
Click on some MO
When pressing the 'ALT' shortcut key the Scrap and Cancel tabs offer the letter 'Z'.
According to this spreadsheet
the scrap action (line 79) should be assigned to shortkey 'Y'
OPW-3202893
closesodoo/odoo#118075
X-original-commit: 577a467ca757b1d0c02e13e0710f2c0216c1e6a0
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: malv-odoo <malv@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, the field node id (`field_id`) uses the field name
for the first occurrence on the arch, and add an underscore and a number
for the rest of the occurrences. This can create inconsistencies when
sombody assumes that the field_id is equal to the name, and don't take
into account the possibility of multiple occurrences.
Now, a unique id is created since the first occurrence, this remove all
ambiguity between the id and the name.
Part-of task-id 3179751
closesodoo/odoo#117799
Related: odoo/enterprise#39511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
duration_percent field is a stored integer.
In postgresql, integer are 4 Bytes long, which create a range of -2147483648 to +2147483647.
With a small duration_expected, and a big duration, we can easily break these limits.
OPW-3253333
closesodoo/odoo#117744
X-original-commit: 97892d04341a2cbbe07e4db6442a451b0cf0b164
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
Steps to reproduce the bug:
- Go to the warehouse settings:
- enable “3 steps for manufacturing”
- Create a storable product “P1” with 2 BoM
- Create an orderpoint:
- Preferred route: Manufacturing
- Product: “P1”
- BoM: select the second BoM
- To order: 1
- Click on the “Order once” button
Problem:
The manufacturing order is created with the first BoM instead of the
second.
As we are in 3 steps, the “run_pull” function is triggered first, with
values prepared from the orderpoint so the bom is well set:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_orderpoint.py#L515-L523
Then the “run_manufacture” function is triggered but with vals prepared
from the move, not from the orderpoint, so we lose the BoM information
that the user has selected:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move.py#L1334-L1340
opw-3217945
closesodoo/odoo#117732
X-original-commit: 2371cd29e1c0cfa54b682b2100b9db7f5633a7b4
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
1. Install [Manufacturing] on Apps
2. On [Settings]>[Manufacturing]
- toggle on [Work Orders], [Quality] & [Quality Worksheet]
3. Go to Manufacturing
- Work Centers (a.k.a WC) Overview should be visible
- if no W.C. by default, add from [Configuration]>[Work Centers]
4. click on the 3 dots at the top right corner of each WC card
Issue: ugly layout
Fix: restore the style
affected branch: saas-16.1 up to master
closesodoo/odoo#117695
X-original-commit: 40a5d29d9b5b4070269175a83866837c7725b8c9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Add the group 'mrp.group_mrp_routings' on the main user to make field
'workorder_ids' visible in the form view of 'mrp.production'. Many
tests use that view, and require the subviews of that field to be
present in order to create records.
closesodoo/odoo#116779
Related: odoo/enterprise#38858
Related: odoo/documentation#3968
Signed-off-by: Raphael Collet <rco@odoo.com>
With this PR, the `digest_data` template has been changed, so the `digest_tips`
is not compatible with the new changes.
This commit changes the `digest_tips` data to be compatible with the new changes.
Below are the modules affected:
- account
- crm
- digest
- hr_expense
- hr_timesheet
- im_livechat
- mrp
- project
- purchase
- sale_management
- stock
- website
task-2717426
Part-of: odoo/odoo#89549
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a second warehouse WH02
- Let WH01 be the existing one
3. Create two storable products P_compo, P_finished
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operation Type: "WH02: Manufacturing"
5. Create a MO:
- Product: P_finished
Error: Once the product is set, nothing defines the BoM (and
therefore the components, picking type, and so on)
When opening the MO form, the picking type is directly defined with
"WH01: Manufacturing". Therefore, when looking for a BoM, we use
that picking type as criteria -> we will not find the BoM of step 4
Notes about the fix:
- Small behaviour change: once the picking type is set, it does not
change automaticaly (whatever the BoM is)
OPW-3122384
closesodoo/odoo#116515
X-original-commit: 93381af48e20a10c3fded88f010f89cd03cc5131
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps:
- Enable `Worder orders` in Manufacturing settings
- Create a manufacturing order with a bill of materials and workorder operation set and confirm
- Go to the workorder tab and start, then finish after few seconds
- Update the real duration
- Try to save
Issue:
User Error
Cause:
When writing on a `mrp.production` object we check if the production is still planned and if, it try
to plan all the workorders which are not done or cancelled. But in our case all the workorders are done
so it try to write to an empty object.
opw-3230310
closesodoo/odoo#116122
X-original-commit: 674f37fbbaa4a0d7f34f8d75d16dd11373815932
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
while we are creating a new record of the mrp.workorder from the editable list
view (mrp_production_workorder_tree_editable_view), we are getting the singleton
error, as it is not taking any production record.
by applying this commit, it will resolve that singleton error
sentry - 3982694755
closesodoo/odoo#115862
X-original-commit: 91e7d36a48d58aea1d63999dd150b543983aeba1
Signed-off-by: Tiffany Chang <tic@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Following 873d6d9, the forecast would now redirect correctly to the
corresponding bom when a `product.product` was used.
The issue is that `bom_variant_ids` doesn't exist on `product.template`,
raising a traceback when the forecast was accessed through the product
themselves instead of their variants
closesodoo/odoo#115776
X-original-commit: 93f6bf8dc5319082579a2b4ecbc48b482b81cc9d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Existing constrains method had a bug in it, so let's take this
opportunity to replace it with the more efficient _sql_constraints
check.
closesodoo/odoo#115613Fixes: odoo/odoo#92799
X-original-commit: 0751a0e27b653d5c471120ba7f5dea37a3f30a28
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
No need a common file for 3 tests. On top of it contains
global variable and a lot of indirection, making it impossible
to read.
Also before the quant reservation commit, a savepoint was call
during the action_assign and trigger a flush and recompute all.
Since it has been remove, it's computed during the first read on
it, that's during the mark as done and since the MO state is not
draft it will keep the default value (False). Call it after create
to trigger the computation at the right time.
+ a bit of linting
closesodoo/odoo#115328
Related: odoo/enterprise#38207
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
The value of the timer was wrong when timesheeting with multiple employees
at the same time.
The problem was that the compute duration already takes the current timesheets
into account. So the problem was that we added some time
that was already in the duration
task id : 3216277
closesodoo/odoo#114901
Related: odoo/enterprise#38007
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit add a mass start and stop buttons that allows to start
or stop multiple workorder at the same time.
Starting a workorder checks if the user needs to be logged and
if the workorder is not blocked.
This commit also change the appearance of the mark as done button
task id : 3216277
Part-of: odoo/odoo#114901
Stpes to reproduce the bug:
- Create a storable product “P1” with 2 variants:
- Color: Red and blue in this order
- Create a BoM for each variant
- Create a SO:
- select the product “P1 - blue” → the second variant
- Click on the forecast button → manufacturing forecast
Problem:
The BoM overview is showing the wrong product variation because it pulls
the default BoM of the base product (always the first variant from the
list)
opw-3166074
closesodoo/odoo#115421
X-original-commit: 873d6d921c3955b707d10826a898ae405f296531
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Fix the isuue that manual consumption is not correctly calculated when
backorder/split/merge.
closesodoo/odoo#115429
X-original-commit: d72ddd80d8a6aaa808c07db685972a1c05e8d6a4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
when plan workorder, cancelled/done workorders are taken in to account
when they block current workorder. In this fix, we ignore then when plan
workorder.
Task-3126569
closesodoo/odoo#114940
X-original-commit: 1b629659cb651c62fdd2c880ae591f9a9bb2e1eb
Related: odoo/enterprise#38020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Wrong key was used to display the unit of measure in the BoM Overview,
leaving the cells empty.
closesodoo/odoo#114934
X-original-commit: a6eba909a8f2ab07ddb239b4b64e82d51f724e66
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Before this commit, updating a purchase quantity of subcontracting
product will try to not merge the new and old move to keep the two chain
separated as much is possible and avoid side effects (receipt move,
subcontracting moves, resupply moves). Some were merged, some cancelled,
...
This had two issues:
First, not merging the quantity was not guarantied
as you can specify you don't want to merge them with others but it's not
possible for a stock move to say to any other move do not merge with me.
Second, by not merging the receipt moves, we duplicate every other
object on the chain. This pollute the database uselessly.
opw-3147446
closesodoo/odoo#114739
X-original-commit: 0b1bcfacb13c7de480f30015b91db11ed03f2dfe
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Rahul Reddiar