Since https://github.com/odoo/odoo/pull/110737, it is better to use
`_read_group` instead of `read_group` in the backend. In fact, the
public method is less efficient (it computes display_name of relational
groupby, extra order, ...) and more verbose.
This commit replaces these new uses of `read_group` with `_read_group`.
closesodoo/odoo#136381
Related: odoo/enterprise#47826
Signed-off-by: Raphael Collet <rco@odoo.com>
Add a new button Relocate on the stock.quant views.
This button appears when selecting 1+ quants and allows to create a stock.move to another location.
This button also allows to change the package of the quant(s) selected.
LIMITS:
- if a quant has reserved quantities, it will unreserved along with the related smls
- if a package is not fully moved to a new location, the quants selected will be unpacked
- no intercompany moves are allowed
- only available for stock manager roles
Addendum: there are 2 functions with almost identical names:
- action_set_inventory_quantity_to_zero
- action_set_inventory_quantity_zero
renaming action_set_inventory_quantity_to_zero to action_clear_inventory_quantity to make them easier to differentiate
task 3346212
closesodoo/odoo#124501
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
In order to reduce the amount of RPCs in the detailed operation view.
The two wizards to populate the stock move line one2many with lot/serial
number to create are replaced with twos Owl dialogs.
only one RPCs is done to generate the stock move lines values from
either a serial number + a count or a list of lots name
Task : 3256447
Part-of: odoo/odoo#124409
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
When the user click on the 'import' button without lots in the import
serial/lots wizard in stock then this issue is generated.
Steps to reproduce:
- Install Inventory.
- Inventory >> Operations >> Receipts >> create the new Receipt
- Add product to the receipt which has tracking 'by lots',
Save the Receipts
- Click on the button in a tree view which opens the detailed operation wizard,
And click on Import Serial/Lots in it
- In Import Serial/ Lots wizard click on the import button without passing any
value in the lots field
- Traceback will be generated
Applying these changes will resolve this issue.
sentry-4244975188
closesodoo/odoo#125786
X-original-commit: a45aeea3335a96390de0b4b5760683e3081852df
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In this commit:
================
- Added action to 'set to 0' to declare all uncounted quantities to
0 and works like the 'set' action.
- Moved Unreserve, Scrap and Lock/Unlock buttons in action menu.
- Added Better tooltip for status and hide unnecessary status.
- Updated button and field labels.
- Changeed stat button forecast icon.
- Added Dropship setting.
- Added conflict filter in Inventory adjustment tree view.
TaskID - 3150983
closesodoo/odoo#116799
Related: odoo/enterprise#38872
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
With this commit:
========================
- Added a new field `forecasted_qty` in replenishment to display the
forecasted qty based on a selected warehouse in the wizard
- Changed the `route_ids`(m2m) field to `route_id`(m2o) so that
we can apply a specific route for the
replenishment instead of the product's default routes
- Reduced the width of all the fields
- Remove the time from the scheduled date and make the unit field not editable.
- Can see vendor information with info icon field when buy is selected
- Hide the Dropship route from the Route
TaskId : 2579425
closesodoo/odoo#96948
Related: odoo/upgrade#3796
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This replace the generate serial numbers mechanism on stock move by two
new buttons in the detailed operation wizard. One for generate serial
numbers from a sequence and one to import serial/lot names.
Created lots will create the stock move lines automatically as well.
Task: 3256447
Part-of: odoo/odoo#117513
In a flow where the reservation is used (internal transfers, deliveries,
...) adding a new stock move line is now made from the quantities
available in stock. The 'add a line' button in the show detail wizard
trigger the quant list view to directly pick the wanted lot or location
where the stock is available. Only the quantity done is needed to be
updated before the validation.
This commit remove the 'quant reserve wizard' as the behaviour is an
extension of it.
Task: 3256447
Part-of: odoo/odoo#117513
Steps to Reproduce Issue for single picking:
1. Install Sales, Inventory
2. Create an SO and confirm
3. Go to the transfer, assign the done value to be less than demanded
4. Validate the transfer and cancel the backorder
Current Behavior:
There is no exception error on the SO chatter
Expected Behavior:
An exception error should be logged on the SO chatter
Other Info: When cancelling a backorder for a single picking,
the exception error about less quantity than expected is not logged on the SO.
"process_cancel_backorder" does not call _log_less_quantities_than_expected.
As defined in "process", the exception is only logged when validating multiple pickings at once but
one is to backorder but the other is not.
opw-3222508
closesodoo/odoo#121331
X-original-commit: a1dfc58eebd1badc3eea501b23861748b3762d75
Signed-off-by: Mylyna Hy (myhy) <myhy@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Remove links to UoM form since they are useless and lead to unused
forms.
Part of task-3218314
closesodoo/odoo#119381
Related: odoo/enterprise#40153
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
1-create a weight unit 'jm' bigger than reference
ratio 2.47541 rounding 0.001
2-create a stored product uom:'jm' / purchase_uom: 'kg'
3-set valuation method to automated (fifo)
4-create a replenishement for 200 (jm)
5-confirm and recieve the products
6-valuation for that stock move is null
Bug:
computations in the stock module are done with rounding method (half-up)
when computing the unit price the recieved quantity is computed with up
rounding which leads to a mismatch
Fix:
applied the same rounding method on all the Steps
opw-3213997
closesodoo/odoo#118251
X-original-commit: c305942958c73414def47ebd299227999841c6ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
before this commit, there is typo in unit of measure
after this commit, the typo will be corrected and
unity of measure will be updated to unit of measure
closesodoo/odoo#116764
X-original-commit: 11b89fcffe748e6119648dbc32594f0c0bdcf064
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
-Enable multistep routes for manufacturing
-create a MO for 50 products
-In internal transfers from Stock to Pre-production validate
part of the tansfer (20 units) and create a back order
for the remaining qty (30 units)
-create and validate another pertail transfer (3 units)with a back order
for the remaining quantity (27 units)
-create a return for the last validated transfers
Bug:
the default qty for the return is set to -20 where it should be 3
this commit[1] deducts the previous transfers from the returned amount
Fix:
only deduct returns from current transfer
opw-3104699
[1]:https://github.com/odoo/odoo/commit/7b08f0ae0a39e8f575b21e744de16264b6365704closesodoo/odoo#115929
X-original-commit: 0278a4a7ba5cdd7a722e5d576d22820a3ee64308
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@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>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit allows the user to choose which quants to reserve from stock
and the quantity to reserve from each quant, making reservation much more
flexible from the picking form.
In addition, the `reserved_uom_qty` of stock.move.line
is now editable in views to allow for users to change the qty reserved
by existing move lines. When editing the reserved qty, if quantity is not available,
it will reserve only what is available..
closesodoo/odoo#106006
Taskid: 3090913
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently, even if a `default_quantity` is given to the replenish
wizard, that quantity will be overwritten by the product's
`virtual_available`, which defeats the point of setting a
`default_quantity`.
This will allow to bypass that computation when a `default_quantity` is
given to the wizard.
Also makes it return a close action with some custom info when `Confirm`
is clicked, so it's possible to know which button was clicked to close
the wizard.
closesodoo/odoo#113394
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Now, the button "Update Quantity" and the stat button "Qty. On Hand" on
the product's form view will both call `action_update_quantity_on_hand`,
which who can call `action_open_quants` is an advance option is enable
(multilocation, owner or package) or if the product is tracked by lot or
serial numbers.
Also, displays the product's UoM in the `stock.change.product.qty`
wizard and changes its style so labels have more space.
task-3076044
Part-of: odoo/odoo#109511
In `_check_backorder`, changes the condition so it checks if the qty
done is enough compared to the actual reserved quantity (instead of the
demand).
Also, removes an unused bloack of code and makes minor visual changes.
task-3076044
Part-of: odoo/odoo#109511
Refactoring of report_stock_forecasted to owl
Since it wasn't really a report (no print action),
it changed from a report to a client action.
Task: 2885757
See Upgrade : odoo/upgrade#3926
See Enterprise : odoo/enterprise#32116closesodoo/odoo#101247
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
When printing labels in a `ready` picking, if no quantities are set it
will only print the reserved quantities as labels.
Then, if a product has no reserved quantity, it will not have any
move_lines. Which means its initial demand won't be able to be fetched,
and the default behavior will be used, which is to print a single label.
By giving the moves instead of the move_lines to the wizard, we allow to
fetch for moves that have no reservation and print labels correctly
using their initial demand if no reservation is found.
The standard behavior once quantities are set remains untouched.
closesodoo/odoo#106414
Related: odoo/upgrade#4091
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When using the "Apply All" button to make inventory adjustments, a
wizard is opened to choose a name. Then, this wizard calls the quant's
`action_apply_inventory` method but doesn't return it.
But sometime, this method doesn't apply immediately the inventory but
ask for confirmation before (e.g.: trying to "Apply All" with quants for
tracked product but without lot/serial number).
In these cases, the "Apply All" does nothing.
closesodoo/odoo#104307
X-original-commit: e555333cf3ca2511df55105a027ca52e55c13774
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, the `stock.replenishment.info` wizard form
had alignment issues, because of `group` tag, the content was aligned
to the left.
closesodoo/odoo#102505
X-original-commit: 7391961c552214e95e3613be9ab07b61ff86feac
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
Adapts the layout of the backorder wizard to the new grid css for
groups.
Part of task-2985735
X-original-commit: b3f151b3a64312939e5f10c209f54a38b621c8a8
Part-of: odoo/odoo#102495
When validating a batch containing both fully done pickings and
partially done pickings, if we select "No backorder" it will remove the
partially done pickings from the batch.
This is because only the partially done pickings will be considered as
"pickings not to backorder", while the fully done will be considered as
"pickings to backorder".
Then validation is splitted between the two groups of pickings, and
since by the end of the first validation, the batch is not fully done
(since the other group will be validated afterwards), those pickings are
removed from the batch.
This fix aim to consider all pickings that are fully/partially done as
"not to backorder" if this option is selected.
opw-2971574
closesodoo/odoo#102382
X-original-commit: a98b3ff73d1c3d5fda7da3433caf83d58acc2f3c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This pr follow the framework refactoring and translate the widgets
of stock module to wowl.
CountedQuantityWidgetField needs to add an upper listener on input since
the function onChange and onInput of `useInputField` are not overidable.
Json fields had their template in the json send from the server. With
wowl, the template needs to be declare before the setup. So a new wiget
is create for each template and those widgets extends the
a common component that put the json content in the props.
co-author svs-odoo <svs@odoo.com>
X-original-commit: 350a7a0d6f4816ee75676b80a9a5b9769bf80fe6
Part-of: odoo/odoo#101305
This commit fixes the alignment of the message shown when validating
transfer without quantities set.
The `group` tag caused the misalignment as it created a grid class div
and aligned content into div column to the right. since the form just
displays a message and the grid is not needed the `group` tag was
removed entirely.
closesodoo/odoo#102001
X-original-commit: 1a63edc684512330ca64682ec9b626681b6a95cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
Make the choice of available stock effective
(previously the total quantity was always applied).
Show warehouses with the most available stock first.
Show quantity warning only when appropriate.
closesodoo/odoo#101010
Task: 2985735
X-original-commit: 483764412985163168333e2731bed359cc588bbb
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Replaces <p> by <div> and gives a name to the first paragraph to make an
override easier (for now, overrided by `stock_barcode`).
task-2666478
Part-of: odoo/odoo#91807
Minor UX updates in purchase and stock:
Reworded (in stock):
- Default name location "Partner Locations" => "Partners"
- Default result for "Apply All" wizard "Inventory Adjustment" =>
"Quantity Updated"
- Individual "Apply" move reference/name updated for individual quants
(i.e. "Quantity Updated / Confirmed") so that the scheduled date is
no longer included
Removed (from purchase):
- Duplicated menuitems, i.e. "Purchase > Reporting > Purchase" showed
the same thing as Enterprise menuitem and both were being displayed in
Enterprise version. Also updated the no records found help message
since old message appeared to be slightly out of date.
ENT PR: odoo/enterprise#29974
"other" part of b2b task: 2882539
Part-of: odoo/odoo#97109
- reorder/rename/remove menu contents for "Inventory" and "Reporting",
including:
- removed "Forecasted Inventory" menuitem since this view is no longer
considered useful (code for view to be removed in separate commit)
- removed "Stock Moves" (moves report) menuitem
- renamed "Product Move" (move lines report) menuitem => "Moves
History", this will also be reflected in any "History" buttons that
open this view from other views.
- made "Inventory Report" menuitem visible only when applicable (i.e.
multi-location or consignment is active/debug mpde)
- made "Run Scheduler" menuitem only available in debug mode (
main_flow_tour updated to skip scheduler click since general flow is
expected to still the same/work)
Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.
- "Run Scheduler" in mrp menus has also been made debug only viewable as
well to mirror the inventory change.
"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Part-of: odoo/odoo#97109
Current behavior:
If the UoM of a product is not 'units' (e.g 'kg') and tracked by lot.
When trying to print labels 'per unit', some users except one label printed
per 'kg'. But it will actually print one label per lot.
This is not a bug so we are just adding a tooltip to make it clear that only
one label will be printed for lots using UoM different from 'units'
Steps to reproduce:
- Create a product tracked by lots with 'kg' as UoM
- Create a purchase order for 5kg of this product
- Validate the PO and receive the products in 2 lots
- Print the labels "Lot/SN Labels" > "One per unit"
- Confirm, the PDF shows 2 labels
opw-2941942
closesodoo/odoo#98812
X-original-commit: 5b2eb07d3831406146d70150e3a9f61fa3aca7c3
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
- go to Inventory > Operations > Inventory Adjustments
- Select at least one product
- Click on Request a count; A dialog box containing a form should appear
- Select a user other than the current user
- Make sure to check "Set Current Value"
- Click "Confirm"
You should see that the user you selected is not the one assigned for
the count. Instead, the count is assigned to the current user.
This is happening because currently, calling
`action_set_inventory_quantity` also sets the user as the current one
if the quantity is not already set.
opw-2924694
closesodoo/odoo#96914
X-original-commit: f2b79bc4c6198aacca33eea8905fd62c629706a1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Avoid leaks in case of exception.
closesodoo/odoo#93993
X-original-commit: 1a1a10b7ce53f24eabed3e3a38f34b354d2d1911
Signed-off-by: Christophe Simonis <chs@odoo.com>
Steps to reproduce the bug:
- Go to inventory > Reporting > Inventory report
- Click on “Inventory At Date” > Select a date > Confirm
Problem:
The date is not displayed in the breadcrumb, like in inventory valuation
opw-2791566
closesodoo/odoo#88943
X-original-commit: d7a09a257bfb3690a4b580ed26bbf2894a74a6c3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The history of the replenishment info may be empty while it should not
To reproduce the issue:
(Set your device on January)
1. Process a delivery for product P
2. (Inventory > Operations > Replenishment, create a new one for P)
3. Click on the information icon (I) of the P's line
Error: The sales history does contain anything
When calling `relativedelta`, `month` is considered as an absolute value
and will replace the corresponding value while `months` is a relative
value and will be added/subtracted to the corresponding value.
OPW-2740123
closesodoo/odoo#84881
X-original-commit: c87fea0916b61cb4b0c37f3fe2ddad8359e6aeb2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Rémy Voet (ryv)