Repository navigation
[FIX] purchase_stock_ux: cancel remaining on subcontracted lines - #384
fw-bot-adhoc wants to merge 2 commits into
Conversation
|
|
|
@ced-adhoc @mav-adhoc cherrypicking of pull request #377 failed. stdout: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?).
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
you can use
|
@ced-adhoc @mav-adhoc this forward port of #377 is awaiting action (not merged or closed). |
5ff85cf to
c60a116
Compare
Cancel remaining on a subcontracted line raised "Nothing to check the availability for." and left the order unusable, with nothing or part of it received. Lowering product_qty makes core create a negative move that nets against the pending receipt and empties it. mrp_subcontracting then calls action_assign() on that receipt in _action_confirm(), and the receipt has no open move left. For subcontracted lines, cancel the open receipt moves before lowering the quantity, so no negative move is created. Cancelling the receipt cancels the subcontracting MO and, through its procurement group, the resupply transfer. Ordering the quantity again creates a new MO with the current BoM. propagate_cancel is turned off first, as core does when it nets the negative move, so a customer delivery fed by the receipt is not cancelled. If the subcontractor already recorded production on the MO, stop with a message instead of cancelling it and losing what was recorded: the user receives what was produced or cancels the MO first. With a refunded return the line keeps the previous flow: there the negative move does not empty the receipt, and cancelling first would make core create a new receipt and MO for the returned quantity. Other lines keep the current flow. The filter of open moves to cancel moves to _get_remaining_moves_to_cancel(), used in both places. Change note: Al usar "Cancelar remanente" en una línea de compra de un producto subcontratado, con nada o parte recibido, Odoo mostraba el error "No hay nada para lo que comprobar disponibilidad" y la compra quedaba sin poder modificarse. Ahora se cancelan la recepción pendiente, la orden de subcontratación y el reabastecimiento al subcontratista. Si después se vuelve a cargar la cantidad, se genera todo de nuevo con la lista de materiales vigente. La entrega a un cliente que dependa de esa compra no se cancela. Si el subcontratista ya registró producción, se avisa para recibir lo producido o cancelar esa orden de producción antes de cancelar el remanente. X-original-commit: 395ee69
c60a116 to
2685dbb
Compare
|
Se retira del forward-port |
|
El resguardo de producción registrada queda inerte en 19.0: el core borró Importa porque El resto del port lo revisé y está bien. |
The cancel remaining guard relied on a helper and a flag that do not exist in 19.0 (subcontracting_has_been_recorded is never written), so it never stopped and the subcontracting MO was cancelled together with what the subcontractor recorded. Use the state of the MO instead: progress or to_close.
|
@roboadhoc r+nobump |
|
@ced-adhoc @mav-adhoc because this PR has multiple commits, I need to know how to merge it:
|
|
Found while forward-porting this change to 20.0: a purchase manager without manufacturing access gets an Steps (reproduced on 20.0, same code path in 19.0 by reading, not run on 19.0):
Result: The tests of this PR run as superuser, so they do not catch it. In 20.0 we fixed it by running the check and the cancel of the subcontracted moves as superuser (the MO belongs to the subcontractor, not to the buyer): if subcontracted_moves:
# The MO is the subcontractor's: a purchase user may not have manufacturing access
subcontracted_moves = subcontracted_moves.sudo()with a test that runs |
Ticket: https://www.adhoc.inc/odoo/helpdesk.ticket/129539
Qué pasa
En una línea de compra de un producto subcontratado, con nada o parte recibido, "Cancelar remanente" falla con
Nothing to check the availability for.y la compra queda sin poder modificarse: la recepción, la orden de subcontratación y el reabastecimiento al subcontratista quedan abiertos con la lista de materiales vieja.Por qué
Al bajar
product_qty, core crea un movimiento negativo que se compensa contra la recepción pendiente y la deja en cero. Después,stock.move._action_confirm()demrp_subcontractingllama aaction_assign()sobre esa recepción, que ya no tiene movimientos abiertos, y lanza el error.Qué cambia
Solo en líneas subcontratadas, se cancelan los movimientos de recepción pendientes antes de bajar la cantidad, así no se crea el movimiento negativo:
propagate_cancel, igual que hace core al compensar el negativo (_clean_merged), para no cancelar una entrega a cliente que dependa de esa recepción (MTO con la regla de Comprar propagando la cancelación);_get_recorded_subcontract_production()), el botón frena con un mensaje: recibir lo producido o cancelar esa orden antes de cancelar el remanente. Así no se pierde lo registrado sin aviso;Las líneas que no son subcontratadas siguen igual que hoy; la compensación general del movimiento negativo la resuelve
stock_ux(oba_features.net_negative_moves). El filtro de movimientos pendientes a cancelar pasa a_get_remaining_moves_to_cancel(), que se usa en los dos lugares.Tests
En
test_cancel_remaining.py(se saltean si no están instaladosmrp_subcontracting/sale_stock):test_subcontracted_cancel_remaining_nothing_received(recepción en 1/2/3 pasos): no hay error; se cancelan la recepción, la orden de subcontratación y el reabastecimiento; al volver a cargar la cantidad se usa la lista de materiales nueva. Con el código anterior falla con el mismo error.test_subcontracted_partial_receipt_cancel_remaining(1/2/3 pasos): se cancela lo pendiente y su orden, y se conserva el tramo interno de lo recibido.test_subcontracted_recorded_production_blocks_cancel_remaining: con producción registrada, el botón frena y la orden sigue viva.test_subcontracted_refunded_return_cancel_remaining: con devolución con reembolso no se crean recepciones ni órdenes de más. Falla sin la condición nueva.test_subcontracted_cancel_remaining_keeps_sale_delivery(1/2/3 pasos): la entrega al cliente no se cancela. Falla si se saca el resguardo depropagate_cancel.Corrí en local toda la suite de
purchase_stock_ux(14 tests) en verde. Además probé, fuera de los tests del PR, compra para una venta con recepción en 1/2/3 pasos y entrega en 1/2/3 pasos, con nada y con parte recibido, y compras con varias líneas: sin error y sin cancelar la entrega al cliente (con el código anterior, 21 de esos escenarios daban el error).Pendiente de verificar en runbot: que los tests no se salteen por falta de
mrp_subcontracting/sale_stocken el build.Forward-Port-Of: #377