[FIX] purchase_stock_ux: only count returns of the line product in qty_returned - #371
fw-bot-adhoc wants to merge 1 commit into
Conversation
…y_returned
_compute_qty_returned() iterated over every move of the line, so a
return was counted even when it belonged to a product that is no longer
the one on the line. When a wrong product is received, returned to the
vendor marked to refund, and then corrected on the same purchase order
line, that return was subtracted from what is left to bill for the new
product: qty_to_invoice dropped to 0 and invoice_status became
'invoiced' with nothing actually billed, so the vendor bill could not be
created ("There is no invoiceable line").
Iterate over _get_po_line_moves() instead, which filters the moves by
the product of the line. It is the same helper the core uses in
_compute_qty_received(), so both quantities are now built from the same
set of moves. A return of the product that is on the line keeps being
counted, so the refund case is unchanged.
Add move_ids.to_refund to the depends as well: the flag is what decides
whether a move counts as returned, and without it correcting the flag
left the stored qty_to_invoice and invoice_status untouched.
Signed-off-by: les-adhoc <les@adhoc.inc>
X-original-commit: 889d8a3
|
|
|
@les-adhoc @mav-adhoc cherrypicking of pull request #370 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 
|
@les-adhoc @mav-adhoc this forward port of #370 is awaiting action (not merged or closed). |
|
El forward-port automático quedó con conflictos sin resolver por la divergencia 18.0/19.0 en |
3 participants
Qué pasa
_compute_qty_returned()recorre todos los movimientos de la línea, sin filtrar por producto. Si se recibe un producto equivocado, se lo devuelve al proveedor marcando "Para abonar", y después se corrige el producto en la misma línea de la orden de compra, esa devolución se descuenta de lo que queda por facturar del producto nuevo:La línea queda en
invoice_status = 'invoiced'sin nada facturado, y la factura de proveedor no se puede crear: "No hay líneas para facturar". El estado no se puede revertir desde la interfaz, porqueto_refundsolo es editable en el asistente de devolución, antes de validarla.El cambio
Recorrer
_get_po_line_moves(), que filtra los movimientos por el producto de la línea. Es el mismo helper que usa el core en_compute_qty_received(), así que las dos cantidades pasan a construirse sobre el mismo conjunto de movimientos.Una devolución del producto que sí está en la línea se sigue contando: el caso de devolución con nota de crédito no cambia.
Se agrega también
move_ids.to_refundaldepends. Ese flag es el que decide si un movimiento cuenta como devuelto, y sin él corregirlo dejaba intactos los campos almacenadosqty_to_invoiceeinvoice_status.Cómo probarlo
purchase_stock_ux/tests/test_qty_returned.py:test_return_of_replaced_product_not_counted— reproduce el caso: recibir A, devolver A con "Para abonar", cambiar la línea al producto B. Esperaqty_returned = 0y la línea facturable. Sin el fix falla conAssertionError: 10.0 != 0.test_return_of_same_product_counted— no regresión: la devolución del mismo producto de la línea sigue contando (qty_returned = 10,qty_to_invoice = 0). Pasa con y sin el fix.Verificado en 18.0: con el fix
0 failed, 0 error(s) of 2 tests; revirtiendo solo el cambio del modelo,1 failed.Nota para el review
Los campos
qty_to_invoiceeinvoice_statussonstore=Truey no dependen deto_refund, así que las órdenes ya bloqueadas no se recalculan solas al actualizar el módulo. Queda a definir si esta corrección merece un script que fuerce el recómputo de las líneas con devoluciones.Forward-Port-Of: #370