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>
Usecase:
- Product A 10 units in stock
- Do a planned transfer of 7 units to customer
- Reserve
- Do an rpc or execute code to call copy on the stock.move.line
It will result with 2 sml that have 14 units reserve and 7 units
reserved on stock.quant
It's the same result if you create twice the stock.move.line without
updating the stock.quant at the same time. However in stable we
try to only use _update_reserved_quantity on stock.move or some
override in create/write method for 'done' stock.move.line in unlock
cases.
So we never use the copy in stable and define the basic behavior as
'we don't copy the reservation' could prevent some usecase where
the update on the stock.quant is forgotten after.
closesodoo/odoo#74489
X-original-commit: e5041ee1d9b5036cab55f4332977aeb818a3b1e1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In the popover date and float are wrongly formatted. This PR format date and float according to the user language.
closesodoo/odoo#74032
X-original-commit: a46f8d66965cce5759ca4af17c71b0aa18eda9ec
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Step to follow
Do not activate multiple companies, keep it standard to 1
Enable multi-locations and routes
Create a second location for raw materials and a new Receipt operation type with the new location as destination location
Go to routes -> edit the buy route -> add a second rule with "Buy" and save.
Cause of the issue
When a stock rule is created from a stock route, the default company
cannot be found as there is none assigned to the stock route.
Solution
Override the default_get method for stock rules in order to use the
current company
opw-2578984
closesodoo/odoo#74380
X-original-commit: 2b8d7d76adceeca16f97e394a6734bb5be633c3b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.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>
replace t-field with t-esc so it's support "or" operation
opw-2589887
closesodoo/odoo#74297
X-original-commit: 193946ff266ee947c7ca976e773849526ed119b1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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>
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>
- Define a [DEMO] prod with tracking by SN and add some SNs
- Activate "use existing lot/serial number" on the receipt picking type
- Create a purchase order for [DEMO]
- Process the receipt in the barcode app:
* Scan the product
* Scan the SN barcode
* Validate
User will get an error.
It seems that Odoo is trying to create this SN instead of
matching the existing one
opw-2474347
closesodoo/odoo#73610
X-original-commit: 09a1252b8a5bc194ffccd6c2437985328d08ba08
Related: odoo/enterprise#19632
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.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.
Currently the replenishment report look for forecasted quantity of
product today. It means that for a product if the delivery is planned
for today the forecast will be -1, at j-1 it will be 0. However for the
majority of use case, products take days to order and arrive.
Example:
- Product A, purchase delivery time 5 days.
- You are the 01-01-2021 and create a SO for 10-01-2021
Currently:
- Product will appear in the replenishment report the 10-01-2021 and
you will receive it the 15-01-2021. So you are late to deliver your
customer.
Desired behavior:
- Product appear in the replenishment report the 05-01-2021 and if you
order it directly you will receive it the 10-01-2021.
If you want to have more time to deliver than one day, security lead
time are there for it.
However the usecase like:
Product arrive in 2 months and you receive it in 3 days, the product won't
appear in the replenish report anymore since the forecast in 3months is
0
It could happens that more product are missing in 3 months than today,
so the system could have more delivery lead times and forecast at date
to compute -> be slower. In that case a parameter could be
added to skip the delivery times computation for each product/warehouse
and just display the forecast in 3 months and let user compute their
schedule themself.
closesodoo/odoo#73737
X-original-commit: f988b7629f8f54e8e3f48bf76e6af9d97b4f47da
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
During the creation of the second warehouse,
a warning popup to tell that it will activate also the
Storage Locations setting even if this one is already activate.
Only raise this warning if the is Storage Locations not activate yet.
task-2558097
1. When creating a putway rule, default location_in_id is receipt
destination location (in case of single warehouse).
2. When changing location_in_id, copy value to location_out_id.
3. Allow to hide some fields and change of some labels.
4. Move location tab to a smart button.
closesodoo/odoo#69580
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Move candidate.unlink out of the for loop to unlink
records in batch.
Remove to_unlink_candidates.move_id from move_to_recompute as
move_line.unlink() will trigger recompute of their move's state.
---
opw-2585598
closesodoo/odoo#73160
X-original-commit: e2e51c15d082ec17743b73ad1422e4a223268be9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
before this commit: create_text was passed in node options and due to which it
was not parsed by translate.py, pass add-label as attribute on field so that
translate.py parse it and it is translated.
after this commit: create_text will be passed as field attribute instead of
node options.
task-1923433
closesodoo/odoo#59713
Related: odoo/enterprise#19418
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.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>
Usecase to reproduce:
- Setup a maximal of 100units in a storage category
- Set the storage category on shelf1 and shelf2
- Create two putaway rule from wh/stock to wh/stock/shelf1 and
wh/stock/shelf2
- Create an immediate receipt
- Set 100 units of product on stock move line (should suggest shelf1)
- Put in pack
- Create a new stock.move.line in the receipt.
It will suggest the same location than in the first line despite the
location is the same. It happens because the check look only at quantity
reserved in the location but the user could have create new line without
quantity reserved.
This commit, take the maximum between the quantity reserved and the
quantity done to give an estimation of what could happens.
closesodoo/odoo#72689
X-original-commit: d9d98d4264295532f2248c6072aabbd72f32f054
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When consulting a delivery slip, a portal user won't see the lots/serial
numbers used.
To reproduce the error:
(Need demo data)
1. Create a product P
- Product Type: Storable
- Tracking: By Lots
2. Update its quantity
3. In Settings, enable "Display Lots & Serial Numbers on Delivery Slips"
4. Create + Validate a SO:
- Customer: Joel Willis
- Lines: 1 x P
5. Validate the delivery
6. Log in DB with 'portal' (Joel Willis)
7. On SO, open the Delivery Slip
Error: The product's lot is not mentioned
Here is the condition to display the lot:
https://github.com/odoo/odoo/blob/c61db20204700a375f7005f50f95b44a60c3bb70/addons/stock/report/report_deliveryslip.xml#L77-L79
Problem is that portal users are not part of
`group_lot_on_delivery_slip`
When enabling the option, the groups are updated here
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L570-L576
`implied_group` (which is `stock.group_lot_on_delivery_slip` in our
case) is added to `groups.implied_group`
The variable `groups` comes from `classified`, which is defined thanks
to method `_get_classified_fields` (see L553 in above code block)
And here is an extract of how this method works:
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L460-L462
At some point, it checks if the field `group_lot_on_delivery_slip` has
an attribute `group`. In case `group` is not defined, the group
`base.group_user` is used. This is the reason why, by default, the
option is enabled for internal users only instead of all users.
Therefore, we just need to define the attribute `group` to the field
`group_lot_on_delivery_slip`
OPW-2558761
closesodoo/odoo#72656
X-original-commit: 475b35397b7254012a082a1206c478084c069857
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit: when writing something in signture field in stock.picking
and enable signature field in listview throws traceback.
After this commit: when signature field is set and enabling it in list view
will not throw traceback, traceback was generated because boolean field
was applied on Image field, to fix it simply remove boolean widget on
signature field.
task-2570929
closesodoo/odoo#72479
X-original-commit: 2679b6721f74ad26f790285855102a44e30fac71
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Improve res.patner._compute_on_time_rate performances by calling
mapped('quantity_done') once on all the order_lines.move_ids.
Moving it out of the for loop allows to befinit from the performance
gains of the read_group call in stock.move._quantity_done_compute.
closesodoo/odoo#72422
X-original-commit: 2841525a3a2f1273783874947884b57494def849
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
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
To prepare the rewriting of the webclient in owl, we move all
current js files of web in a legacy/ folder. This folder will
eventually be removed, as soon as each file it contains will be
converted to owl and moved to the proper place in the new file
structure.
Some changes in the delivery slip layout:
- For delivered products, replaces the Quantity column by two other
columns: Ordered and Delivered;
- Shows the non-delivered products even when the delivery is done and
haven't any backorder.
task-2373833
closesodoo/odoo#61366
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, on the delivery slip, the quantities aren't
displayed at the same way if we display the move ones or move line ones.
In the first case, we print directly the value from a record, so the
float decimal is correclty placed when the float is converted into a
string.
In the second case, we get the value from a dict, so there is no
conversion and the float is simply translated into a string.
For example, for 2 qty.:
- For a move it display 2.00
- For a move line it display 2
task-2373833
A security has been added to avoid an infinite loop due to custom
code if the failing orderpoints were not correctly return in order
to exclude them from the set to retry.
However after a first batch if some orderpoints were correctly exclude
orderpoints_exceptions will not be empty and during the second iteration
failed_orderpoints will be always filled from exceptions of previous
iterations and the infinite loop will not be detected.
opw-2525893
closesodoo/odoo#71938
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently there is an action_assign_serial_show_details button within
the detailed operations form of a serial tracked product move.
Unfortunately there is no way to undo the assigning/creating of move
lines from this action (including via clicking the "Discard" button).
This can lead to a lot of manual work (e.g. 500 SNs produced instead of
50) to remove unwanted move lines. To remedy this, we add in a button
to unlink all of the move's move lines whenever the Assign Serial
Numbers button is visible.
closesodoo/odoo#71831
Task: 2426281
X-original-commit: a6191c43001f961c20b5b4d32e1fcb218df69d17
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
1. Add product category in inventory report.
2. Default quantity when creating a transfer switched to 1 instead of 0.
3. Remove the reorganize lines step in purchase tour (there is only 1
line).
closesodoo/odoo#69483
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider that Reservation = manual (Inventory>Configuration)
- Let's consider two interna users I1 and I2 with the following access rights:
-Sales: own document only
-Inventory: user
- Login as I1 : Create sale order SO1 to sell a storable product P
- Confirm SO1 to create delivery order DO1
- SO1's Sales Person should be assigned to I1 and DO1's status should be "waiting"
- Login as I2 : Create sale order SO2 to sell P
- Confirm SO2 to create delivery order DO2
- SO2's Sales Person should be assigned to I2 and DO2's status should be "waiting"
Bug:
When I1 or I2 tried to access DO1 or DO2, an access error was raised due to personal order line record rule
opw:2530101
closesodoo/odoo#71725
X-original-commit: ab2663ae0e6f29540b8b8e8ef8b6178ecbd9d7b8
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: William Henrotin <Whenrow@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 -> Fieldss
1) stock.location -> comment
2) stock.picking -> note
Task Id: 2499504
X-original-commit: 96f5316a219568add44bee528245c2c8e49c3bbc
Currently, to identify records based on state, in most of the list views we
use 'badge' widget on 'state' fields which can be decorated as needed.
However, for the list views, best approach would be to also add list
decoration along with 'badge' widget so that the whole line is colored
and it's easy for user to 'scan' the information
This commit improves the behavior adding decorations to several list-views.
To check the list of changes, kindly see the task specification
Apart from that, this commit also improves label of the module state from
'Not Installed' to 'Uninstalled'.
TaskID-2527119
closesodoo/odoo#71367
Related: odoo/enterprise#18587
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
General improvements of the new Inventory Adjustment mechanism, among which:
From the Inventory Adjustment page
- A new inventory_quantity_set Boolean field is used to hide the Counted Quantity when not set instead of showing 0.
- Possibile to set 0 as a Counted Quantity directly (not using the set button).
- Allows to provide a name for the Inventory Adjustment when using the Apply button at the top of the tree view. This name is applied on the corresponding stock moves.
- Add warnings when trying to Apply/Set on multiple records when some records are not set/already set.
- Highlight lines when there is a mismatch between Quantity / Counted Quantity / Difference. If the user still tries to Apply, shows the option to either keep the current Difference or the current Counted Quantity for all records.
- Set the user when directly inserting a Counted Quantity (before only when using the Set button)
- Add the possibility to import records.
- Add "To Apply" filter.
- Add a 'Reset' button at the top of the tree view for multiple records.
From the Update Quantity page of a product
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
- Pre-fill a default location (Last used location for tracked products or default destination location in single WH environment)
From the Inventory Report
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
closesodoo/odoo#71199
Task-id: 2495664
Pr-community: 71199
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
On a delivery, when changing the initial demand of a stock move, if its
value was 0 and becomes > 0, its state will be 'Partially Available' but
the reserved quantity will still be 0.
To reproduce the error:
1. Create 2 products P01, P02
- Product Type: Storable
- Qty On Hand: 1
2. Create + Confirm a SO with 1xP01 and 1xP02
3. Open SO's delivery
4. Unlock, set P01's initial demand to 0, Save, Lock
5. Unreserve, Check Availability
6. Unlock, set P01's initial demand to 1, Save
7. Click on PO1 line
Error: The stock move state is "Partially Available", but the initial
demand is 1 and the reserved quantity is 0. It should be "Waiting
Availability"
On step 5, since the wanted quantity of P01 is 0, the state of the stock
move becomes "Available". Then, when increasing the requested quantity,
the state automatically becomes "Partially Available" because the module
does not consider the case where the state is "Available" with a
reserved quantity equal to 0.
OPW-2488580
closesodoo/odoo#71445
X-original-commit: 05b6dfa0b1e4daf46d569c2e0a330b35e6437f8d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The `groupby` function is used to builds groups of(product, lot) keys
and their corresponding move lines / quants. `groupby` groups
*consecutive* keys, which is why the input is sorted by the keys.
`sorted` on recordsets keys will not sort as we would expect in this
particular situation, as the comparison operators on records act as
Set Comparison operators on the record ids, i.e. to compare the sets
superset/subset relationships:
```
>>> env["product.product"].browse(1) < env["product.product"].browse(2)
False
>>> env["product.product"].browse(1) < env["product.product"].browse([1, 2])
True
```
Example of sorted on stock.move.line records, where the product id 7313
is both in the slots 4 and 12 instead of being consecutive:
```
>>> [l.product_id.id for l in sorted(lines, key=itemgetter('product_id'))]
[7436, 7437, 7352, 7423, 7313, 7351, 7423, 7424, 7320, 7398, 7312, 7352, 7313, 7436, 7437, 7442, 7443, 7320, 7423, 7424, 7318, 7396, 7368, 7355, 7316]
```
Now when we group by id the 2 ids 7313 are correctly placed together in
slots 1 and 2:
```
>>> [l.product_id.id for l in sorted(lines, key=attrgetter('product_id.id'))]
[7312, 7313, 7313, 7316, 7318, 7320, 7320, 7351, 7352, 7352, 7355, 7368, 7396, 7398, 7423, 7423, 7423, 7424, 7424, 7436, 7436, 7437, 7437, 7442, 7443]
```
This commit aims to sort by "id" of the related records, to ensure the
same (product, lot) couples are consecutive.
closesodoo/odoo#71276
X-original-commit: d53d8bdf789e8f79ea4d531d944686abb59d6a26
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
1. activate routes setting + multi-step incoming shipments (2 or 3,
doesn't matter)
2. create an immediate transfer receipt
3. add a done quantity (optional: validate)
4. open corresponding 2nd step internal transfer
Expected result:
- amount done in immediate transfer receipt will be demand of internal
transfer
Actual result:
- demand (and all other values) will be 0
closesodoo/odoo#68885
Task: 2492994
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
"Set Quantities" button does not make sense to show for immediate
transfers since there are no quantities to reserve, therefore we hide
it.
Task: 2492994
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>
Pratima Gupta