currently the returned warning from the sale, stock and repair apps are not translatable to user languages.
this pr makes the string's translatable and correct the grammer of the warning.
closesodoo/odoo#108379
X-original-commit: 217115e68d117d7cf1eeb94794118819d6082547
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The delivery slip of a picking with an operation type where 'Move Entire
Packages' is enabled doesn't print the delivery address
Steps to reproduce:
1. Go to Settings > Inventory > Operations and enable 'Packages'
2. Go to Inventory > Configuration > Warehouse Management > Operations
Type
3. Open operation type 'Delivery Orders' and enable 'Move Entire
Packages'
4. Create a new transfer with operation type 'Delivery Orders', add a
delivery address and a move and save
5. Mark as todo, put in pack and validate
Solution:
Always use the partner of the `move_lines` in the delivery address
Apply the same logic to the address used in the picking operations
report
Problem:
The delivery slip always uses the partner of `move_ids_without_package`
but there might not be any if the picking uses packages
opw-3091139
closesodoo/odoo#108465
X-original-commit: d113e0d7a5aa1c1f6bb933771cda4a3365361ba0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
In this commit, we will convert all the customisations of the list view
consist in adding an always present button in the control panel that
performs an action/calls a model's method.
To do this, we will use the new display="always" parameter applicable
to buttons in the header of list views. This allows us to define a
button that is always visible in a list view.
closesodoo/odoo#106519
Taskid: 3082303
Related: odoo/enterprise#34387
Related: odoo/documentation#3044
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
Steps to reproduce :
- Create two products
- Create a planned internal transfer with one of each product from Stock
-> Location A
- Hit "Mark as todo"
- Hit "Put in pack"
- Validate the picking
- Create an new planned internal transfer, with the same products and
quantities, but from Location A -> Location B
- Remove the destination package for one product.
- This will remove the destination package for all products in the same
package.
When unlinking a package level, it will unlink all moves and move_lines
at the same time. Problem is that if a single move_line is updated in a
picking where multiple move_lines are in the same package, it will
unlink it for all the move_lines instead.
closesodoo/odoo#107448
X-original-commit: 9dcbc420f50ece3356dff57cbdc467c7893ff2c2
Signed-off-by: Tiffany Chang <tic@odoo.com>
The delivery slip of an outgoing picking prints the warehouse address
instead of the delivery address (which should be displayed as it may
be different from the customer address)
Steps to reproduce:
1. Install Contacts and Inventory
2. Open Contacts and add a delivery address named "delivery" to contact
Azure Interior
3. Go to Inventory > Operations > Transfers
4. Create a new transfer with:
- Contact: Azure Interior, delivery
- Operation Type: San Fransisco: Delivery Orders
- Product: Large Cabinet
5. Save the transfer and print the Delivery Slip
6. The warehouse address is displayed and there is no info about the
delivery address
Solution:
Add a method to know if we should print the delivery address. We should
print it if the picking has a delivery address and it is of type
outgoing (or if it's a dropship)
Problem:
Printing the delivery address when the package partner is different from
the picking partner is wrong because the delivery address might be
different from the customer address
opw-3064203
closesodoo/odoo#107355
X-original-commit: ec929f787f629940cd38a4ed25e5012335e2483d
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit changes popover widget such that instead of altering the
popover component during app lifecycle to make dynamic
popover templates, use `t-call` to call template passed in props.
closesodoo/odoo#107286
X-original-commit: f1a9de85c19a53c9516cac44de6cbaf53d850842
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Commit 168cbe66bee7824bdf389de5c6c680342e27bc6d removes fields
with the 'groups' attribute from views when the user is not part
of the groups.
This is the case of product_uom_id in stock_scrap_form_view2,
but the field is mandatory for scrap creation,
therefore we use the unit of measure of the scrapped product
when not provided (as this is the case when uom are not checked).
Task: 2985735
Part-of: odoo/odoo#104062
Issue:
At anypoint we should be able to call the method "_set_lot_ids" from stock.move on moves that are already done and the quantities should not change.
This is not the case for lots that get their quantity changes to 1 as if the product was tracked by serial number.
This commit should be seen a a complement to the commit: https://github.com/odoo/odoo/pull/79565
Fix:
Check the product is tracked by SN before trying to change the quantities to 1.
Related ticket: 2689724
closesodoo/odoo#91769
X-original-commit: b56f96d6d63435d629f0a8137a038dacaf0782fe
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
On the ticket https://github.com/odoo/odoo/pull/101547 a constraint was added to prevent the user from changing the product type if some moves have already been made.
This was done because changing the type creates inconsistencies (like breaking the valuation).
However, it currently only checks if there are moves on the current company, when it should check in all companies.
This can be fixed by adding sudo.
closesodoo/odoo#106346
X-original-commit: e8bb4a50aa0d3829d590858784e2c573118bc392
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When we have too many products from orderpoints we cannot compute the
forecasts for all at once. Otherwise we may get a MemoryError. Here we
iterate by chunks.
This error was observed on upg-417045, where there were 381927 prodcuts.
closesodoo/odoo#106196
X-original-commit: feea4e5f147b3b26cbc032daaf0ceabbe3417912
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
This PR
Reverts the change in #105425 as the code is redundant see Discussion
Fixes the issue and explain the details as it doesn't get triggered from
inventory adjustment view but from current stock view in location X.
Steps to reproduce:
- Install inventory
- Activate storage locations
- Allow import in Locations/WH/Stock/Current Stock
- Export the current stock of WH/Stock
- Change the Location in the file to WH/Output
- Import the modified file
In the Location/Current stock view, the _load_records_write/create methods are bypassing the allowed_fields checks in the def create/write since this check only occurs when _is_inventory_mode() = True. This can cause inconsistencies if there are quants reserved. To solve the problem we set inventory_mode to True so that the method returns True and the checks are triggered (and prevent these inconsistencies).
Task id: 3007499
closesodoo/odoo#106077
X-original-commit: 7240c5b19e9c06fe22a929ca3ec83115c29a5c7f
Related: odoo/enterprise#34153
Signed-off-by: Tiffany Chang <tic@odoo.com>
Avoid raising an error if `warehouse_id` isn't in the vals.
Steps to reproduce :
Inventory -> Configuration -> Operation Types -> Create a new Operation
Type.
Then, either the warehouse field is empty because it doesn't appear due
to the multi-warehouse not being activated yet, or its saved when the
field is empty.
Changes the onchange into a compute to have a better consistency between
the frontend and the backend.
Part of task-2985735
X-original-commit: 2421619ecb0c2076f1d1694a30a724c92ff94c87
Part-of: odoo/odoo#106039
scrap_qty was recently turned into a compute but was missing
readonly=False so scraps created from scratch were stuck on a scrap_qty
of 1.
X-original-commit: e2a2a6e2526446b6f8d041135a4e5653fa96bb47
Part-of: odoo/odoo#104900
currently odoo is allowing to create a scrap order record with 0 quantty, which doesn't make sense and also if it is allowed, user wont be able to edit change the quantity later. currently zero quantity is not blocked by _check_positive_qty_done on stock.move.line. And it doesn't make sense to scrap 0, thus preventing the same by raising a validation
closesodoo/odoo#105752
X-original-commit: eb899fe8dda12d0f0e4ae515bb01e65981f4fbcd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create a product and complete a sales order.
- Then try to change the product type.
- The following message is shown:
"You cannot change the products type because it is already used in sales orders."
However, we can close the message and save.
Problem:
If some sales were already made, it should not be possible to change the product type.
There is a warning message on the onchange but it's not blocking.
This causes inconsistencies between the quantities and value shown in the quants and in the valuation layers.
Solution:
Raise an user error when trying to save the changes.
opw-3000886
closesodoo/odoo#105496
X-original-commit: 1b468ad100960cbd6940a24fbfaeeae4f01994de
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
I do not see a good reason why height, width, length are integers.
It has been introduced in 2015 here: 2ff3749064https://github.com/odoo/odoo/pull/9994
Having float is better : it's allow more expressiveness and is less prone to errors for our users.
closesodoo/odoo#85268
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Commit ef1cadce3c58d702b9e63e2102b72172e45c486f introduced the
inventory_quantity_auto_apply field used in inventory report.
The stock.quant create method can return an existing record.
In inventory report, updating an existing record do the job.
But adding an already existing record to the list creates an inventory
adjustment with no visual clue that the adjustment has to be applied.
closesodoo/odoo#101894
Task: 2961768
X-original-commit: 1e07d8e2bfe3d4f5e07fed8e96226ab1fdbf390b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
When a warehouse is renamed, associated route's name shall be renamed accordingly.
As previously, the call to 'route.write()' in method '_update_name_and_code' was done after the 'super().write()',
there was no way to remember the old name of the warehouse, and the 'replace' was so uneffective.
The effectivenes of the replace is reestablished by doing the 'super().write' after the call to '_update_name_and_code',
however, it breaks the method '_get_sequence_values' because it expects the name and code to be already written.
That's why the optional parameters 'name' and 'code' are added to this last method.
Task : 2985735
closesodoo/odoo#102968
X-original-commit: 3ebb80828f2d0bc15dd53c594c07bc374cc5be8d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Use case to reproduce:
- Create a new db
- Go to warehouse and create a new one.
Expected behavior (same than enable location options from settings):
- Internal location has been enable
- It's possible to create locations
It happens because during the warehouse create call, the multi warehouse
and multi locations groups are set. However `res.config.settings`
contains a hook on `set_values` that enable some views and internal
location. Write directly on the groups won't go throuhg this code.
closesodoo/odoo#102913
X-original-commit: 6f965fa75d3cf4283482f597712010d09044736f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Make operation type a title.
Change description of some fields in General tab.
closesodoo/odoo#102703
Task: 3004014
X-original-commit: 2cc799edc58f96009c0323e0871e077339967557
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Quantity done will be always editable. Different use case:
1. If there is not location/package/tracing/owner -> same behavior than
before
2. If the details are needed:
- Immediate transfer. In case of increase the quants are reserved and the
`qty_done` on `stock.move.line` is increased depending the reservation.
If the quantity couldn't be fully reserve then default `stock.move.line`
are create (depending the putaway rules or multiple ones if the products
are tracked). In case of decrease, the quantity reserved are unreserve
but the `stock.move.line` are not unlink until the validation.
- Planned transfer. The quantity done will fill the reservation. If the
picking is not assign, it will reserve the quantity needed. In case of
decrease, it will only unreserve the extra quantity (compare to the
initial demand). To unreserve the quantity bellow the intial demand, the
`stock.move.line` could be unlink or use the `unreserve` button.
force_qty in `_action_assign` is needed because we don't reserve only
base on the initial demand (`product_uom_qty`) but sometimes on the
quantity_done.
In order to never block the user. The action_show_details is always
available. If the id is not available, it will save and open the record
(we take the record based on the new existing line with same product
and highest id).
closesodoo/odoo#102738
Task-id: 2960983
X-original-commit: cacc677a08066bc23e1c89df36027599d05f2a08
Related: odoo/enterprise#32555
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install sale_ebay,
- Some accounting localization
- Go to currencies and check the box saying it can be use with eBay
- Go to attributes and create two of them
- Create a product
- Put the attributes
- Go to the eBay tab of the product
- Put fixed price to the listing type field
- try to check one of the product variant
Current behavior:
Error:
Database fetch misses ids ((<NewId origin=3>,
<NewId origin=4>) and has extra ids ((3, 4)),
may be caused by a type incoherence in a previous
request
Expected behavior:
No error
Explanation:
In this situation the product_variant_ids are newID
and we can use only read on their origin record.
opw-2974596
are a
closesodoo/odoo#102655
X-original-commit: 7e998f225096ab03c60c1cdeffc2f17a795b37de
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
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>
Move the sanity check from the `button_validate()` outside so it can be
run premptively in a different context.
Basically it allows batches to run the santiy_check as a whole. This
means that when the function checks if there is at least one quantity
done to check only those move_lines for the lot/serial numbers, it is
now able to check the pickings independantly from each others like
before, but also as if they were a single entity.
This can avoid this weird behavior in the following batch :
Picking | product_name | qty | done_qty
--------|----------------|-----|---------
Pick_1 | product_1 | 2 | 0
Pick_1 | product_serial | 1 | 0
Pick_2 | product_2 | 2 | 0
Setting a done_qty on product_1 would be fine to validate the batch,
since at least one done_qty would be found within Pick_1. But setting a
done_qty on product_2 would raise an error for missing serial numbers
since then no done_qty would be found within Pick_1.
This commit evens the behavior of the sanitizer in this case. While
keeping the way it works outside of a batch validation.
Task-2971346
X-original-commit: 3a3b5d90d58339f65b1db0b52a2c81e02b5a3f17
Part-of: odoo/odoo#102382
When duplicating a location, it is currently confusing to know if we're
now updating the duplicate or the original.
Adding a (copy) to the `name` after a duplicate will make it easier to
know which location we are currently updating.
Part of task-2985735
closesodoo/odoo#102244
X-original-commit: 177c50076e175a1d607a9aae87aee8307709f71c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@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
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Due to a last minute request we add this store to handle a difference
between the quantity done and the `stock.move.line` sum. The remaining
of the feature (mainly javascript) should arrive soon. We do it at this
time since the previous fixes also add a store attribute, and the user
on existing deployed server will only face once the issue.
closesodoo/odoo#101905
Task: 2960983
X-original-commit: 05a2e5b7b9af58eea931dd9d80c506186e4131a8
Related: odoo/enterprise#32172
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since that commit: dd7f4d501a4d23b04a1899be8fd51cc583673c9d
A picking type cannot make the scan of the source location mandatory if
the scan of the destination source is optional.
An error is raised in case the user tries to edit and save a picking
types with this erronous config but there is also an issue if the user
tries to set the outgoing shipments in 2 or 3 steps.
The method `_create_or_update_sequences_and_picking_types` was the cause
of this issue because of an `update` on the `stock.picking.type`.
We try to update `restrict_scan_source_location` to "mandatory" and
`restrict_scan_dest_location` to "no" for the pick operation, the issue
is with `update`, each field is write one by one, and so, it will write
on `restrict_scan_source_location` first while `restrict_scan_dest_location`
is still set on "optional".
To fix that, we replace the `update` by a `write`.
closesodoo/odoo#101663
X-original-commit: 07fb4af8c68ae1296e796c2f3714823ed828e680
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Suppose a product P with an available quantity equal to 1. Suppose a
user writes on an existing SML for that product and sets the reserved
quantity to 2. When writing on such a field, `StockMoveLine.write` tries
to reserve the same quantity on the quants. If it fails (which would be
the case here because there is only one P available), the reserved
quantity of the SML is reset to 0 (and so does the reserved quantity of
the quant).
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L301-L313
However, there is an issue: the incorrect reserved quantity is still in
`vals`. As a result, later on in the method, this incorrect value is
written on the SML:
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L362
This creates an inconsistency: a SML affirms that 2 x P are reserved
while the reserved quantity of the quant is 0. Moreover, when marking
the SML as done, it will lead to a "unreserve more than..." issue.
OPW-2936689
closesodoo/odoo#100858
X-original-commit: 2ea52bbcdbc2beaac916fa5f127ffc0ab2650708
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Purpose of the task is to be able to click on inventory adjustment
history and do a reverse adjustment by using `Revert Inventory` action.
`Revert Inventory` action is available in Inventory Adjustments > History
and Product Moves > select some lines > actions dropdown. This
method creates a new move that reverts the quantity (including negative
values) with prefix `[reverted]`.
TaskID - 2859490
closesodoo/odoo#95720
Signed-off-by: Tiffany Chang <tic@odoo.com>
Because `quant_ids` (`stock.quant.package`) is a one2many inverse of
`package_id` and some depends use it.
It is important to have in index on package_id on `stock.quant`
closesodoo/odoo#100371
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commit [1] made it so the computed stock_location.warehouse_id field is
stored. Unfortunately it did not correctly add the additional depends
value of `location_id` so when this value is changed after the record
has been initially created+saved without a location_id, the warehouse
will never be correctly computed.
[1] https://github.com/odoo/odoo/commit/9978bcb366d0ea48ed25a7891e0c7653a2f96bfb
Followup to task: 2882539
closesodoo/odoo#100219
Related: odoo/upgrade#3901
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
savepoint do a flush that throw the current context and then recompute
the stored field (with a random matching context from the transaction).
In the case of qty_to_order, it will call qty_forecast and then
_compute_quantities on product.product.
Currently it will call _compute_quantities with a mix of self.env.context
(from the transaction) and a context generated from the orderpoint (with
deterministic data). But sometimes in the context took from the
transaction it could remain some other key used by _compute_quantities
(e.g. warehouse_id). Since qty_to_order doens't depends from context
it should not use self.env.context and only use the deterministic
context from the stock.orderpoint
closesodoo/odoo#100150
X-original-commit: 79694a88978ebc1213d6ba0ac0dcc59640f16d04
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
If `_merge_moves_fields` is called with a recordset of several SM, and
if there are more than one `self.picking_id`, the method will trigger a
`ValueError` (Expected singleton)
OPW-2861605
closesodoo/odoo#100087
X-original-commit: d3924054437cb2add044f51a3c03346a67f24674
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).
We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL
"product moves" part of b2b task: 2882539
closesodoo/odoo#97109
Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Adds a new reporting view for [storable] product.product to allow for
easier analysis by product (rather than by quant which is location
specific).
This includes:
- adding 3 new fields for products:
- avg_cost = total svl value / total qty
- total_value = avg_cost / on hand
- company_currency_id = self.env.company.currency_id (i.e. the
currently selected company) for which currency symbol to display in
the view
- IMPORTANT NOTE:
- these variables (and some of the existing ones) do NOT support
multi-company aggregations due these values being used to calcuate
future svls which should be company specific. Larger refactoring
would be needed to ensure correct calc in both cases. Larger issue
occurs in stock.report which uses these variables in combination
with variables that do take into account multi-company records.
- A customized `SearchPanel` so that a warehouse context can be applied
to the view, rather than a filter. (viewable only when more than 1
warehouse)
"stock report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
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
Note this includes the view shown when clicking on:
- "History" button in inventory adjustments
- "Product Moves" button in scrap/product forms
- "Reporting" > "Moves History"
At time of this commit being written. Other move line views not changed
since they are specific to inputting data rather than readonly data.
Minor UX updates to stock move lines report:
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated + src/dest location filters replaced with
generic filter that checks if either meets condition
- add src/dest package to list view
- add status, lot, and from/to dest to kanban view and replace picking
with reference so inventory adjustments are visible as well
- order by date desc so most recent ones are first
- always display location src/dest to help understanding of moves
Specific to "History" button in Inventory Adjustments / Reporting >
Locations (i.e. inventory report), moved product_id from domain to
default_search for more user analysis flexibility/ease.
"product moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Minor UX updates to stock moves report:
- don't default groupby source location
- order list by date
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated
- make to location_{dest_}id text-muted when not a physical location
(i.e. internal/transit)
- display "Quantity" instead of "Demand" for product_uom_qty and show
sum at bottom of list
"stock moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
niyasraphy