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
Purpose is to ease understanding of applications / categories and their
links with the access rights labelling.
This commit is related to task 1884968 and PR #29176.
Create data for all tests in order to speed data test creation. We don't want the test to be demo data dependent
What we are testing in this test case.
-> Check that procurement is creating requisition with correct details or not.
-> Check that purchase order created is consistent when we create it with supplier info.
-> Two blanket orders on different 'make to order' products must generate two different purchase orders.
Task ID : 1851286
closesodoo/odoo#30187
The purpose of this commit is to make requisition usable with only services. Stock part is extracted in a new module `purchase_requisition_stock` which allows to create requisition based on product availbility or demand, also
we have moved all security access related stock in this bridge module.
Task ID : 1851286
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
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
This commit simply move code into the right file.
The goal is here to fit the guidelines and prepare
the module for some changes. This will ease the
reading of module code.
Task-1851286
closesodoo/odoo#28795
Steps to reproduce the bug:
- Create a product : stockable + purchase : propose a call for tenders + reordering rule (qty min 0, max 0, multiple 1)
- Create a SO for that product.
- Run the scheduler once : a requistion is generated (Purchases > Purchase > Purchase Agreements), which is normal behavior
- Run the scheduler a second time
Bug:
A new requistion was generated for the same product, by the same reordering rule
opw:1892950
closesodoo/odoo#28611
payment_term.id, creates a tuple wich works if payment_term.id is set
in case payment_term.id is False this creates the tuple (False,) which
is then converted by the Odoo ORM to a account.payment.term(False, )
record set, which in term may cause weird behaviour as this value does
not eval to false in cases like `if self.payment_term_id:`
Closesodoo/odoo#28397
Arnold Moyaux