The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
Divide "Delivery"/"Incoming Shipment" smart button of "Sale"/"Purchase"
order form between normal "Delivery"/"Incoming Shipment" and a
"dropship" picking.
Also clean a little bit technically
task-2486811
Part-of: odoo/odoo#75041
Allow to produce several serial numbers at once.
Only when BoM do not contain any component tracked by unique serial number
and lot ones are from 1 lot.
Also allow to copy/paste serial numbers.
This applies to manufacturing orders.
Task: 2444742
Part-of: odoo/odoo#71732
When you want to obtain `dropship_picking_type`, it is possible to have
several results. This will lead to an error when doing
`dropship_picking_type.id`.
```
dropship_picking_type = self.env['stock.picking.type'].search([
('company_id', '=', company.id),
('default_location_src_id.usage', '=', 'supplier'),
('default_location_dest_id.usage', '=', 'customer'),
])
```
The fix ensures that `dropship_picking_type` contains only one element.
closesodoo/odoo#61256
X-original-commit: 3e3b1b335ced1ff20129172e6a7b2b0dcbe1a20d
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Same issue than for commit 203bb4d9c11 but for dropship rules instead of
missing dropship types.
closesodoo/odoo#59629
X-original-commit: 1372cc427e9946b3f6ba81b4e895b145468092a2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In the function `create_missing_dropship_picking_type()`, the way to
search companies that already have dropship picking type was not robust
enough as it used the translatable `name` field in a search domain and
the ORM `search` method used the translated value of `Dropship` name value
instead of the raw value.
A better approach is to search `stock.picking.type` with a default source
location usage set to `supplier` and a default destination location usage
set to `customer`.
Related to upgrade request: #54154closesodoo/odoo#59142
X-original-commit: 203bb4d9c113f5c24ad00d39e2ae46b4689117f4
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Due to a typo, dropshipping sequences were created twice. We created a
"stock.dropshipping" sequence if no "stock.dropshippping" sequence was
found.
closesodoo/odoo#47908
X-original-commit: 021268734a5857f47cda5991fbd28abdd41f512a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In order to improve the navigation between of SO and PO in the case of
MTO, add a direct link between PO<->SO. When the SO is confirmed
(with storable product(s) with MTO + buy),
PO is/are generated, in this case, add a stat button on each model form
to avoid to manually search the related SO with the source field (name).
task-1913392
Move the method `_prepare_purchase_order_line` from 'stock.rule' to
'purchase.order.line'. The purpose is to reuse it in approvals_purchase.
task-2040710
closesodoo/odoo#41046
Related: odoo/enterprise#6702
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Now that company_id is required on the picking type, make sure we create
as many dropship picking type/rules/sequence as there are companies
task-1985992
Selling a product you don't have in stock anymore triggers a message
without pertinent information about available quantity.
This commit adds a little widget on sale order line to inform the salesman
there are not enough quantity available. Clicking on it will reveal:
* The estimated delivery date
* The actual quantity on hand
* The quantity forcasted at the estimated delivery date
For kit product, the quantities are the maximum occurence of kit available
regarding components quantities.
Task 2003485
closesodoo/odoo#34336
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Fine tuning of commit b9e3c153, for the same use-case.
The route may not be passed in values, in which case the bug is still present.
There are two ways to go around that.
We could add the stock.rule in values, which contains the route.
The solution we adopt here is to use the sale_line_id field on the purchase line
If it is present, it was added through _prepare_purchase_order_line,
and thus we want to keep track of the origin.
opw 1957701
closesodoo/odoo#32683
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Create a SO with a dropship product, set a qty of 1.0
- Validate the SO
- Validate the corresponding PO
- Change the qty to the SO to 2.0
2 PO are created: the first one with a qty of 1.0, another with a qty of
3.0.
There is an overlap of functionality between:
- `_purchase_increase_ordered_qty` from `sale_purchase` (first PO)
- `_action_launch_stock_rule` from `sale_stock` (second PO)
The quantity is incorrectly computed since the quantity on the PO is
taken into account only if the no stock move exist.
We remove the latter condition, so the procurement quantity is computed
correctly.
opw-1950076
closesodoo/odoo#31963
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Only search once for batch of moves that should be assign
to the same picking and assign them all at once.
Since the moves are processed in batch for a picking
commit 8fe8ca9 is not needed anymore.
closesodoo/odoo#30699
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.
- Create a SO with 2 lines of the same product (set route as Drop Ship)
- At validation, both lines are merged into a single line in the PO
As a result, one SO line will be over-delivered, and the other
under-delivered.
Two lines should be kept in the PO.
opw-1928702
closesodoo/odoo#30800
- Set a vendor on Product A
- Create a SO with 1 Unit of A, set the Drop Ship route
- Confirm the SO
=> a PO with 1 Unit is created
- Change the oredered quantity to 2
The PO is updated with a total quantity of 3 instead of 2.
Since the removal of procurements, the quantity is computed based on the
stock moves. However, in this case, no stock move has been created since
the PO is not yet confirmed.
In this specific case, we fall back on the PO line quantity. The logic
is similar to `_quantity_in_progress`.
opw-1879118
This commit adds a new module providing the automatically services
purchasing feature ("Service Subcontracting").
The product of 'service' type can be flag (in the purchase tab of
its form view) as "purchase automatically".
When adding an sale order line with that kind of product, it will
generate a Purchase Order for the supplier of the product, on Sales
Order confirmation. The PO will contains one line with the quantity
on the sale line, with the UoM conversion (purchase uom might be
different from the sale uom on product configuration). The generated
PO is in draft state.
Then several cases can happen:
1/ Increasing the quantity on the sale line
- If PO is draft state ('draft', 'sent', 'to approve') : increase
the quantity on the PO
- If PO is confirmed state ('purchase', 'done', 'cancel') : create
a new PO
2/ Decreasing of quantity on the sale line
- in any cases: shedule a next activity on the PO
3/ Cancelling SO: shedule a next activity on the impacted PO
4/ Cancelling PO: shedule a next activity on the origin SO
The introduction of this module required to move the link between
sale.order.line and purchase.order.line from stock_dropshipping to
thie module, and put sale_purchase as a dependency of
stock_dropshipping.
This commit also brings some test cases.
Task #39340Closes#25221
Previously mrp, stock and purchase used _run methon on procurement
group and start with a if checking for the action type. This commit
instead launch a specific method depending the rule's action's type
Also _run method and their submethod used in procurement group
was always called with a rule. Thus we choose to move this method
on the rule object himself.
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
This effectively reverts the patch 7bdd4de that was made on 8.0 then reverted by 001610e (in 8.0 too) but each of them manually forward ported to 9.0, except that the forward port of the last one forgot to remove the faulty commit.
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.
The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).
This is a forward-port/cherry-pick of 7bdd4de805
William Henrotin