This fixes the problem of recomputing that field in a much better way. The
field was stored for the sake of searching; instead we implemented a search
method for it.
In the earlier fix 327f88df, the computation of the amount crashes when the
field `tax_id` is not set. Simply add an 'if' statement to avoid that case.
Case 1: To check schedule date of picking and manufacturing order,
- Configure lead times:
- At a product level set Manufacturing Lead Time and Customer Lead Time
- At a company level set Manufacturing Lead Time and Sales Safety Days
Case 2: To check schedule dates of pickings and manufacturing order,
- Configure lead times:
- At a product level set Manufacturing Lead Time and Customer Lead Time
- At a route level set delay of pull rules
Detailed Use Cases
==================
CASE 01 :
========
(Consider order date : 2016-04-18 11:10:44)
Create Product
--------------
Name : Product A
Product type : stockable
Manufacture : True
Make To Order : True
Manufacturing Lead Time : 5 days
Customer Lead Time : 5 days
Configure your company data
---------------------------
Manufacturing Lead Time : 3 days
Sales Safety Days : 3 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 10
Confirm this SO
Run scheduler
Result
------
Manufacure Order :-- Schedule date : 2016-04-12 11:10:44
Delivery Order :-- Schedule date : 2016-04-20 11:10:44
CASE 02 :
========
(Consider order date : 2016-04-18 11:10:44)
Create Product
--------------
Name : Product A
Product type : stockable
Manufacture : True
Make To Order : True
Manufacturing Lead Time : 5 days
Customer Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Outgoing Shippings : Pick + Pack + Ship
Routes
------
YourCompany: Pick + Pack + Ship
Procurement Rules:
------------------
WH: Output -> Customers :-- Delay : 2 days
WH: Packing Zone -> Output :-- Delay : 2 days
WH: Stock -> Packing Zone :-- Delay : 2 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 5
Confirm this SO
Run scheduler
Result
------
Manufacure Order :-- Schedule date : 2016-04-14 11:10:46
Delivery Orders :--
PICK :--> Schedule date : 2016-04-19 11:10:46
PACK :-> Schedule date : 2016-04-19 11:10:46
OUT :--> Schedule date : 2016-04-21 11:10:46
Case 1: To check schedule date of picking,
- Configure lead times:
- At a product level set Customer Lead Time
- At a company level set Sales Safety Days
Case 2: To check schedule dates of pickings,
- Configure lead times:
- At a product level set Customer Lead Time
- At a route level set delay of pull rules
Detailed Use Cases
==================
CASE 01 :
========
(Consider order date: 2016-04-18 05:34:00)
Create Product
--------------
Name : Product A
Product type : stockable
Customer Lead Time : 5 days
Configure your company data
---------------------------
Sales Safety Days : 3.00 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 10
Confirm this SO
Result
------
Delivery Order :-- Schedule date : 2016-04-20 05:34:00
CASE 02 :
========
(Consider order date: 2016-04-18 05:34:00)
Create Product
--------------
Name : Product A
Product type : stockable
Customer Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Outgoing Shippings : Pick + Pack + Ship
Routes
------
YourCompany: Pick + Pack + Ship
Procurement Rules:
------------------
WH: Output -> Customers :-- Delay : 2 days
WH: Packing Zone -> Output :-- Delay : 2 days
WH: Stock -> Packing Zone :-- Delay : 2 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 5
Confirm this SO
Result
------
Delivery Orders :--
PICK :--> Schedule date : 2016-04-17 05:34:28
PACK :-> Schedule date : 2016-04-19 05:34:28
OUT :--> Schedule date : 2016-04-21 05:34:28
Case 1: To check order date of purchase order and schedule dates of shipment and purchse order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a company level set Purchase Lead Time
Case 2: To check order date of purchase order and schedule dates of multiple purchase order line of the same purchase order,
we create two procurements for the two different product with same vendor and different Delivery Lead Time
Case 3: To check order date of purchase order and schedule dates of shipments and purchase order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a route level set delay of push rules
Detailed Use Cases
==================
Consider today's date = 2016-04-21 ( date_planned of procurement = today's date + 10 days)
CASE 01:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Configure your company data
---------------------------
Purchase Lead Time : 3.00 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 15.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-23 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 02:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Create another Product
----------------------
Name : Product B
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 2 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 10.00
Planned Date: 2016-05-01 00:00:00
Procurement Request for second product
--------------------------------------
Warehouse : YourCompany
Product : Product B
Quantity : 5.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-26 00:00:00
Schedule date of purchase order line for product A: 2016-05-01 00:00:00
Schedule date of purchase order line for product B: 2016-04-28 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 03:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Incoming shipments : three steps
Routes
------
YourCompany : Receipt in 3 steps
Push Rules:
-----------------
WH: Input -> Quality Control :-- Delay : 2 days
WH: Quality Control -> Stock :-- Delay : 2 days
Create Procurement:
-------------------
Product : Prosuct A
Quantity : 5.000
Warehouse : YourCompany
Procurement Location : WH/Input
Schedule date : 2016-05-01 10:30:43
Notes : 'Test scheduler for RFQ'
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-05-01 10:30:43
Order date: 2016-04-26 10:30:43
Incoming shipments schedule dates :--
In type :-- 2016-05-01 10:30:43
Internal type 1 :-- 2016-05-03 10:30:43
Internal type 2 :-- 2016-05-05 10:30:43
- Hide life_time, use_time, removal_time and alert_time if tracking = no tracking
- Change the tooltip of these fields(life_time, use_time, removal_time, alert_time)
- Add filter 'Expiration Alert' on the Lot/Serial Number list view based on the lot/sn alert date
- Add a tag 'Expiration alert' when the alert_date is reached.
Currently all delivery methods are published after module installation. But if none is published we have an issue processing the checkout.
Free of charge : published by default
The other ones : unpublished by default
Grant the ability to publish delivery methods from the website for those who
have the access rights, in that case to sales manager with publication access rights.
Use the previous commit to display small buttons
To be able to have publish buttons for the website of adaptable sizes.
example:
<t t-call="website.publish_management">
<t t-set="btn_class" t-value="'btn-group-xs'"/>
<t t-set="object" t-value="delivery"/>
<t t-set="publish_edit" t-value="True"/>
</t>
Purpose
=======
On a stock stock.quant.package form view, the "Package Transfer" button does not have any filter, it opens all the pickings
Clicking on "Package Transfer" button should display its related pickings
Before, the '_set_quantity_listener' function was opening a 'window.prompt'
which had different comportment depending the navigator. For example,
the focus was not allways on the input field, the enter key 'Cancel'
the prompt or 'validate' it.
So to improve the usability and the consistancy we used a dialog instead
a prompt, to manage the focus and the 'Enter' key pressed when we want to
set a quantity.
The field was a stored computed field without dependencies, and therefore it
was never (re)computed. Add a simple dependency on the model `ir.model.data`
to make the recomputation everytime a view is modified. Moreover, when views
are created from modules, delay the recomputation of view fields until their
`ir.model.data` record is created.
When the user clicks on the stat button to access the partner invoices,
the invoices are not displayed.
This is because the domain is wrong.
Fixes#13883
When a account statement is validated, it's not possible to cancel a statement line.
To cancel a line from a validated statement, you must first reset to new the statement.
In this way, it's not possible to have a validated statement with unreconciled lines.
opw:690766
On a PO linked to a purchase tender, changing the quantity on a PO line
will trigger a recompute of the unit price. However, this recomputation
will take into account the unit price of the supplier pricelist, not the
unit price on the purchase tender.
opw-690483
When the purchase tender of a PO refers to a blanket order, the price
unit used to create/update the order lines doesn't take into account the
potential difference of UoM.
When returning an item by entering an orderline with a negative quantity
you got a warning message asking you to confirm a large payment
amount. Introduced by 5a3d9ce9ce.
Closes#13777
If you validate an order it will be sent to the backend. If you then
close the POS frontend somehow before clicking 'Next order' this order
will be reloaded from localStorage when reopening it. This is
problematic because it allows the user to then modify this order and
validate it again. Everything will appear fine but in the backend this
new, modified order will be ignored as it has the same pos_reference as
the one that was sent initially.
The deeper underlying issue is that there exists a brief timeframe where
the same order can exist twice in the db: both as 'order' and
'unpaid_order'. To ensure this does not happen this fix removes the
order from the unpaid orders after it is saved as a validated order.
Fixes#13538
Mansi Gandhi