Steps to reproduce the bug:
- Let's consider a consumable product P with an internal note IN in Dutch
- Create a SO with dutch partner P and confirm it
- Process the delivery and validate it
- Print the delivery slip
Bug:
The internal note IN was displayed on the delivery slip.
The internal note must never appear on a delivery slip.
opw:2227613
closesodoo/odoo#50689
X-original-commit: 4b8d9806c6ee0a85812041f25080617daa7b10f1
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create a product P with 10 units on hand
- Create a SO with 5 units, validate
- Create another SO with 5 units, validate
- Update the quantity on hand to 8
The picking linked to the first SO as 2 units unreserved, while one
would expect the unreservation on the second picking.
When unreserving, sort the move lines according to the picking scheduled
date. The latest schedule date comes first.
opw-2233331
closesodoo/odoo#49830
X-original-commit: 41c05cbfb015407dbbf7100233999ecd154267dc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Set the padding on the write for date. Modify the text to be consistent
with the manual and automatic orderpoint. Explains the min, max
and quantity to order mechanism.
closesodoo/odoo#48536
Task: 2161378
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Allow to set a BoM or a vendor on an orderpoint. In this case it's
passed to the values and will be processed by _run_buy and
_run_manufacture to use them.
Task: 2161378
Technicaly it's anoying to create orderpoint and explicitely
set the product_min and product_max to 0.0. If another value
should be use, it would probably not be forgotten.
Task: 2161378
Set a default route on orderpoint created by the replenishment report.
First it select the first route on the product if it exists (it's
uselss since it's a preferred route on the report but it's used for
clarity). If the product has no route then it tries to guess it
with vendor pricelist or BoM on the product.
Task: 2161378
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
_search_rule on procurements search in a specific way in this order:
- First: route passed in the procurement values
- Second: route on product/product category
- Third: route on warehouse
- Fourth: remaining route.
However _get_rule doesn't allow to simulate the first usecase with
the route on procurement. This commit add the functionality.
(Usefull for replenishment report where a route_id could be set
on an orderpoint)
Task: 2161378
Use `float_compare` to avoid the usual float representation comparison
errors.
opw-2215497
closesodoo/odoo#49702
X-original-commit: 500240874cd21c6950210968c8c7e8d84c1c4bee
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install Accounting(account_accountant), Inventory (stock)
1. Create a new user [DEMO] with the next access:
- Accounting: Advisor
- Administration: Settings
2. With the user [DEMO] , go to Accounting>Configuration>Settings
and change any value.
3. Try to save the settings.
Access error will occur "Sorry, you are not allowed to modify documents
of type 'Picking Type' (stock.picking.type)..."
This occur because when stock is installed an override in 'execute' make
the backend check for multi locations, packaging or tracking settings
and activate show_operation on stock.picking.type causing the access
error for unprivileged users
Calling the write with sudo solve the issue
opw-2233193
closesodoo/odoo#49555
X-original-commit: f560a9966dfbbacb259f0de74437743d1385d8a6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When computing `quantity_done` in an onchange, `move.id` is a `NewId`,
not an `int`. However, the `read_group` call returns regular integers
for `move_id`.
Consequently, `rec.get(move.id, [])` is an empty list.
closesodoo/odoo#49495
X-original-commit: 2ce1ed31a9c1ec7a7467983a040e4a056f8f4e69
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The generation of SN is incorrect with the following initial sequence:
`BAV023B00001S00001`.
Indeed, the sequence generated is: `BAV023B00001S`, `BAV023B00002S`.
This occurs because the same digits `00001` appear more than once.
opw-2230913
closesodoo/odoo#49408
X-original-commit: b3369bc230160d6cafec77eed0e756c6f1c576d9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Inventory > Configuration > Operation Types
- In Receipt, activate 'Show Detailed Operations'
- Go Inventory > Overview, click on 'Receipts'
- Create a picking, and in the 'Operations' tab add 5 units of a product
tracked by unique S/N
- Click on the + sign
- Set the First SN (e.g. TEST001) and Number of SN to 5, then Assign
Serial Numbers
Nothing appear in the Detailed Operations, and it's impossible to
validate the picking.
The stock move lines are created, but not linked with the picking.
opw-2230913
closesodoo/odoo#49383
X-original-commit: 55ffc3027d26a36fc390d5efefa2d743cdc3e09f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase : sell a mto/manufacture product. Confirm the sale order.
Cancel the delivery and the production then
duplicate the delivery.
- if the delivery was cancelled before the production, another
production is created.
- if the delivery was cancelled after the production, no other
production is created.
In the second case, the production cancellation will reset the procure
method of the delivery. The duplication will not trigger the mto
procurement.
This commit will override the procure method of each cancelled moves and
set it to `make_to_stock'. This way, we have the same behavior independently of the flow.
Task : 2212125
closesodoo/odoo#48366
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Rename warehouse of compagnies as following:
- YourCompany -> San Francisco
(WH) (WH)
- My Company (Chicago) -> Chicago 1
(MyCo) (CHIC1)
- Chicago Warehouse -> Chicago 2
(Chic) (CHIC2)
Also, can pass a default code through the context when create a new
company to set the `code` value when creating the default warehouse for
the newly created company.
Task #1970460
Currently when the warehouse is created the picking type are created
with a fixed barcode that contains the warehouse code. Later, a
warehouse's code modification will not impact the barcode on the
picking type. However when a company is created the warehouse is
also created with a default code. It's easier to modify all the
barcodes when the code is modified rather than update picking type
one by one. We expect users to setup warehouse configuation before
starting to customise its components so it should not be problematic
but it implies that a late configuration could impact small
configuration on locations and picking types.
Usecase to reproduce:
- Create Warehouse with code A -> Picking type sequence start with A/
- Set the warehouse's code to B -> Picking type sequence remains A/
- Set the warehouse's code to C -> Picking type sequence become B/
It happens because _update_name_and_code is called before the write and
it updates the picking_type's sequence with warehouse current name and
code.
This code adapts all business code instances of calls to
`resolve_2many_commands` and replaces them by calls to `new` which
returns a record-like object whose api is more familiar than the
`resolve_2many_commands` api.
Since trying to create a record in a grouped tree view has no effect
(previously that opens a new record in form view), this commit removes
useless dynamically added default group for the quant list view.
task-2217907
Related to b08e3d114a
Since the related commit, when a product has no available quantity, the
button "Update Quantity" and the stat button "Qty. On Hand" doesn't work
properly: the view doesn't find the default product(s) and doesn't adapt
the fields according to the product (for instance: serial/lot number).
To fix that, we need to take also all active product variants of the
template, even they have no available quantity.
task-2217907
- Install Purchase
- Activate multi-step routes, multi warehouses and packaging
- Create 2 wharehouses WH1 et WH2
- 'WH1: Receipts' and 'WH2: Receipts'
Show Detailed Operations: True
Pre-fill Detailed Operations: True
Move Entire Packages: True
- 'WH1: Internal Transfers'
Show Detailed Operations: True
Move Entire Packages: True
- Create a route 'WH1 -> WH2':
Applicable On WH1
Rule:
Action: Push To
Operation Type: WH2: Receipts
Source Location: Virtual Locations/Inter Company Transit
Destination Locaion: WH2/Stock
Automatic Move: Manual Operation
- Create a PO for 100 units of P1 and P2, validate
- Go to the picking, set 40 units done for P1 and P2
=> Put in Pack
- Set 60 units done for P1 and P2
=> Put in Pack
- Validate
- Create an Internal Transfer in WH1:
Operation Type: WH1: Internal Transfers
Source Location: WH1/Stock
Destination Location: Virtual Locations/Inter Company Transit
- Add the 2 packages previously created, save and validate
4 pickings are created in 'WH2: Receipts': 40 P1, 40 P2, 60 P1 and 60
P2. There should only be one picking with the 2 packages.
The issue is similar to 2d4a743600f4501bbbed60a063ea2a87f1bce075: the
`default_immediate_transfer` context key pollutes the creation of the
pickings.
opw-2197720
closesodoo/odoo#48038
X-original-commit: 6e5cfb62b43f0781c246e9a27259e63199203221
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
If you create a quant through the inventory mode of the list view and
you don't set a quantity, the quantity is null and the quant isn't
unlinked by _unlink_zero_quants.
Also consider null quantity as 0.
We don't have the issue for the reserved_quantity field since this one
is not nullable.
closesodoo/odoo#48005
X-original-commit: 08e428458aa545b3602c56b6866a447126cf8825
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
=======
PURPOSE
=======
Improve duplicated serial number message to show more information.
=======
SPEC
=======
In this commit, we show full information about all invalide product name
and lot/sn number when the user enters duplicated ones.
- Change the sql constraint for checking duplicate sn/lot to python
constraint to support customised error message.
- Create lot in batch to show all invalide ones in error message.
=======
LINKS
=======
task 2083605
pr #44366
Related: odoo/upgrade#954
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
PURPOSE
Keep consistent behavior of the stat buttons and the different stock
reports when archiving a product
SPECIFICATION
Currently, you can archive a product but the behavior of the different
stock reports, stat buttons isn't coherent afterwards. Here are the
different behaviors that should be improved:
1.Keep quantity on hand and forecasted quantity visible (in the stat
button + when opening it)
2.Automatically (un)archive RR and BOM if the product is (un)archived
3.Valuation report: show the archived products without the "archived"
filter (behaves already this way in the inventory and forecast reports)
4.When a product has been archived and still has quantity in stock,
include it in inventory adjustments for which counted quantity = default
to stock on hand (dont do so for archived exhausted products).
Also, revert #47478 since we don't have active field.
LINKS
Task 2178269
PR #45586Fixes#41634
Related: odoo/upgrade#811
Related: odoo/enterprise#8513
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Allow to propagate custom information to upper document. It could be
usefull in many buisness that do custom stuff for people
(t-shirt with user defined text, poster with own pictures...)
The customes values are pass throught procurements'values and are
display on MO or purchase order line.
Task: 1970476
Make it so documents auto-generated by other actions have Odoobot set as
the creator rather than the user triggering the action. This includes
the following documents:
1. Delivery (stock.picking) - generated by Sales orders (including MTO)
2. Purchase orders - generated by dropshipping, manual replenishment,
and run scheduler
3. Manufacturing orders - generated by made to order (MTO)
This is addresses specification 2 of overall usability improvement task.
Task: 2041853
- Install Inventory, Purchase
- General Settings/tick Multi-step routes
- In Warehouses/YourCompany
Incoming Shipments: Receive goods in input, then quality and then
stock (3 steps)
- Create a PO and add the same products on 2 lines. One has a scheduled
date in the future
- Go to transfers, where "Picking List" or "Procurement Group"
correspond to your PO
=> the 3 scheduled_date correspond to Datetime.now()
- Validate the first picking (WH/IN)
The scheduled_date (resp date_expected) in the remaining pickings WH/INT
(resp. stock moves) are changed to the past.
This is due to the fact that both moves are merged in subsequent
pickings. The cleanest solution would be to avoid the merge in case the
expected dates are different. Although this makes sense, that also
implies a change of behavior.
Therefore, we avoid such situation by preventing the propagation of an
expected date in the past, which does not make much sense when
propagating.
opw-2171509
closesodoo/odoo#47155
X-original-commit: c7b2341b35aabe394a34e14c48a913a8595737fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Adds a method to be able to override the error message in the case where
the user try to validate a picking with no quantities done nor reserved.
task-2123726
closesodoo/odoo#45457
Related: odoo/enterprise#8364
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a write on the active field is done, we only want to synchronize
this value to the locations downward.
Steps to reproduce the issue:
Import this file to update Stock Locations on a fresh runbot instance:
id,name,location_id,usage,active,comment
stock.stock_location_stock,STOCK,WH,internal,1,comment STOCK
Expected:
* The location "Stock" is renamed to STOCK with a comment: "comment
STOCK".
Before the correction:
* The location "Stock" is renamed to STOCK with a comment: "comment
STOCK".
* All the children locations of "Stock" are renamed to STOCK with the
same comment
closesodoo/odoo#46188
Opw: 2188690
X-original-commit: 02e7558b221461545ad881319433607b2ac4334c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a kit which contains a stockable product and a service
- Create a SO with the kit, validate
The service is included in the picking, while it shouldn't be.
The procurements only make sense for for consumable and stockable
products. Therefore, we do not run procurements for services.
opw-2201923
closesodoo/odoo#46175
X-original-commit: 30387a1a6e90adf760146591809ad141ff645187
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit set an index on column `picking_id` of table
`stock_move_line`. Many sql requests on stock_move_line
have picking_id in their where-clause.
On a database filled with 1M pickings, reading a picking of 10
stock_move_lines is 60 times faster.
Closes https://github.com/odoo/odoo/issues/44623closesodoo/odoo#46153
X-original-commit: a36a693733579e1e8bdaa3aa00fcc482c6299acf
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Missing part of #44947 of task 2160847
closesodoo/odoo#45922
X-original-commit: 367d236a974b1b726a770e58a03344a3d83fa49f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Activate multi-step routes
- Set Incoming Shipments: Receive goods in input, then quality and then
stock (3 steps)
- Create an Immediate Transfer from 'WH/Input' to 'WH/Quality Control'
- Add 2 products, set a quantity
- Validate
Two immediate transfers are created, one for each product, while a
single planned transfer is expected.
This is because the `default_immediate_transfer`i key is polluting the
context.
opw-2180556
opw-2197720
closesodoo/odoo#45843
X-original-commit: 74ad073fd66ca4ff345aaf37a7245a8b93808cb3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Goffin Simon