Skip to content

[FIX] account_payment_pro: sync amount when all to_pay lines are removed - #1054

Open
jjscarafia wants to merge 1 commit into
ingadhoc:19.0from
adhoc-dev:19.0-h-115891-jjs
Open

[FIX] account_payment_pro: sync amount when all to_pay lines are removed#1054
jjscarafia wants to merge 1 commit into
ingadhoc:19.0from
adhoc-dev:19.0-h-115891-jjs

Conversation

@jjscarafia

Copy link
Copy Markdown
Member

Contexto

Alternativa al #1049 (FW directo de #1040 a 19.0).

En 19.0 ya existe _onchange_to_pay_lines_adjust_amount (introducido en a2c84339, parte de #1000) que también triggerea por to_pay_move_line_ids. El FW #1049 agregaba un segundo onchange _onchange_amount paralelo, lo que genera dos efectos:

  • Orden de ejecución no determinístico entre los dos onchange. Cuando hay líneas con tasa distinta de la del día, según cuál corra primero queda abs(to_pay_amount) + diff_in_a o abs(to_pay_amount) (perdiendo el ajuste por tasa que el refactor de 19.0 t 64401 rov #1000 vino a aplicar).
  • Naming engañoso (_onchange_amount triggerea por líneas, no por amount) y falta de filtro state == 'draft'.

Approach

Consolidar el caso del ticket dentro del onchange existente, con dos ramas según haya o no líneas:

  • Sin líneas: si amount quedó stale respecto de abs(to_pay_amount), sincronizar. Cubre el caso del ticket #115891 (proveedor AFIP/SICORE: borran todas las líneas de deuda, sin retenciones, y el importe quedaba con el valor anterior).
  • Con líneas: lógica existente intacta — ajustar amount por payment_difference a la tasa de hoy.

Un único onchange como fuente de verdad sobre to_pay_move_line_ids → amount. Sin solapamiento.

Test plan

  • Crear pago a proveedor en 19, agregar líneas de deuda, borrarlas todas → amount pasa a 0.
  • Crear pago desde factura con tasa distinta a la de hoy → amount se ajusta por diff_in_a (regresión del refactor 19.0 t 64401 rov #1000 — debe seguir andando).
  • Caso mixto: agregar líneas, después borrar algunas → amount se ajusta por payment_difference.
  • Pago en company sin use_payment_pro → onchange no hace nada.

Referencias

@roboadhoc

Copy link
Copy Markdown
Contributor

Pull request status dashboard

skywardodoo pushed a commit to skywardodoo/account-payment that referenced this pull request May 12, 2026
…ayment_bundle: apply upstream fixes from PRs ingadhoc#1055, ingadhoc#1054, ingadhoc#1051, ingadhoc#1049

- account_payment_pro_receiptbook: enforce receiptbook prefix in _get_next_sequence_format
  (PR ingadhoc#1055): replaces previous _get_last_sequence_domain approach; now detects prefix
  mismatch after _get_last_sequence() and falls back to direct SQL filtered by correct
  sequence_prefix, preventing PAY-prefixed orphan sequences from propagating.

- account_payment_pro: sync amount when all to_pay lines removed (PR ingadhoc#1054); add
  _onchange_amount to keep amount in sync with to_pay_amount on line changes (PR ingadhoc#1049).

- l10n_ar_payment_bundle: wrap action_post unlink/validation in for-rec loop and filter
  draft_linked by parent non-draft state to fix batch posting (PR ingadhoc#1051).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Extiende `_onchange_to_pay_lines_adjust_amount` para cubrir el caso en
  el que se remueven todas las líneas de deuda (sin retenciones), donde
  `amount` quedaba stale respecto de `to_pay_amount`.
- Mantiene la lógica existente de ajuste por `payment_difference` cuando
  hay líneas y diferencia por tasa de hoy.
- Evita un segundo onchange paralelo sobre `to_pay_move_line_ids`
  (alternativa al PR ingadhoc#1049, que introducía solapamiento de orden no
  determinístico con este onchange).

**Change note:**
Al quitar todas las líneas de deuda en una orden de pago, el importe
del pago ahora se actualiza a 0 (o al monto pendiente sin reconciliar)
en lugar de quedar con el valor anterior. Antes este caso solo se
corregía manualmente por el usuario.

Closes-Same-Issue-As: ingadhoc#1049
Related-Ticket: 115891
@cav-adhoc
cav-adhoc force-pushed the 19.0-h-115891-jjs branch from 3d8d5a1 to 5766c78 Compare May 29, 2026 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants