Usecase to reproduce:
- Product with routes MTO and BUY
- Add a supplier on a product with a min qty of 5
- Create a SO with a qty of 1
A PO is created with the supplier and a quantity of 1. It should return
an error since there is no suppliers that sell with this quantity.
It happens because _run_buy directly use the suppliers on the product
without check for date and minimal quantity.
This commit replace it by _select_seller that manage every details.
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 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.
Display product picking,receipt or delivery description depending
the picking type. The purpose is to display usefull information/note at
the right place at the right moment.
This commit is related to task ID : 1880135
closesodoo/odoo#28175
The reference is not copied to the invoice move because the invoice needs the move to get the
right number and then, we need the invoice number to compute the reference.
So, this commit is required to copy the reference to the move after the invoice validation.
/!\ DO NOT FORWARD-PORT!
This behavior has been already fixed in 12.1 but with too much refactoring for a stable branch.
closesodoo/odoo#29391
property_cost_method is removed from product.product and product.template.
And use property_cost_method of product.category everywhare.
In This -
Used property_cost_method of product.category instead of cost_method or property_cost_method of product.template.
This commit is related to task#1866333.
Usecase to reproduce:
- Install a database with demo date and mrp or purchase
The buy/manufacture rules have a wrong company for warehouses
in company 'My company, Chicago'
It happens because the warehouse is not specify in the create
values. In this case it creates the rules and set the user current
company as default.
This commit specify the company during the create call.
closesodoo/odoo#28682
Usecase to reproduce:
- Create a product with a vendor and mto/buy route checked.
- Create 2 SO and confirm them
The system generated 2 RDF instead of a single with 2po lines (same than
v11). It happens because the propagation option of buy rules is
leave empty in v11 and Propagate in v12. It was unintentionally removed
by commit 1e160dffd3
This commit set leave empty as default value for buy rules.
opw-1904165
closesodoo/odoo#28637
Non deductible taxes (ones without an account set), increase the target
account of the product.
In case of a inventory operation, this means the inventory account.
To reflect this stock valuation wise, we need to calculate this incremented
values and rely on it during the inventory move price calculation.
This commit does exactly that.
The received quantity on Purchase Order line can be compared
to the delivered qty on Sales Order line. It is now time for
both to share the same mecanism (introduced in
3bf8a62e0d).
This commit sets `qty_received` as a computed field, depending
of a method (`qty_received_method` field) to compute it. The
value can be computed based on
- manual value; for services (all the time), and consummable
products (when stock is not installed).
- stock moves; for stockable and consummable products (when
stock is installed)
This is now easier to extend the way the received quantity
need to be computed (like in sale).
Task #1850689closesodoo/odoo#27663
Before this commit, when the user chose to not make a backorder, a backorder was created then immediatly canceled.
This behaviour is now changed as in such a case the backorder is simply not created anymore
- Create a product sold by Dropshipping
- Create a SO, validate
- Validate the corresponding PO
- On the picking, print the 'Picking Operations' or the 'Delivery Slip'
There is no delivery address printed.
The root cause of the issue is that the field `dest_address_id` of the
PO is empty. This is because `partner_dest_id` is not used anymore since
1e160dffd3.
opw-1892990
closesodoo/odoo#27850
It's not needed to see the many2many of PO and SO during the create and
edit since the lot could not be already sell or buy during its creation.
Task 1909002
closesodoo/odoo#28817
When creating a warehouse with purchase app installed, it will
traceback since the route_warehouse0_buy is referenced in a wrong
module.
closesodoo/odoo#27523
Arnold Moyaux