Call super on overridden `_prepare_sellers` method in
purchase_requistion.
Closes#31649
opw-1963883
closesodoo/odoo#32470
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In described Modules, there are some fields label like Unit of measure, Discount,
Ordered Quantity, etc... in views(list,form), report and portal, that are messy
and barely readable when lots of features are installed.
Purpose of the task is to shorter that all fields label to make clean view in
order to make it more readable without getting labels uselessly spread out on
several lines
Related to task #1933746Closes#31962
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This widget does not exist anymore since the merge between the all widgets
(new view refactoring).
closesodoo/odoo#31643
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When creating a new PO from a purchase requisition, the order date of
the PO is the last date of the contract. There is no reason for this,
and althoguh the date can be manually changed, it is error-prone.
opw-1937141
closesodoo/odoo#31969
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
uom_po_id is the 'Purchase Unit of Measure' and is required so should be used
here.
This way, the onchange matches the behaviour of purchase module or the reset of
the purchase_requisition code
closesodoo/odoo#29717
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Improve the procurement requests performance. Instead of processing
procurement request one by one, search rules that apply for each of
them and group them by rule's actions.
The main technical change is the record creation order.
E.g. 2 SO lines with pick ship delivery.
-Before this commit:
line1 -> LAUNCH_RULE -> PICK MOVE1 -> MOVE1 CONFIRM -> OUT MOVE1
line2 -> LAUNCH RULE -> PICK MOVE2 -> MOVE2 CONFIRM -> OUT MOVE2
-After this commit:
line1/2 -> LAUNCH RULE -> PICK MOVE1/2 -> MOVE1/2 CONFIRM -> OUT MOVE1/2
Also there is one batch creation by company_id. It implies that values
are group by company_id. Since company_id are passed by previous
procurement or by the rule, it become a required value and it's added to
the procurement arguments (it was already always passed in the values,
no functional modification).
_run_buy is reworked. It receives a bathc of procurements, those
procurements could be merged in the same PO or the same PO lines.
However the PO/PO lines are created (if procurement couldn't be
merged in an existing one) at the end of the method. It implies
that 2 procurements creating a PO and merged inside, would now create
2 distinct PO (same for po lines). _run_buy in order to fix this issue:
- group procurements by PO search domain. If the PO doesn't exist,
create only one.
- Inside the same PO: merge quantities, move_dest_ids for procurements
with the same product and UoM.
Other _run_ methods are just adjusted in order to process batch.
For a pick pack ship scenario, without procurment_jit confirm a SO
containing 500 lines will take 40s instead of 15 minutes.
Purpose of the task is some demo data values are not matching with the products
mentioned so update the demo data values with matching product.
Task: 1892754
closesodoo/odoo#28573
In a multi-company environment, the creation of a purchase requisition
fails in a company with ID != 1 because of an empty name.
This is because the sequence is created for the company with ID = 1
only.
opw-1941552
closesodoo/odoo#31153
Before the fix we were requiring for product.supplierinfo.requisition_id
which is a non existing field of the model 'product.supplierinfo'. I
just change it then to purchase_requisition_id which is the required
field.
This triggered an error when you add a product selled by the defined
vendor for an aggreement type defined as 'Blanket order'.
opw-1914712
closesodoo/odoo#29342
Usecase to reproduce:
- Enable 'Managers must approve orders'
- Set agreement type as 'exclusive'
- Connect as purchase user
- Create a requisition and an RFQ linked to it
- Confirm the RFQ
It raises a usererror that ask to close other PO linked
to requisition.
It happens because the purchase requisition code do not take
care of double validation on PO. It will try to close the requisition
once button_confirm is called. However it will only write 'to approve'
on PO state and thus trigger the requistion error will be raise since
all linked PO are not 'done' or 'cancel'.
In order to fix it, the action_done on requisition should be call
on button_approve instead of button_confirm. (button_approve is
automatically called when double validation is not enable).
Task: #1884410Closes#28068closesodoo/odoo#29049
Christophe Simonis