As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
Purpose:
========
A blanket order (it's an agreement with a vendor) is not a call for tenders (you aks several vendor to provide you an offer) but they are regrouped under the category "Calls for tenders" in the Settings of Purchase which should be changed .
Specification:
==============
- Change the setting option for 'Call For Tenders'
- Change 'Purchase Requisitions -> 'Purchase Agreements'
If the data is available in the current context it should be passed to
_select_seller. The calls to _select_seller throughout the lifetime of a
purchase should be consistent (as possible) or the result of
_select_seller could be inconsistent when dealing with multiple sellers
(product_supplierinfo).
Modify a few signature of private methods to pass available information.
Closes#11414
To be triggered on the fields that are used inside the computed field.
Was not very problematic before as the fields were not stored and recomputed
at each modification. It could be backported if needed.
Next commit will store these fields for performance reason, fixing the trigger
first is required.
Linked to #15259
When seller_ids are set on a product with a Minimal Order Quantity(MOQ),
the function _select_seller didn't get the ordered quantity so the
sellers with an MOQ were never selected.
opw:704856
This function is only used in purchase_order_change and order_id is a required field
in a purchase.order.line. So this fix has no impact on stable version.
But now it s more generic.
opw:705105
When the quantity of a purchase order line is manually decreased and if
the purchase order line as been generated by more than one procurement.
If the new quantity is lower than the quantity of the smallest
procurement, it is impossible to validate the picking containg the
stock_moves created by the purchase order validation.
It is impossible to validate the picking, because it contains
stock_moves with 'product_qty' set to 0. Those stock_moves are generated
during the validation of a purchase order.
To fix this issue, we avoid the creation of stock moves with a
'product_qty' set to 0 which has no sense.
The field `purchase_count` is described as '# Purchases' (which is an
integer), so the user should expect the number of POs associated to the
product, not the quantity ordered as it is the case before this commit.
opw-697815
There was several issues with this method:
- the workflow is incorrectly called (`purchase.signal_workflow(...)` instead)
- the workflow no longer exists (`purchase.state = 'sent'` instead)
- the code is only triggered when sending an actual mail and not a notification
- the code is never executed as the change is already changed
The last point is due to the override of `send_mail` in mail.compose.message.
The state is changed before `_postprocess_sent_message` is called (if called at
all).
Similar change of state is already done for sale.order.
This commit replaces and closes#14760
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
=======
Purpose
=======
There are some confusion about the use of the vendor price and the cost price.
Moreover, in the purchase app, the RFQ should take the variant vendor price, if one is set
==========
Specification
==========
Add a clear tooltip on the Cost field (standard_price) : "The cost price is used for valuate stocks or to asses the price of manufacturing a product. The purchase orders are fetching the vendor prices."
In the simplified view, add the vendor cost o2m : https://drive.google.com/a/openerp.com/file/d/0BxqHe5rtIxY0LVZHZXFWcWFHckk/view?usp=drivesdk
Variant vendor prices should be indenpendant from each other, and from the template ones.
In the purchase app, when creating an RFQ : the system fetches the variant cost price (from vendor o2m), if no price on variant, it takes the vendor price on template.
NB: fp request
When we enable in the settings 'Get 2 levels of approvals' with a
'Double validation amount', and then create a request for quotation.
When we confirm it, even if the total amount of the request for
quotation is below the amount set in the settings, the purchase order
needs to be approved.
We excpect that if a purchase order has a total amount below the
validation amount setting, the purchase order is automatically
confirmed.
So to fix it, we compare the amount when the user click on the button
confirm. And immediatly call the function 'button_approve' if the amount
is below the double validation amount set in settings.
Bug introduced in rev: https://github.com/odoo/odoo/commit/9d4efc81a
opw - 694381
This reverts commit cbc760acb8.
The reasons we put the product name and description is in the SO line:
- users want to be able to change the description in the printed quotation
- product is in user lang, description+product_name is in customer lang
That commit breaks what was a good behaviour
- sale: Improvement in quotation/so line's description
Currently, quotation/so line's description shows product's name with description.
It should show only description of product if description is there else show name of the product in backend views.
- sale: show product with description in sale report
Due to change in description of quotation/SO line, sale report is affected. Fixed it.
- website_sale: show only description in cart lines
Due to previous commit, cart lines shown with product and it's description as a quotation/so line's name.
When we create order from frontend, quotation/so lines' name field takes product name and it's description.
It should only take description if description is there else product name. Fixed it.
- purchase: Improvement in RFQ/PO line's description
Currently, RFQ/PO line's description shows product's name with description.
It should show only description of product if description is there else show name of the product in backend views.
- purchase: show product with description in purchase report
Due to change in description of RFQ/PO line, purchase reports are affected. Fixed it.
Set the company rounding policy to "Round Globally". Create the
following SO (or PO), with a 7 % excluded tax:
- Qty Price
- 880.000 5.79
- 120.000 4.36
- 28.000 2.88
- 68.000 11.09
- 35.000 5.20
- 35.000 5.32
The total tax on the SO is 477.48, while it is 477.50 on the invoice
generated from the SO.
Fixes#13687
opw-690090
In procurement form view display a Purchases stat button that redirects to
the purchase order. It opens the PO form view. Note that Purchase Order field
in Extra Information is left untouched. It is just a shortcut to ease
usability.
When increasing the amount on a confirmed purchase order line,
an extra move is created in the incoming picking.
When the purchase creates the moves in the picking on confirmation, it takes into account
the procurements that triggered the purchase order and creates a move for every procurement.
This is necessary in order to make the next steps ready.
With this commit, when you increase the quantity, it will take into account the amounts of moves
already created for a procurement and not link the new move with a procurement if not necessary.
This case can be tested by confirming the PO with less than foreseen by the procurements and increasing
the amount afterwards. (which is more of a corner case, but it is good to do things right)
Dhaval Panchal