* This commit adds an easy access to products and variants from the app switcher / root menu, similar to what exists for contacts.
* Move an action to view stockable products to stock, as it is only executed from stock.
1) Configure the warehouse "Your company" to pick-pack-ship operation
(you'll need to activate the advance route on WH config + set up the
correct process through the warehouse configuration wizard.
2) Create a SO with a product (on stock) and confirm it
3) Display the deliveries, you'll have 3 : pick, pack, ship
4) Take the pick, force availability if needed, and confirm it
5) Return the pick and validate (e.g. imagine you missed something like
puting the lot, so you want to reverse the pick).
6) Go back to the SO, click to view the deliveries
7) You create another, new, pick here (which is correct). Take it and
confirm it.
8) Look at the pack => his state is "Waiting another operation"... This
is not good ! We should have it "Ready to transfer" (now "Available")
because we just (re)confirm the pick operation.
Odoo don't know he should make the next operation (pack) available.
This additional administration group was formerly used to hide
the configuration menuitems for the common users.
Being manager should be enough to access these items
The customer address must be the shipping address defined on the SO.
The contact address can be removed from the report because the object
passed to the report is the stock.picking where the partner_id is the
one linked to the shipping contact.
opw:669015
- Separate group_stock_multiple_locations into 2 groups:
o group_stock_multi_locations
o group_stock_multi_warehouses
- Add a selection fields to manage the 3 levels of warehouses management complexity:
o Manage 1 WH with 1 location
o Manage 1 WH with multi locations
o Manage multi WHs with multi locations
- Display the menuitems and fields accordingly
- On a company creation : Create a related Warehouse
- stock.location : Add a helper on the parent location
- stock.warehouse : Add a helper on the company_id field
Lead times are too advanced for most of our online users. Most of the companies just
buy and sell and don't manage scheduling. As an example, when they do MTO, they
purchase the same day they sold.
The problem with current lead time is that users don't understand the dates produced
on delivery orders and receptions. They even have receptions in the past, and they
don't understand why. (customer lead time default to 7 and vendor lead time to 1,
as well as security days, ...)
Could incorrectly rename the stock.location.path objects, and in case
the route has push_ids but no pull_ids would crash the method entirely.
closes#10747
* It is sometime useful to be able to set the package type and the package weight during the delivery
* These fields can be edited during the 'put in pack' operation or after, with a button in the view
* As the weight is computed, a new field 'shipping_weight' has been added
* These fields (package type and weight) will be used in the delivery carrier for the shipping
* Packaging types are now handled in a centralized way for all shippers
The system cannot create two inventory adjustements in state 'in Progess'
with the same product, with the same location, same package, same lot and
same owner.
Example:if two adjustments(ADJ1, ADJ2) are created with the same product(P)
and with the same location(L), let's say:
qty_available for P is 10
in ADJ1: Theoritical Quantity=10 and Real Quantity=20 => a quant with +10 is created
in ADJ2: Theoritical Quantity=10 and Real Quantity=30 => a quant with +20 is created
When ADJ1 is validated then qty_available for P is now 20(that 's ok)
When ADJ2 is validated then qty_available for P is now 40(that's wrong because
the Real Quantity is expected which is 30)
This is why this fix is required.
opw:660658
The system cannot create two inventory adjustements in state 'in Progess'
with the same product, with the same location, same package, same lot and
same owner.
Example:if two adjustments(ADJ1, ADJ2) are created with the same product(P)
and with the same location(L), let's say:
qty_available for P is 10
in ADJ1: Theoritical Quantity=10 and Real Quantity=20 => a quant with +10 is created
in ADJ2: Theoritical Quantity=10 and Real Quantity=30 => a quant with +20 is created
When ADJ1 is validated then qty_available for P is now 20(that 's ok)
When ADJ2 is validated then qty_available for P is now 40(that's wrong because
the Real Quantity is expected which is 30)
This is why this fix is required.
opw:660658
Srushti Patel